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 <dennis.re...@gmail.com> wrote:
>
> 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?
>
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
