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
On Apr 26, 2014, at 1114PM, Dennis Reedy wrote:
>
> On Apr 26, 2014, at 839PM, Greg Trasuk 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 no
On Apr 26, 2014, at 841PM, Greg Trasuk 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 classp
On Apr 26, 2014, at 839PM, Greg Trasuk 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
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
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 wrote:
> Dennis is right, these classes have snuck into jsk-platform.jar, they'r
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 wrote:
> Dennis is right, these classes have snuck into jsk-platform.jar, they're not
> in there in Jini2.1
>
> Because these classes aren'
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
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
On Apr 26, 2014, at 254PM, tras...@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, th
What is the rationale for inclusion/ exclusion ?
Greg Trasuk
Original Message
From: dre...@apache.org
Sent: Saturday, April 26, 2014 2:46 PM
To: comm...@river.apache.org
Reply To: dev@river.apache.org
Subject: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Author
11 matches
Mail list logo
