river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Thu, 20 Feb 2014 04:23:57 GMT
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)


Mime
View raw message