On Nov 1, 2011, at 9:58 AM, mikevan wrote: > > > David, > > > > When I read the early-release of the OSGi Service Platform Spec that > contained the Subsystem Specification, I gotta admin, I got pretty excited. > > > > I like the ability to group a set of bundles into a subsystem , and then to > control the visibility of packages both within the subsystem and external to > the subsystem. When we talk about deploying a Karaf-managed application (a > set of subsystems and the core karaf bundles) into a virtual machine, the > ability to pick and choose the specific subsystems to deploy will make things > like thread-management and cpu utilization easier. > > > > While the karaf features provisioning mechanism provides a grouping and > deployment mechanism, there is no way to define the visibility of packages > outside of a feature. Either a package is available to everyone, or it is > available to no-one. A subsystem provisioning mechanism that allows for this > control of visibility will in all likelihood allow us to solve a number of > problems that karaf users are currently faced with.
That seems likely. What I'm slightly uncomfortable with in (my understanding of) the subsystem spec is that it ties a "region" (set of bundles with restricted visibility to other regions) to a subsystem (either feature, composite, or application) which has fairly fixed content. I'm afraid this is going to be too restrictive and that most people may want to set up a few regions with specified visibility to other regions and then start deploying sets of bundles (karaf features) into specific regions. This seems to me like a more flexible point of view. Anyway this is what I'm implementing and maybe we can see if people like it. This will also give people a chance to experiment with isolation before the spec is out. > > When thinking this through, I wonder if provisioning should be handled by > Felix instead of Karaf? Felix is a service platform, and will need to > implement its own provisioning capability at some point. Does it make sense > to continue keeping it in karaf? I know this is thinking about something > that may not take place for a while (maybe 6 months to a year), but I do > think we should start looking into it. > I'm not sure exactly what you mean by provisioning. Aries is developing the subsystem RI on top of the eclipse regions jar. My understanding of the subsystem spec is that a subsystem has an application manifest that lists the bundles you are sure you want in the subsystem, and then a deployment manifest is generated that also includes all the other bundles needed to make it work. I think this uses OBR (possibly a newer spec version than current felix obr implementation, I'm not sure). Then you deploy the subsystem from the deployment manifest, and it tells you where the bundles to install are. So from this point of view I'm not sure what parts of this are provisioning and how provisioning could be part of felix when the subsystems stuff is in aries. I'm always confused by what provisioning is.... maybe this time I'll find out :-) thanks david jencks > ----- Original Message ----- > > > From: "David Jencks [via Karaf]" <ml-node+s922171n3471177...@n3.nabble.com> > To: "mikevan" <mvangeert...@comcast.net> > Sent: Tuesday, November 1, 2011 12:39:47 PM > Subject: Re: Aries and Spring Co-Existance in Karaf > > I'm not at all a spring expert but I think people are being unclear about > exactly what they are trying to do. There are a lot of capabilities in > spring products and being very specific about exactly what you want might > help clear things up. > > -- you can only use one blueprint implementation within one bundle (either > the aries or the eclipse/spring one). (similarly for jpa, jta, ...) > -- as long as all types of framework used within a bundle communicate > cross-framework only through osgi services there should be no problem using > as many frameworks as you want. But if, for example, some spring web object > directly uses a blueprint component that isn't a service that almost > certainly ties the spring web stuff to the spring blueprint implementation. > > As a separate issue, virgo has isolation between "kernel" and "application" > code and karaf doesn't. I'm looking into implementing this in karaf using > the same code (regions) as virgo uses (this is also the basis of the > subsystems isolation code under development in aries) but at best this will > only work in karaf trunk. This may or may not be important to any particular > project. > > thanks > david jencks > > On Nov 1, 2011, at 8:25 AM, mikevan wrote: > > >> >> >> Raman, >> >> >> >> Can you describe the technical reason why you couldn't use camel, aries, and >> gemini contexts in the same bundle? To my knowledge, aries and gemini both >> leverage the osgi interfaces for osgi stuff. So, as long as the service is >> consumed by the same context used by camel, shouldn't they work? >> >> >> >> ----- Original Message ----- >> >> >> From: "Raman Gupta [via Karaf]" < [hidden email] > >> To: "mikevan" < [hidden email] > >> Sent: Tuesday, November 1, 2011 11:06:36 AM >> Subject: Re: Aries and Spring Co-Existance in Karaf >> >> On 11/01/2011 10:30 AM, mikevan wrote: >>> Why can't Gemini work in Karaf? >> >> You're right. I don't know if it will work. I should have said "it >> doesn't work out of the box". If you decide to try it and get it >> working I'd be interested in your features.xml. >> >> I too have used Virgo extensively but have decided to move to Karaf >> for my current project. But I'd definitely like to see Gemini on Karaf. >> >> I believe your other scenario (camel, blueprint, spring contexts in >> the same bundle) is not possible with Aries Blueprint, but is possible >> with Gemini Blueprint. >> >> -- >> Raman Gupta >> VIVO Systems >> http://vivosys.com >> >> >> >> >> >> >> >> If you reply to this email, your message will be added to the discussion >> below: >> http://karaf.922171.n3.nabble.com/Aries-and-Spring-Co-Existance-in-Karaf-tp3438050p3470927.html >> >> To start a new topic under Karaf - User, email [hidden email] >> To unsubscribe from Karaf - User, click here . >> >> ----- >> Mike Van (All links open in new tabs) >> Committer - Kalumet >> >> Atraxia Technologies >> >> NCI Inc >> >> Mike Van's Open Source Technologies Blog >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Aries-and-Spring-Co-Existance-in-Karaf-tp3438050p3470974.html >> >> Sent from the Karaf - User mailing list archive at Nabble.com. > > > > > > If you reply to this email, your message will be added to the discussion > below: > http://karaf.922171.n3.nabble.com/Aries-and-Spring-Co-Existance-in-Karaf-tp3438050p3471177.html > > To start a new topic under Karaf - User, email > ml-node+s922171n930749...@n3.nabble.com > To unsubscribe from Karaf - User, click here . > > ----- > Mike Van (All links open in new tabs) > Committer - Kalumet > > Atraxia Technologies > > NCI Inc > > Mike Van's Open Source Technologies Blog > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Aries-and-Spring-Co-Existance-in-Karaf-tp3438050p3471232.html > Sent from the Karaf - User mailing list archive at Nabble.com.
