Hm this is fantastic, thanks David (both for the note here and for your contribution by way of the blog post)! Seems mostly in-line with what I’m looking for. Correct me if I’m wrong, but this seems also like the OSGi-standard way of approaching what Apache Karaf calls features in their provisioning model. Is that right?
If I may ask ― is there good tooling support for automating the creation of .esa files? I use a maven toolchain in-house so something such as the karaf-maven-plugin and it’s ability to generate feature files from Maven poms would be highly valuable. Bringing things full-circle, and taking into account both your and Felix M.’s advice here, it seems like a good picture is coming together about the solution I’d need to satisfy the use cases. Thanks for your help! Derek On 3/15/14, 3:02 PM, "David Bosschaert" <[email protected]> wrote: >Hi Derek, > >If you're looking for a quick intro into subsystems, have a look at >the following blog: >http://coderthoughts.blogspot.com/2013/04/osgi-subsystems.html >there is an updated post that uses Apache Felix here: >http://coderthoughts.blogspot.com/2014/01/osgi-subsytems-on-apache-felix.h >tml > >From briefly reading your mail, it looks like Subsystems allow >precisely the type of bundle constellation that you're looking for, >including sharing of bundles part of multiple constellations. >The abstraction to define these would be the Subsystems manifest >(SUBSYSTEM.MF (and possibly DEPLOYMENT.MF) files inside the subsystem. > >Subsystems are defined in OSGi enterprise spec chapter 134 >(http://www.osgi.org/Download/Release5) and are not technically >related to Deployment Admin (although you could view that they >supercede the deployment admin spec). > >Cheers, > >David > >On 15 March 2014 19:34, Derek Abdine <[email protected]> wrote: >> Thanks Felix! I'll take a look at these. By subsystems, do you mean >> subsystems of deployment admin or some other related OSGi service... ? >> >> Speaking of the event admin, is it common for this to be used for high >> velocity message piping through a formal message bus that may be >> distributed (i.e., rabbit, activemq, kafka, etc.)? Reading the spec a >> while ago I got the feeling that it was best used for lightweight >> in-container bundle communication. I'd be interested in any known >> real-world uses if you happen to know of any. >> >> Thanks again! >> D >> >> On 3/14/14, 1:00 AM, "Felix Meschberger" <[email protected]> wrote: >> >>>Hi >>> >>>Reading through your message Deployment Admin and Subsystems come to >>>mind. >>> >>>Also I have the impression that for wedding eventing you might want to >>>look into the EventAdmin service >>> >>>Regards >>>Felix >>> >>>On 14.03.14 01:35, "Derek Abdine" <[email protected]> wrote: >>> >>>>Hello all! I have a set of requirements that I¹d appreciate your >>>>feedback >>>>on. >>>> >>>> >>>>First, I want to be able to identify a set of bundles to deploy to an >>>>OSGi container through some configuration (perhaps represented as a >>>>file) >>>>in a way that allows multiple of such configurations to be deployed >>>>into >>>>a single container either locally or >>>> remotely. So: >>>> >>>>1. Configuration 1 - Featureset A >>>> >>>>1. Bundle A v1.0.0 >>>>2. Bundle B v1.2.1 >>>>3. Bundle C v1.0.0 >>>> >>>> >>>>2. Configuration 2 - Featureset B >>>> >>>>1. Bundle A v1.0.1 >>>>2. Bundle B v1.2.1 >>>>3. Bundle C v1.0.0 >>>> >>>> >>>> >>>>The end result would be that the container has bundles: A v1.0.0; A >>>>v1.0.1; B v1.2.1, C v1.0.0 installed. I¹m looking for a >>>>felix-compatible >>>>set of bundles that would allow me to apply both bundle configurations >>>>to >>>>a single container through some configuration >>>> abstraction (such as the configuration admin). From what I¹ve seen in >>>>Karaf, it seems to support this using feature files >>>>(https://karaf.apache.org/manual/latest-2.2.x/users-guide/provisioning. >>>>ht >>>>m >>>>l), >>>> alongside build tooling support (karaf-maven-plugin) to help build >>>>these >>>>files within maven. The only part that isn¹t clear is how I could >>>>remotely push commands to install, update and refresh features. Are >>>>there >>>>bundles or bundle sets that facilitate the >>>> workflow for this type of functionality? >>>> >>>> >>>>~~~ >>>> >>>> >>>>Second, I want a type of domain-specific language I can use to define >>>>instances of managed services which themselves have their own >>>>configuration. This is not unlike spring bean composition or ipojo¹s >>>>composition model >>>>(http://felix.apache.org/site/ipojo-composition-tutorial.html). >>>> For this case, I may have several bundles which I want to configure to >>>>work together in a similar way: >>>> >>>> >>>>Bundle A.impl: Listens for wedding bells, publishes an event on an >>>>implementation of B.api. Must be configured with a church to listen >>>>for. >>>>Bundle B.api: Defines a consumer of wedding events. >>>>Bundle B.impl1: Defines an implementation of B.api which saves the date >>>>and time of the bell ring to a database. >>>>Bundle B.impl2: Defines an implementation of B.api which saves the date >>>>and time of the bell ring to a flat file. >>>> >>>> >>>>All impl bundles create OSGi services. >>>> >>>> >>>>I want a way to express N variations of instance configuration and >>>>service composition, such as: >>>> >>>> >>>>BundleA.impl(church1) -> BundleB.impl1 >>>>BundleA.impl(church2) -> BundleB.impl1 >>>>BundleA.impl(church3) -> BundleB.impl2 >>>> >>>> >>>>As with the previous case, I¹d like to be able to perform CRUD >>>>operations >>>>on these configurations or construct them on the fly and push them into >>>>the container. I am using iPojo at the moment. It seems like something >>>>could be built, but I¹m wondering if >>>> there are ready-to-use bundles that handle workflows around >>>>locally/remotely publishing configurations, applying them, etc. Any >>>>thoughts? >>>> >>>> >>>>Thank you! >>>>Derek Abdine >>>> >>>> >>>> >>>> >>>> >>>>This electronic message contains information which may be confidential >>>>or >>>>privileged. The information is intended for the use of the individual >>>>or >>>>entity named above. If you are not the intended recipient, be aware >>>>that >>>>any disclosure, copying, distribution >>>> or use of the contents of this information is prohibited. If you have >>>>received this electronic transmission in error, please notify us by >>>>e-mail at ([email protected]) immediately. >>> >>>_______________________________________________ >>>OSGi Developer Mail List >>>[email protected] >>>https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> This electronic message contains information which may be confidential >>or privileged. The information is intended for the use of the individual >>or entity named above. If you are not the intended recipient, be aware >>that any disclosure, copying, distribution or use of the contents of >>this information is prohibited. If you have received this electronic >>transmission in error, please notify us by e-mail at >>([email protected]) immediately. >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >_______________________________________________ >OSGi Developer Mail List >[email protected] >https://mail.osgi.org/mailman/listinfo/osgi-dev This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at ([email protected]) immediately. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
