multilocation sounds fantastic. Can't wait for the day. I'm curious, do you think we don't quite understand the concept? It really isn't that difficult. How does that work in R4 David? Blueprint isn't getting updated anymore so I can't imagine it going in anytime soon. Besides from what I can see OSGI group seems to be inhabited by anti-blueprint, DS zealots.
That isn't how this works worth the Maven mojos. Generate everything, install via features and later if you want to install a crosscut ting change you modify that shared property and the filtered resources put them in the appropriate cfg file and build that into the bundle. Rerun the features install and overwrite the cfg. If you reuse a port in five cfg files, then you change that in a shared properties file which is loaded. When the filtered cfg files are written out, the port gets filled in. Want to change the port? Simply modify the propetry, rerun the build and simply reinstall the features.
Most of that would be pretty automatic. Check in your properties to source control, build kicks off in Jenkins, bundle of cfg files is created and installed in Nexus. Rerun your features install and pick up all the changed cfg's.
That takes one configuration bundle. One properties and resources plug-in configuration and you are done.
Or you can get involved in trying to get some interest in adding something to blueprint from the OSGI group who are actively hostile to blueprint. We can wish that maybe the large chunk of us who live with karaf 2.x and R4 might somehow get the crumb of features handed down.
My concern is the near monomania for DS in the OSGI group as if solving that one very hairy problem is going to yield an abundance.
From my perspective we've lost almost 4 years to DS pipe dreams and something as basic as Camel SCR is a mess and doesn't seem much used much less loved by anyone.
Four years ago I thought OSGI was on the cusp of a breakout. I'm pretty sure that isn't the case anymore. Was DS navel gazing responsible? It contributed. Especially all the shouting down of technologyes that don't contribute toward the DS dream .
Interestingly there are so many of us involved in OSGI and Camel and blueprint who are now looking for our next home. Where will I be doing Middleware development in 5 years? Probably still use Camel and Maven. OSGI? Perhaps not.
On Jul 11, 2016 5:31 PM, "David Jencks" <[hidden email]> wrote:
I started out in OSGI as a blueprint zealot (I wrote xbean-blueprint, for instance, partly to help integrate activemq into geronimo 3). After being forced nearly against my will to do some DS work, I came to see it’s advantages for the kinds of problems I work on, and at the moment can’t imagine problems that would long-term be better solved with blueprint. That doesn’t mean they don’t exist, and certainly doesn’t mean that for instance blueprint isn’t the best solution for running a project on both non-osgi spring and osgi. At the moment I’m in the fortunate position of not having to do that.
I’m quite sure that if anyone showed up and started working on an osgi blueprint spec update they would be welcomed. AFAIK no one has since IBM pushed the original spec through and more or less financed the development of the aries implementation. However, any spec update would be part of R7, not R4, so if you are constrained to an R4 environment a spec update wouldn’t do you any good.
I’m pretty sure that blueprint as it exists now would work fine with multi locations on something that has an R5+ config admin and a way to actually set the multilocation. I expect that if it doesn’t already support setting multiloication it would be nearly trivial to enhance karaf to do it. It would be nice to find out what happens.
If a vendor is leaving an osgi based product at R4 I would question their commitment to OSGI support. That’s not something the Apache Aries community can help much with AFAIK.
I”ve never actually used camel, but due to this discussion I just started looking at camel’s osgi usage and camel-scr. So far I’m somewhat surprised it works at all. It’s not always a good idea to try to wrap something designed to work in a javaee environment, full of ee-isms, into osgi as there are generally much simpler and more direct ways of solving problems than the ee-isms allow for. Possibly I may have some suggestions after I understand the code better. For instance, IIUC Christian mentioned that there are problems with optional dependencies not getting resolved at an appropriate time. This can often be solved using configuration, using a <target-name>.cardinaitly.minimum property to make the reference not optional.
With the small amount of camel knowledge I have so far, I’d think that the java DSL would generally be the easiest configuration route. Could you supply an example where you think xml is more convenient?
|Free forum by Nabble||Edit this page|