On 18 February 2010 20:07, Guillaume Nodet <[email protected]> wrote:
> 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.
Agreed
> If the Application-Content header isn't present, it's supposed to be
> implied as the list of artifacts in the archive.
It is implied as the list of artefacts in the archive post conversion,
so if we couldn't convert something it isn't in the
Application-Content. Note there is a bug in the code I'll raise a JIRA
for this.
> The artifacts are provided for the resolver, but you really have no
> guarantee that they will be used instead.
When we generate the Application-Content from the artefacts in the
archive we set the version explicitly to their version, so you do have
this guarantee.
> The Application-Content is used by the resolver as the root artifacts
> to deploy and the resolver will find any missing requirements.
Yes
>
> 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.
So the problem you are describing is that if you specify the
Application-Content there is currently no way to reference an artefact
in the archive because you don't know the bundle symbolic name and
version. I agree this is a problem.
>
> 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
>
I do not like this approach because it leads to a fundamental
transformation of the application model. The model for applications is
that the artefact is passed through a resolution process to gain
transitive closure. Delaying conversion until install time means we
cannot ensure transitive closure during the resolve step which means
the application author has to get it right. That is fine for
provisioning server runtimes, but not for applications.
I think we can address this problem much more simply as follows:
1. Augment the BundleConverter interface to have a public boolean
isTypeSupported(String type); method
2. Add to the Application-Content a type directive. This directive
would indicate the type of the resource. The default type is "bundle"
and during application creation the relevant converters are called.
3. Update the BundleConverter.convert method to add a Map of
attributes and a Map of directives. These are read from the
Application-Content header and passed through to parameterise the
conversion.
4. When the type is non bundle then the identifier is a path into the
archive that locates the file.
5. If we are converting something and don't know the type we still
just call all the BundleConverters, but when we have a type we only
call a converter where isTypeSupported returns true
6. We augment the AriesApplication so you can find out about
non-converted artefacts so you can decide if this is an issue or not.
I believe this fulfils your requirements without making fundamental
changes to the application model.
Alasdair
>
> 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
>
--
Alasdair Nottingham
[email protected]
