Up to now, the com.ibm.jscript.std.FunctionObject does not implement Serializable. In my opinion, when working with server-side JavaScript (SSJS) it would be very beneficial if it could be serialized. Since I'm no Java expert, I'd like to ask if there is a special reason why the FunctionObject does not implement Serializable, while other SSJS objects (like the ObjectObject) do. Will it never be serializable?
I suspect it's because FunctionObject is intended not as an SSJS version of a Java object but more as an SSJS version of a Java static class, so just a set of utility functions and so a single object per NSF. I doubt it will ever be serializable.
In my opinion SSJS is a limbo language for those getting started with XPages and coming from a Domino background. It allows easy access to Formula Language, global objects (like context and database), LotusScript-style Domino Object Model and client-side JavaScript-style libraries (e.g. i18n).
I think the expectation is that if developers are familiar enough with things like serialization and developing using objects, they are probably ready to go down the road of Java classes as managed beans or Data Objects, plus validators, converters, or even a full MVC model. That also leads the way to moving cross-database components and utilities out of the NSF and into an OSGi plugin or extension library. There are more and more examples of that on OpenNTF now.
Related
I am new to SPRING and was assigned to work on project currently under development. Unfortunately development of the project has been slow so people have come and gone so I cant ask them why some things were done a certain way.
The project is a web service using SPRING.
They are using a View - Controller - Service (interface & implementation) - DAO (interface & implementation) - POJO (class used to transport data structure across layers).
Every POJO I have checked implementations serialization. On closer examination and search of the code, none of the POJO's are ever written or read, either in the POJO itself or any other file. Which has lead me to ask why its being done.
The POJO's are populated from Oracle statements in the DAO, which bubble upto the view, and then will bubble back down to the DAO where they information from them are written to the database using Oracle statements. The POJO itself is not written into the database.
Does SPRING MVC or java web applications require serialization and it is being used in the background? Is it needed to transmit the data between server and client connections? Is there a good reason that all the POJO's are using it that someone new would not recognize?
Depends on technologies used in the layers as well as implementation details.
If persistence is done using JPA/Hibernate then POJOs most likely will need to be Serializable.
In case if the POJO is passed to view via servlet session and session replication is on then you need to have your POJOs Serializable.
Use of Java's default serialization is a normal way for regular POJOs.
Java specifies a default way in which objects can be serialized. Java classes can override this default behavior. Custom serialization can be particularly useful when trying to serialize an object that has some unserializable attributes.
This might not be the correct answer, but so far in my case it matches and explains what I am seeing. I have not seen this information mentioned else where, but the answer is well upvoted, has been around for awhile, and is from a high reputation user, so I am inclined to trust it.
There is an answer from another question where they mention something important.
As to the why you need to worry about serialization, this is because most Java servlet containers like Tomcat require classes to implement Serializable whenever instances of those classes are been stored as an attribute of the HttpSession. That is because the HttpSession may need to be saved on the local disk file system or even transferred over network when the servlet container needs to shutdown/restart or is being placed in a cluster of servers wherein the session has to be synchronized.
The application Im working on DOES use Tomcat, so if this is a restriction or behavior, then I can easily see why all the POJO's are created in this fashion, simply to avoid issues that might develop later, and is a result of experience having worked with this all before, and its that experience that I am lacking.
I am writing an application in Qt that I want to extend with plugins.
My application also has a library that the plugins will use. So, I need a 2 way communication. Basically, the plugins can call the library, and my application which loads the plugins will call them.
Right now, I have my library written in C++, so it has some classes. The plugins can include the header files, link to it and use it. I also have a header file with my interface, which is abstract base class that the plugins must have implemented. They should also export a function that will return a pointer to that class, and uses C linkage.
Up to this point I believe that everything is clear, a standard plugin interface. However, there are 3 main problems, or subtasks:
How to use the library from other languages?
I tried this with Python only. I used SIP to generate a Python component that I successfully imported in a test.py file, and called functions from a class in the library. I haven't tried with any other language.
How to generate the appropriate declaration, or stub, for my abstract class in other languages? Since the plugins must implement this class, I should be able to somehow generate an equivalent to a header in the other languages, like .py files for Python, .class files for Java, etc.
I didn't try this yet, but I suppose there are generators for other languages.
How am I going to make instances of the objects in the plugins? If I got to this point the class would be implemented in the plugins. Now I will need to call the function that returns the instance of the implemented abstract class, and get a pointer to it.
Based on my research, in order to make this work I will have to get a handle to the Python interpreter, JVM, etc., and then communicate with the plugin from there.
It doesn't look too complex, but when I started my research even for the simplest case it took a good amount of work. And I successfully got only to the 1st point, and only in Python. That made me wonder if I am taking the right approach? What are your thoughts on this.. maybe I should not have used Qt in my library and the abstract base class, but only pure C++. It could probably make the things a bit easier. Or maybe I should have used only C in my library, and make the plugins return a C struct instead of a class. That I believe would make the things much easier, since calling the library would be a trivial thing. And I believe the implementation of a C struct would be much easier that implementing C++ class, and even easier that implementing a C++ class that uses Qt objects.
Please point me to the right direction, and share your expertise on this. Also, if you know of any book on the subject, I'd be more than happy to purchase it. Or some links that deal with this would do.
C++ mangles its symbols, and has special magic to define classes, which is sort of hacked on top of standard (C) object files. You don't want your files from other languages to understand that magic. So I would certainly follow your own suggestion, to do everything in pure C.
However, that doesn't mean you can't use C++. Only the interface has to be C, not the implementation. Or more strictly speaking, the object file that is produced must not use special features that other languages don't use.
While it is possible for a plugin to link to your program and thus use functions from it, I personally find it more readable (and thus maintainable) to call a plugin function after loading it, passing an array of function pointers which can be used by the plugin.
Every language has support for opening shared object (SO or DLL) files. Use that.
Your interface will consist of functions which have several arguments and return types, which probably have special needs in how they are passed in or retrieved. There probably are automated systems for this, but personally I would just write the interface file by hand. The most important is that you properly document the interface, so people can use any language they want, as long as they know how to load object files from their language.
Different languages have very different ways of storing objects. I would recommend to make the creator of the data also the owner of the memory. So if your program has a class with a constructor (which is wrapped in C functions for the plugin interface), the class is the one creating the data, and your program, not the plugin, should own it. This means that the plugin will need to notify your program when it's done with it and at that point your program can destroy it (unless it is still needed, of course). In languages which support it, such as Python and C++, this can be done automatically when their interface object is destroyed. (I'm assuming here that the plugin will create an object for the purpose of communicating with the actual object; this object behaves like the real object, but in the target language instead of C.)
Keep any libraries (such as Qt) out of the interface. You can allow functions like "Put resource #x at this position on the screen", but not "Put this Qt object at this position on the screen". The reason is that when you require the plugin to pass Qt objects around, they will need to understand Qt, which makes it a lot harder to write a plugin.
If plugins are completely trusted, you can allow them to pass (opaque) pointers to those objects, but for the interface that isn't any different from using other number types. Just don't require them to do things with the objects, other than calling functions in your program.
I am current using Seasar2 Framework on a project that I am in. The framework is quite popular here in Japan but I am having problem in finding English documentations. Even on their official English translation site, they just discuss that the framework use Dependency Injection and AOP.
I was intrigued with the way they use it in one of their component S2Dao. Basically you only need to create interface DAO class and the framework automatically, changes the code on runtime and creates intermediate class that get called in the middle. Hence DB transactions codes are automatically added to the class. I was wondering, is there any step by step explanation on how this is done? Can java change code on runtime and change the method on runtime?
Are good reference on how this is done? I just want to know how the framework is doing this.
Yes, it is possible to do dynamic implementations of an interface at runtime, and to manipulate the compiled bytecode also.
Java provides a built-in mechanism to implement interfaces at run-time, called dynamic proxy classes.
There are also good libraries like cglib or javassist, that allow you not only to implement interfaces, but also to extend classes and to manipulate bytecode at run-time (to change the behavior of a method, for example). Frameworks like Spring and Hibernate use libraries like these to make their magic, so your framework may be using some of these also.
NOTE: If you are curious, these libraries can "tweak" the bytecode because instead of using the default ClassLoader of the JVM, they load your classes using their own ClassLoader, so they have total control of every single byte of the loaded class, and they can do whatever they want with them :).
I'm developing a webapp with Java backend and Flash (pure ActionScript) frontend using BlazeDS.
I'm using the RemoteObject stuff to send objects, using custom serialization, where I need to implement Externalizable (Java) and IExternalizable (AS) interfaces. This works fine so far.
But now I need to send objects from Java to Flash, whose classes are generated with JAXB/XJC. Of course these generated Java classes don't implement the Externalizable interface, so it seems that I can't use my approach here.
One possibility seems to be writing a XJC plugin which makes the classes implement Externalizable. But this looks like a tough job...
Does anyone have a good idea how to solve this problem?
A couple of options:
build a set of objects on top of your JAXB generated classes. I would choose this option.
build a proxy on top of your JAXB generated classes which will serialize/deserialize accordingly each object. If your objects are implementing the Externalizable interface you can use the Dynamic Proxy API from Java, no need for dynamic code generation
modify the blazeds distribution. I would stay away from it, but it is doable.
I finally developed a JAXB/XJC plugin. (If someone's interested, just contact me.)
Works fine now.
I'd like to add persistence to my Swing-based application; and this is the first time that I'm doing something like that.
I know how to use Java serialization APIs (though I'm using xstream instead), I know that JComponent's are serializable, but I'm interested in more architectural considerations: how an application should be designed so that making it persistent becomes easy; etc.
I'd be happy to see any sources with in-depth consideration of these issues, though I'd be also happy to hear some best practices explicitly :)
You should use a model-view-controller approach. You only serialize the model, not the view. The view should be populated from the model. Serializing Swing components is anyways not recommended at all:
While Swing components do implement the Serializable interface, they are not portable between different versions of the Java Virtual Machine
Looking at what you have, you should have some classes that are your model and have only data. These classes will be serialized using XStream somewhere. Your Swing Classes then have methods to receive these model classes and populate the fields and editors. You can then extend the UI, for example, without having to change the class, adding more funcionality, or provide different views for the same data set.
To make it fancier, the Swing Component should not store and load the model, but you should have a controller interface that you pass to the swing component to perform these operations. This way, you can unit test better and you decouple the storage logic from the view logic.
If XStream is correctly configured, and if you are careful about the model and the fields, it should be possible to add more fields to your model classes without breaking backwards compatibility.
I don't recommend using Java Serialization anyways, as it is not a good practice to use it for storage. Java Serialization excels at Remote Method Invocation. It is relatively fragile when the model classes change..
And the javadoc says (for instance on JComponent): As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.
So see XMLEncoder.
From architectural point of vue, this serialization work best with beans, collections, and the notion of default value. On beans, it save only properties beans with a different value than default value. (sorry for my english)
You can configure that as you want.