You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/02/18 18:18:01 UTC
Support for additional content type (Re: [jira] Created: (ARIES-168)
AriesApplicationManagerImpl#createApplication should support artifacts that
are not jars somehow)
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 <no...@apache.org> 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) <ji...@apache.org> 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
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Support for additional content type (Re: [jira] Created:
(ARIES-168) AriesApplicationManagerImpl#createApplication should support
artifacts that are not jars somehow)
Posted by Alasdair Nottingham <no...@apache.org>.
I think you can get to the point where you just deploy an application.mf.
The OBR resolver converts the Application-Content entries to a set of
requirement of type bundle.
For an entry with a different type we would generate a requirement of
the alternate type. You then
just advertise the entity in an OBR repository.xml with a capability of the type
we need to select from. You can even specify the url you want in the
resources uri attribute.
I think this would work.
Alasdair
On 19 February 2010 15:07, Guillaume Nodet <gn...@gmail.com> wrote:
> Yeah, it fulfills the requirement. That's a good solution but for
> point #4. I think there is a problem in doing that, because this
> means an application manifest can no longer be used standalone. I was
> under the assumption that one of the goal was to support this use
> case.
> This would mean that for all osgi bundles their actual location can be
> obtained from the resolver, but for other kind of artifacts they need
> to be in the archive. I think that's wrong and makes the use of
> applications at development time for example more difficult and also
> introduce a big difference between osgi bundles and other artifacts.
>
> About changing the application model, if the problem is simply the
> delay of the transformation, we don't have to necesseraly delay it.
> Actually it might be a problem to do so because you then don't have
> any osgi bundle to compute dependencies from. So you can drop that
> part.
>
> On Fri, Feb 19, 2010 at 14:44, Alasdair Nottingham <no...@apache.org> wrote:
>> On 18 February 2010 20:07, Guillaume Nodet <gn...@gmail.com> 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
>>> <vm...@googlemail.com> 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 <no...@apache.org> 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) <ji...@apache.org>
>>>>>> 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
>>>>>> not@apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: Support for additional content type (Re: [jira] Created:
(ARIES-168) AriesApplicationManagerImpl#createApplication should support
artifacts that are not jars somehow)
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, it fulfills the requirement. That's a good solution but for
point #4. I think there is a problem in doing that, because this
means an application manifest can no longer be used standalone. I was
under the assumption that one of the goal was to support this use
case.
This would mean that for all osgi bundles their actual location can be
obtained from the resolver, but for other kind of artifacts they need
to be in the archive. I think that's wrong and makes the use of
applications at development time for example more difficult and also
introduce a big difference between osgi bundles and other artifacts.
About changing the application model, if the problem is simply the
delay of the transformation, we don't have to necesseraly delay it.
Actually it might be a problem to do so because you then don't have
any osgi bundle to compute dependencies from. So you can drop that
part.
On Fri, Feb 19, 2010 at 14:44, Alasdair Nottingham <no...@apache.org> wrote:
> On 18 February 2010 20:07, Guillaume Nodet <gn...@gmail.com> 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
>> <vm...@googlemail.com> 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 <no...@apache.org> 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) <ji...@apache.org>
>>>>> 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
>>>>> not@apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Support for additional content type (Re: [jira] Created:
(ARIES-168) AriesApplicationManagerImpl#createApplication should support
artifacts that are not jars somehow)
Posted by Alasdair Nottingham <no...@apache.org>.
On 18 February 2010 20:07, Guillaume Nodet <gn...@gmail.com> 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
> <vm...@googlemail.com> 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 <no...@apache.org> 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) <ji...@apache.org>
>>>> 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
>>>> not@apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> 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
not@apache.org
Re: Support for additional content type (Re: [jira] Created:
(ARIES-168) AriesApplicationManagerImpl#createApplication should support
artifacts that are not jars somehow)
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<vm...@googlemail.com> 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 <no...@apache.org> 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) <ji...@apache.org>
>>> 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
>>> not@apache.org
>>>
>>
>>
>>
>> --
>> 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
Re: Support for additional content type (Re: [jira] Created: (ARIES-168) AriesApplicationManagerImpl#createApplication should support artifacts that are not jars somehow)
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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 <no...@apache.org>
> 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) <ji...@apache.org>
>> 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
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com