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 <[email protected]> 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 <[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 > -- Alasdair Nottingham [email protected]
