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.html
>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
