I would greatly appreciate if you could look into a better way of
combining camel with DS.
I recently tried to make camel work with DS and found that the DS
support camel provides is quite complex and does not work well.
See http://camel.apache.org/camel-and-scr.html
The problem are the camel components. These are announced as services
and must be available before you start the camel context.
The camel scr AbstractCamelRunner needs a lot of config to run and still
is not correct. The problem is that it simply adds and removes the
components at runtime
but once the camel context starts it is too late to add a component.
You will not notice the problem in karaf as karaf has very specific
start level settings for the components to make sure they come up early
but this sucks.
I have used a different approach for a demo:
https://github.com/cschneider/osgi-chat/blob/master/irc/src/main/java/net/lr/demo/chat/irc/IRCConnector.java
I simply add mandatory references to all components I use. So DS makes
sure my component only comes up once everything is in place and also
stops when some component is missing.
This works fine but is a bit inconvenient. Maybe you have a better idea
how to do this.
Btw. For CXF support I currently work on improvements for Remote Service
Admin with CXF as a provider I think this is currently the best way to
use CXF in DS but we have to make sure it covers
all use cases people have. The CXF blueprint support allows a lot of
settings and we have to make sure the RSA support can also offer all the
needed customizations.
Hibernate support works quite well now with Aries JPA and JPATemplate or
alternatively with Aries tx-control.
Christian
On 08.07.2016 02:49, David Jencks wrote:
It sounds like as a DS partisan I should investigate camel and figure
out a good DS way to come up with a route :-)
thanks
david jencks
On Jul 7, 2016, at 4:08 PM, Brad Johnson
<[email protected] <mailto:[email protected]>>
wrote:
Interesting that there should be such a discrepancy from what I see
in the field and the specification work that's going on. If you look
at the releases related to Aries, for example, the multiple blueprint
projects have had multiple releases and updates this past year. Just
looking at the Maven repo shows an incredible amount of activity.
The Blueprint CM 1.0.8 was just released this March.
I sound like a blueprint advocate but I'm not really. I actually
loathe working in XML. Believe me I've had a few years of blueprint
headaches and have more than enough complaints about it. I just need
pragmatic ways of wiring Camel and OSGi services together for
enterprise applications with the dependency injection and OSGi
interoperability and Camel EIPs that blueprint provides. If
something better comes along then great, I'm all for it.
But I've also had enough experience withe Camel Java route builders
to not really want to get into them again (despite the advantages in
the IDE). And SCR annotations are pretty ugly quite frankly (I know,
everyone has their own opinion of that). While I find the debate
about proxy versus cascading services mildly interesting from an
intellectual standpoint it isn't of tremendous importance to me. What
is important to me is that my EIPs and routes work when I'm counting
on a service reference being available. But I guess I can always dip
into service order start up to hopefully make such guarantees.
Perhaps someday when someone writes that enterprise Camel with SCR
book that makes it all easy and great in the day-to-day enterprise
development world with CXF, JMS, Hibernate and so I'll flip to
declarative services and abandon Blueprint. In the meantime I'm
stuck with it as a tool.
Frankly if DS is the only game in town for the future then perhaps
it'll be time to explore the wider world of technologies.
On Thu, Jul 7, 2016 at 4:48 PM, David Jencks <[email protected]
<mailto:[email protected]>> wrote:
Well, its the user list rather than dev list, but that’s minor.
My point is that you are suggesting designing some new
functionality for (possibly) blueprint. I suggest that if you
want to end up with a good design, you get osgi experts
involved. In my experience this results in a much improved
design over what I can come up with by myself.
You are also telling me that blueprint is very popular among osgi
users. My personal impression from working on osgi specs is that
blueprint is regarded as basically dead as there has been no spec
activity since IBM pushed the original spec. Getting involved in
updating the blueprint spec for R7 might be a good way to
popularize the benefits of blueprint — just because I don’t see
them doesn’t mean they aren’t there.
Finally, I’m not convinced that you have a good understanding of
the different services and their currently specified behavior.
If multi-location solves your problem and you are on R4.2 the
solution is not to reinvent it for R4.2 or blueprint but to
upgrade to R5+.
thanks
david jencks
On Jul 7, 2016, at 12:38 PM, Brad Johnson
<[email protected]
<mailto:[email protected]>> wrote:
Isn't this the Aries discussion forum which has a Blueprint
implementation? Why would this be the incorrect place to ask
about such issues?
On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson
<[email protected]
<mailto:[email protected]>> wrote:
As I said on the Camel mailing list Red Hat isn't pushing
that approach and I can't push my clients into things they
don't want. You and Scott England Sullivan seem to be the
ones who think that DS is going to save the world. I have a
number of friends in consultancy both inside and outside Red
Hat and they don't like or push DS.
On Thu, Jul 7, 2016 at 2:30 PM, David Jencks
<[email protected] <mailto:[email protected]>> wrote:
I strongly suggest that you work on this in the context
of an OSGI RFP/RFC. You are apt to get much better
advice that conducting the design discussion here. I
think it’s fairly ridiculous that after all these years
blueprint’s relationship to config admin is unspecified.
I think that there are no “blueprint people” other than
users these days.
I would also suggest studying at least the R6 config
admin spec and understanding multi locations as that
will make it clear that blueprint shouldn’t have
anything explicit to do with bundle locations and that
your concerns about sharing configuration across bundles
have been dealt with in the appropriate spec already.
In addition I suggest studying the DS R6 multiple pid
support as a possible model for what you are interested
in. I don’t think your apparent idea of using pid name
parsing as the way of relating multiple pids is very
scalable or comprehensible.
On the other hand, you could approach this all from a
management agent perspective and have the management
agent merge configuration source data with related
“names" into a single configuration. This would work
with current blueprint cm.
I think that merging data in config admin is an
untenable approach. It certainly wasn’t the approach
adopted for DS, and I would think getting spec support
for it would be difficult.
david jencks
> On Jul 7, 2016, at 10:53 AM, Brad Johnson
<[email protected]
<mailto:[email protected]>> wrote:
>
> As I work in more environments now that want to use
microservices the limitations of the blueprint
properties mechanics become a bit hairier. I commonly
find that I have bundles that have common properties
shared across them and I can't find a good solution
other than creating my own OSGi service for serving them
up for such crosscutting concerns.
>
> I'm not an expert on the specification and
implementations of compendium or blueprint libraries so
don't know how feasible something like this would be but
I would find the following terribly useful.
>
> A properties hierarchy much like Maven that permits
you to specify a parent that you inherit from and then
can add to or override.
>
> com.foo.parent.cfg
> com.foo.child.cfg
>
> The child cfg file might have a #! directive at the
top specifying com.foo.parent PID. And if another one was
>
> com.foo.grandchild.cfg
>
> it might specify com.foo.child as its parent. Then
the CM would load parent, override it with child and
finally override that grahdchild.
>
> Yes, I'd still have to specify
>
> <cm:property-placeholder
persistent-id="com.foo.granchild" update-strategy="reload">
>
> in my bundle and that would still be bound to that
single bundle but this could alleviate the need for
replication of properties across a lot of bundles.
>
> Technically that is all rather straightforward but I'm
not sure how well that would align with the
specifications or goals of CM.
>
> Brad
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
