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:35:55 GMT
Hi Lin,  I'm not quite following, so another comment below...

On 19 April 2010 14:18, Lin Sun <> wrote:
> Hi Graham
> I totally agree with what you said below that we need to allow people
> to plugin in their own resolver and use that to resolve/find the
> content.
> What is being proposed here in a bit further is to use url schema to
> determine which resolver it should go to.  for example obr:content1
> would goes to obr url handler to find/resolve content1; p2:content1
> would go to the p2 url handler to find/resolve content1.

Maybe I'm misunderstanding, but this sounds to me like the subsystem
definition will state whether to go to obr or p2 and that's what I
have a problem with.  I think the subsystem should just say it
contains content1 and it's up to the environment into which the
subsystem is deployed to determine how to obtain content1.  One
environment might support obr, another might support p2.  We should
not require two entries or two separate subsystem definitions in order
to allow that flexibility.  Basically, I'm saying it's not the
responsibility of the subsystem author to state where the things will
be hosted.  Does that make sense?

> I also like the rule you have that if the resource or bundle is listed
> in the content or resource, then it is installed inside.  If not, then
> installed outside.
> Lin
> On Mon, Apr 19, 2010 at 9:04 AM, Graham Charters
> <> wrote:
>> 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 <>
>>>>> Well, I agree it's easier, but it's way less powerfull.  The first thing
>>>>> like to make sure is that installing a subsystem
>>>>> is a predictable operation, i.e. it's not affected by what is deployed
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> property file, while the ConfigAdmin processor
>>>>> only handles xml files, so I need to convert my property file into a
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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