Benjamin Schmaus <[EMAIL PROTECTED]> writes: > Also, in the case of a ManagedServiceFactory, if a factory PID > exists with several Configurations (and matches a component name) > then a DS component will be created for each Configuration.
Great, that's exactly what I'm looking for. > I posted some configuration-related work over at ops4j, which may be > of interest to you. > > https://scm.ops4j.org/repos/ops4j/laboratory/users/bschmaus/net.tucana.osgi.impl.config/README Nice. I've just started thinking about this "how to feed the configuration data from /outside/ my bundles" problem, and it looks like you've already solved it. > IMO, I think that the days of DeclarativeServices may be numbered > since Spring sounds pretty serious about supporting OSGi, and there's > also the iPOJO project which is similar to DS. My head hurts. I had glanced at iPOJO before even noticing that DS was part of the OSGi Compendium, and I concluded that iPOJO must have been a kind of prototype that would be subsumed by DS. Do I have this backwards? And now Spring: I've seen the phrase "Spring/OSGi" mentioned, but not until I've come to be familiar with DS does applying Spring to OSGi make more sense to me. The Spring OSGi specification hits a lot of the same points as DS. Less obvious is how much of Spring one must bite off to take advantage of its OSGi services. With DS, one can use it or not on a bundle-by-bundle basis, and even use it in part for some components in a bundle. Do you know if Spring OSGi will allow this kind of selective, piecemeal integration? Finally, given these choices of similar DS-like technologies, which one are /you/ betting on? -- Steven E. Harris _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
