river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: svn commit: r1590276 - /river/jtsk/skunk/qa_refactor/trunk/build.xml
Date Sun, 27 Apr 2014 04:14:21 GMT

On Apr 26, 2014, at 1114PM, Dennis Reedy <dennis@asarian-tech.com> wrote:

> 
> On Apr 26, 2014, at 839PM, Greg Trasuk <trasukg@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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message