aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <>
Subject Re: [DISCUSS] Subsystem API (was Re: Application API)
Date Mon, 19 Apr 2010 13:04:51 GMT
On 16 April 2010 07:44, Guillaume Nodet <> wrote:
> For urls, I agree, but I think some people don't, but I'd like to hear
> their arguments.

I think we need to keep the subsystem description independent of the
way in which things are found.  For example, I don't think we should
be burning the use of obr into the content.  The subsystem needs to
identify the content, but leave the means for how those things are
found up the the environment into which the subsystem is being
deployed.  Some may use OBR, others might use P2, or any other
repo/provisioning system.  If we make too many decisions up front then
we restrict the environments into which subsystems can be deployed.

> I think we still need to install resources inside the subsystem, not
> only outside.  Actually I think it would be fine if resources other
> than bundles can only be installed inside the subsystem.

It would be good to keep the rules clean and simple.  For example, if
the thing is listed in the content, then it's installed inside, if
it's not, then it's installed outside.  This probably covers the 80:20
and is easy to explain.

> For the ResourceResolver, I think it's nice to be pluggable, but it
> could still be an implementation specific feature without being part
> of the API or SPI documented for the user.

For consumers of Aries, this is probably something other environments
will want to plug in different implementations.

> I'll be in vacation today and next week, but I'll try to think a bit
> more about that.
> On Thursday, April 15, 2010, Lin Sun <> wrote:
>> So for Subsystem-content, it doesn't need to be converted, and can
>> come from the user specified obr repos or from the eba file.   The
>> contents will be installed in the subsystem while the transitive
>> dependencies will be installed outside the subsystem, however the
>> required packages/services will be imported from composite bundle to
>> the subsystem.
>> Examples:
>> Subsystem-Content: bundlesymbolicname;version="1.0.0"
>> or
>> Subsystem-Content: bundlesymbolicname;version="[1.0.0, 2.0.0]"
>> For Subsystem-resource, it needs to be converted and the type needs to
>> be specified so that we can delegate work to the corresponding
>> converter.  The resources will be installed in the subsystem.  Are we
>> assuming the subsystem-resource have to be supplied in the eba file?
>> If not, I am not sure how we can find the resource, given it is not a
>> bundle yet and won't be available in the OBR repo.
>> Do we expect any transitive dependencies for the war?  I think it can
>> have like a war requires servlet 3.0, a blueprint xml requires
>> blueprint APIs.    Would it also be installed outside the subsystem
>> but required packages/services flown into the subsystem?
>> Examples:
>> Subsystem-Resource: test.war;type=war
>> However, if we use URI to represent subsystem content/resource, we
>> could just have Subsystem-content, as the URI would convey which URL
>> handlers would invoke already.
>> Examples:
>> Subsystem-Content: obr:bundlesymbolicname;version="[1.0.0, 2.0.0]",
>> webbundle:test.war;web-contextpath=/test1
>> Anything without the obr: should be found in the .eba archive.   I
>> agree that later one is powerful and you can pass in params too.
>> Regarding ResourceResolver, I don't see the need for user to supply it
>> while it would be a useful interface for our subsystem.
>> Lin
>> On Thu, Apr 15, 2010 at 12:39 PM, Guillaume Nodet <> wrote:
>>> Well, I agree it's easier, but it's way less powerfull.  The first thing i'd
>>> like to make sure is that installing a subsystem
>>> is a predictable operation, i.e. it's not affected by what is deployed or
>>> not (or at least in a controlled way).
>>> The other thing, is that I think we should allow other types of resources
>>> than bundles to be installed, hence the SPI
>>> for ResourceProcessor.
>>> Not let's take an example: we implement a ResourceConverter which is able to
>>> take a blueprint xml file and turn it into a bundle.
>>> Now, we can embed the blueprint xml into the subsystem archive and expect it
>>> to be installed if needed.
>>> This raises a few questions / problems:
>>>   * the subsystem admin need to be able to identify which ResourceConverter
>>> will be used, and in a way that the user
>>>      can be sure which one will be used.  If a converter that can transform
>>> a spring xml file into a bundle has been
>>>      registered, how will the subsystem admin know which one to choose
>>>   * how are the symbolic name / version found for the resource ?
>>> Another use case: I want to install some ConfigAdmin configurations as a
>>> property file, while the ConfigAdmin processor
>>> only handles xml files, so I need to convert my property file into a xml
>>> file in a know format.
>>> So I need to specify:
>>>  * the type of the resource that will be installed by the ResourceProcessor
>>>  * the type of the original resource (property file) that need to be
>>> converted, or the name of the converter somehow
>>>  * but i also need to be able to point to the property file somehow
>>> Another use case: I have a war available in a maven repo and I want to
>>> install it as part of my subsystem, without
>>> embedding it in the archive.  I then need:
>>>  * a way to identify and point to the war
>>> Note that converters are not critical, they are only for ease of use, as any
>>> conversion that they will do could be done
>>> offline.
>>> Second, we need to be able to point to resources that are not osgi bundles,
>>> such as wars or config files, either from
>>> inside the subsystem archive or from outside the archive.
>>> My first idea was to simply get rid of the converters and use URI.  URIs are
>>> much more powerful than anything we could come up with.
>>> In addition, OSGI supports custom URI handlers and we could use an indirect
>>> uri for that:
>>>     webbundle:obr:symbolicname/version
>>> The webbundle scheme will leverage the existing spec and will transform the
>>> war on the fly.
>>> The obr url will delegate to OBR to find a resource with the give symbolic
>>> name and version.
>>> We could use a maven url too:
>>>    webbundle:mvn:groupid:artifactid:version:war
>>> I can understand some people are reluctant to using URI in the first place,
>>> so using symbolicname/version.
>>> The problem is that a symbolic name and version does not really give you a
>>> location to download the jar from.
>>> So, back to the problem.  I think the user needs to care about the
>>> transformation.  And it should not matter if
>>> the resource comes from the subsystem archive or from an external location.
>>>  The idea in the eba archive is that
>>> the content of the archive is used to create some kind of repository which
>>> can be used by the resolver to resolve
>>> the needed dependencies.  So it's just *another* repository, but I don't
>>> think that transformations should apply
>>> only to the resources inside the archive.  We should be able to transform a
>>> war without including it imho.
>>> Anyway, I hope I raised a few interesting questions.
>>> I'd really like to avoid adding a whole object model representation of the
>>> manifest in the api.
>>> There's no point in doing that, as everybody can parse the manifest.
>>> I'd rather remove the ResourceResolver completely from the SPI, as I don't
>>> think
>>> this is something which is needed to be plugged in by the user.
>>> As a drastic operation for now, we could only keep the SPI with:
>>>  * Resource which defines how to access something
>>>  * ResourceProcessor which can actually process the thing
>>> Converters can be done offline and the Resolver is more an implementation
>>> detail imho.
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

View raw message