Here's the problem with the current converters api.
In the application, we have the Application-Content header and the
artifacts in the archive which are treated separately.
If the Application-Content header isn't present, it's supposed to be
implied as the list of artifacts in the archive.
The artifacts are provided for the resolver, but you really have no
guarantee that they will be used instead.
The Application-Content is used by the resolver as the root artifacts
to deploy and the resolver will find any missing requirements.
Now, we want to be able to convert artifacts on the fly to osgi
bundles. The problem is that the artifacts are not osgi bundles, so
they don't have a symbolic-name and version attributes, but those will
be generated by the converter somehow. The Application-Content is a
list of bundle symbolic names with an associated version. So there is
no way to actually use those, because we don't know what the symbolic
name of the transformed artifacts will be.
An additional problem is that converters are found from the list of
registered services in the framework. THis simply means that you
don't control what's happening. Let's say you install an application
which is supposed to contain a web application. If you have the web
app converter registered, the application will be correctly installed.
Unfortunately, if you have a simple jar->bundle converter, you will
end up with a transformed artifact that is not a wab. So imho, one
requirement is that the application manifest should contain somehow
the conversion strategy to ensure a predictable installation.
The karaf features have a lot of missing features, but that one is
quite well supported imho.
The way it's done is by leveraging URL and OSGi URL handlers.
For example, in servicemix 4, we install the activemq broker with the
following feature:
<feature name="activemq-broker" version="${version}">
<feature>spring-dm</feature>
<feature version="${activemq.version}">activemq</feature>
<bundle>spring:file:etc/activemq-broker.xml</bundle>
</feature>
When installing the feature, no particular processing is done. The
url is simply given to the framework for installing the bundle. In the
above case, it will warp the spring xml configuration on the file
system into an osgi bundle and install it on the fly.
Using URL would also allow to specify the conversion such as bundle
symbolic name, war context name, etc ...
I think we should also be able to specify converting an artifact
without actually embedding it.
So i'm proposing to extend the Application-Content header syntax to
support URLs.
We could have:
Application-Content: bundle-a;version=1.0,
war:http://host/myfile.war&Bundle-SymbolicName=mywar,
obr:bundle-b/1.0.1
I suppose we need to access files from within the archive, so maybe we
could introduce a specific url syntax for that:
eba:myfile.war
would actually return a stream to the myfile.war file in the root of
the eba archive.
I think this solves most of the problems by:
* allow controlling the conversion of bundles, including what kind
of conversion and parameterizing the conversion itself
* improve performances by not transforming artifacts all artifacts
systematically
On Thu, Feb 18, 2010 at 19:39, Valentin Mahrwald
<[email protected]> wrote:
> Could use case #2 be supported through the existing design of using
> BundleConverter services to convert EBA content, which is not a bundle yet?
> The code modified would have to be modified to also consider non-archive
> files.
>
> I think the original intention of the code was at least to support web
> applications as well. For this there is the WabConverterService, which is
> built on top of the webbundle handler, ready to be plugged in.
>
> Regards,
>
> Valentin
>
>
> On 18 Feb 2010, at 17:18, Guillaume Nodet wrote:
>
>> My use cases are multiple.
>>
>> #1. I have an application which uses the configuration admin. I want
>> to link the configurations to the application somehow and make sure it
>> will be installed as part of the installation process
>>
>> #2. I have a file which I know how to transform into a bundle using a
>> URL handler and I want to install it as part of the application.
>> I think that's the way web applications should be supported, but
>> this is a more general thing, as you can then support much more
>> artifact types.
>> I'm thinking about deploying this way a simple blueprint application
>> using the blueprint url handler from karaf for example. Given the web
>> app spec specifies a url handler, I think it would make sense to reuse
>> it too
>
>> On Tue, Feb 16, 2010 at 12:02, Alasdair Nottingham <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> I'm not entirely sure I follow what you are asking for here. Do you
>>> want to be able to access non jar content using the AriesApplication
>>> interface, or do you want to convert non-jar artifacts into bundles
>>> somehow or something else?
>>>
>>> Thanks
>>> Alasdair
>>>
>>> On 16 February 2010 08:00, Guillaume Nodet (JIRA) <[email protected]>
>>> wrote:
>>>>
>>>> AriesApplicationManagerImpl#createApplication should support artifacts
>>>> that are not jars somehow
>>>>
>>>> ------------------------------------------------------------------------------------------------
>>>>
>>>> Key: ARIES-168
>>>> URL: https://issues.apache.org/jira/browse/ARIES-168
>>>> Project: Aries
>>>> Issue Type: Improvement
>>>> Components: Application
>>>> Reporter: Guillaume Nodet
>>>>
>>>>
>>>> Deploying configurations for example or plain blueprint configuration
>>>> files would be really handy
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> [email protected]
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
