Hi, On Sat, 2004-02-14 at 11:36, Andrew Haley wrote: > JOnAS (http://jonas.objectweb.org/) is, as you may know, the Open > Source implementation by ObjectWeb of the J2EE(TM) specification. > > We're having trouble with running it. The basic problem is (quoth > Simon Nieuviarts) "because Carol is an improvement or a replacement of > RMI. As such, it needs to plug low in the ORB in functions that are > not intended to be exported to the end user. AFAIK, without the use of > internal classes you can not implement mechanisms like interceptors > which propagate transaction contexts." To do this, carol uses classes > in sun.rmi.transport.*. > > What I would like to do is define an interface in Classpath which > exposes the functionality that JOnAS needs. > > Trouble is, I know zip about RMI.
Good more interest in RMI. I know also almost zip about RMI, but I am sure when pulling some knowledge together we can get somewhere. Once upon a time the Orp developers got our RMI implementation working good enough to support JBoss. And I know the kaffe developers recently fixed up some little things to make a couple of standard RMI examples work on kaffe. Also Norbert Frese has been posting a couple of RMI patches on the gcj mailinglist <http://gcc.gnu.org/ml/java/2004-01/msg00022.html>, <http://gcc.gnu.org/ml/java-patches/2004-q1/msg00080.html>, <http://gcc.gnu.org/ml/java-patches/2004-q1/msg00081.html> and he made a RMI interoperability testsuite <http://www.scheinwelt.at/~norbertf/gcj/tests/>. Yesterday have been looking a bit at the Cajo project <https://cajo.dev.java.net/> which is a distributed object framework build on top of RMI. (John Catherina has been CCed since he might have some ideas and clearly knows more about RMI then most of us). Cajo stress tests RMI and Serialization a lot. And we do have some way to go before it works. Things I noticed that are currently broken: - Our rmic implementation doesn't seem to handle 'super-interfaces' correctly. This doesn't seem to be that hard to fix and can be easily worked around by implementing the 'super-interface' directly. - Our java.awt.Font serialization (which the main cajo example uses) is broken. Not hard to fix, but to make it compatible with other implementations might be hard since not everything is clearly documented. - When extending UnicastRemoteObject a object gets immediatly exported through its constructor which might be to early since then not all fields of the object are initialized. This looks like a harder problem to solve. BTW Florent Benoit from JOnAS will be at FOSDEM http://www.fosdem.org/index/speakers/speakers_benoit Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
