On Apr 26, 2014, at 1114PM, Dennis Reedy <den...@asarian-tech.com> wrote:
>
> On Apr 26, 2014, at 839PM, Greg Trasuk <tras...@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
