http://cxf.apache.org/dosgi-ds-demo-page.html
I see the SCR using XML in there but the annotations and SCR
annotation processor Maven plugin will automatically create that won't
it. I'm so used to using blueprint that it all feels a bit lopsided.
On Wed, Sep 7, 2016 at 9:52 AM, Brad Johnson
<brad.john...@mediadriver.com <mailto:brad.john...@mediadriver.com>>
wrote:
http://cxf.apache.org/docs/a-simple-jax-ws-service.html
<http://cxf.apache.org/docs/a-simple-jax-ws-service.html>
That looks a lot like what I'm looking for. Then I could set up a
server bundle to do the repetitious stuff and have it export a
service like SoapServer that takes a SoapInstallEvent and inside
that I could send the interface, implementation and URI.
Obviously the URI could be settable in cfg or properties file.
Then when the bundle is being uninstalled it could send a
SoapUninstallEvent. So the SoapServer OSGi service would only
take those two events. Obviously I could set up the same thing for
REST service.
In that blueprint project I did that's pretty much how I handled
it and it worked fine but I never knew about what the transport
was really doing (Jetty, HTTP server, etc.) I don't like rolling
my own code like that when it's far better letting the guys who
know the libraries set it up.
Brad
On Wed, Sep 7, 2016 at 9:16 AM, Brad Johnson
<brad.john...@mediadriver.com
<mailto:brad.john...@mediadriver.com>> wrote:
I'll give it a look. That sounds like a move in the right
direction. In the short term I'll just set up the CXF
server/endpoints with blueprint and use the camel recipient
list to route them to the correct bundle. That doesn't work
well for microservices. It probably would be OK for cxfrs
since it can take lists of interfaces to expose and those
could be read from an external configuration file. To move a
service in or out one would just modify the etc cfg file to
add or remove the service interface and install or uninstall
the bundle. But I don't think that the CXF soap server can
take lists like that as far as I know.
The CDI annotations added in to pax-cdi for using OSGi
services right from a bundle using only CDI and not a
combination of CDI/DS is a very big deal I think. That's
going t be a real winner for a couple of reasons. First it
has fewer dependencies and annotations one must get right.
Second it will aid folks from other platforms who know how to
use CDI but are not as familiar with OSGi or DS. So making the
move from any platform to the Camel, pax-cdi platform is going
to be much smoother.
Brad
On Wed, Sep 7, 2016 at 1:34 AM, Christian Schneider
<ch...@die-schneider.net <mailto:ch...@die-schneider.net>> wrote:
For CXF in DS or CDI you should try CXF DOSGi. I am
currently woking on a new major version that is slimmer
and should allow almost all CXF settings you can also do
in blueprint.
The idea is to publish the settings as OSGi services
marked as intents. The new CXF DOSGi examples are all
using DS and one example shows the setup of https with
client cert authentication which was not possible before
without blueprint.
Christian
2016-09-07 0:19 GMT+02:00 Brad Johnson
<brad.john...@mediadriver.com
<mailto:brad.john...@mediadriver.com>>:
I'll definitely get my Nexus instance pointed at that
repo and pull it down. One of the biggest problems
I'm going to have in the near term is that the
blueprint CXF allows for set up of everything to run
on Jetty fairly easily but to do the same thing on
straight Java I end up having to roll that myself.
Perhaps an SCR/CDI library using the pax-cdi is in the
works once it has been released. I'll probably look
at the Camel src code for CXF to see how they do it
internally with blueprint and attempt to duplicate it.
One of the frustrations I was having trying to do the
CDI/SCR was that I have it working perfectly well in
one project but couldn't get it to work correctly in
the second project. I'm trying to make this so my
bundles can be microservices that when installed are
picked up by the CXF Rest and/or SOAP service and
register themselves and when they are undeployed
automatically unregister. That's important in
environments where you might find out that one of the
bundles is getting hammered by traffic on occasion and
that brings the whole bunch to a crawl. But if you
can just uninstall it and move it to a duplicate
karaf/felix installation on another machine/VM and
have it auto deploy itself it makes that a snap.
I did something with blueprint that was that way
though I confess some of the configurability was a bit
overkill. Still, one bundle might require badgerfish,
as I had in a recent installation, while others did
not. Simply registering the bundle and having the
SOAP/REST server pick it up made that easy to
configure. A bit of bundles as microservices. The
only way I can think of reasonably doing this now with
just annotated classes is if I could inject the
blueprint create servers into my classes but I'm not
sure what they'd even look like in that context. What
I ended up with is creating my own JaxRSFactory and
the equivalent with SOAP and starting them up. Of
course that meant they were running on the internal
HTTP server and not on something more suited to an
enterprise environment.
https://github.com/Ranx0r0x/Enjekt-Microservice
<https://github.com/Ranx0r0x/Enjekt-Microservice>
On Tue, Sep 6, 2016 at 1:57 PM, Guillaume Nodet
<gno...@apache.org <mailto:gno...@apache.org>> wrote:
You need to use the 1.0.0-SNAPSHOT version
available from the following maven repository:
https://oss.sonatype.org/content/
<https://oss.sonatype.org/content/>*reposito*ries/ops4j-snapshots
I've just uploaded a new version to make sure it's
up to date.
2016-09-06 20:50 GMT+02:00 Brad Johnson
<brad.john...@mediadriver.com
<mailto:brad.john...@mediadriver.com>>:
Is there a newer or extension bundle than:
pax-cdi-api-1.0.0.RC1.jar
I don't see these annotations in there an
Eclipse can't find them.
org.ops4j.pax.cdi.api.Component
org.ops4j.pax.cdi.api.Immediate
org.ops4j.pax.cdi.api.Service
On Tue, Sep 6, 2016 at 11:09 AM, Guillaume
Nodet <gno...@apache.org
<mailto:gno...@apache.org>> wrote:
The new annotations are
org.ops4j.pax.cdi.api.Component
org.ops4j.pax.cdi.api.Immediate
org.ops4j.pax.cdi.api.Service
...
Those annotations are different from the
SCR or DS annotations, so you clearly do
not need the felix scr annotations bundle.
Guillaume
2016-09-06 17:51 GMT+02:00 Brad Johnson
<brad.john...@mediadriver.com
<mailto:brad.john...@mediadriver.com>>:
@gnodet
I have been using the new CDI along
with Camel 2.17.3 and it sounds as if
I don't need the SCR at all then? So
I'd be able to remove the felix scr
annotations dependency? The last
element in the list which I've italicized.
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
</dependency>
<dependency>
<groupId>org.ops4j.pax.cdi</groupId>
<artifactId>pax-cdi-api</artifactId>
<version>1.0.0.RC1</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-cdi</artifactId>
</dependency>
///<dependency>/
/<groupId>org.apache.felix</groupId>/
/<artifactId>org.apache.felix.scr.annotations</artifactId>/
/</dependency>/
On Tue, Sep 6, 2016 at 10:47 AM, Brad
Johnson <brad.john...@mediadriver.com
<mailto:brad.john...@mediadriver.com>>
wrote:
@gnodet
Thanks for the info regarding the
@OsgiServe/@OsgiServiceProvider.
Perhaps that's where I go the idea
that one needed to specify start
up order on bundles. In some
recent test projects I have been
using the Felix SCR but most of
the testing has been using the
CamelCDI runner as it is very
fast. That obviously creates some
problems with having to double
annotate some items for Inject vs
Reference and so on and the fact
that CDI isn't going to respect
bundle boundaries inside the
test. But that isn't a huge
problem because in the context of
testing it isn't like I have 300
bundles running. It's just a few
application bundles and their
dependencies.
It does mean I'll have to get
ready to deal with some errors
when moving from the IDE
environment over to the
Karaf/felix environment but for
development/testing speed it
definitely seems worth it.
I'm so used to using
CamelBlueprintTestSupport and
blueprint.xml that all of this
still feels a bit left handed --
"If I were doing this in
blueprint, this what I'd do...."
On Mon, Sep 5, 2016 at 6:38 AM,
Guillaume Nodet <gno...@apache.org
<mailto:gno...@apache.org>> wrote:
I don't really recommend using
the @OsgiService /
@OsgiServiceProvider of Pax-CDI.
The main reason is that if the
bundles are not started in the
correct order, the bean
validation will simply fail
and your CDI app won't be
created at all.
I'd really recommend to look
at the new annotations of
Pax-CDI which haven't been
released yet (in
1.0.0-SNAPSHOT). They are very
similar to the DS semantics
(and they actually use part of
Felix SCR implementation as
the core engine). The
lifecycle of the CDI beans is
similar to those of DS, so the
dependency mechanism is really
straightforward from a user
point of view.
Cheers,
Guillaume
2016-09-02 19:46 GMT+02:00
Brad Johnson
<brad.john...@mediadriver.com
<mailto:brad.john...@mediadriver.com>>:
Matt,
For the past few weeks
I've been working with the
Camel 2.17 CDI and it's
marvelous. I've been using
blueprint for a few years
now and I won't be going
back to twiddling XML
unless I have to (I'm not
sure how to set up CXF
server without it right
now). But the CDI test
runner is fast and a snap
to use. The annotation
automated wire up and
RouteBuilder automatic
running is just like you'd
think ought to be.
The pax-cdi implementation
actually creates blueprint
proxies for annotations
like @OSGiServiceProvider
and will inject it where
you specify the service
consumer. The only caveat
to the CDI test runner is
that it is not OSGi based
but uses Weld. So you
have to be careful about
what you test but I can
live with that. Truly
stunning when one sees a
technology that works
almost like magic - like
you'd dream it should work.
On Fri, Sep 2, 2016 at
12:04 PM, Matt Sicker
<boa...@gmail.com
<mailto:boa...@gmail.com>>
wrote:
On 2 September 2016 at
11:30, Timothy Ward
<timothyjw...@apache.org
<mailto:timothyjw...@apache.org>>
wrote:
As things stand
currently
blueprint is most
widely used for
working with
Camel. From what I
can tell
configuring Camel
is horrible, and
my understanding
is that the main
advantage of
blueprint is that
there is a huge
amount of
ready-built Camel
integration
available. If
Camel had a nicer,
container agnostic
configuration
mechanism then I
would see little
reason to choose
blueprint over DS.
This right here is
exactly how I feel. If
there was a well
supported way of
simply using DS
instead of Blueprint
with Camel, then I'd
drop Blueprint in a
single sprint and
never look back.
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gno...@redhat.com
<mailto:gno...@redhat.com>
Web: http://fusesource.com
<http://fusesource.com/>
Blog:
http://gnodet.blogspot.com/
<http://gnodet.blogspot.com/>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gno...@redhat.com
<mailto:gno...@redhat.com>
Web: http://fusesource.com
<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
<http://gnodet.blogspot.com/>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gno...@redhat.com <mailto:gno...@redhat.com>
Web: http://fusesource.com <http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
<http://gnodet.blogspot.com/>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
