Re: DS vs Blueprint

If you use ds then you can always override any service property using a config. This allows to dynamically change the address at runtime. Christian Am 08.09.2016 16:39 schrieb "Brad Johnson" : > Perfect. Thanks. It was always a bit unclear as to whether I was

Re: DS vs Blueprint

Perfect. Thanks. It was always a bit unclear as to whether I was firing up a new instance of HTTP server instead of reusing the instance specified in the Jetty setup. It sounds though that as long as I specify uri and port along with everything else I get the Jetty instance. That makes it a lot

Re: DS vs Blueprint

It simply uses the existing HttpService so it will not start a new instance. You can even use the felix http service bundle instead. CXF will not care. I typically use this variant as it only needs one port for all services which makes it easier to manage. Christian 2016-09-08 0:25 GMT+02:00

Re: DS vs Blueprint

Ah, very good. Does it start a new instance or does it piggyback endpoints on the already running one configured in the etc dir? (Yeah, I promised no more questions but a guy's just gotta know!) On Wed, Sep 7, 2016 at 4:01 PM, Christian Schneider wrote: > It depends

Re: DS vs Blueprint

It depends on the address (like in plain cxf). If the address start with / then it will use the HttpService of the container. If it starts with http://server:port it will start a new jetty instance. Christian 2016-09-07 22:18 GMT+02:00 Brad Johnson : > Thanks.

Re: DS vs Blueprint

Thanks. Fuse launches Jetty by default I just wanted to make sure that under the covers it wasn't using its own server instead. Brad On Wed, Sep 7, 2016 at 3:13 PM, Benson Margulies wrote: > On Wed, Sep 7, 2016 at 4:03 PM, Brad Johnson >

Re: DS vs Blueprint

On Wed, Sep 7, 2016 at 4:03 PM, Brad Johnson 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

Re: DS vs Blueprint

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 < ch...@die-schneider.net> 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

Re: DS vs Blueprint

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

Re: DS vs Blueprint

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

Re: DS vs Blueprint

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,

Re: DS vs Blueprint

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

Re: DS vs Blueprint

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

Re: DS vs Blueprint

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 : > Is

Re: DS vs Blueprint

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

Re: DS vs Blueprint

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

Re: DS vs Blueprint

As with anything that uses the OSGi Service Registry properly, DS waits for a service to be available before activating a component which uses that service. This means that there is no configuration of startup order, and that there are no points when the graph is incomplete assuming that: a)

Re: DS vs Blueprint

I hadn't really either until just recently. It won't take long to pick it up. If your bean needs access to a route you just have ProducerTemplate injected. If your route needs access to a bean you just name the bean with @Named and refer to it in your route with the string "bean:myBeanName".

Re: DS vs Blueprint

I've never used CDI before, but that's certainly worth looking into. Thanks. On 2 September 2016 at 12:52, Brad Johnson wrote: > http://camel.apache.org/cdi.html > http://camel.apache.org/cdi-testing.html > https://ops4j1.jira.com/wiki/display/PAXCDI/Cheat+Sheet >

Re: DS vs Blueprint

http://camel.apache.org/cdi.html http://camel.apache.org/cdi-testing.html https://ops4j1.jira.com/wiki/display/PAXCDI/Cheat+Sheet On Fri, Sep 2, 2016 at 12:34 PM, Brad Johnson wrote: > Yes but doesn't the independent start up order of DS require configuration > of

Re: DS vs Blueprint

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

Re: DS vs Blueprint

On 2 September 2016 at 11:30, Timothy Ward 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 >

Re: DS vs Blueprint

I've been using DS annotations and XML Blueprint. If I can ditch Blueprint for CDI in 2.17, that might be a nice upgrade honestly. On 27 August 2016 at 14:04, Brad Johnson wrote: > The Camel 2.17 CDI implementation will automatically pick up the > RouteBuilders. I

Re: DS vs Blueprint

The Camel 2.17 CDI implementation will automatically pick up the RouteBuilders. I was kicking the tires on it and was very pleased. The RouteBuilders in turn pick up their dependencies from either in bundle annotated beans and providers or from external OSGi services. Pretty slick. Matt, do you

Re: DS vs Blueprint

I've been using the Java DSL route builders, and you still need to use Blueprint just to load them via in the element. On 27 August 2016 at 13:44, Brad Johnson wrote: > I assume you mean blueprint XML routebuilders and not Java DSL > routebuilders? I've used

Re: DS vs Blueprint

I assume you mean blueprint XML routebuilders and not Java DSL routebuilders? I've used the XML approach for a long time. CamelBlueprintTestSupport has gotten much better but it still has limitations on multiple contexts and I find I'm commonly debugging the tests as much as making the code run

Re: DS vs Blueprint

Also, if I could go without seeing a bundle in a GracePeriod state ever again, that would be great. I love lazy evaluation in programming languages, and since DS provides a neat way to lazily load components, it would be great for Camel to support lazy loading of everything as well. This

Re: DS vs Blueprint

If the Blueprint support in Camel were less Blueprint-biased and more generic to OSGi services, then I feel it would integrate much better with DS. I've been using DS for services more often lately because wiring s in an XML file is so blasé, but I still need to use BP to load my Camel routes, and

Re: DS vs Blueprint

I actually personally passionately hate not using RouteBuilders so for me BP really is about inversion of control and I prefer argument to properties so I can easily test the same code, not to mention I never have to dig for a NPE bean wiring in large systems. /je > On Aug 27, 2016, at 11:44

Re: DS vs Blueprint

Agreed that it is philosophical and can be contentious. I just started using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also I think the pax-cdi that Guillame and I think JB Onofre created are relatively new. So I've just started using and have a project using it without any

Re: DS vs Blueprint

I’ve never seen DS used in the wild other than in places where say central infrastructure IT provides container services and frameworks. Still have to see a lot of CDI use and with PaaS offerings and Spring revamps and a lot of push BP is from what I gather the only viable alternative. Just my

DS vs Blueprint

While I understand the benefits of DS I'm wondering if it makes much difference for end users. I mean if I were creating a library for commons, XStream, Beanio or something else then it makes a lot of sense to expose it via DS. But when creating end user bundles with Camel routes, beans,