You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Greg Trasuk (JIRA)" <ji...@apache.org> on 2014/02/20 03:58:19 UTC
[jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive
Service Deployment Packaging
[ 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)
Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Feb 20, 2014, at 11:31 AM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
> Dnia 2014-02-20, czw o godzinie 11:02 -0500, Greg Trasuk pisze:
>> On Feb 20, 2014, at 9:50 AM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>>
> (...)
>>> That's why we need PreferredCL,
>>> to ensure that these classes are loaded from the right jar.
>>> I thought employing the api/impl/proxy would make PreferredCL obsolete,
>>> wouldn't it?
>>>
>>
>> I don’t think so. PreferredClassLoader does two things -
>>
>> 1 - It isolates the service proxy from the client’s classes
>> 2 - It helps reduce the “lost codebase” problem by making sure that classes used only by the proxy aren’t loaded from the local CL.
>
> Correct me if I'm wrong, but PreferredCL decides on which jar to use
> based on jar's metadata - PREFERRED.LIST. If you have two identical
> jars, one local and one remote, there's no way to decide which to load.
>
On the client side, the “-proxy” jar should never be in the local class path. Preferred CL mainly applies to third-party libraries that might be used by the proxy, but aren’t accessed by the client itself. You’re right, that the applicability is limited in most cases.
> But I'm not sure if there is a need anymore, as API classes used by the
> client must be in the export codebase anyway. Incoming proxy will we
> deserialized using it's codebase but it must use interface loaded from
> local CL in order to be assignable to a reference.
>
That’s right - the “-api” classes need to be in the client’s local class path (assuming the client is in Java). In fact, the client doesn’t really need them in the codebase annotation, and won’t generally download them remotely. It’s actually only the service browser that fails if the “-api.jar” isn’t in the codebase. I suppose it could also be a problem if you were using a dynamic language (Groovy maybe?, Jython, Javascript, etc) on the client side that didn’t actually need “-api.jar”.
> Regards,
> Rafał
>
>
Cheers,
Greg.
Re: [jira] [Commented] (RIVER-435) Proposed Standard for
Single-Archive Service Deployment Packaging
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-02-20, czw o godzinie 11:02 -0500, Greg Trasuk pisze:
> On Feb 20, 2014, at 9:50 AM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>
(...)
> > That's why we need PreferredCL,
> > to ensure that these classes are loaded from the right jar.
> > I thought employing the api/impl/proxy would make PreferredCL obsolete,
> > wouldn't it?
> >
>
> I don’t think so. PreferredClassLoader does two things -
>
> 1 - It isolates the service proxy from the client’s classes
> 2 - It helps reduce the “lost codebase” problem by making sure that classes used only by the proxy aren’t loaded from the local CL.
Correct me if I'm wrong, but PreferredCL decides on which jar to use
based on jar's metadata - PREFERRED.LIST. If you have two identical
jars, one local and one remote, there's no way to decide which to load.
But I'm not sure if there is a need anymore, as API classes used by the
client must be in the export codebase anyway. Incoming proxy will we
deserialized using it's codebase but it must use interface loaded from
local CL in order to be assignable to a reference.
Regards,
Rafał
Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Feb 20, 2014, at 9:50 AM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>
> Greg,
> from what I understand, River service has now two jars, impl nad dl,
> with some classes in the both of them.
It gets a little confusing with the infrastructure services like Reggie, because the API classes are already in jsk-lib, so they’re in the local CL. Also, going back to the roots of Jini, when people just set the system property ‘java.rmi.server.codebase’ rather than using a class loader that did codebase annotations correctly, it was a nuisance to call out more than one jar file in the codebase. So, I think that’s why you see the ‘classdepandjar’ approach that was trying to build one single “download” jar. As well, the tradition wasn’t to use multiple project modules - people would want to produce both an ‘api’ jar and a ‘dl’ jar from the same source project, which mandated a tool like ‘classdepandjar’ if you didn’t want to manually track which classes should go into which jar.
The “-api.jar”/ “-proxy.jar”/etc convention removes the need to use ‘classdepandjar’, but you still have classes duplicated between the service class path and the published “codebase”. Only now, the duplication is more explicit, in the form of having the same jar appear in the class path and the codebase. Specifically, the service’s class path includes (e.g. for a ‘hello’ service) ‘hello-api.jar’, ‘hello-proxy.jar’ and ‘hello-impl.jar’, whereas the published codebase annotation will include ‘hello-api.jar’ and ‘hello-proxy.jar’, without the implementation jar.
> That's why we need PreferredCL,
> to ensure that these classes are loaded from the right jar.
> I thought employing the api/impl/proxy would make PreferredCL obsolete,
> wouldn't it?
>
I don’t think so. PreferredClassLoader does two things -
1 - It isolates the service proxy from the client’s classes
2 - It helps reduce the “lost codebase” problem by making sure that classes used only by the proxy aren’t loaded from the local CL.
> Regards,
> Rafał
>
Cheers,
Greg Trasuk
Re: [jira] [Commented] (RIVER-435) Proposed Standard for
Single-Archive Service Deployment Packaging
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-02-20, czw o godzinie 09:08 -0500, Greg Trasuk pisze:
> 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.
Greg,
from what I understand, River service has now two jars, impl nad dl,
with some classes in the both of them. That's why we need PreferredCL,
to ensure that these classes are loaded from the right jar.
I thought employing the api/impl/proxy would make PreferredCL obsolete,
wouldn't it?
Regards,
Rafał
Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Posted by Greg Trasuk <tr...@stratuscom.com>.
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)
>
Re: [jira] [Commented] (RIVER-435) Proposed Standard for
Single-Archive Service Deployment Packaging
Posted by 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)
> > >
> >
Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Posted by Gregg Wonderly <ge...@cox.net>.
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)
>>
>
Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive
Service Deployment Packaging
Posted by Peter Firmstone <ji...@zeus.net.au>.
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)