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.
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)
