Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging

[Peter <ji...@zeus.net.au>]

To add to what Gregg has mentioned:

Exported objects, that are Remote, but not services themselves, can be passed as parameters to services.

If a service receives a remote object as a parameter and allows this object's smart proxy classes to load, then it's important for the proxy to only see the Service API classes in the application class loader and not the service implementation or other proxy code.

It's a simple solution for maximum compatibility by default, to ensure only what needs to be shared is loaded into the application classloader, such as the Jini platform and service api.

If someone wants something different, we're not preventing it, this is just a sensible default to avoid problems for new users, which the proposed river container is targeting.

If implementation classes are in their own ClassLoaders, they have their own unshared static fields and ProtectionDomain.  Dynamic policy grant's are made to ClassLoaders, put implementation classes in the wrong ClassLoader and security is busted.

Just my 20 cents.

Cheers,

Peter.

----- Original message -----
> 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 <tr...@stratuscom.com>
> > wrote:
> > 
> > 
> > > On Feb 19, 2014, at 11:23 PM, Peter Firmstone <ji...@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)
> > > 
> >