river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Date Sun, 27 Apr 2014 02:25:08 GMT
These classes are in jsk-lib.jar and jsk-dl.jar, in case the client doesn't have jsk-lib.jar
installed on the class path.

If classes resolved into the application class loader are reserialised, the application classloader
will not annotate the classes, they will only be annotated when sent via a service.

Mike Warres wrote a paper about it, should be available on the net, otherwise I can email
it to you.

This is where a new RMIClassLoaderSpi that uses Maven provisioning could be useful, we just
need to work out how to re-annotate classes from the application ClassLoader with enough information
for maven to resolve them.  File names can be obtained from CodeSource's for all classpath
classes.

Regards,

Peter.





----- Original message -----
>
> And actually, why shouldn’t they be resolved in the application’s class
> loader?   Isn’t an application possibly looking for a service with a
> given name or address?
>
> Cheers,
>
> Greg
>
> On Apr 26, 2014, at 8:28 PM, Peter <jini@zeus.net.au> wrote:
>
> > Dennis is right, these classes have snuck into jsk-platform.jar,
> > they're not in there in Jini2.1
> >
> > Because these classes aren't preferred, they'll be resolved in the
> > application loader, simply because they're present, annotated or not.
> >
> > ----- Original message -----
> > > Hi Dennis:
> > >
> > > I’m not sure I follow you - why would they not be annotated?
> > > jsk-platform goes in the application’s class loader, so either it’s
> > > annotated with a CodebaseAccessClassLoader or with the
> > > java.rmi.codebase property.
> > >
> > > Are you sure you’re not thinking of jsk-policy.jar?     That normally
> > > goes “one level above” the application’s class path (since it has to
> > > control the security), so wouldn’t get a codebase annotation.     But
> > > that jar only contains the policy provider.
> > >
> > > Cheers,
> > >
> > > Greg Trasuk
> > >
> > > On Apr 26, 2014, at 5:21 PM, Dennis Reedy <dennis.reedy@gmail.com>
> > > wrote:
> > >
> > > >
> > > > On Apr 26, 2014, at 254PM, trasukg@stratuscom.com wrote:
> > > >
> > > > > What is the rationale for inclusion/ exclusion ‎?
> > > >
> > > > Classes that are loaded by the system classloader never get
> > > > annotated with a codebase. These classses were in
> > > > jsk-platform.jar. The class in question are the net.jini.lookup
> > > > classes, they are service attributes:
> > > >
> > > > net/jini/lookup/entry/Address.class
> > > > net/jini/lookup/entry/AddressBean.class
> > > > net/jini/lookup/entry/Comment.class
> > > > net/jini/lookup/entry/CommentBean.class
> > > > net/jini/lookup/entry/EntryBean.class
> > > >
> > > > These need to be in jdk-dl.jar (which they were, but they would
> > > > never have a codebase since they were loaded by the system
> > > > classloader). Peter asked me to help him modularizing qa_refactor,
> > > > this was something I spotted.
> > > >
> > > > Dennis
> > >
> >
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message