You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2014/04/27 02:28:33 UTC
Re: svn commit: r1590276 -
/river/jtsk/skunk/qa_refactor/trunk/build.xml
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 <de...@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
>
Re: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Posted by Greg Trasuk <tr...@stratuscom.com>.
Discussion Intertwined…
By the way - just looked at the 2.2 branch that’s released, and jsk-platform.jar doesn’t appear to have the net.jini.lookup.entry classes - they’re only in jsk-lib.jar. So it looks like this issue is only on trunk/qa_refactor.
Cheers,
Greg.
On Apr 27, 2014, at 12:14 AM, Dennis Reedy <de...@gmail.com> wrote:
>
> On Apr 26, 2014, at 1114PM, Dennis Reedy <de...@asarian-tech.com> wrote:
>
>>
>> On Apr 26, 2014, at 839PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>
>>>
>>> But, so what? If they’re part of the platform, they’re supposed to be there in all Jini clients and services.
>>
>> Then why not put all the lookup attributes in the platform? Why not put all of jsk-lib.jar in the platform?
>> And why is this even an issue for you at all?
>
> Yeah, this came out kind of wrong (so did the previous few). You have questions on why this change was made, okay. Although I'm not sure why you don't understand that the result of the change aligns exactly with the current jar structure and contents of jsk-platform.jar (except for the additional work that Peter has added). The classes in question were added as an oversight, and were corrected with a one-line fix.
>
> If you take a look at the current state of affairs in how River services are created, you end up with a classloader hierarchy that looks like this (ascii art, hope the formatting works):
>
> SystemCL
> |
> +
> +-------+-------+----...---+
> | | |
> Service-1CL Service-2CL Service-nCL
>
>
> SystemCL - Contains start and platform classes
> Classpath: start.jar, jsk-platform.jar, jsk-resources.jar (and other required jars needed to bootstrap)
> Codebase: none
>
> Service-nCL - Contains service specific implementation classes.
> Classpath: serviceImpl.jar, jsk-lib.jar
> Codebase: serviceX-dl.jar jsk-dl.jar
>
> This is the current state of affairs in River started services, where you typically have a multi-service environment, and setting of java.rmi.server.codebase is not applicable. You can certainly create an über jar that includes jsk-platform, jsk-lib, and have all classes in River resolved by the system classloader. I'm not sure thats what you want (or maybe it is?). If this were the case, then only service-specific download classes would end up being in the codebase. Then all clients would need to have all River classes in their classpath, or just one jar. Might make sense, certainly easier. Clients would never have to have jsk-lib.jar in their classpath, just river-über.jar.
>
> So I guess a better way of asking "why is this even an issue for you at all", is to ask: Why do you want to change what the platform currently is?
>
OK, now I get it. Long time ago I decided I didn’t like the service-starter framework. As a result, the class loader hierarchy above is not “the way I’ve always done it”. As a result, my mental image of the class loader hierarchy looks a little different from yours, although the end result is the same, since the 2.2 branch actually doesn’t have the entries in jsk-platform. So I’m really not suggesting a change, it’s just that in my mental image of the class loader, it wouldn’t actually matter where they were (and they’re currently where you’re suggesting anyway).
Just so you know where I’m coming from, this is the CL hierarchy that I’m more used to:
Extension-loader
+—————+
Bootstrap-CL |
+
SystemCL
+—————+
ContainerCL |
+——————+——————+
App1-CL App2-CL App3-CL
Bootstrap-CL: The real startup class path. Contains the container jar but not jsk-policy. Only used to setup the “System” and “Container” class loaders, really.
System-CL: Contains jsk-policy. No codebase annotation.
Container-CL: Container jar and maybe other utils, but nothing Jini-related.
Appn-CL: jsk-platform, jsk-lib, jsk-resources, svc-jar. Codebase annotation includes jsk-dl, svc-dl.
I won’t argue that this is better or worse than any other layout, just that in a container setup, it seemed better to separate the applications entirely. Of course a given app could publish more than one service endpoint (i.e. terminology is slightly different from service-starter talking about multiple services). As a side-effect, all the “Jini” classes end up getting a codebase annotation (that’s why it wouldn’t matter which jar the entry classes are in), although in all likelihood a client will end up resolving them locally, since they would also have the same classes locally, and making the entries “preferred” wouldn’t make much sense (cause the local app needs them).
> Dennis
Re: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Posted by Dennis Reedy <de...@gmail.com>.
On Apr 26, 2014, at 1114PM, Dennis Reedy <de...@asarian-tech.com> wrote:
>
> On Apr 26, 2014, at 839PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>>
>> But, so what? If they’re part of the platform, they’re supposed to be there in all Jini clients and services.
>
> Then why not put all the lookup attributes in the platform? Why not put all of jsk-lib.jar in the platform?
> And why is this even an issue for you at all?
Yeah, this came out kind of wrong (so did the previous few). You have questions on why this change was made, okay. Although I'm not sure why you don't understand that the result of the change aligns exactly with the current jar structure and contents of jsk-platform.jar (except for the additional work that Peter has added). The classes in question were added as an oversight, and were corrected with a one-line fix.
If you take a look at the current state of affairs in how River services are created, you end up with a classloader hierarchy that looks like this (ascii art, hope the formatting works):
SystemCL
|
+
+-------+-------+----...---+
| | |
Service-1CL Service-2CL Service-nCL
SystemCL - Contains start and platform classes
Classpath: start.jar, jsk-platform.jar, jsk-resources.jar (and other required jars needed to bootstrap)
Codebase: none
Service-nCL - Contains service specific implementation classes.
Classpath: serviceImpl.jar, jsk-lib.jar
Codebase: serviceX-dl.jar jsk-dl.jar
This is the current state of affairs in River started services, where you typically have a multi-service environment, and setting of java.rmi.server.codebase is not applicable. You can certainly create an über jar that includes jsk-platform, jsk-lib, and have all classes in River resolved by the system classloader. I'm not sure thats what you want (or maybe it is?). If this were the case, then only service-specific download classes would end up being in the codebase. Then all clients would need to have all River classes in their classpath, or just one jar. Might make sense, certainly easier. Clients would never have to have jsk-lib.jar in their classpath, just river-über.jar.
So I guess a better way of asking "why is this even an issue for you at all", is to ask: Why do you want to change what the platform currently is?
Dennis
Re: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Posted by Dennis Reedy <de...@gmail.com>.
On Apr 26, 2014, at 839PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> But, so what? If they’re part of the platform, they’re supposed to be there in all Jini clients and services.
Then why not put all the lookup attributes in the platform? Why not put all of jsk-lib.jar in the platform? And why is this even an issue for you at all?
>
> Greg.
>
> On Apr 26, 2014, at 8:28 PM, Peter <ji...@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.
Nope. Classes that are loaded by the system classloader never get an annotation.
Dennis
Re: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Posted by Greg Trasuk <tr...@stratuscom.com>.
But, so what? If they’re part of the platform, they’re supposed to be there in all Jini clients and services.
Greg.
On Apr 26, 2014, at 8:28 PM, Peter <ji...@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 <de...@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
>>
>
Re: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Posted by Dennis Reedy <de...@gmail.com>.
On Apr 26, 2014, at 841PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> 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?
This is why the application classloader includes jsk-lib.jar in it's classpath. The jsk-platform.jar is in the system classloader, not the application (service) classloader.
Take a look at the current jsk-platform.jar, jsk-lib.jar and jsk-dl.jar.
Re: svn commit: r1590276 -
/river/jtsk/skunk/qa_refactor/trunk/build.xml
Posted by Peter <ji...@zeus.net.au>.
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 <ji...@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 <de...@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
> > >
> >
>
Re: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Posted by Greg Trasuk <tr...@stratuscom.com>.
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 <ji...@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 <de...@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
>>
>