Christian,
One last question and I promise to stop. In the simple example, when
starting the JaxWsFactory bean or its equivalent in Rs, that will not take
advantage of Jetty in a stack like ServiceMix or Fuse but use its own
in-built HttpServer. Do I have that correct? In a lot of cases it won't
really matter if I use the same address? The simple example uses:
svrFactory.setAddress("http://localhost:9000/helloWorld";);
But if Jetty is running on port 8081 then if I change that to:
svrFactory.setAddress("http://localhost:8081/helloWorld
<http://localhost:9000/helloWorld>");
will that simply use the Jetty port?
http://cxf.apache.org/docs/a-simple-jax-ws-service.html
On Wed, Sep 7, 2016 at 10:44 AM, Brad Johnson <[email protected]>
wrote:
> Great, that's sort of how I figured it would work and I'l give it a shot.
>
> Brad
>
> On Wed, Sep 7, 2016 at 10:36 AM, Christian Schneider <
> [email protected]> wrote:
>
>> In the old code the DS xml was manually created. The wiki is still at
>> that level.
>> In the new code the user only uses annotations and the maven bundle
>> plugin does the xml creation.
>>
>> Christian
>>
>>
>> On 07.09.2016 17:06, Brad Johnson wrote:
>>
>> 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 <
>> [email protected]> wrote:
>>
>>> 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 <
>>> [email protected]> 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 <
>>>> [email protected]> 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 <[email protected]>:
>>>>>
>>>>>> 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
>>>>>>
>>>>>> On Tue, Sep 6, 2016 at 1:57 PM, Guillaume Nodet <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> You need to use the 1.0.0-SNAPSHOT version available from the
>>>>>>> following maven repository:
>>>>>>> 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 <
>>>>>>> [email protected]>:
>>>>>>>
>>>>>>>> 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 <[email protected]
>>>>>>>> > 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 <
>>>>>>>>> [email protected]>:
>>>>>>>>>
>>>>>>>>>> @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 <
>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>> [email protected]>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <[email protected]
>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2 September 2016 at 11:30, Timothy Ward <
>>>>>>>>>>>>>> [email protected]> 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: [email protected]
>>>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ------------------------
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Red Hat, Open Source Integration
>>>>>>>>>
>>>>>>>>> Email: [email protected]
>>>>>>>>> Web: http://fusesource.com
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Red Hat, Open Source Integration
>>>>>>>
>>>>>>> Email: [email protected]
>>>>>>> Web: http://fusesource.com
>>>>>>> Blog: 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>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Christian Schneiderhttp://www.liquid-reality.de
>>
>> Open Source Architecthttp://www.talend.com
>>
>>
>
