Part of the decision logic for class loader structure involves proxies which could interact. In the past we've required the client to put such shared types into the application classloader. There is always the chance that there are abstractions and implementations that might be shared between proxies yet unknown to the application/client.
So, having some layers on the classloader is sometimes a necessity, and even a super proxy or middleman proxy can solve the problem but become a pain. Gregg Sent from my iPhone > On Feb 20, 2014, at 8:08 AM, Greg Trasuk <tras...@stratuscom.com> wrote: > > >> On Feb 19, 2014, at 11:23 PM, Peter Firmstone <j...@zeus.net.au> wrote: >> >> You could adopt the directory conventions api, impl and proxy, instead of >> lib and lib-dl? That way you could make sure the api is loaded into the >> application class loader, while the implementation can be loaded into a >> child ClassLoader for maximum cooperation (in case the service >> implementation also uses other remote services) while avoiding name space >> visibility issues. >> > > I’m not sure what that would accomplish. As it stands now, the application > has one class loader which is effectively a child of the system class loader. > If the app is going to act as a consumer, it will unmarshall the service > provider’s proxy in the usual way, which will end up with a > PreferredClassLoader that is a child of the application’s class loader > (standard Jini stuff - nothing to do with the container), so proxies from > other providers are effectively in different class loaders. What would be > the advantage of separating the API classes from the implementation classes? > It’s only the lib-dl jars that are available to outsiders, so there’s no > chance of leaking the implementation classes to consumers, assuming the jars > files are created correctly, which is the service author’s responsibility. > > So, I would not be in favour of separating out the class loaders in that way. > It adds complexity and imposes a structure on service authors for no reason. > The only fundamental question that service writers need to answer now is > “should this class be available for download to remote clients?” If so, it > goes into a jar file that’s in the ‘lib-dl’ folder (that folder would > typically include ‘hello-api.jar’ and ‘hello-proxy.jar’ (assuming the naming > conventions are followed for the ‘hello’ service). If not, it goes into > ‘lib’ (that folder would contain ‘hello-api.jar’, ‘hello-proxy.jar’ and > ‘hello-impl.jar’. > > Or perhaps I misunderstand your suggestion…Please elaborate if that’s the > case. > > I should also note that as currently implemented and written in the proposed > spec, the container _does not_ share the Jini platform libraries (jsk-lib, > jsk-platform, etc) between applications. Each application class loader > includes the Jini libraries separately. I just couldn’t think of a case > where sharing made very much sense, plus eventually it would make sense to > have separate thread pools per application (1), which would be complicated if > the platform jars were shared. > > (1) Each application will have separate threads as it is, but the threads are > created inside the JERI framework, so they’re not under the container’s > control, i.e. it’s not possible for the container to setup prioritization > between apps, until the threading system is updated. > > Cheers, > > Greg Trasuk > > >> Regards, >> >> Peter. >> >>> On 20/02/2014 12:58 PM, Greg Trasuk (JIRA) wrote: >>> [ >>> https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906531#comment-13906531 >>> ] >>> >>> Greg Trasuk commented on RIVER-435: >>> ----------------------------------- >>> >>> Comments from the mailing list discussion... >>> >>> Greg Trasuk >>> ========== >>> OK, so on the topic of the jar file naming conventions (hello-api.jar, >>> hello-proxy.jar, hello-impl.jar, etc), I thought we had already adopted >>> that as a recommended convention. It follows common “good practices” that >>> most of us have used for a long time, and it allows you to build without >>> ‘classdepandjar’. As well, it happens to dovetail nicely with a Maven >>> build. >>> >>> Having said that, I don’t believe that convention needs to be mentioned in >>> the single-archive packaging spec (or at least not required - I suppose it >>> could be referenced as good practice). >>> >>> The spec differentiates between “class path” and “codebase” jars by having >>> them in different folders inside the deployment archive (lib and lib-dl). >>> So, while the build that creates the archive may very well use the >>> conventions to determine which dependent files go into which folder, from >>> the container’s point of view, it doesn’t care about the naming >>> conventions. Basically, everything in the ‘lib’ dir gets included in the >>> service’s class path, and everything in the ‘lib-dl’ dir gets published >>> through the codebase server and included in the service’s codebase >>> annotation. In fact, a service may want to include other jar files in >>> either its codebase or class path (for instance domain objects). These >>> other jar files shouldn’t be forced into a River convention, especially >>> since that might require renaming or repackaging the jar files. >>> >>> Jeff Ramsdale >>> =========== >>> No, services shouldn't be required to use this standard but the >>> River-provided services should model it as the best practice, as mentioned >>> in another thread. >>> >>> >>>> Proposed Standard for Single-Archive Service Deployment Packaging >>>> ----------------------------------------------------------------- >>>> >>>> Key: RIVER-435 >>>> URL: https://issues.apache.org/jira/browse/RIVER-435 >>>> Project: River >>>> Issue Type: Improvement >>>> Components: com_sun_jini_start >>>> Reporter: Greg Trasuk >>>> Attachments: SingleArchiveServiceDeployment.docx, >>>> SingleArchiveServiceDeployment.pdf >>>> >>>> >>>> The attached document proposes the layout and general requirements for an >>>> archive file to support simplified "drag-and-drop" deployment for services >>>> that adhere to the Service Starter conventions. >>> >>> >>> -- >>> This message was sent by Atlassian JIRA >>> (v6.1.5#6160) >> >
