Jonathan 3.0 : more information

[Bruno Dumant]

 
Dear all,

The CVS version has been in a very unstable version this morning. I sincerely hope no one has tried to get the new version... For some reason, some of the modifications I committed yesterday were commited on a branch while the others were commited on the main trunk. No idea what really happened. Nevertheless, the available version on the server is now usable, and is version 3.0 alpha.

Here is some more information about what has been done in this new version of Jonathan.

Best regards,

Bruno

Modifications in Jonathan 3.0 alpha

Contexts

The main modification is the introduction of a new configuration mechanism, replacing the properties and the static init() methods that could be found here and there in the code.

The new configuration mechanism is based on a new abstraction, the Context. A context lets typed names be associated with implementations. The main methods on contexts are very similar to the methods that could be found on Kernel : addElement, taking a name, a type and an object as parameters, lets a name be registered in the context, getElement, taking a name as parameter, returns the corresponding object, if any. These two operations, very similar to the previous export and bind operations on Kernel, are proposed with different signatures for a greater ease of use.

The main difference with the previous Kernel, is that contexts may be organised in a hierarchical structure : a context may have subcontexts, themselves having subcontexts, etc. It is thus possible to organise contexts in a graph or tree structure. This is reflected at the naming level, since a name may cross several contexts and subcontexts : if context C has a subcontext C' named c, and e is the name of element E in C', then E may be directly accessed from C using name "c/e". When contexts are organised in trees, then the concepts of parent context and root context are directly accessible using standard conventions :  ".." designates the parent contexts, "/" the root. Actually, the separator used is not imposed.

Another difference is that contexts may have scopes. A scope is itself a context : if context C is in the scope of context S, then all elements of S are seen as elements of C, except when an element with the same name exists both in C and S. This is very useful to inherit configurations, and used, for instance in IIOPORB.

Contexts are thus essentially an organised way to store information. The first use of this is in the configuration mechanism. Contexts make it possible to store typed information. To store this information in files, we could have kept properties with some naming convention. But it would certainly have been awkward. Instead, we now use XML files (...), with a simple DTD that lets us express more accurately the nature of contexts.

The DefaultProperties.prop file has thus been replaced by a Kernel.xml file (in the same directory). This file is compiled to Kernel.java, using a new XML2Kernel utility, based on the open source XML parser nanoxml (included in the distribution). The Jonathan.prop file is not supported any longer. We still support command line system properties definitions, but we'll certainly replace the Jonathan.prop by a Jonathan.xml file, since the XML format is more expressive.

Configuration  contexts don't simply contain objects : they usually have to contain factories that will be able to construct objects. This was already the case before, but we have tried to make this more explicit : we have introduced a new Factory type, and the XML configuration file now lets the user declare factories explicitly. A side-effect of this is that we don't resort any longer to the Java reflection apis to create objects, but just need to use the Class.newInstance() and Class.forName() methods. This should make porting Jonathan to specific JVMs easier.

Factories are now explicit in the code : many factory classes have been added, most of them inheriting from a GenericFactory abstract class (in org.objectweb.jonathan.libs.kernel). The code of the factories is now cleanly seprarated from that of the constructed objects. The GenericFactory mechanism also allows a better reuse of objects.

The "contexts" packages are renamed "binding"

The reason for this is very simple : it was not very natural to have Contexts implementations in "kernel" packages, and naming contexts in contexts. We thus decided to rename these packages binding. You may update your code and modifications using this kind of script :

flist=`find $1 -name '*.java' -type f -print`
for i in $flist

do

        echo $i

        sed -e 's/\.contexts;/.binding;/' $i > /tmp/sedout

        sed -e 's/\.contexts\./.binding./' /tmp/sedout > $i

done

flist=`find $1 -name 'Makefile' -type f -print`

for i in $flist

do

        echo $i

        sed -e 's/\.contexts;/.binding;/' $i > /tmp/sedout

        sed -e 's/\.contexts\./.binding./' /tmp/sedout > $i

done


Other modifications
Jonathan 3.0 contains very few other modifications : only some cosmetic
changes here and there.

Future plans
This version is still alpha : it passes all the tests, but other APIs should
change. In particular, we'll certainly replace all Object "hints" parameters,
and Object contexts associated with Marshallers by real Contexts.
In a different area,  protocols should be identified by some "Protocol
authority", playing the role of Domains for protocols. It will make sense
then to have encoding and decoding methods on protocols, and will be a
step towards dynamically specified protocol stacks and graphs.
These modifications should be available in a Jonathan beta version,
early in 2001. The final Jonathan 3.0 version should be released at the
end of the first quarter 2001.
--
*******************************************************************
Bruno Dumant
DTL/ASR
france telecom R&D
38-40 rue du général Leclerc
92794 Issy Moulineaux Cedex 9
FRANCE
mailto:[EMAIL PROTECTED]
tel: +33 1 45 29 46 03
fax: +33 1 45 29 66 04
*******************************************************************