river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Tue, 25 Feb 2014 19:08:53 GMT

On Feb 25, 2014, at 12:18 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:

> On Tue, Feb 25, 2014 at 12:36 PM, Michal Kleczek <michal.kleczek@xpro.biz>wrote:
>> Hmm... I don't think it is an implementation detail - codebase annotations
>> must be understood by every client - so the format becomes a part of the
>> spec.
> Fair enough, it does need to be part of a specification.
>> For example Maven based naming (groupId:artifactId:version:classifier:version)
>> is incompatible with Eclipse p2 (MANIFEST.MF OSGI metadata - in practice I
>> would say it would be bundleId:version or bundleId:version-range).
>> Additionally - just name/version based artifact identification is not
>> enough - I would much rather see something like "strong names" from .NET
>> where signature is part of the identifier.
>> Besides... Maven based provisioning requires every party to agree on a set
>> of common repositories.
> Not necessarily true. If there is no context for a repository in the
> annotation then yes. An example where there is context is in the following
> URL:
> artifact:groupId/artifactId/version[/type[/classifier]][;
> repository[@repositoryId]]
>> Ideal solution would be to decouple the client from the "how" code is
>> downloaded. Not having this is one of the problems with current River
>> architecture - all have to have http and httpmd URL handlers installed.
>> This decoupling could be achieved if codebase annotations were objects -
>> that was my proposal discussed some time ago. It allows a service to
>> provide clients with "code downloaders" as annotations.
> This. I like this. How would this work, would it be an Entry, an attribute
> of the service (perhaps similar to the ServiceUI factory?).

What I think would be good, would be to make the annotation be used to download the details.
 That is, that today, it is the client code.  What if it was actually running code which created
child class loaders that would be attached to the parent class loader that the annotation
URL was associated with.

Today, you would do this by using a delegate pattern on the service interface, so that the
first use of any method on the interface, would “get” the actual code, and then delegate
method calls into it.

With a “tool”, (named ccd for createCodeDelegate) one could say something like

    ccd -t maven -r repository-spec --classpath code.jar —class serviceClassName —interfaces
interface.name1 interface.name2

which would know about ‘-t’ argument types and pass the -r details to them.  it would
use code.jar to resolve the interface names and the ‘-t’ details to create delegating
implementations of the specified interfaces.  Now, ideally, this would be a “proxy” whose
invoke() method would check if code has been resolved, and do that once, before delegating
to the proxy’s delegate.

Gregg Wonderly
View raw message