On Wed, Sep 7, 2016 at 4:03 PM, Brad Johnson
<[email protected]> wrote:
> 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";);
That depends on which CXF transport you include. You can depend on
pax-web, or you can let CXF launch jetty for itself.
>
> But if Jetty is running on port 8081 then if I change that to:
> svrFactory.setAddress("http://localhost:8081/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/repositories/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
>>>>>>
>>>>>> Open Source Architect
>>>>>> http://www.talend.com
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>
>>
>
