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 <[email protected]> wrote: > 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] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
