You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Ranx <br...@mediadriver.com> on 2016/01/29 01:02:27 UTC
Camel SCR
Having worked with blueprint and CamelBlueprintTestSupport for a couple of
years now at different clients I'm trying to find a better alternative. I
go into clients who usually have a lot of Java developers so staying in the
familiar Java world is something they appreciate.
As of 2.16 the SCR is core and it can be used with earlier versions. I'm
wondering how many folks are using it in development and production and what
sort of experiences they've been having with it.
Essentially, do folks feel it is ready for primetime?
One concern I have is the registry mechanics. In the example generated by
the archetype it uses the simple registry and not an OSGi registry. Perhaps
that's not a problem but with blueprint crossing registry boundaries can
lead to quirky behavior.
Any thoughts, guidance, clues, guesses, gesticulations, hare brained
schemes, cogent remarks or deep technical insights are all appreciated.
Brad
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel SCR
Posted by Ranx <br...@mediadriver.com>.
I kind of like the fact that it is generating the XML and not interpreting
the annotations at runtime. At least if there are problems you can crack
open the jar file and look at the generated XML to see what's going on.
When I mentioned the configuration I was thinking about the Maven plugin
that does this and feature that does what follows:
*Plugin*
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>src/main/resources/configuration.cfg</file>
<type>cfg</type>
<classifier>configuration</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
*Feature*
<configfile
finalname="/etc/${project.groupId}.invoice.${project.version}.cfg">mvn:${project.groupId}/invoices/${project.version}/cfg/configuration</configfile>
Obviously one would have to put up some sort of metadata tag in the bundle
so it would know the associated cfg file. But with my deep ignorance of
SCR I don't know if that would work or not.
On Fri, Jan 29, 2016 at 2:05 PM, Quinn Stevenson [via Camel] <
ml-node+s465427n5777015h90@n5.nabble.com> wrote:
> We haven’t found a plugin to generate the CFG files (property files in our
> case) - they’re created by hand. Luckily they don’t change much - that’s
> why the rename thing for semantic versioning will be a royal pain.
>
> I sympathize with the issues you’re having with CamelBlueprintTestSupport
> - until recently, it’s been very problematic with the race conditions.
> Since the last set of fixes went in, I haven’t had any issues. Note that
> the Camel archetype for blueprint used to generate a bad configuration in
> the POM that caused me a lot of grief. I submitted a PR and it was merged
> into 2.17-SNAPSHOT, but you could use that and then change the Camel
> version in the POM and get a good start.
>
> That said, by using the Java RouteBuilders, we can test our routes using
> CamelTestSupport and get around all those CamelBlueprintTestSupport
> issues. We’re working on some integration tests as well using Pax Exam, so
> we’ll only be using CamelBlueprintTestSupport during development - we won’t
> care so much if those test fail in our CI builds.
>
> The one thing about camel-scr I don’t particularly like is all the
> annotations - it really muddies-up the code. They are only used by the
> maven-scr-plugin to generate a beans.xml file. I think I’d rather build
> this file using maven filters or something. Also, watch out for the
> version of the maven-scr-plugin you use - I don’t remember which version it
> was, but one of the newer ones didn’t work (a beans.xml file wasn’t
> generated).
>
>
> > On Jan 29, 2016, at 12:55 PM, Ranx <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5777015&i=0>> wrote:
> >
> > Thanks for the insights. It sounds as if the cfg files would need a
> form of
> > semantic versioning then like bundles use. Obviously my insights are
> > limited. Do you create your configuration files via the maven plugin
> and
> > install them in etc with a feature? That might obviate some of the
> pain.
> >
> > I'd have to look a bit closer at it. I do like what I see of it. I get
> > tired of XML fingerfehlers causing CBTS to hang with the rather nebulous
> > "Gave up waiting for CamelContext" errors. I'm also an old Java hack so
> > prefer it anyway.
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5777014.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5777015.html
> To unsubscribe from Camel SCR, click here
> <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5776954&code=YnJhZC5qb2huc29uQG1lZGlhZHJpdmVyLmNvbXw1Nzc2OTU0fDI4MjkxODI4OQ==>
> .
> NAML
> <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5777016.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel SCR
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
We haven’t found a plugin to generate the CFG files (property files in our case) - they’re created by hand. Luckily they don’t change much - that’s why the rename thing for semantic versioning will be a royal pain.
I sympathize with the issues you’re having with CamelBlueprintTestSupport - until recently, it’s been very problematic with the race conditions. Since the last set of fixes went in, I haven’t had any issues. Note that the Camel archetype for blueprint used to generate a bad configuration in the POM that caused me a lot of grief. I submitted a PR and it was merged into 2.17-SNAPSHOT, but you could use that and then change the Camel version in the POM and get a good start.
That said, by using the Java RouteBuilders, we can test our routes using CamelTestSupport and get around all those CamelBlueprintTestSupport issues. We’re working on some integration tests as well using Pax Exam, so we’ll only be using CamelBlueprintTestSupport during development - we won’t care so much if those test fail in our CI builds.
The one thing about camel-scr I don’t particularly like is all the annotations - it really muddies-up the code. They are only used by the maven-scr-plugin to generate a beans.xml file. I think I’d rather build this file using maven filters or something. Also, watch out for the version of the maven-scr-plugin you use - I don’t remember which version it was, but one of the newer ones didn’t work (a beans.xml file wasn’t generated).
> On Jan 29, 2016, at 12:55 PM, Ranx <br...@mediadriver.com> wrote:
>
> Thanks for the insights. It sounds as if the cfg files would need a form of
> semantic versioning then like bundles use. Obviously my insights are
> limited. Do you create your configuration files via the maven plugin and
> install them in etc with a feature? That might obviate some of the pain.
>
> I'd have to look a bit closer at it. I do like what I see of it. I get
> tired of XML fingerfehlers causing CBTS to hang with the rather nebulous
> "Gave up waiting for CamelContext" errors. I'm also an old Java hack so
> prefer it anyway.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5777014.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel SCR
Posted by Ranx <br...@mediadriver.com>.
Thanks for the insights. It sounds as if the cfg files would need a form of
semantic versioning then like bundles use. Obviously my insights are
limited. Do you create your configuration files via the maven plugin and
install them in etc with a feature? That might obviate some of the pain.
I'd have to look a bit closer at it. I do like what I see of it. I get
tired of XML fingerfehlers causing CBTS to hang with the rather nebulous
"Gave up waiting for CamelContext" errors. I'm also an old Java hack so
prefer it anyway.
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5777014.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel SCR
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
We’ve been running routes based on camel-scr in production for a few months now (Fuse 6.2 patch 1), and it’s been working pretty well. We use the SCR routes as templates, and then create instances with configuration files (cfg files in Karaf, properties files in Fabric8).
The biggest issues we have in production are:
- The Karaf camel:* command don’t work
- We can’t run multiple versions of our SCR templates at the same time - makes staging releases difficult. This isn’t really an issue with camel-scr - it’s because of the way we implemented it. The PIDs are the same for each version of a given template, so if we deploy two versions of the SCR template, we never know for sure which one will pickup the PID. We may wind up changing our build such that the PID has the version number embedded in it, but that will be a real pain because for a normal maintenance update, we’d have to change the names of 300+ configuration files. I’m going to try another method to address this, but I haven’t gotten around to it yet.
The other big runtime difference between the two is the way the two implementations deal with “disappearing” OSGi services - The camel-scr component shuts-down the context when the required services go away while blueprint uses it’s service proxies to wait for the services to come back. However, you can hook into this and get pretty much what camel-scr does using blueprint. They both work - it really depends on your requirements as to which is preferable.
As far as developing components using camel-scr, it depends on your use case IMO. If you’re trying to build configurable routes with very straightforward service dependencies, it’s pretty easy to deal with - the biggest problem is there isn’t a “camel-test-scr” module, so you wind up with a bunch of boilerplate code in your tests. Also, if you base your tests on what comes from the archetype, you don’t have all the nice tools/support that Camel***TestSupport provides.
For more complex service dependencies and templates/factories, I think the Blueprint method works better (at least for us). We can stage our update rollouts and we don’t have to rename PID files all the time. There are also some issues with Blueprint that can make this a little challenging, but I still prefer it for our environment.
In summary - I think it depends on your use case.
> On Jan 28, 2016, at 5:02 PM, Ranx <br...@mediadriver.com> wrote:
>
> Having worked with blueprint and CamelBlueprintTestSupport for a couple of
> years now at different clients I'm trying to find a better alternative. I
> go into clients who usually have a lot of Java developers so staying in the
> familiar Java world is something they appreciate.
>
> As of 2.16 the SCR is core and it can be used with earlier versions. I'm
> wondering how many folks are using it in development and production and what
> sort of experiences they've been having with it.
>
> Essentially, do folks feel it is ready for primetime?
>
> One concern I have is the registry mechanics. In the example generated by
> the archetype it uses the simple registry and not an OSGi registry. Perhaps
> that's not a problem but with blueprint crossing registry boundaries can
> lead to quirky behavior.
>
> Any thoughts, guidance, clues, guesses, gesticulations, hare brained
> schemes, cogent remarks or deep technical insights are all appreciated.
>
> Brad
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel SCR
Posted by Ranx <br...@mediadriver.com>.
Thud? Opinions, thoughts, wild gesticulating, futurism, and keen technical
insight are all welcome. Is this still so new that it isn't being used by
many folks?
How about the developers of the SCR bundle? What are your thoughts about
it? How do you like it compared with Blueprint?
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5776987.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel SCR
Posted by Ranx <br...@mediadriver.com>.
I want to follow this up with a quick question and observation.
I've noticed quite a bit of difference in the examples created by the
archetype for 2.15 and 2.16 with 2.16 being far more stripped down. But
both of them use a a deprecated API for part of their testing. That's
something of a smell.
I like the properties mechanics a lot and I'm guessing that if my features
file installs a cfg file in karaf with the same name as the service it will
override the properties(?)
If I have a component label like com.foo.my.service.InvoiceServices would
karaf/camel pick up a com.foo.my.service.InvoiceServices.cfg file?
At first glance this all seems a bit more elegant to use if still a bit
loose in the joints with the implementation.
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5776960.html
Sent from the Camel - Users mailing list archive at Nabble.com.