I think perhaps this is where a subsystem is different from an application, but I'm a little out of my depth here having not been on the subsystem calls or having read the RFC/RFP.
Alasdair On 16 February 2010 16:20, Guillaume Nodet <[email protected]> wrote: > IIRC, we had some discussions around that on a subsystems conference call. > I think the outcome was roughly that we may want to support three modes: > * all shared > * all private > * mixed content > > It should be quite simple using a global flag somehow which could be > overriden for some specific bundles. Shared would mean to install in the > main framework, while private would mean that the bundles would be > installed in a composite bundle. > > I also think we need the same kind of flags at package and service > level so that one > can control what services and packages will be visible from outside > the composite > bundle. > > The approach you propose has the limitation of not being able to > deploy an application > in an all-shared environment IIUC. > > > > On Tue, Feb 16, 2010 at 14:28, Alasdair Nottingham <[email protected]> wrote: >> I haven't been following the subsystem work in the alliance as closely >> as you (Graham Charters has, but is on vacation this week so it'll be >> interesting to see his thoughts when he gets back next week), but >> based on my understanding I also see applications as a specialisation >> of subsystems, and I do think that aries should support both >> applications, and the more general sub-system solution. I also see a >> strong affinity between an application and a composite bundle. >> >> On the subject of applications being self contained I have a slightly >> different view, in fact I was going to send an email today about >> contributing some improvements. I'll try to explain my thoughts here >> (let me know if it needs a different discussion thread). I'm going to >> talk about this in terms of composite bundles, because that best >> describes what I am trying to achieve. >> >> The Application-Content of an application describes the isolated, or >> core, content of the application. When an application is installed a >> composite bundle is created and the bundles in the Application-Content >> are installed into the composite. The application may need additional >> packages or services that are not provided by the core content. This >> is also possible and bundles that provide those packages are installed >> outside the application composite and can be shared with other >> applications. >> >> This is not reflected in our current implementation, but I was going >> to propose adding it in. I was not planning on changing the >> Application.MF, it would still have the application-content as it is >> today, but when you call createApplication on the >> AriesApplicationManager we generate a deployment.mf that is used when >> install is called (we call out to a resolver to do this). This >> deployment.mf currently contains a Deployed-Content header which >> contains all the bundles in Application-Content, but ties them down to >> a specific version. In addition to doing this I was going to add a >> header named "Provision-Bundle" which denotes bundles that are needed >> to support the application-content. These bundles would be installed >> into the host framework and be shared with other applications. >> >> So the Application-Content in the Application.mf is isolated content, >> but the Deployment.mf contains additional shared bundles that are >> required to support the application. >> >> What do you think? >> Alasdair >> >> On 16 February 2010 11:21, David Bosschaert <[email protected]> >> wrote: >>> Yeah, maybe we need to tidy up the terminology a bit and come to >>> agreement on that, I think Guillaume's clarification helps. >>> >>> In my opinion it would be nice if Aries could provide both models. The >>> shared subsystem building block one as well as the more isolated >>> application one. Since I tend to think about Applications as a >>> specialization of a subsystem it should be possible to do this quite >>> naturally. >>> >>> Just my thoughts, >>> >>> David >>> >>> On 15 February 2010 22:21, Guillaume Nodet <[email protected]> wrote: >>>> Are you talking about nested framework instead of subsystems ? >>>> Subsystems are currently defined by RFC 152 and nested frameworks by RFC >>>> 138. >>>> >>>> My understanding is that applications as they stand are meant to be >>>> self-contained (or mostly) and isolated, >>>> whereas subsystems can be considered more as building blocks with >>>> sharing capabilities >>>> >>>> The way applications or subsystems can be isolated could be done using >>>> nested frameworks or manifest rewriting for example. >>>> >>>> On Mon, Feb 15, 2010 at 22:58, David Jencks <[email protected]> wrote: >>>>> >>>>> On Feb 15, 2010, at 1:34 PM, Guillaume Nodet wrote: >>>>> >>>>>> Aries applications model is quite similar to the subsytem model being >>>>>> discussed in the OSGi EEG. >>>>>> I'd like to think that subsytems are more generic than applications, >>>>>> or said another way, that applications >>>>>> are specialization of subsystems. Subsystems allow reference to other >>>>>> subsystems, scoping, etc... >>>>>> >>>>>> I'd like to see how we can make both fits together. I guess the first >>>>>> question to solve it whether we want >>>>>> to keep applications the way they are, without advanced features >>>>>> provided by subsystems such as >>>>>> sharing / scoping, dependencies on other subsytems, etc... >>>>>> >>>>>> Once we've answered that, we can think about the way we want to support >>>>>> both. >>>>>> >>>>>> Thoughts ? >>>>>> >>>>> >>>>> My point of view.... perhaps shared by no one else.... is that an >>>>> application would be deployed or installed into a particular subsystem, >>>>> but >>>>> that several apps and plain bundles can all be installed into a single >>>>> subsystem. I'm thinking of an application as a way to deploy a set of >>>>> bundles at once, where the "maven-like" dependencies aren't specified, and >>>>> where the framework has a way to resolve the osgi dependencies into >>>>> maven-like dependencies. >>>>> >>>>> I don't think this idea is expressed in the current code in any way. >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>>> -- >>>>>> 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]
