[
https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908530#comment-13908530
]
Greg Trasuk commented on RIVER-435:
-----------------------------------
Post-back of mailing list comments to JIRA...
Gregg Wonderley
==============
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
Peter Firmstone
============
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.
> 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)
