Re: [VOTE] Release Apache Camel 2.12.3
+1 Regards, Gert Vanthienen On Wed, Feb 19, 2014 at 2:37 AM, Willem Jiang wrote: > +1 > > -- > Willem Jiang > > Red Hat, Inc. > Web: http://www.redhat.com > Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/) > (English) > http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > > > On February 16, 2014 at 12:17:03 PM, Hadrian Zbarcea (hzbar...@gmail.com) > wrote: >> >> This is a vote to release Apache Camel 2.12.3, a patch release >> coming >> with about 128 issues fixed. >> >> Release notes: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211&version=12325593 >> >> Staging repo: >> https://repository.apache.org/content/repositories/orgapachecamel-1002 >> >> Tarballs: >> https://repository.apache.org/content/repositories/orgapachecamel-1002/org/apache/camel/apache-camel/2.12.3/ >> >> Tag: >> https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=4bf31d2e2cbc34fda60d68c0dd33cb39d63ba1c6 >> >> Please test this release candidate and cast your vote. >> [ ] +1 Release the binary as Apache Camel 2.12.3 >> [ ] -1 Veto the release (provide specific comments) >> Vote is open for at least 72 hours. >> >> Thanks, >> Hadrian >> >
Re: 3.0 Ideas
Hey Marco, Just noticed your remark about the Exception you got when running things in ServiceMix and I raised JIRA https://issues.apache.org/jira/browse/SMX4-1423 to ensure we look into this before doing the next release. The basic example I tried worked fine, but that was only exposing a web service and not calling an external service. If you have a moment, it would be good if you could add a comment to the JIRA issue explaining how we can reproduce your problem? Thanks in advance, Gert On Thu, Mar 28, 2013 at 4:21 PM, Marco Westermann wrote: > Hi, > > I use camel for more that one year now and it is actual great for > integration questions. One thing that I always mess around with is calling > external web services (soap in general). And IMHO this is a central use case > for soa / integration purposes. I received the impression that this central > use case has not the weight it should have in an integegration framework > like camel. E.g. most examples with camel and cxf shows how to expose a web > service, not how to consume one; there are maven archtypes which create new > projects again only for exposing a service - there is no archtype for > consuming one. Even the camel in action book mostly covers cxf to use as a > provider. So I think this should be made much easier with much more > examples. (or that easy that no example is neccessary) If you know openesb > / glassfish esb there it is a matter of drag and drop a wsdl to the project, > use an operation as endpoint (which you can use from a drop down box) and > specify the message-mapping (all is supported by easy clicky clicky) > > Don't get me wrong. I really like camel very much, but I always have some > problems with: > > * what component should I use (http, cxf, spring-ws) I think cxf should be > the standard but should be easier to use > * most of my camel routes run in smx. my acutal problem in smx 4.5 (which > seems to be an osgi-problem) is that I get an exception which says that no > org.apache.cxf.jaxws.spi.ProviderImpl could be found. And I already tried 4 > hours to fix this issue without success.. > > These hurdles makes it to a costly task to implement a route which should > call a service. IMHO this should not take longer that 5 mins to implement > that if you already have a wsdl for the service. > > > I hope my suggestions are understandable / useful. > > I which you all Happy Easter, > > regards, > > Marco Westermann > >
Re: Need your help on camel-scala!
Babak, I think the changes in http://pastie.org/private/f7urpvnbvkk8xgawoa7wshould get camel-scala building again. Regards, Gert Vanthienen FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Wed, Jan 11, 2012 at 1:39 PM, Babak Vahdat wrote: > Hi > > Just in case somebody intends to help out on this issue here is > http://camel.465427.n5.nabble.com/file/n5136738/camel-scala-problem.diff > camel-scala-problem.diff the diff of my workspace which contains *only* > the > changes regarding this issue I've already mentioned by this thread. > > The steps to reproduce the problem on your workspace: > > - Apply the patch on your workspace > - By the camel-core module do a "mvn clean install -Pfastinstall" > - On camel-scala module do a "mvn clean install" to see the Scala-Compiler > errors. > > As you see *one* of the good side effects by this refactoring is the > removal > of CastUtils.cast() stuff. > > Babak > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Need-your-help-on-camel-scala-tp5134007p5136738.html > Sent from the Camel Development mailing list archive at Nabble.com. >
Re: Release a Camel 2.8.3 ?
Jean-Baptiste, Removing the would avoid the issue, but it would also cause the Camel descriptor to no longer be self-contained, so people would need to read the documentation in order to get things working. One of the proposals in the karaf-dev thread I referred to earlier, is to ensure that version ranges are fully supported in the element by first checking if there's already a matching descriptor installed and, if not, go out and resolve a suitable version using Pax Url's Maven version range support. Personally, I'd just keep the tag for now and improve things at the Karaf end first, as that would fix the same issue for e.g. some of the ServiceMix features descriptors as well. Once the Karaf improvements have been made, we can start using version ranges in the references and get the best of both worlds - a self-contained features descriptor that allows for the flexibility to switch to a newer fix version as well. Regards, Gert Vanthienen FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Fri, Oct 28, 2011 at 11:39 AM, Jean-Baptiste Onofré wrote: > Hi Gert, > > +1 for a new Camel 2.8.3 release. > > I would propose to remove the tag for CXF. > > It doesn't make sense to use a version range for the CXF feature, but still > specify a CXF version in the tag. > > I would prefer to document for the users that they have to install the cxf > feature first. > > WDYT ? > > Regards > JB > > > On 10/28/2011 10:23 AM, Gert Vanthienen wrote: > >> L.S., >> >> >> Over at the ServiceMix project, we are finalizing things for doing a >> ServiceMix 4.4.0 release. The original plan was to use CXF 2.4.2 and >> Camel >> 2.8.1 because of an issue with the CXF 2.4.3 release in combination with >> Felix. However, Dan has volunteered to do a quick CXF 2.4.4 release to >> help >> us out which the CXF problem. Cfr. >> http://servicemix.396122.n5.**nabble.com/Toward-ServiceMix-** >> 4-4-td4909262.htmlfor<http://servicemix.396122.n5.nabble.com/Toward-ServiceMix-4-4-td4909262.htmlfor> >> some background... >> >> Unfortunately, because of a reference in the Camel features >> descriptor, that would mean we would also need a new Camel 2.8.x release >> to >> ensure everything works fine again. I'm aware that the release >> announcement >> for 2.8.2 only went out earlier this week, so just checking if we would >> consider doing a Camel 2.8.3 release right after the CXF 2.4.4 release is >> out. For the Apache ServiceMix project, this would definitely be highly >> appreciated, as it would allow us to upgrade to the latest and greatest >> Karaf, CXF and Camel for our upcoming release. >> >> FWIW, in the meanwhile we're also working at both the Karaf and the >> ServiceMix end to make a things a more reliable and maintainable when >> upgrading parts of the application, so this should allow us to prevent >> these >> kinds of issues in the future, but for now we're still trying to align the >> entire universe here ;) >> >> >> Regards, >> >> Gert Vanthienen >> >> FuseSource >> Web: http://fusesource.com >> Blog: >> http://gertvanthienen.**blogspot.com/<http://gertvanthienen.blogspot.com/> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Release a Camel 2.8.3 ?
L.S., That's awesome - thanks a lot! Regards, Gert Vanthienen FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Fri, Oct 28, 2011 at 10:46 AM, Willem Jiang wrote: > I can help to do the release of camel 2.8.3 :) > > > On Fri Oct 28 16:23:01 2011, Gert Vanthienen wrote: > >> L.S., >> >> >> Over at the ServiceMix project, we are finalizing things for doing a >> ServiceMix 4.4.0 release. The original plan was to use CXF 2.4.2 and >> Camel >> 2.8.1 because of an issue with the CXF 2.4.3 release in combination with >> Felix. However, Dan has volunteered to do a quick CXF 2.4.4 release to >> help >> us out which the CXF problem. Cfr. >> http://servicemix.396122.n5.**nabble.com/Toward-ServiceMix-** >> 4-4-td4909262.htmlfor<http://servicemix.396122.n5.nabble.com/Toward-ServiceMix-4-4-td4909262.htmlfor> >> some background... >> >> Unfortunately, because of a reference in the Camel features >> descriptor, that would mean we would also need a new Camel 2.8.x release >> to >> ensure everything works fine again. I'm aware that the release >> announcement >> for 2.8.2 only went out earlier this week, so just checking if we would >> consider doing a Camel 2.8.3 release right after the CXF 2.4.4 release is >> out. For the Apache ServiceMix project, this would definitely be highly >> appreciated, as it would allow us to upgrade to the latest and greatest >> Karaf, CXF and Camel for our upcoming release. >> >> FWIW, in the meanwhile we're also working at both the Karaf and the >> ServiceMix end to make a things a more reliable and maintainable when >> upgrading parts of the application, so this should allow us to prevent >> these >> kinds of issues in the future, but for now we're still trying to align the >> entire universe here ;) >> >> >> Regards, >> >> Gert Vanthienen >> >> FuseSource >> Web: http://fusesource.com >> Blog: >> http://gertvanthienen.**blogspot.com/<http://gertvanthienen.blogspot.com/> >> >> > > > >
Release a Camel 2.8.3 ?
L.S., Over at the ServiceMix project, we are finalizing things for doing a ServiceMix 4.4.0 release. The original plan was to use CXF 2.4.2 and Camel 2.8.1 because of an issue with the CXF 2.4.3 release in combination with Felix. However, Dan has volunteered to do a quick CXF 2.4.4 release to help us out which the CXF problem. Cfr. http://servicemix.396122.n5.nabble.com/Toward-ServiceMix-4-4-td4909262.htmlfor some background... Unfortunately, because of a reference in the Camel features descriptor, that would mean we would also need a new Camel 2.8.x release to ensure everything works fine again. I'm aware that the release announcement for 2.8.2 only went out earlier this week, so just checking if we would consider doing a Camel 2.8.3 release right after the CXF 2.4.4 release is out. For the Apache ServiceMix project, this would definitely be highly appreciated, as it would allow us to upgrade to the latest and greatest Karaf, CXF and Camel for our upcoming release. FWIW, in the meanwhile we're also working at both the Karaf and the ServiceMix end to make a things a more reliable and maintainable when upgrading parts of the application, so this should allow us to prevent these kinds of issues in the future, but for now we're still trying to align the entire universe here ;) Regards, Gert Vanthienen FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Features
L.S., Using the OBR resolver without helps a bit already, but in only helps in one direction. If you first install the newer bundle version (e.g. Spring 3.0.6), the OBR resolver will avoid installing 3.0.5 again. But if the first feature defines an older version (Spring 3.0.5) and you second feature uses Spring 3.0.6, you're either getting only the old version of the bundle or both versions (depending on the import version ranges of the other bundles in the second feature). For ServiceMix, I have been considering to generate an OBR repository.xml that consists of all bundles found in all (karaf, cxf, servicemix, activemq) features descriptors we use to fix this problem. Another option could be to use a single OBR in-memory repository for resolving all boot features and only then switch to the per-feature resolver implementation we are currently using. Perhaps the latter is even a better option as it could benefit all Karaf users without introducing any extra work for them while assembling the container? Regards, Gert Vanthienen FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Sat, Oct 15, 2011 at 3:35 PM, Guillaume Nodet wrote: > Using obr without repos already helps a lot as the featurzs deployer will > only deploy the required bundles avoiding duplicates if possible. > > On Saturday, October 15, 2011, Johan Edstrom wrote: > > Yup, > > > > I probably had spent another few days without that previous knowledge, it > is still > > in need of work. > > > > And using the OBR given the complexity I think personally is a no-go > right > now, > > it isn't simple enough, nor do we have a global OBR repo. > > > > I did ask Tim O'Brien about a new sonatype OBR repo last week, that would > help. > > > > > > /je > > > > On Oct 15, 2011, at 12:26 AM, Daniel Kulp wrote: > > > >> On Friday, October 14, 2011 11:58:26 PM Johan Edstrom wrote: > >>> Hey, > >>> > >>> Just poking around in the features, and yes I cross post this - > >>> > >>> I know there has been work going on with regards to creating a sane > default > >>> set of features but currently the CXF features in 2.4.2 (I think it > was) > >>> uses spring 3.0.6, the karaf features 3.0.5 and the camel features > actually > >>> copy in cxf with a similar version but the older neethi. > >>> > >>> If we want these features in a consistent state, should we have a > master > >>> reference? > >>> > >>> I know this will impact development and agility, but it sure as heck > would > >>> improve stability if we had a solid inheritance chain? > >>> > >>> I know we also have a bunch of different features in the SMX area, > would > a > >>> new features project help? Just asking… > >> > >> > >> This is pretty much exactly where JB and I have been going with the > recent > >> changes in the features. Basically, the projects all STOP redefining > features > >> like spring and cxf and such. Instead, they grab those from the > appropriate > >> place (and using a version range to accommodate updates). > >> > >> For example: > >> Karaf 2.2.4 defines all the Spring things. Thus, neither Camel or CXF > define > >> that anymore. They just grab spring from there (using "[3,4)" or > similar). > >> Camel 2.8.2 will use the CXF 2.4.3 features directly. (no redefines) > >> > >> If you don't use an obr, we still have issues with different bundle > versions > >> of various things. I did sync CXF and Camel as much as possible a > little > >> while ago, but they will likely drift a bit. > >> > >> Anyway, Karaf 2.2.4, CXF 2.4.3, and Camel 2.8.2 will go a long way to > make it > >> a lot easier and more consistent. > >> > >> Dan > >> > >> > >> > >>> > >>> > >>> Cheers! > >> -- > >> Daniel Kulp > >> dk...@apache.org > >> http://dankulp.com/blog > >> Talend - http://www.talend.com > > > > > > -- > > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com >
Re: Features
L.S., Yeah, we are moving in the right direction there, so nice work! One thing I bumped into while doing a bit of a refactoring of the servicemix features codebase, was the fact that some features descriptors contain a reference to another one, e.g. the camel features descriptor refers to the cxf features descriptor. While this does ensure that the Camel features descriptor is self-contained, it also means that if you combine it with version of CXF you now suddenly have all feature definitions twice (which has caused some confusion for me when it picked the wrong version, so I'm guessing the same thing will happen for users). Not really sure what the ideal solution here would be. Using a version range for the mvn: url for the features.xml would be a start, but then you end up with Maven version resolution that might not work well in an offline situation or may even pick up another version of CXF than the one you intended to use. Perhaps we could reimplement this to behave like a pre-requisite instead, first looking if there's a feature descriptor installed that matches the version range and only then trying to resolve and install it? Regards, Gert Vanthienen FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp wrote: > On Friday, October 14, 2011 11:58:26 PM Johan Edstrom wrote: > > Hey, > > > > Just poking around in the features, and yes I cross post this - > > > > I know there has been work going on with regards to creating a sane > default > > set of features but currently the CXF features in 2.4.2 (I think it was) > > uses spring 3.0.6, the karaf features 3.0.5 and the camel features > actually > > copy in cxf with a similar version but the older neethi. > > > > If we want these features in a consistent state, should we have a master > > reference? > > > > I know this will impact development and agility, but it sure as heck > would > > improve stability if we had a solid inheritance chain? > > > > I know we also have a bunch of different features in the SMX area, would > a > > new features project help? Just asking… > > > This is pretty much exactly where JB and I have been going with the recent > changes in the features. Basically, the projects all STOP redefining > features > like spring and cxf and such. Instead, they grab those from the > appropriate > place (and using a version range to accommodate updates). > > For example: > Karaf 2.2.4 defines all the Spring things. Thus, neither Camel or CXF > define > that anymore. They just grab spring from there (using "[3,4)" or similar). > Camel 2.8.2 will use the CXF 2.4.3 features directly. (no redefines) > > If you don't use an obr, we still have issues with different bundle > versions > of various things. I did sync CXF and Camel as much as possible a little > while ago, but they will likely drift a bit. > > Anyway, Karaf 2.2.4, CXF 2.4.3, and Camel 2.8.2 will go a long way to make > it > a lot easier and more consistent. > > Dan > > > > > > > > > Cheers! > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com >
[jira] [Commented] (CAMEL-4439) Error in camel-restlet feature definition
[
https://issues.apache.org/jira/browse/CAMEL-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102467#comment-13102467
]
Gert Vanthienen commented on CAMEL-4439:
Fixed in trunk by Freeman
(http://svn.apache.org/viewvc?view=revision&revision=1164544)
and marked the restlet jar as a dependency in OBR resolution in
http://svn.apache.org/viewvc?view=revision&revision=1169620
> Error in camel-restlet feature definition
> -
>
> Key: CAMEL-4439
> URL: https://issues.apache.org/jira/browse/CAMEL-4439
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
>Priority: Minor
>
> The current contents of the camel-features.xml file reads:
> {code}
>
> camel-core
>dependency="true">mvn:org.apache.camel/camel-restlet/2.7.1-fuse-00-43
>
> mvn:http://maven.restlet.org!org.restlet.jse/org.restlet/2.0.5
>
> {code}
> It actually should read
> http://fernandoribeiro.eti.br/2011/09/12/bug-in-fuse-4-4/ (Thanks to Fernando
> Ribeiro for the heads up!)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4439) Error in camel-restlet feature definition
Error in camel-restlet feature definition
-
Key: CAMEL-4439
URL: https://issues.apache.org/jira/browse/CAMEL-4439
Project: Camel
Issue Type: Bug
Affects Versions: 2.8.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Priority: Minor
The current contents of the camel-features.xml file reads:
{code}
camel-core
mvn:org.apache.camel/camel-restlet/2.7.1-fuse-00-43
mvn:http://maven.restlet.org!org.restlet.jse/org.restlet/2.0.5
{code}
It actually should read
http://fernandoribeiro.eti.br/2011/09/12/bug-in-fuse-4-4/ (Thanks to Fernando
Ribeiro for the heads up!)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4347) Set thread context class loader when starting camel-blueprint routes
[ https://issues.apache.org/jira/browse/CAMEL-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-4347. Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revision&revision=1159171 This fix also sets CamelContext's application context classloader field with the new thread context classloader to ensure the same object can always be retrieved again when necessary. > Set thread context class loader when starting camel-blueprint routes > > > Key: CAMEL-4347 > URL: https://issues.apache.org/jira/browse/CAMEL-4347 > Project: Camel > Issue Type: Improvement > Components: camel-blueprint >Affects Versions: 2.8.0 >Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 2.9.0 > > > When routes are getting started by the camel-blueprint component, the thread > context classloader at that moment is the container's boot classloader. This > is causing problems for e.g. ActiveMQ object messages that need to get > deserialized, because the boot classloader is not aware of classes that might > be available inside the container. The class used for reading the ActiveMQ > object messages is > http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/ClassLoadingAwareObjectInputStream.java. > We can fix this by setting a more appropriate classloader as the thread > context classloader while starting the CamelContext from a Blueprint > definition. I see we also have a similar class in camel-jdbc and there are > no doubt other libraries that depend on this classloader being set as well, > so this change should help with all of those cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4347) Set thread context class loader when starting camel-blueprint routes
Set thread context class loader when starting camel-blueprint routes Key: CAMEL-4347 URL: https://issues.apache.org/jira/browse/CAMEL-4347 Project: Camel Issue Type: Improvement Components: camel-blueprint Affects Versions: 2.8.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 2.9.0 When routes are getting started by the camel-blueprint component, the thread context classloader at that moment is the container's boot classloader. This is causing problems for e.g. ActiveMQ object messages that need to get deserialized, because the boot classloader is not aware of classes that might be available inside the container. The class used for reading the ActiveMQ object messages is http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/ClassLoadingAwareObjectInputStream.java. We can fix this by setting a more appropriate classloader as the thread context classloader while starting the CamelContext from a Blueprint definition. I see we also have a similar class in camel-jdbc and there are no doubt other libraries that depend on this classloader being set as well, so this change should help with all of those cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4164) A camel component for ISO8583 protocol
[ https://issues.apache.org/jira/browse/CAMEL-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059609#comment-13059609 ] Gert Vanthienen commented on CAMEL-4164: Unfortunately, GNU Affero GPL is one of the licenses listed as "NOT be included" on http://www.apache.org/legal/resolved.html, but we should be able to move it into camel-extra instead > A camel component for ISO8583 protocol > -- > > Key: CAMEL-4164 > URL: https://issues.apache.org/jira/browse/CAMEL-4164 > Project: Camel > Issue Type: New Feature >Reporter: Lekan Omotayo > Labels: camel-iso,, camel-iso8583, > > A new component to interface with ISO8583 protocol. When started as a > consumer, it listens on a port, and when started as a producer, it connects > to a remote server. Let me know if this has been useful to you. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4147) Add support for lightweight OSGi deployment (without Spring, Blueprint, ...)
Add support for lightweight OSGi deployment (without Spring, Blueprint, ...) Key: CAMEL-4147 URL: https://issues.apache.org/jira/browse/CAMEL-4147 Project: Camel Issue Type: Improvement Affects Versions: 2.7.2 Reporter: Gert Vanthienen Fix For: 2.9.0 We should be able to deploy Camel in a plain OSGi container without requiring Spring-DM or Blueprint to bootstrap the routes, cfr. http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-td4507473.html A possible solution: add a ServiceTracker for RouteBuilder instances in the OSGi Service Registry and automatically create and start a CamelContext for any RouteBuilder instance it discovers. We should add a few optional properties that can be passed in when registering the service: * a CamelContext name, so the tracker can add multiple RouteBuilders to the same CamelContext * a property to disable automatically starting the context -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3763) Update Camel features descriptor to be Karaf 2.2.0 compliant
[ https://issues.apache.org/jira/browse/CAMEL-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016167#comment-13016167 ] Gert Vanthienen commented on CAMEL-3763: Took an initial stab at marking stuff as a dependency in http://svn.apache.org/viewvc?view=revision&revision=1089275. Marking a bundle as a dependency allows the OBR resolver to skip that exact bundle if it can reuse a previously installed bundle to provide the required imports. I marked normal OSGi bundles, specification bundles and common bundles like Spring stuff as dependencies. I tried to avoid marking any implementations for specs as a dependency, as the other bundles will only import the specification packages we need to keep those implementations explicitly listed as the OBR resolver won't look for them. Could someone take another look at this commit to ensure I didn't do anything wrong there? > Update Camel features descriptor to be Karaf 2.2.0 compliant > > > Key: CAMEL-3763 > URL: https://issues.apache.org/jira/browse/CAMEL-3763 > Project: Camel > Issue Type: Task > Components: karaf >Reporter: Jean-Baptiste Onofré >Assignee: Hadrian Zbarcea > Fix For: 2.8.0 > > Attachments: CAMEL-3763.patch, CAMEL-3763.patch > > > To be compliant with Karaf 2.2.0, the Camel features descriptor will be > update: > - to avoid to override the Aries blueprint bundle > - to not define Karaf external repository > - to use the OBR resolver -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3763) Update Camel features descriptor to be Karaf 2.2.0 compliant
[
https://issues.apache.org/jira/browse/CAMEL-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015307#comment-13015307
]
Gert Vanthienen commented on CAMEL-3763:
In order to fully leverage the {{resolver='(obr)'}} set on the features, we
should mark the dependency bundles in every feature with the attribute
{{dependency='true'}}. AFAIK, without this marker, the features service will
consider all bundles as mandatory and will never really leverage OBR to use a
previously installed bundle to provide some packages.
> Update Camel features descriptor to be Karaf 2.2.0 compliant
>
>
> Key: CAMEL-3763
> URL: https://issues.apache.org/jira/browse/CAMEL-3763
> Project: Camel
> Issue Type: Task
> Components: karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Hadrian Zbarcea
> Fix For: 2.8.0
>
> Attachments: CAMEL-3763.patch, CAMEL-3763.patch
>
>
> To be compliant with Karaf 2.2.0, the Camel features descriptor will be
> update:
> - to avoid to override the Aries blueprint bundle
> - to not define Karaf external repository
> - to use the OBR resolver
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CAMEL-3268) Maven 3 to build source
[ https://issues.apache.org/jira/browse/CAMEL-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992528#comment-12992528 ] Gert Vanthienen commented on CAMEL-3268: KARAF-440 has been fixed, so with a new Karaf 2.1.4-SNAPSHOT the features validation works again! Also removed a few runaway TABs and fixed a minor issue in the features.xml while I was at it. Committed in http://svn.apache.org/viewvc?view=revision&revision=1068934 > Maven 3 to build source > --- > > Key: CAMEL-3268 > URL: https://issues.apache.org/jira/browse/CAMEL-3268 > Project: Camel > Issue Type: Task >Affects Versions: 2.5.0 >Reporter: Claus Ibsen >Assignee: Christian Müller >Priority: Minor > Fix For: 2.7.0, 3.0.0 > > Attachments: CAMEL-3268_maven-checkstyle-plugin_upgrade.patch > > > It should be possible to build the project with Maven 3 without any issues. > Dan Kulp says there is an issue with using old Maven 1 repo style. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CAMEL-3620) Blueprint container goes 'GracePeriod' if component is defined in the same XML file
Blueprint container goes 'GracePeriod' if component is defined in the same XML
file
---
Key: CAMEL-3620
URL: https://issues.apache.org/jira/browse/CAMEL-3620
Project: Camel
Issue Type: Bug
Components: camel-blueprint
Affects Versions: 2.6.0
Reporter: Gert Vanthienen
Fix For: 2.7.0
When a Blueprint file contains both a route and a component bean definition,
the Camel routes get started correct but the Blueprint container will go to
status 'GracePeriod'.
An example:
{code:xml}
http://www.osgi.org/xmlns/blueprint/v1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
http://camel.apache.org/schema/blueprint";>
FileMovedEvent(file: ${file:name}, timestamp:
${date:now:hh:MM:ss.SSS})
{code}
After the 5 minute time-out period, the routes are stopped and we end up with
this message in the log file.
{noformat}
Unable to start blueprint container for bundle activemq2.xml due to unresolved
dependencies
[(&(component=log)(objectClass=org.apache.camel.spi.ComponentResolver)),
(&(component=amq)(objectClass=org.apache.camel.spi.ComponentResolver))]
{noformat}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (CAMEL-3235) Restarting a bundle with a jetty endpoint also stops connector for other jetty endpoints (in different bundles)
[ https://issues.apache.org/activemq/browse/CAMEL-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen moved SMX4-609 to CAMEL-3235: - Component/s: (was: camel-nmr) camel-jetty Affects Version/s: (was: 4.3.0) 2.4.0 Key: CAMEL-3235 (was: SMX4-609) Project: Apache Camel (was: ServiceMix 4) > Restarting a bundle with a jetty endpoint also stops connector for other > jetty endpoints (in different bundles) > > > Key: CAMEL-3235 > URL: https://issues.apache.org/activemq/browse/CAMEL-3235 > Project: Apache Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.4.0 > Environment: Windows Vista, Linux (CentOS release 5.5) >Reporter: Auke van Leeuwen > Attachments: test-projects.zip, test-scenario-log.log > > > Scenario: I create two simple routes in different bundles: > > http://0.0.0.0:15000/jetty?matchOnUriPrefix=true"/> > > > and (the other bundle): > > http://0.0.0.0:16000/jetty?matchOnUriPrefix=true"/> > > > When I go to http://localhost:15000/jetty or http://localhost:16000/jetty I > get both log message in my log. My routes are working. However when I restart > one of those bundles both jetty servers are killed and only one is restarted. > See also > http://servicemix.396122.n5.nabble.com/Jetty-connector-stops-unexpectedly-td3208647.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CAMEL-463) Extend/document the Scala DSL to support every EIP the Java DSL does
[ https://issues.apache.org/activemq/browse/CAMEL-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62491#action_62491 ] Gert Vanthienen edited comment on CAMEL-463 at 10/11/10 7:17 AM: - Adding a few more things: - http://svn.apache.org/viewvc?view=revision&revision=1021301 adds support for route id and the log() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021302 adds support for the pollEnrich() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021305 adds support for the validate() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021306 adds support for the sort() DSL method was (Author: gertvanthienen): Adding a few more things: - http://svn.apache.org/viewvc?view=revision&revision=1021301 adds support for route id and the log() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021302 adds support for the pollEnrich() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021305 adds support for the validate() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021301 adds support for the sort() DSL method > Extend/document the Scala DSL to support every EIP the Java DSL does > > > Key: CAMEL-463 > URL: https://issues.apache.org/activemq/browse/CAMEL-463 > Project: Apache Camel > Issue Type: Task > Components: camel-scala > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen >Priority: Minor > Fix For: Future > > Attachments: CAMEL-463-01.diff, CAMEL-463-02.diff, CAMEL-463-03.diff, > CAMEL-463.diff > > > Work on the Scala DSL started with CAMEL-419, but it still requires a lot of > work to have it support every EIP the Java DSL does. > http://cwiki.apache.org/confluence/pages/pageinfo.action?pageId=82603 gives a > list of all the EIPs to be implemented. We should make sure to add an > example for every EIP as we move along to make sure the entire DSL gets > documented properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-463) Extend/document the Scala DSL to support every EIP the Java DSL does
[ https://issues.apache.org/activemq/browse/CAMEL-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62491#action_62491 ] Gert Vanthienen commented on CAMEL-463: --- Adding a few more things: - http://svn.apache.org/viewvc?view=revision&revision=1021301 adds support for route id and the log() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021302 adds support for the pollEnrich() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021305 adds support for the validate() DSL method - http://svn.apache.org/viewvc?view=revision&revision=1021301 adds support for the sort() DSL method > Extend/document the Scala DSL to support every EIP the Java DSL does > > > Key: CAMEL-463 > URL: https://issues.apache.org/activemq/browse/CAMEL-463 > Project: Apache Camel > Issue Type: Task > Components: camel-scala >Reporter: Gert Vanthienen >Assignee: Gert Vanthienen >Priority: Minor > Fix For: Future > > Attachments: CAMEL-463-01.diff, CAMEL-463-02.diff, CAMEL-463-03.diff, > CAMEL-463.diff > > > Work on the Scala DSL started with CAMEL-419, but it still requires a lot of > work to have it support every EIP the Java DSL does. > http://cwiki.apache.org/confluence/pages/pageinfo.action?pageId=82603 gives a > list of all the EIPs to be implemented. We should make sure to add an > example for every EIP as we move along to make sure the entire DSL gets > documented properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-2951) Upgrade to Scala 2.8.0 final
[ https://issues.apache.org/activemq/browse/CAMEL-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61361#action_61361 ] Gert Vanthienen commented on CAMEL-2951: We already have a bundle for this at https://repository.apache.org/content/repositories/snapshots/org/apache/servicemix/bundles/org.apache.servicemix.bundles.scala-library/2.8.0_1-SNAPSHOT/ Jean-Baptiste is planning to do the new bundles' release over the next few weeks, which will include this bundle as well. > Upgrade to Scala 2.8.0 final > > > Key: CAMEL-2951 > URL: https://issues.apache.org/activemq/browse/CAMEL-2951 > Project: Apache Camel > Issue Type: Task >Affects Versions: 2.4.0 >Reporter: Claus Ibsen >Assignee: Gert Vanthienen >Priority: Trivial > Fix For: 2.5.0 > > > Scala 2.8.0 final has just been released. > We need to check if the 2.8.0 release is OSGi friendly out of the box. If not > we need gertv to wrap a bundle at SMX bundles repo like he did for RC7. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-2899) out of heap space if remote FTP site has too many files to pick up
[
https://issues.apache.org/activemq/browse/CAMEL-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60406#action_60406
]
Gert Vanthienen commented on CAMEL-2899:
I think you can already configure that with the *{{maxMessagesPerPoll}}* URI
parameter to limit the number of files being processing in a single poll (cfr.
http://camel.apache.org/file2.html) - could you give that a try to see if it
solves your problem?
> out of heap space if remote FTP site has too many files to pick up
> --
>
> Key: CAMEL-2899
> URL: https://issues.apache.org/activemq/browse/CAMEL-2899
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.3.0
>Reporter: Karl Palsson
>
> 2010-07-02 11:38:07,439 FATAL
> [org.apache.camel.component.file.remote.FtpConsumer:CamelThread 10] -
>
> java.lang.OutOfMemoryError: Java heap space
> My remote FTP server has ~60k 100 byte files, and the camel endpoint consumer
> falls over and doesn't start again. I can use JMX to stop/start the
> consumer, (it still has status "started") and it will log in to the remote
> server again, but then fall over with the out of heap space.
> I can work around this by increasing the heap, or by moving some of the files
> aside, but I don't think camel should care how many files there are, or at
> least, I think it should deal with it more gracefully.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CAMEL-2167) Upgrade camel-scala to scala 2.8.0.RC6
[ https://issues.apache.org/activemq/browse/CAMEL-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60213#action_60213 ] Gert Vanthienen edited comment on CAMEL-2167 at 6/22/10 4:27 PM: - Looks like the changes to the generics in the Java types together with the upgrade to the latest Scala 2.8.0.RC6 does work. Fixed in http://svn.apache.org/viewvc?view=revision&revision=957013 Thanks to Hadrian and Barry for all the hard work in figuring these things out! was (Author: gertvanthienen): Looks like the changes to the generics in the Java types together with the upgrade to the latest Scala 2.8.0.RC6 does work. Fixed in http://svn.apache.org/viewvc?view=revision&revision=957013 > Upgrade camel-scala to scala 2.8.0.RC6 > -- > > Key: CAMEL-2167 > URL: https://issues.apache.org/activemq/browse/CAMEL-2167 > Project: Apache Camel > Issue Type: Improvement > Components: camel-scala >Affects Versions: 2.0.0 >Reporter: Barry Kaplan >Assignee: Hadrian Zbarcea > Fix For: 2.4.0 > > Attachments: Upgrade_to_scala_2_8.patch > > > The attached patch upgrades to 2.8.0-SNAPSHOT (actually a specific version, > but pretty close to today). > Only a few changes were required: > - Change package declarations to new 2.8 style that allows relative imports > - Change org.apache.camel.scala.conveters.ScalaTypeConverter from a > singleton object to a class. Otherwise ObjectHelper failed to instantiate the > converter due to private access. (This could be 2.8 bug. I will need to raise > an issue.) > - Removed generic parameters on references to java classes that were not > generic. Don't know why this compiled with scala 2.7. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2167) Upgrade camel-scala to scala 2.8.0.RC6
[ https://issues.apache.org/activemq/browse/CAMEL-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated CAMEL-2167: --- Summary: Upgrade camel-scala to scala 2.8.0.RC6 (was: Upgrade camel-scala to scala 2.8) > Upgrade camel-scala to scala 2.8.0.RC6 > -- > > Key: CAMEL-2167 > URL: https://issues.apache.org/activemq/browse/CAMEL-2167 > Project: Apache Camel > Issue Type: Improvement > Components: camel-scala >Affects Versions: 2.0.0 >Reporter: Barry Kaplan >Assignee: Hadrian Zbarcea > Fix For: 2.4.0 > > Attachments: Upgrade_to_scala_2_8.patch > > > The attached patch upgrades to 2.8.0-SNAPSHOT (actually a specific version, > but pretty close to today). > Only a few changes were required: > - Change package declarations to new 2.8 style that allows relative imports > - Change org.apache.camel.scala.conveters.ScalaTypeConverter from a > singleton object to a class. Otherwise ObjectHelper failed to instantiate the > converter due to private access. (This could be 2.8 bug. I will need to raise > an issue.) > - Removed generic parameters on references to java classes that were not > generic. Don't know why this compiled with scala 2.7. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-2167) Upgrade camel-scala to scala 2.8
[ https://issues.apache.org/activemq/browse/CAMEL-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-2167. Resolution: Fixed Looks like the changes to the generics in the Java types together with the upgrade to the latest Scala 2.8.0.RC6 does work. Fixed in http://svn.apache.org/viewvc?view=revision&revision=957013 > Upgrade camel-scala to scala 2.8 > > > Key: CAMEL-2167 > URL: https://issues.apache.org/activemq/browse/CAMEL-2167 > Project: Apache Camel > Issue Type: Improvement > Components: camel-scala >Affects Versions: 2.0.0 >Reporter: Barry Kaplan >Assignee: Hadrian Zbarcea > Fix For: 2.4.0 > > Attachments: Upgrade_to_scala_2_8.patch > > > The attached patch upgrades to 2.8.0-SNAPSHOT (actually a specific version, > but pretty close to today). > Only a few changes were required: > - Change package declarations to new 2.8 style that allows relative imports > - Change org.apache.camel.scala.conveters.ScalaTypeConverter from a > singleton object to a class. Otherwise ObjectHelper failed to instantiate the > converter due to private access. (This could be 2.8 bug. I will need to raise > an issue.) > - Removed generic parameters on references to java classes that were not > generic. Don't know why this compiled with scala 2.7. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Camel 1.6.3
+1 Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 1 June 2010 06:14, Willem Jiang wrote: > This my +1. > > Willem > > Hadrian Zbarcea wrote: >> >> A new maintenance release of apache-camel-1.6.3 is out with approximately >> 39 issues resolved: new features, improvements and bug fixes. >> >> Please find the staging repo here: >> https://repository.apache.org/content/repositories/orgapachecamel-024/ >> The tarballs are here >> >> https://repository.apache.org/content/repositories/orgapachecamel-024/org/apache/camel/apache-camel/1.6.3/ >> >> Please review and vote to approve this binary as the final 1.6.3 >> maintenance release. Your vote counts! >> >> [ ] +1 Release the binary as Apache Camel 1.6.3 >> [ ] -1 Veto the release (provide specific comments) >> Vote is open for 72 hours. >> >> Here's my +1 >> >> Hadrian > >
[jira] Commented: (CAMEL-2775) features - Reorder features so they are listed nice and dandy
[
https://issues.apache.org/activemq/browse/CAMEL-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59616#action_59616
]
Gert Vanthienen commented on CAMEL-2775:
Yes, those are two seperate JARs that happen to have the same Bundle-Name.
If you do osgi:headers for those two bundles, you'll notice that
the Bundle-SymbolicName is different though:
*{{org.apache.ws.commons.axiom.axiom-impl}}* and
*{{org.apache.ws.commons.axiom.axiom-api}}*
> features - Reorder features so they are listed nice and dandy
> -
>
> Key: CAMEL-2775
> URL: https://issues.apache.org/activemq/browse/CAMEL-2775
> Project: Apache Camel
> Issue Type: Task
> Components: osgi
>Affects Versions: 2.3.0
>Reporter: Claus Ibsen
>Priority: Trivial
>
> When you list the Camel features in Karaf
> {code}
> features:addUrl mvn:org.apache.camel.karaf/apache-camel/2.3.0/xml/features
>
> ka...@root> features:list
> State Version Name Repository
> [uninstalled] [2.5.6.SEC01] spring karaf-1.6.0
> [uninstalled] [1.2.0 ] spring-dmkaraf-1.6.0
> [uninstalled] [1.6.0 ] wrapper karaf-1.6.0
> [uninstalled] [1.6.0 ] obr karaf-1.6.0
> [uninstalled] [1.6.0 ] http karaf-1.6.0
> [uninstalled] [1.6.0 ] war karaf-1.6.0
> [uninstalled] [1.6.0 ] webconsole karaf-1.6.0
> [installed ] [1.6.0 ] ssh karaf-1.6.0
> [installed ] [1.6.0 ] management karaf-1.6.0
> [uninstalled] [2.5.6.SEC01] spring repo-0
> [uninstalled] [1.2.0 ] spring-dmrepo-0
> [uninstalled] [2.3.0 ] http repo-0
> [uninstalled] [2.3.0 ] camelrepo-0
> [uninstalled] [2.3.0 ] camel-core repo-0
> [uninstalled] [2.3.0 ] camel-spring-osgirepo-0
> [uninstalled] [2.3.0 ] camel-test repo-0
> [uninstalled] [2.3.0 ] camel-cxfrepo-0
> [uninstalled] [2.3.0 ] camel-cache repo-0
> [uninstalled] [2.3.0 ] camel-castor repo-0
> [uninstalled] [2.3.0 ] camel-crypto repo-0
> [uninstalled] [2.3.0 ] camel-dozer repo-0
> [uninstalled] [2.3.0 ] camel-http repo-0
> [uninstalled] [2.3.0 ] camel-http4 repo-0
> [uninstalled] [2.3.0 ] camel-mina repo-0
> [uninstalled] [2.3.0 ] camel-jetty repo-0
> [uninstalled] [2.3.0 ] camel-servletrepo-0
> [uninstalled] [2.3.0 ] camel-jmsrepo-0
> [uninstalled] [2.3.0 ] camel-amqp repo-0
> [uninstalled] [2.3.0 ] camel-atom repo-0
> [uninstalled] [2.3.0 ] camel-bamrepo-0
> [uninstalled] [2.3.0 ] camel-bindy repo-0
> [uninstalled] [2.3.0 ] camel-cometd repo-0
> [uninstalled] [2.3.0 ] camel-csvrepo-0
> [uninstalled] [2.3.0 ] camel-flatpack repo-0
> [uninstalled] [2.3.0 ] camel-freemarker repo-0
> [uninstalled] [2.3.0 ] camel-ftprepo-0
> [uninstalled] [2.3.0 ] camel-guice repo-0
> [uninstalled] [2.3.0 ] camel-groovy repo-0
> [uninstalled] [2.3.0 ] camel-hl7repo-0
> [uninstalled] [2.3.0 ] camel-hawtdb repo-0
> [uninstalled] [2.3.0 ] camel-ibatis repo-0
> [uninstalled] [2.3.0 ] camel-ircrepo-0
> [uninstalled] [2.3.0 ] camel-jacksonrepo-0
> [uninstalled] [2.3.0 ] camel-jaxb repo-0
> [uninstalled] [2.3.0 ] camel-jcrrepo-0
> [uninstalled] [2.3.0 ] camel-jing repo-0
> [uninstalled] [2.3.0 ] camel-jdbc repo-0
> [uninstalled] [2.3.0 ] camel-josql repo-0
> [uninstalled] [2.3.0 ] camel-jparepo-0
> [uninstalled] [2.3.0 ] camel-jxpath repo-0
> [uninstalled] [2.3.0 ] camel-juel repo-0
> [uninstalled] [2.3.0 ] camel-ldap repo-0
> [uninstalled] [2.3.0 ] camel-lucene repo-0
> [uninstalled] [2.3.0 ] camel-mail repo-0
> [uninstalled] [2.3.0 ] camel-msvrepo-0
> [uninstalled] [2.3.0 ] camel-mvel repo-0
> [uninstalled] [2.3.0 ] camel-nagios
[jira] Commented: (CAMEL-2669) XPath - Add type converters from the pesky XPath types to String, InputStream etc.
[
https://issues.apache.org/activemq/browse/CAMEL-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59279#action_59279
]
Gert Vanthienen commented on CAMEL-2669:
When I look at the XPathToFileTest, I would have expected it to behave
differently, outputting the XML element selected by the xpath expression
instead of only the text node values.
{noformat}
Index: src/test/java/org/apache/camel/component/file/XPathToFileTest.java
===
--- src/test/java/org/apache/camel/component/file/XPathToFileTest.java
(revision 942839)
+++ src/test/java/org/apache/camel/component/file/XPathToFileTest.java
(working copy)
@@ -51,11 +51,11 @@
File first = new File("target/xpath/xpath-0.xml").getAbsoluteFile();
assertTrue("File xpath-0.xml should exists", first.exists());
-assertEquals("Claus",
context.getTypeConverter().convertTo(String.class, first));
+assertEquals("Claus",
context.getTypeConverter().convertTo(String.class, first));
File second = new File("target/xpath/xpath-1.xml").getAbsoluteFile();
assertTrue("File xpath-1.xml should exists", second.exists());
-assertEquals("Jonathan",
context.getTypeConverter().convertTo(String.class, second));
+assertEquals("Jonathan",
context.getTypeConverter().convertTo(String.class, second));
}
{noformat}
If you do a {{convertBodyTo(String.class)}} after the splitter but before
sending the contents to a file, this is what happens, but the implicit
conversion to InputStream that is being used in the file: endpoint seems to
drop the {{}}s
> XPath - Add type converters from the pesky XPath types to String, InputStream
> etc.
> --
>
> Key: CAMEL-2669
> URL: https://issues.apache.org/activemq/browse/CAMEL-2669
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.0.0, 2.1.0, 2.2.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.3.0
>
>
> See nabble
> http://old.nabble.com/XPath-Splitter-Problem-ts28325959.html
> Then its easier for Camel end users as they wont have as many problems with
> the bad XPath result types for NODESET and whatnot.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2708) File name lost when it starts with the same characters as the relative directory on the endpoint
[
https://issues.apache.org/activemq/browse/CAMEL-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen updated CAMEL-2708:
---
Attachment: CAMEL-2708.diff
Attaching the patch because svn down at the moment
> File name lost when it starts with the same characters as the relative
> directory on the endpoint
>
>
> Key: CAMEL-2708
> URL: https://issues.apache.org/activemq/browse/CAMEL-2708
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.2.0
>Reporter: Gert Vanthienen
> Assignee: Gert Vanthienen
> Fix For: 2.3.0
>
> Attachments: CAMEL-2708.diff
>
>
> When polling file from a directory using a relative file URI, the file name
> gets lost when it starts with the same characters as the directory name.
> E.g. a directory 'orders' containing 'orders-1719.xml' and 'orders-1819.xml'
> {code}
> from("file:orders").process(new Processor() {
> public void process(Exchange exchange) {
> // there's no file name on the message here
> (exchange.getIn().getHeader(Exchange.FILE_NAME) returns null)
> }
> });
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-2708) File name lost when it starts with the same characters as the relative directory on the endpoint
File name lost when it starts with the same characters as the relative
directory on the endpoint
Key: CAMEL-2708
URL: https://issues.apache.org/activemq/browse/CAMEL-2708
Project: Apache Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.2.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: 2.3.0
When polling file from a directory using a relative file URI, the file name
gets lost when it starts with the same characters as the directory name.
E.g. a directory 'orders' containing 'orders-1719.xml' and 'orders-1819.xml'
{code}
from("file:orders").process(new Processor() {
public void process(Exchange exchange) {
// there's no file name on the message here
(exchange.getIn().getHeader(Exchange.FILE_NAME) returns null)
}
});
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] OSGI improvements
L.S., Guillaume's suggestion is to create a separate JAR with the OSGi helper bits and embed that in both camel-blueprint and camel-spring. I don't think there's a real problem with a compile-time dependency, as long as we mark the Maven dependency optional in the pom.xml -- we just have to make sure that we don't use the OSGi specific classes when running in a non-OSGi environment and then we should be fine there, shouldn't we? I suppose the goal is to look for Camel bundles and register components, converters, languages, ... in the OSGi Service Registry so we can respond to changes in the environment for our Blueprint and Spring DM deployed routes. For example: for camel-blueprint, we could set-up a component/converter/... locator class in an OSGI-INF/blueprint/camel.xml file which would only get started in an OSGi- and Blueprint-aware container to avoid the tight link. I'm not entirely sure about META-INF/spring/*.xml for camel-spring, but I don't think that will get automatically picked up in a non-spring-dm environment either. One other question: shouldn't we consider to build support for deploying Camel in a pure OSGi environment as well (like an embedded environment or inside Eclipse) without requiring the use of either Spring DM or Blueprint (although the latter is probably lightweight enough to be installed in almost any environment) -- e.g. have a ServiceTracker to track RouteBuilder instances in the OSGi Service Registry and have a means of auto-starting them (e.g. by adding some property when registering the service)? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 7 May 2010 09:19, Claus Ibsen wrote: > On Fri, May 7, 2010 at 9:06 AM, Guillaume Nodet wrote: >> I'm working on improving and refactoring the OSGi bits and I'd like to >> propose the following: >> * make camel-osgi a plain jar just used to share common code between >> camel-blueprint and camel-spring >> this jar would contain osgi specific classes and also common code for >> jaxb parsing / factory logic > > >> both camel-spring and camel-blueprint would embed the classes defined >> here as to simplify deployment > > How would that be possible for camel-spring to NOT require any osgi jars at > all, > for people who simply want to use Camel in non osgi environments? > > > The problematic part as I see, is the "logic" which is required in > camel-spring to prepare the routes before they are ready to be used at > runtime. > This logic is a bit extensive and would require to be duplicated for > blueprint as well. > > This has annoyed me that camel-spring required this work, where as > camel-core would not (eg there is a potential difference between Java > DSL and Spring XML routes). Hence I have though of refactoring this > logic into camel-core so both Java DSL and Spring XML leverages it. > I have though of attempting that for Camel 3.0. But in light of this > we could consider moving this forward. > > Then if implemented then camel-blueprint and camel-spring can be > independent of each other, as they are today. > > >> * merge camel-spring-osgi back into camel-spring >> this would be easier for end users i think as they would just have to >> deploy camel-spring and that's all >> whether they are in an osgi environment or not would be transparent >> > > Still I don't see this possible. Its important that OSGi does not > become invasive in any way for people not using it at all. > And that means no OSGi jars required at runtime. > > > > >> Thoughts ? >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus >
[jira] Resolved: (CAMEL-2605) Asynchronous processing in DLC endpoint breaks message handling
[ https://issues.apache.org/activemq/browse/CAMEL-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-2605. Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revision&revision=929537 > Asynchronous processing in DLC endpoint breaks message handling > --- > > Key: CAMEL-2605 > URL: https://issues.apache.org/activemq/browse/CAMEL-2605 > Project: Apache Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 1.6.2 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 1.6.3 > > > When using an asynchronous processor to handle the message in a > deadletterchannel, the async message handling is broken (not all > AsyncCallbacks get invoked correctly), causing the exchange never to be > terminated correctly - e.g. the call to sendBody will never return. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-2605) Asynchronous processing in DLC endpoint breaks message handling
Asynchronous processing in DLC endpoint breaks message handling --- Key: CAMEL-2605 URL: https://issues.apache.org/activemq/browse/CAMEL-2605 Project: Apache Camel Issue Type: Bug Components: camel-core Affects Versions: 1.6.2 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 1.6.3 When using an asynchronous processor to handle the message in a deadletterchannel, the async message handling is broken (not all AsyncCallbacks get invoked correctly), causing the exchange never to be terminated correctly - e.g. the call to sendBody will never return. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-2562) Camel-rss don't work in OSGi
[ https://issues.apache.org/activemq/browse/CAMEL-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58413#action_58413 ] Gert Vanthienen commented on CAMEL-2562: L.S., If the patch provided fixes the issue, it's OK for me. We have two ways to get this included in Camel: # use the version provided in repository.code-house.org which already includes the fix # build a servicemix bundle for Rome which includes this fix Personally, I would prefer option 2 because that will eventually get us a valid bundle for Rome in central repository. If that's OK for everyone, I'll move the issue to the SMX4 project and build the bundle to update the Camel features.xml afterwards. If we stick to scenario 1, all we need to do in Camel is use that bundle in our features.xml and we're done. Regards, Gert > Camel-rss don't work in OSGi > > > Key: CAMEL-2562 > URL: https://issues.apache.org/activemq/browse/CAMEL-2562 > Project: Apache Camel > Issue Type: Bug > Components: camel-rss >Affects Versions: 2.2.0 > Environment: ServiceMix 4.x, FUSE 4.2.x > Reporter: Łukasz Dywicki >Assignee: Gert Vanthienen > Attachments: patch.patch > > > Rss polling endpoints can not be started in OSGi due NoClassDefError in ROME. > Root cause of all problems are com.sun.syndication.io.impl.PropertiesLoader > and Thread.currentThread().getContextClassLoader() usage in this class. > Patch provided in > http://repository.code-house.org/content/repositories/code-house.public.release/rome/rome/1.0-osgi/ > may break rome features like providing own Parsers/Generators/Converters > using rome.properties file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-2481) Update camel-scala to match aggregator overhaul
[ https://issues.apache.org/activemq/browse/CAMEL-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=57754#action_57754 ] Gert Vanthienen commented on CAMEL-2481: Claus, Thanks for clarifying that -- completely missed that change Regards, Gert > Update camel-scala to match aggregator overhaul > --- > > Key: CAMEL-2481 > URL: https://issues.apache.org/activemq/browse/CAMEL-2481 > Project: Apache Camel > Issue Type: Improvement > Components: camel-scala >Reporter: Stan Lewis >Assignee: Stan Lewis > > Changes to aggregator need to be reflected in camel-scala so the component > builds again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-2481) Update camel-scala to match aggregator overhaul
[ https://issues.apache.org/activemq/browse/CAMEL-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=57752#action_57752 ] Gert Vanthienen commented on CAMEL-2481: Stan, While the commits adds the missing pieces to the Scala DSL, it also seems to remove the option of just using aggregate() without having to explicitly specify the AggregationStrategy (i.e. automatically pick the UseLatestStrategy). Was this a deliberate change, because the Java Fluent API still seems to support that scenario after the aggregator overhaul? Regards, Gert > Update camel-scala to match aggregator overhaul > --- > > Key: CAMEL-2481 > URL: https://issues.apache.org/activemq/browse/CAMEL-2481 > Project: Apache Camel > Issue Type: Improvement > Components: camel-scala >Reporter: Stan Lewis >Assignee: Stan Lewis > > Changes to aggregator need to be reflected in camel-scala so the component > builds again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-2487) camel feature file is missing for release 2.2.0. It need for deploying camel components to Felix Karaf
[
https://issues.apache.org/activemq/browse/CAMEL-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved CAMEL-2487.
Resolution: Working as Designed
The features file has been renamed for Camel 2.2.0 (cfr. CAMEL-2218) : the
artifact id is now apache-camel instead of features.
For Camel 2.2.0, the newly named features.xml file can be found in
http://repo2.maven.org/maven2/org/apache/camel/karaf/apache-camel/2.2.0/
You can use it in Karaf by doing a *{{features:addUrl
mvn:org.apache.camel.karaf/apache-camel/2.2.0/xml/features}}*
> camel feature file is missing for release 2.2.0. It need for deploying camel
> components to Felix Karaf
> --
>
> Key: CAMEL-2487
> URL: https://issues.apache.org/activemq/browse/CAMEL-2487
> Project: Apache Camel
> Issue Type: Bug
> Components: karaf
>Affects Versions: 2.2.0
>Reporter: Aleksey Masny
>Assignee: Hadrian Zbarcea
>Priority: Critical
> Fix For: 2.2.0
>
>
> Camel feature file is missing for release 2.2.0. This "repository" xml file
> need for deploying released camel components to Felix Karaf.
> For example, in release 2.1.0 -
> http://repo1.maven.org/maven2/org/apache/camel/karaf/features/2.1.0/features-2.1.0-features.xml.
> In release 2.2.0 it is missing now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-2472) A Zookeeper Component for Camel
[ https://issues.apache.org/activemq/browse/CAMEL-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=57591#action_57591 ] Gert Vanthienen commented on CAMEL-2472: We could always add this artifact to http://svn.apache.org/repos/asf/camel/m2-repo/ and rename it 3.3.0-SNAPSHOT until the Zookeeper release has been cut (or create a m2-snapshots repo to avoid mixing snapshot and releases in our existing repo). > A Zookeeper Component for Camel > --- > > Key: CAMEL-2472 > URL: https://issues.apache.org/activemq/browse/CAMEL-2472 > Project: Apache Camel > Issue Type: New Feature >Affects Versions: 2.3.0 >Reporter: Stephen Gargan >Priority: Minor > Fix For: 2.3.0 > > Attachments: zookeeper-3.3.0.jar, zookeeper.patch > > > I've put together a basic component implementation for interacting with a > Zookeeper Cluster (http://hadoop.apache.org/zookeeper/). Its a reasonably > complete implementation, providing much of the available functionality of the > 3.3.0 api. The main features being the abilities to > - Creation of nodes in any of the ZooKeeper create modes. > - Get and Set the data contents of arbitrary cluster nodes. > - Create and retrieve the list the child nodes attached to a particular node. > - A Distributed RoutePoilcy that leverages a Leader election coordinated by > ZK to determine if exchanges should get processed. > It's build against the Head of Zookeepers current release stream, 3.3.0. > Zookeeper (Like the rest of the Hadoop project) uses a custom ant build and > so there are no SNAPSHOTS. This is a bit of an impediment, but its likely > that the Zookeepr project will cut a release before too long. In the > meantime, to get some soak time in the real world, I've attached a freshly > cut jar from the head today so you can try the component out. It can be > installed using the following command. > mvn install:install-file -DgroupId=org.apache.zookeeper > -DartifactId=zookeeper -Dversion=3.3.0 -Dpackaging=jar > -Dfile=zookeeper-3.3.0.jar > I'm putting together some documentation and will be happy to add it to the > wiki if the component gets picked up. I hope the project can find this useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Camel 2.2.0
+1 Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 12 February 2010 10:42, Willem Jiang wrote: > +1. > > It's good to see we will release apache-camel 2.2.0 before the coming up > Chinese tiger year :) > > Willem > > Hadrian Zbarcea wrote: >> >> A new release apache-camel-2.2.0 is out with approximately 180 issues >> resolved: new features, improvements and bug fixes. >> This is only a re-stage off of the 2.2.0 release tagged [1] a few days >> back, targeted at fixing the bad md5 and sha1 digests (now verified). >> Extra credit (and beer from) me go to Gert who spotted this. >> Since some of you already tested this kit I believe having a voting >> window reduced to 48 hours is appropriate. Please let me know if there >> are any objections. >> Please find the staging repo here: >> https://repository.apache.org/content/repositories/orgapachecamel-012/ >> The tarballs are here >> >> https://repository.apache.org/content/repositories/orgapachecamel-012/org/apache/camel/apache-camel/2.2.0/ >> >> Please review and vote to approve this release binary >> >> [ ] +1 Release the binary as Apache Camel 2.2.0 >> [ ] -1 Veto the release (provide specific comments) >> Vote is open for 48 hours. >> >> Here's my +1 >> >> Hadrian >> [1] https://svn.apache.org/repos/asf/camel/tags/camel-2.2.0 >> > >
Re: [jira] Commented: (CAMEL-2419) SCTP Comonent
L.S., Unfortunately, it looks like the license on that particular project is GPL, which is something we shouldn't be using at Apache according to http://www.apache.org/legal/3party.html. Perhaps we can put it in camel-extra instead? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 10 February 2010 13:27, albiii wrote: > > There is a SourceForge SCTP Java project. > http://sourceforge.net/projects/jsctp/ > I am going to create an SCTP Camel Component using it. > -- > View this message in context: > http://old.nabble.com/-jira--Created%3A-%28CAMEL-2419%29-SCTP-Comonent-tp27355458p27530427.html > Sent from the Camel Development mailing list archive at Nabble.com. > >
Re: Camel components not working inside felix
L.S., Did you deploy the camel-spring-osgi bundle as well? Afaik, that one has some extra bits for making sure that additional components/converters/... get loaded properly in an OSGi environment. You can always have a look in http://repo2.maven.org/maven2/org/apache/camel/karaf/features/2.1.0/features-2.1.0-features.xml to get a list of bundles needed for a given component (or you could switch over to Karaf, which also supports Felix and Spring DM and allows you to install Camel components with a single command ;) ) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 8 February 2010 17:55, NagendraCorpus wrote: > > Hi, > i am able to run route with bean and file components , but i am getting > problem with when i am using camel sql and camel activemq and other > remaining components . can u please send any sample code which is using > camel sql component in routing. > > Thanks , > Nagendra > > > > S. Ali Tokmen-4 wrote: >> >> Hello >> >> Are you able of running ANY route on Camel? >> >> Cheers >> >> S. Ali Tokmen >> savas-ali.tok...@bull.net >> >> Office: +33 4 76 29 76 19 >> GSM: +33 66 43 00 555 >> >> Bull, Architect of an Open World TM >> http://www.bull.com >> >> >> Le 08/02/2010 14:50, NagendraCorpus a écrit : >>> hi , can any one please give me reply soon. >>> Thanks, >>> Nagendra >>> >>> >>> NagendraCorpus wrote: >>> >>>> hi >>>> I am using camel 2.1.0 and felix is 1.8.0 and spring dm is 2.5.1 , >>>> i am trying to use camel sql component in camel routing with felix , but >>>> sql component routing is not working inside felix . file and bean >>>> components are working but remaining camel components are not working >>>> ,inorder to work camel sql routing ,which bundles i have to deploy >>>> inside >>>> felix ,please reply soon . >>>> >>>> Thanks and Regards >>>> M.Nagendra >>>> >>>> >>> >> >> >> > > -- > View this message in context: > http://old.nabble.com/Camel-components-not-working-inside-felix-tp27497195p27502829.html > Sent from the Camel Development mailing list archive at Nabble.com. > >
Re: Apache Camel 2.2.0 Release
L.S., For Felix and ServiceMix, we have a script to validate the signatures/hashes in a staged release. I have created a similar script for Camel in http://svn.apache.org/viewvc/camel/scripts/check_camel_release.sh. It does report problems with the SHA/MD5 hashes in the uploaded release candidate (tried running it as check_camel_release 007). I've also tried validating the files manually, but that still gives me different hash values, but I'm not an expert on these things so perhaps I'm missing something or doing things wrong. g...@pantoef:/tmp/camel-staging/007/org/apache/camel/camel-core/2.2.0$ for f in *.jar; do echo "`cat $f.md5` <-> `md5sum $f`"; done; 4222e0cf273b1f0c5d0c0e726b3a0f4d <-> 45c4c6d2469832e648b6e1fafe3a3330 camel-core-2.2.0.jar 0367eb9ba508638e0cea22fac160283c <-> 4634a859faf50d6d1284b02206fc7bd8 camel-core-2.2.0-javadoc.jar afbdb070cc55bfa0373843630dcedd5d <-> 88fb8f7c49260435e29cba525a164762 camel-core-2.2.0-sources.jar b5856cf16623249153c3372b45fa61d8 <-> 4e2be691ff30ffd66c8ee9179f842b72 camel-core-2.2.0-tests.jar Is anyone else seeing these problems? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 9 February 2010 07:36, Claus Ibsen wrote: > Hi > > camel-gae was missing LICENSE.txt in the -source .jar (eg not in > src/main/resources/META-INF) > I have committed the needed files to trunk. > > > > On Sun, Feb 7, 2010 at 7:49 AM, Hadrian Zbarcea wrote: >> Hi, >> >> The Apache Camel 2.2.0 Release Candidate is built and available at [1]. The >> only issue I noticed is the missing pdf manual due to a http 502 during the >> release:perform phase after building fine in previous builds. I don't think >> this is a blocker, I will upload it manually, but I need to find a more >> reliable way of generating/deploying it. >> >> I will start a vote tomorrow, after a more thorough test of this release >> candidate. Many thanks to all the contributors! >> Hadrian >> >> [1] https://repository.apache.org/content/repositories/orgapachecamel-007/ > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus >
Re: Hudson and Unit Tests
L.S., I also think it makes sense to deploy snapshots, even for unstable builds, but currently this requires us to disable the unit tests on one build and create a second CI build to run the unit tests. FWIW, I created a patch for HUDSON-3773 [1] which would allow Hudson to deploy a SNAPSHOT even for unstable builds. This will allow us to have a single build definition to run tests and deploy regular snapshots. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ [1] http://issues.hudson-ci.org/browse/HUDSON-3773 2010/1/19 Willem Jiang : > The SNAPSHOT release means a unstable release, I'm +1 for the publish the > SNAPSHOT everyday. > In most case we just don't recommend user to use the SNAPSHOT release, > only for new feature or some other integration test we use the SNAPSHOT. > > Back to the Camel unit tests, as most unit test need to start the whole > camel context, it's a time consuming work, so most unit tests take more than > 1 second to run. Maybe we need find a way to speed up the camel-unit test by > build it separately. > > Willem > > Claus Ibsen wrote: >> >> On Tue, Jan 19, 2010 at 8:31 AM, Christian Schneider >> wrote: >>> >>> Hi Willem, >>> >>> does it make sense to deploy if not all test succeed? This causes that >>> sometimes snapshots will have low quality. >>> I would prefer to only deploy when all tests work. Skipping some tests is >>> sure ok for some time if an issue can not be worked >>> out quickly. What do you think? >>> >> >> No I think its great as it is. >> >> Camel have 4600+ unit test and still counting. It takes like 3-4h on >> the hudson server to complete a test and it can break somewhere in for >> some strange reasons. We see this on the Fuse CI platforms where we >> got 10+ platforms to run Camel every single day. >> >> At Apache people want to latest code in SNAPSHOT which also can help >> when they want to verify a fix committed fixed their issue. >> If we only deploy if 100% green then SNAPSHOT could easily turn weeks >> old or longer. >> >> The current setup is great as it is IMHO. >> >> If you want SNAPSHOT which have 100% green they you can use the >> SNAPSHOTs from the fuse repos. >> >> >>> Greetings >>> >>> Christian >>> >>> >>> Am 19.01.2010 03:10, schrieb Willem Jiang: >>>> >>>> I found this issue weeks ago, it looks like we just use the Apache >>>> Hundson >>>> to deploy the camel kits now. >>>> >>>> And Gert said we can create two Hudson jobs (one for deployment and >>>> other >>>> for running test) for Camel. >>>> >>>> It's time to get them started :) >>>> >>>> Willem >>>> >>>> chrislovecnm wrote: >>>>> >>>>> A quick question >>>>> >>>>> Why are the tests skipped during the CI Hudson builds? I have filed >>>>> three >>>>> bugs today that deal directly with unit tests not building or failing. >>>>> IMHO >>>>> these may have been caught if the test where not skipped. Or a hudson >>>>> build >>>>> could be setup that nightly runs the unit tests? >>>>> >>>>> I am sure that there is a reason why the tests are off, but I was just >>>>> curious. Plus a bit frustrated that the build is broken :) >>>>> >>>>> Chris >>>> >>> >> >> >> > >
[jira] Commented: (CAMEL-463) Extend/document the Scala DSL to support every EIP the Java DSL does
[ https://issues.apache.org/activemq/browse/CAMEL-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56735#action_56735 ] Gert Vanthienen commented on CAMEL-463: --- http://svn.apache.org/viewvc?view=revision&revision=895588 adds a few more things to the Scala DSL: - intercept, interceptFrom, interceptTo - threads - Camel's AOP support - explicit keywords for filter, transform and pipeline - ... and a few improvements to the existing bits > Extend/document the Scala DSL to support every EIP the Java DSL does > > > Key: CAMEL-463 > URL: https://issues.apache.org/activemq/browse/CAMEL-463 > Project: Apache Camel > Issue Type: Task > Components: camel-scala >Reporter: Gert Vanthienen >Assignee: Gert Vanthienen >Priority: Minor > Fix For: Future > > Attachments: CAMEL-463-01.diff, CAMEL-463-02.diff, CAMEL-463-03.diff, > CAMEL-463.diff > > > Work on the Scala DSL started with CAMEL-419, but it still requires a lot of > work to have it support every EIP the Java DSL does. > http://cwiki.apache.org/confluence/pages/pageinfo.action?pageId=82603 gives a > list of all the EIPs to be implemented. We should make sure to add an > example for every EIP as we move along to make sure the entire DSL gets > documented properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Spring 3.0.0 supports in Camel
L.S., Do we need to maintain support for spring 2.5 java config in Camel trunk? Wouldn't it make more sense to migrate trunk to Spring 3.0 entirely and stick to 2.5 for one or more branches? I agree we should try to make sure that Camel trunk works with 2.5 as much as possible, but I don't think there would be a real issue in telling the camel-spring-javaconfig users that this requires Spring 3 (for Camel 2.2 and above). Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/12/23 Willem Jiang : > Just a quick updated, I managed to get ride of most failed tests in > camel-spring and camel-jms by some simple fix. > > The issue for camel-spring is caused by CamelEndpointFactory, and the issue > of camel-jms is the default JMS listenContainer doesn't seem to autostart by > default anymore. > > Now there is the camel-spring-configure issue, I will create a JIRA for it. > > Willem > > Claus Ibsen wrote: >> >> Good start. >> >> Dejan created a ticket in AMQ to get it working with Spring 3.0. >> >> And I think camel-jms depends on some API in 2.5 that was @deprecated. >> So we should take a 2nd look and mark it public as @deprecated as well >> in Camel 2.2. >> >> >> On Tue, Dec 22, 2009 at 3:36 PM, Willem Jiang >> wrote: >>> >>> Hi, >>> >>> I just committed a spring-3.0 profile in trunk/parent/pom.xml. >>> You can build the camel with spring 3.0.0 by using -Pspring-3.0 >>> I just run some test in camel-core , camel-spring and camel-jms. >>> There about 4~5 tests are failed in camel-spring, and lots of tests >>> failed >>> in camel-jms. >>> >>> For the camel-spring-configure, as the spring java configure is a part of >>> spring framework, lots changes there, we need to do change the >>> camel-spring-configure code. >>> So we can't support spring 3.0 and spring 2.x at the same time in >>> camel-spring-configure. >>> >> >> Yeah but Spring 3.0 have java config build in, so I think we may need >> a new component to support spring 3.0 and keep the one for 2.5. >> >>> For camel-spring-integration, it can run with spring 3.0 and spring 2.x >>> and >>> the same time. >>> >>> Any thought? >> >> >>> Willem >>> >> >> >> > >
[jira] Commented: (CAMEL-1567) Upgrading to JUEL 2.1.1 - Beware of API changes in JUEL
[
https://issues.apache.org/activemq/browse/CAMEL-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56151#action_56151
]
Gert Vanthienen commented on CAMEL-1567:
I managed to reproduce the binary incompatibility issue that Hadrian mentioned
earlier -- it looks like juel by default ships with a slightly different set of
javax.el classes:
{noformat}
java.lang.NoSuchMethodError:
javax.el.ExpressionFactory.newInstance(Ljava/util/Properties;)Ljavax/el/ExpressionFactory;
at
org.apache.camel.language.juel.JuelExpression.getExpressionFactory(JuelExpression.java:66)
at
org.apache.camel.language.juel.JuelExpression.setVariable(JuelExpression.java:105)
at
org.apache.camel.language.juel.JuelExpression.populateContext(JuelExpression.java:88)
at
org.apache.camel.language.juel.JuelExpression.evaluate(JuelExpression.java:57)
{noformat}
The way to avoid running into this issue is by using the JUEL
ExpressionFactoryImpl class directly (cfr.
http://svn.apache.org/viewvc?view=revision&revision=885153)
> Upgrading to JUEL 2.1.1 - Beware of API changes in JUEL
> ---
>
> Key: CAMEL-1567
> URL: https://issues.apache.org/activemq/browse/CAMEL-1567
> Project: Apache Camel
> Issue Type: Task
> Components: camel-juel
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Claus Ibsen
>Assignee: Hadrian Zbarcea
> Fix For: 2.1.0
>
>
> Hi Claus,
> Here is an explanation of the API change from Christopher Beck at JUEL:
> Hello Yogesh,
> the API to resolve methods has changed in 2.1.1. Camel's method resolver
> is breaks with JUEL 2.1.1. Generally, methods are still resolved via
> ELResolver.getValue(context, base, property), but
> - in 2.1.0, the method name was passed as a property
> - in 2.1.1, an instance of de.odysseus.el.misc.MethodInvocation is passed
> as a property
> The reason for this is to provide more detailed information about the
> method invocation to the resolver (i.e the method name, number of arguments
> and whether vararg calls are supported).
> Now, camel-juel uses its BeanAndMethodELResolver to resolve methods.
> There, findMethod(context, base, property) only handles a property
> parameter of type string. That's why it doesn't work. When migrating to
> juel 2.1.1, the BeanAndMethodELResolver class needs to be updated to work
> with MethodInvocation objects as properties.
> The JUEL 2.1.1 distribution contains a sample resolver. Taking the sample
> code, updating camel's resolver should be pretty straightforward. When
> doing so, you may also want to add property "javax.el.varArgs" in
> JuelExpression.populateDefaultExpressionProperties(..). That way you would
> take real profit by invoking vararg methods from within EL expressions.
> There's also a way to quickly modify your resolver to work with both, JUEL
> 2.1.0 and 2.1.1. Just don't ask for "property instanceof String" but use
> property.toString() as a candidate method name: the MethodInvocation's
> toString() will answer the method name.
> See nabble:
> http://www.nabble.com/Camel-JUEL-expression-weirdness-in-1.6.0-td23177119s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1567) Upgrading to JUEL 2.1.1 - Beware of API changes in JUEL
[
https://issues.apache.org/activemq/browse/CAMEL-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56150#action_56150
]
Gert Vanthienen commented on CAMEL-1567:
I've added a juel 2.1.2 bundle and upgraded to the snapshot in
http://svn.apache.org/viewvc?view=revision&revision=885088
Running *{{mvn -Pvalidate install}}* does not report any problems with this
upgrade.
I'll try to cut a release of this bundle later today so you can still get it in
camel 2.1.
@hadrian: does this bundle address the incompatibility you were referring to?
it just does a plain import of javax.el, without any additional version
constraints.
> Upgrading to JUEL 2.1.1 - Beware of API changes in JUEL
> ---
>
> Key: CAMEL-1567
> URL: https://issues.apache.org/activemq/browse/CAMEL-1567
> Project: Apache Camel
> Issue Type: Task
> Components: camel-juel
>Affects Versions: 1.6.0, 2.0-M1
>Reporter: Claus Ibsen
>Assignee: Hadrian Zbarcea
> Fix For: 2.1.0
>
>
> Hi Claus,
> Here is an explanation of the API change from Christopher Beck at JUEL:
> Hello Yogesh,
> the API to resolve methods has changed in 2.1.1. Camel's method resolver
> is breaks with JUEL 2.1.1. Generally, methods are still resolved via
> ELResolver.getValue(context, base, property), but
> - in 2.1.0, the method name was passed as a property
> - in 2.1.1, an instance of de.odysseus.el.misc.MethodInvocation is passed
> as a property
> The reason for this is to provide more detailed information about the
> method invocation to the resolver (i.e the method name, number of arguments
> and whether vararg calls are supported).
> Now, camel-juel uses its BeanAndMethodELResolver to resolve methods.
> There, findMethod(context, base, property) only handles a property
> parameter of type string. That's why it doesn't work. When migrating to
> juel 2.1.1, the BeanAndMethodELResolver class needs to be updated to work
> with MethodInvocation objects as properties.
> The JUEL 2.1.1 distribution contains a sample resolver. Taking the sample
> code, updating camel's resolver should be pretty straightforward. When
> doing so, you may also want to add property "javax.el.varArgs" in
> JuelExpression.populateDefaultExpressionProperties(..). That way you would
> take real profit by invoking vararg methods from within EL expressions.
> There's also a way to quickly modify your resolver to work with both, JUEL
> 2.1.0 and 2.1.1. Just don't ask for "property instanceof String" but use
> property.toString() as a candidate method name: the MethodInvocation's
> toString() will answer the method name.
> See nabble:
> http://www.nabble.com/Camel-JUEL-expression-weirdness-in-1.6.0-td23177119s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-2221) Inconsistent out message when using recipient list
[ https://issues.apache.org/activemq/browse/CAMEL-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-2221. Resolution: Fixed Fix Version/s: 1.6.3 Fix has been applied to trunk in http://svn.apache.org/viewvc?view=revision&revision=883713 and backported to the 1.x branch in http://svn.apache.org/viewvc?view=revision&revision=883781 > Inconsistent out message when using recipient list > -- > > Key: CAMEL-2221 > URL: https://issues.apache.org/activemq/browse/CAMEL-2221 > Project: Apache Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.0.0 >Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 1.6.3, 2.1.0 > > Attachments: CAMEL-2221.diff > > > When using the Dynamic Recipient List pattern, there's an inconsistency > between two ways of of defining that pattern: > - when using a @RecipientList-annotated method with a beanRef, you get the > list of endpoints as the out message body > - when using the same method with a recipientList(bean(...)) call, you get > the aggregated result of the invoked endpoints > I think it would be better if both options returned the same response message > and I would suggested the aggregated result of the invoked endpoints is the > more appropriate one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2221) Inconsistent out message when using recipient list
[ https://issues.apache.org/activemq/browse/CAMEL-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated CAMEL-2221: --- Attachment: CAMEL-2221.diff This patch solves the issue by always returning the aggregated result. Can someone take a quick look before I apply it? There's only one problem with this fix -- up to now, if a user mistakenly configured an @RecipientList-annotated method with the recipientList(bean(...)) call, the end result would still be ok because the bean(...) call would result in the list of endpoints being sent back. This fix would break that behavior. > Inconsistent out message when using recipient list > -- > > Key: CAMEL-2221 > URL: https://issues.apache.org/activemq/browse/CAMEL-2221 > Project: Apache Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.0.0 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 2.1.0 > > Attachments: CAMEL-2221.diff > > > When using the Dynamic Recipient List pattern, there's an inconsistency > between two ways of of defining that pattern: > - when using a @RecipientList-annotated method with a beanRef, you get the > list of endpoints as the out message body > - when using the same method with a recipientList(bean(...)) call, you get > the aggregated result of the invoked endpoints > I think it would be better if both options returned the same response message > and I would suggested the aggregated result of the invoked endpoints is the > more appropriate one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-2221) Inconsistent out message when using recipient list
Inconsistent out message when using recipient list -- Key: CAMEL-2221 URL: https://issues.apache.org/activemq/browse/CAMEL-2221 Project: Apache Camel Issue Type: Bug Components: camel-core Affects Versions: 2.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 2.1.0 When using the Dynamic Recipient List pattern, there's an inconsistency between two ways of of defining that pattern: - when using a @RecipientList-annotated method with a beanRef, you get the list of endpoints as the out message body - when using the same method with a recipientList(bean(...)) call, you get the aggregated result of the invoked endpoints I think it would be better if both options returned the same response message and I would suggested the aggregated result of the invoked endpoints is the more appropriate one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-2080) Enable features-maven-plugin validate goal for karaf features build
[ https://issues.apache.org/activemq/browse/CAMEL-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-2080. Resolution: Fixed http://svn.apache.org/viewvc?view=revision&revision=826977 adds the plugin and fixes some problems with the features.xml found by the plugin > Enable features-maven-plugin validate goal for karaf features build > --- > > Key: CAMEL-2080 > URL: https://issues.apache.org/activemq/browse/CAMEL-2080 > Project: Apache Camel > Issue Type: Task > Components: karaf >Affects Versions: 2.0.0 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 2.1.0 > > > A validate goal has been added to the features-maven-plugin which will: > - check if all bundles in the descriptor actually exist > - check if all features' bundles can be resolved (matching exports are found > for the imports) > Adding this to the platforms/karaf/features build will make it easier to > maintain the features.xml file by no longer having to test all the features > manually. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-2080) Enable features-maven-plugin validate goal for karaf features build
Enable features-maven-plugin validate goal for karaf features build --- Key: CAMEL-2080 URL: https://issues.apache.org/activemq/browse/CAMEL-2080 Project: Apache Camel Issue Type: Task Components: karaf Affects Versions: 2.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 2.1.0 A validate goal has been added to the features-maven-plugin which will: - check if all bundles in the descriptor actually exist - check if all features' bundles can be resolved (matching exports are found for the imports) Adding this to the platforms/karaf/features build will make it easier to maintain the features.xml file by no longer having to test all the features manually. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SpringSource bundle for castor in camel-castor feature
L.S., I'm writing a features.xml validator plugin and testing it on the Apache Camel features.xml file. It shows that the camel-castor feature is using a SpringSource bundle for castor. This means the camel-castor feature can not be installed on Karaf without adding the SpringSource bundle repository location to the configuration first. Now, the question is how we are going to deal with this. As far as I see, there are 3 options available: - we can improve Karaf so it allows adding the repo to the configuration from the features.xml file, so the springsource repo is available when adding the features.xml file - we can build a ServiceMix bundle for castor and release that into central repo before we do the next release of Camel - we can just document the fact that the repository url needs to be added before using the Apache Camel features What option do people prefer? Does anyone see another way of solving this? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Camel, OSGi and versioning
L.S., How about we register the default namespace "http://camel.apache.org/schema/spring"; as well as a version-specific namespace "http://camel.apache.org/schema/spring/2.1"; with the namespace handler? If people are only using one version, they can still use the default namespace and if they want to mix and match camel versions, they'd need to add the version to disambiguate between them by adding the version. We probably want to stick with a 2.x version and avoid any schema-breaking changes between 2.1.0 and 2.1.x e.g. though, to avoid that people would have to update their files on every minor upgrade. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/9/17 Guillaume Nodet : > Right, I missed that. So the point is moot. > But as Claus noted, the problem will also happen between 2.1.x and 2.2.x ... > > On Thu, Sep 17, 2009 at 09:52, Willem Jiang wrote: >> Hi Guillaume, >> >> Camel 1.6.x is still using the old namespace for the namespace handler >> "http://activemq.apache.org/camel/schema/spring"; >> >> Can you check if your camel context is updated to new camel namespace >> "http://camel.apache.org/schema/spring"; >> >> Willem >> >> Guillaume Nodet wrote: >>> >>> Unfortunately, I doubt it will work. The reason is that only the >>> schema namespace is used to choose the namespace handler, not it's >>> location, and both namespaces are defined by: >>> http://camel.apache.org/schema/spring >>> >>> On Thu, Sep 17, 2009 at 09:31, Charles Moulliard >>> wrote: >>>> >>>> Guillaume, >>>> >>>> I think that you can solve easily the problem by specifying in the xml >>>> file, >>>> the version of the camel-spring file >>>> >>>> By default, you don't mention it in the schema location and the last ont >>>> will be used (so now 2.0) >>>> >>>> xsi:schemaLocation=" >>>> http://www.springframework.org/schema/beans >>>> http://www.springframework.org/schema/beans/spring-beans.xsd >>>> http://www.springframework.org/schema/context >>>> http://www.springframework.org/schema/context/spring-context.xsd >>>> http://www.springframework.org/schema/osgi >>>> http://www.springframework.org/schema/osgi/spring-osgi.xsd >>>> http://camel.apache.org/schema/osgi >>>> http://camel.apache.org/schema/osgi/camel-osgi.xsd >>>> http://camel.apache.org/schema/spring >>>> http://camel.apache.org/schema/spring/camel-spring.xsd";> >>>> >>>> Can you try this ? >>>> >>>> xsi:schemaLocation=" >>>> http://www.springframework.org/schema/beans >>>> http://www.springframework.org/schema/beans/spring-beans.xsd >>>> http://www.springframework.org/schema/context >>>> http://www.springframework.org/schema/context/spring-context.xsd >>>> http://www.springframework.org/schema/osgi >>>> http://www.springframework.org/schema/osgi/spring-osgi.xsd >>>> http://camel.apache.org/schema/osgi >>>> http://camel.apache.org/schema/osgi/camel-osgi.xsd >>>> http://camel.apache.org/schema/spring >>>> http://camel.apache.org/schema/spring/camel-spring-2.1-SNAPSHOT.xsd >>>> "> >>>> >>>> Regards, >>>> >>>> Charles Moulliard >>>> Senior Enterprise Architect >>>> Apache Camel Committer >>>> >>>> * >>>> blog : http://cmoulliard.blogspot.com >>>> >>>> >>>> On Thu, Sep 17, 2009 at 9:19 AM, Guillaume Nodet >>>> wrote: >>>> >>>>> Ok, I'm mostly done with the OSGi metadata. >>>>> I've committed fixes to both trunk and 1.x branch. >>>>> >>>>> But my original goal is only partially achieved. >>>>> I've run some basic tests in Karaf and deployed camel 1.6-SNAPSHOT and >>>>> 2.1-SNAPSHOT. >>>>> Then, I deployed a simple spring-powered camel route and dropped it >>>>> into the Karaf deploy folder. >>>>> >>>>> Now the question is: how can I choose which version of camel I want to >>>>> run for my route ? >>>>> I guess part of t
[jira] Resolved: (CAMEL-1834) Message content sent to exception handler is not re-readable
[ https://issues.apache.org/activemq/browse/CAMEL-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-1834. Resolution: Fixed Fixed for 1.6.2-SNAPSHOT in http://svn.apache.org/viewvc?view=rev&revision=794375, the extra unit test was added to trunk first in http://svn.apache.org/viewvc?view=rev&revision=794368 > Message content sent to exception handler is not re-readable > > > Key: CAMEL-1834 > URL: https://issues.apache.org/activemq/browse/CAMEL-1834 > Project: Apache Camel > Issue Type: Bug >Affects Versions: 1.6.1 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 1.6.2 > > > When a route contains an exception handler clause, stream based message being > sent to the error handler have been cached, but the message still isn't > readable. > This only happens with a 1.6.2-SNAPSHOT, the trunk handles stream-based > messages correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1834) Message content sent to exception handler is not re-readable
Message content sent to exception handler is not re-readable Key: CAMEL-1834 URL: https://issues.apache.org/activemq/browse/CAMEL-1834 Project: Apache Camel Issue Type: Bug Affects Versions: 1.6.1 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 1.6.2 When a route contains an exception handler clause, stream based message being sent to the error handler have been cached, but the message still isn't readable. This only happens with a 1.6.2-SNAPSHOT, the trunk handles stream-based messages correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (CAMEL-1392) groovy renderer
L.S.,
I wonder if we should not make this a bit more pluggable. It might
make sense to be able to represent the same xxxDefinition in Groovy
DSL, Java DSL, XML, Scala, ... so people can see the same route
definition in multiple languages. Perhaps we can (ab)use the type
converter thing for this, converting an xxxDefinition instance to a
GroovyRenderer or something...
Regards,
Gert Vanthienen
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/7/8 alloyer :
>
> yeah, this additional method may bring improvement for my work as current
> groovy renderer does some hard code to deal with the expressions.
>
>
> janstey wrote:
>>
>> Yeah, thats probably the better option here and wouldn't be too hard to
>> implement. Xueqiang, does this sound good to you? Maybe a toDslString()
>> method or something is needed.
>>
>> On Tue, Jul 7, 2009 at 11:27 AM, Claus Ibsen
>> wrote:
>>
>>> On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey wrote:
>>> > So yeah, rendering languages that we input as a String (i.e. XPath, EL,
>>> > etc.) is easy since we have the language text available. The toString
>>> > operations on PredicateBuilders on the other hand don't return exactly
>>> what
>>> > was used to create them. Like you mentioned,
>>> header("foo").isEqualTo("bar")
>>> > returns header(foo) == bar, which is not very helpful to you.
>>> >
>>> > So, you could provide a patch to the toString methods for the
>>> > PredicateBuilders so that they return something like
>>> > header("foo").isEqualTo("bar") instead of header(foo) == bar. Though
>>> this
>>> is
>>> > not as nice looking for the tracing feature IMO. What do others think
>>> of
>>> > this change?
>>>
>>> Maybe a new method is needed that can output it more DSL like.
>>>
>>> The toString as they are are nice as they are more standard math like
>>> and easy to understand.
>>>
>>>
>>> >
>>> > On Tue, Jul 7, 2009 at 8:52 AM, alloyer wrote:
>>> >
>>> >>
>>> >> yeah, I am now using the toString() method to render the route on some
>>> >> xxxDefinitions, but I am still not sure whether the renderer can deal
>>> with
>>> >> a sufficient complicated expression through this method. I am a little
>>> >> worried
>>> >> about the renderer's handling with some incidental interminable DSL.
>>> >>
>>> >>
>>> >> willem.jiang wrote:
>>> >> >
>>> >> > Hi,
>>> >> >
>>> >> > xxxDefinition classes has the toString() method, which is useful for
>>> >> > tracing the message.
>>> >> >
>>> >> > I don't know if it can help your Groovy rendering.
>>> >> >
>>> >> > Willem
>>> >> >
>>> >> > alloyer wrote:
>>> >> >> groovyRenderer now need a lot of work on string processing and
>>> can't
>>> >> deal
>>> >> >> with some complicated expressions. If the xxxDefinition classes
>>> provide
>>> >> a
>>> >> >> toString() method which presents a DSL-style string, the rendering
>>> work
>>> >> >> will
>>> >> >> be much easier. If it is determined, I will do this work.
>>> >> >>
>>> >> >> Claus Ibsen-2 wrote:
>>> >> >>>
>>> >> >>> I do wonder if we should by default change the toString() in the
>>> >> >>> xxxDefinition to be more Java DSL like so its easier to read the
>>> >> >>> route.
>>> >> >>>
>>> >> >>>
>>> >> >>> On Sat, Jul 4, 2009 at 11:32 AM, Claus
>>> Ibsen
>>> >> >>> wrote:
>>> >> >>>> Hi
>>> >> >>>>
>>> >> >>>> I loaded the RandomLoadBalanceTest unit test from camel-core and
>>> put a
>>> >> >>>> break point at
>>> >> >>>> assertMockEndpointsSatisfied();
>>> >> >>>>
>>> >> >>>> And then inspected the CameContext and its getRouteDefinitions().
>>> >> >>>> See attached pic
Re: [ANNOUNCE] Apache ServiceMix 3.3.1 released
L.S., Sorry about the noise, picked the wrong dev list... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/23 Gert Vanthienen > The ServiceMix team is pleased to announce the availability of ServiceMix > 3.3.1. > > This release includes a number of important fixes and a few > enhancements and comes with the latest version of all the JBI > components > For more information see: > * Website: http://servicemix.apache.org/ > * Release Notes: http://servicemix.apache.org/servicemix-331.html > * Mailing lists: http://servicemix.apache.org/mailing-lists.html > > If you have feedback, questions or would like to get involved in the > ServiceMix project please join the mailing lists and let us know your > thoughts. >
[ANNOUNCE] Apache ServiceMix 3.3.1 released
The ServiceMix team is pleased to announce the availability of ServiceMix 3.3.1. This release includes a number of important fixes and a few enhancements and comes with the latest version of all the JBI components For more information see: * Website: http://servicemix.apache.org/ * Release Notes: http://servicemix.apache.org/servicemix-331.html * Mailing lists: http://servicemix.apache.org/mailing-lists.html If you have feedback, questions or would like to get involved in the ServiceMix project please join the mailing lists and let us know your thoughts.
Re: [Advice] : Architectural design regarding to granularity of SOA
Charles, There currently is no built-in way to preserve state. We could probably add that to Camel, using the exchange id as the correlation identifier to figure out which data belongs to which Exchange. However, wouldn't it be easier to put the validation result in a header? That way, the validation result could travel along with the business object, but rather as metadata about the business object instead of replacing it in the message body. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/15 Charles Moulliard : > Hi, > > I' m confronted to the following "dilemma". The architecture of a product > that I currently design uses Apache Camel 2.0 and Spring DSL. I have decided > to use Spring DSL because I would benefit of the fact that routing can be > modified in the XML file. Nevertheless, I' m confronted to the following > issue who could be solved in different ways. > > This is why I ask point of view of Camel designer to have your advices ! > > The routing calls different services to parse/validate/transform and save > content of messages. These services have been designed as interface and > classes implementing the interface. Spring is used to publish the services > top of OSGI server (Apache Karaf). Here is the description of the routing : > > > > // direct > endpoint > > > > request.body > > > method="createRequestMessage"/> // Receive as input parameter : Map Object> and return a RequestMessage object > > > method="validateRequestMessage"/> // Receive as input parameter : > RequestMessage and return a ValidationResultHolder containing List of > Errors/ boolean isValid > > > > request.isValid = true > > // Receive as > input parameter : RequestMessage and does not return anything ?? > method="saveRequestMessage"/> > > > > request.isValid = false > > method="saveErrors"/> > > > > > > > > ISSUE : After calling the bean process : (2) Validate the business message, > my RequestMessage is lost and replaced by a ValidationResultHolder > containing information about List of Errors, boolean isValid BUT the > requestMessage object is required in the process (3) Save business message > > Scenario possible to solve the issue : > > 1) Encapsulate RequestMessage class in the ValidationResultHolder class and > use the ValidationResultHolder class as input parameter for (3) save > business message process. Is it a good idea to copy objects between classes > 2) Add property in the RequestMessage class to extract from > ValidationResultHolder class : List of Errors/ boolean isValid(). Is the > purpose of a java bean model class to expose result from a validation > service ? > 3) Merge service 1), 2) 3) into one. Granularity/flexility of Camel is lost > 4) Use Java DSL instead of Spring DSL. Routing is hardcoded > > Question : Is a session context available to keep my requestMessage object > during the validation process ? > > Regards, > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > * > blog : http://cmoulliard.blogspot.com >
Re: Camel 2.0 Async Findings - Roadmap to a solution
Hi Claus, Nice work on cleaning up the async API for Camel! Using well-known java.util.concurrency classes to build the API is a good idea, makes it a lot more comprehensible for people. Just a few questions that come to mind... - How does this work relate to introducing the Channel API? Will we have a means for using async channels in the route transparently or are the two unrelated? - What happens with the original thread after the async()? I'm guessing it will wait for the async work to be done before continuing, right? - Do all the threads come from a single thread pool? Do we have a means to configure that pool? I guess my main question is, how likely are we to deadlock the entire Route by having all the threads either waiting on some Future or waiting to get another thread from the pool? Just wondering if we could somehow put an Erlang-style message-passing concurrency mechanism underneath our Route afterwards -- in a transparent way so people wouldn't have to worry about this. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/5/6 Claus Ibsen : > Hi > > Status update > > On Wed, May 6, 2009 at 9:17 AM, Claus Ibsen wrote: >> Hi >> >> I have committed first cut of the new Async API to Camel trunk. >> See ticket CAMEL-1572 for svn revision and details. >> >> The remaining work: >> - Migrate MulticastProcessor > DONE > >> - Remove last piece of old API classes (2 interfaces) > DONE > >> - Introduce Async DSL to replace Thread DSL and with clear intention >> of turning route into async mode and support thread pools using JDK >> executor service. >> - Support Jetty continuation with async >> >
[jira] Resolved: (CAMEL-1526) Add a ServiceMix Kernel features descriptor to Camel
[ https://issues.apache.org/activemq/browse/CAMEL-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-1526. Resolution: Fixed Fix Version/s: 1.6.1 Switched to using simple Maven resource filtering in http://svn.eu.apache.org/viewvc?view=rev&revision=769346 and backported that to Camel 1.x in http://svn.eu.apache.org/viewvc?view=rev&revision=769351 Once SMX4KNL-272 is resolved, we should be able to validate the features.xml file using the plugin so it becomes a bit easier to maintain it over time. > Add a ServiceMix Kernel features descriptor to Camel > > > Key: CAMEL-1526 > URL: https://issues.apache.org/activemq/browse/CAMEL-1526 > Project: Apache Camel > Issue Type: Improvement >Affects Versions: 2.0-M1 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 1.6.1, 2.0.0 > > > ServiceMix 4 already ships with a features descriptor for Apache Camel, but > it would be better if Camel itself could provide the descriptor instead. > Cfr. > http://cwiki.apache.org/SM/discussion-forums.html#nabble-td22832099|a22843269 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Code formatter - Eclipse / checkstyle
Charles,
I think you are looking for the files in etc/eclipse.
I guess we should configure the maven-eclipse-plugin to generate the
correct formatter description in the project settings while doing a
mvn eclipse:eclipse, so these settings happen automatically.
Regards,
Gert Vanthienen
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/4/28 Charles Moulliard :
> Hi Claus,
>
> I already have a look to the files : camel-eclipse-*** but the content of
> these files is completely different from what we have in the eclipse 3.4
> templates :
>
>
>
> description="non-externalized string marker" enabled="true"
> id="org.eclipse.jdt.ui.templates.non-nls"
> name="nls">//$$NON-NLS-${N}$$
>
> So I don't know how such files are used, for which version of Eclipse,
> ???
>
> Regards,
>
> Charles
>
> On Tue, Apr 28, 2009 at 9:26 AM, Claus Ibsen wrote:
>
>> Hi
>>
>> Take a look in the camel source. There should be some checkstyle files
>> that Eclipse can use.
>>
>> In this folder
>> /buildingtools/src/main/resources$
>>
>>
>>
>> On Tue, Apr 28, 2009 at 9:19 AM, Charles Moulliard
>> wrote:
>> > Hi,
>> >
>> > I'm looking for a template that I can use in Eclipse Ganymede 3.4
>> allowing
>> > to format my code according to checkstyle rules which are supported by
>> > Apache Camel community.
>> >
>> > Is such template existing ?
>> >
>> > Regards,
>> >
>> > Charles Moulliard
>> > Senior Enterprise Architect
>> > Apache Camel Committer
>> >
>> >
>> > blog http://cmoulliard.blogspot.com
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>> Apache Camel Reference Card:
>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>
>
Re: Question about load the camel-core feature with PAX-Exam
Willem, The generator now uses a 4 step routine: - make an inventory of all the bundles and OSGi exports in the provided dependencies (that's where we define ServiceMix Kernel) - make an inventory of all the bundles and OSGi exports in the src/main/resources/bundle.properties file - scan the Camel component dependencies for JAR files that are already bundles and keep track of their OSGi exports - finally generate the feature descriptor, using all the bundles it inventorized to satisfy the OSGi imports required by the component Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/27 Willem Jiang : > Hi Gert, > > Yes, when I remove the dependency of the ServiceMix-Kernel, I can see > the spring bundles below the camel-core feature. > Just quick question, how can the SMX features-maven-plugin find out the > bundles which are not in the bundle repository of Servicemix ? > > Thanks, > > Willem > > Gert Vanthienen wrote: >> Willem, >> >> Excluding a bundle from the provided shouldn't have any real >> side-effects. There will be more bundles in the feature descriptor >> but these would be ignored by Kernel because they're already >> installed. If you run a mvn dependency:tree -Dverbose=true in the >> features project, you'll see a list of things that we include (mina, >> spring, commons bits, ...) >> >> We could adjust the features descriptor generator to create another >> features descriptor, not taking into account any of the bundles that >> are available from kernel. Another solution would be creating a >> servicemix-kernel profile for Pax Runner to provide the missing >> bundles. >> >> Regards, >> >> Gert Vanthienen >> >> Open Source SOA: http://fusesource.com >> Blog: http://gertvanthienen.blogspot.com/ >> >> >> >> 2009/4/26 Willem Jiang : >>> Hi Gert, >>> >>> I just found there are not other Spring relates jars in the camel-spring >>> features package. >>> May be I need to install the ServiceMix kernel features first to avoid >>> the org.osgi.framework.BundleException. >>> >>> Willem >>> >>> Willem Jiang wrote: >>>> Hi Gert, >>>> >>>> Since I want to use the features out side of the Karaf, so I want the >>>> stax-api bundle to be included in the camel-core feature. >>>> I guess this inclusion will have side effect on camel-core be load by >>>> Karaf :) >>>> If so I'd like to do that change. >>>> >>>> Thanks, >>>> >>>> Willem >>>> >>>> >>>> Gert Vanthienen wrote: >>>>> Willem, >>>>> >>>>> The generator creates a features descriptor for use in Apache Karaf >>>>> (aka ServiceMix Kernel). It calculates the bundles that are required >>>>> for a given JAR to satisfy all the OSGi imports, but it also knows >>>>> about the packages exported by Kernel itself. In this case, >>>>> ServiceMix Kernel ships with a JAXP spec bundle that has the >>>>> javax.xml.stream packages, so that's why it didn't include that >>>>> bundle. >>>>> >>>>> So, if you'd like to get it included in the features descriptor >>>>> anyway, the way to do it would be by excluding the JAXP Spec bundle >>>>> from the kernel in the features' pom.xml (similar to >>>>> what has been done for the asm bundle). >>>>> >>>>> Regards, >>>>> >>>>> Gert Vanthienen >>>>> >>>>> Open Source SOA: http://fusesource.com >>>>> Blog: http://gertvanthienen.blogspot.com/ >>>>> >>>>> >>>>> >>>>> 2009/4/24 Willem Jiang : >>>>>> Hi Gert, >>>>>> >>>>>> I'm try to load the Camel 2.0 SNAPSHOT features from the PAX-Exam. >>>>>> I got below error when the PAX-Runner load the below bundle >>>>>> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.1/1.3.0 >>>>>> >>>>>> BTW, If I remove the jaxb-api bundle, the camel-context can be start >>>>>> without any error. >>>>>> Did I miss some thing ? >>>>>> >>>>>> ## DEBU
Re: Can we Speed up the build of Camel feature?
Willem, If you run this build on a clean repo, it will download all dependencies for ServiceMix Kernel and all the Camel components. It will also download the replacement bundles to figure out the OSGi imports/exports. It will download these artifacts into your local Maven repo, so a subsequent run of the same build should be significantly faster (I have 50 sec here once the artifacts are in your local repo). Other than that, I agree with Bruce that cutting back the number of repositories would be the best way to solve it. Actually, I'm considering to remove the features generation process and replace it by simple resource filtering in Maven. The main drawback would be that we don't have any validation of the file at build time any more (now the plugin complains about missing imports/bundles), so I raised https://issues.apache.org/activemq/browse/SMX4KNL-272 to create a more specific plugin goal to tackle that. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/27 Willem Jiang : > Hi, > > I found it takes about 18 mins to build the > camel\platforms\karaf\features module. > It will check 4~6 maven repositories for every dependency module, can we > introduce some kind of cache mechanism to speed up the build of Camel > feature? > > Willem >
Re: Question about load the camel-core feature with PAX-Exam
Willem, Excluding a bundle from the provided shouldn't have any real side-effects. There will be more bundles in the feature descriptor but these would be ignored by Kernel because they're already installed. If you run a mvn dependency:tree -Dverbose=true in the features project, you'll see a list of things that we include (mina, spring, commons bits, ...) We could adjust the features descriptor generator to create another features descriptor, not taking into account any of the bundles that are available from kernel. Another solution would be creating a servicemix-kernel profile for Pax Runner to provide the missing bundles. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/26 Willem Jiang : > Hi Gert, > > I just found there are not other Spring relates jars in the camel-spring > features package. > May be I need to install the ServiceMix kernel features first to avoid > the org.osgi.framework.BundleException. > > Willem > > Willem Jiang wrote: >> Hi Gert, >> >> Since I want to use the features out side of the Karaf, so I want the >> stax-api bundle to be included in the camel-core feature. >> I guess this inclusion will have side effect on camel-core be load by >> Karaf :) >> If so I'd like to do that change. >> >> Thanks, >> >> Willem >> >> >> Gert Vanthienen wrote: >>> Willem, >>> >>> The generator creates a features descriptor for use in Apache Karaf >>> (aka ServiceMix Kernel). It calculates the bundles that are required >>> for a given JAR to satisfy all the OSGi imports, but it also knows >>> about the packages exported by Kernel itself. In this case, >>> ServiceMix Kernel ships with a JAXP spec bundle that has the >>> javax.xml.stream packages, so that's why it didn't include that >>> bundle. >>> >>> So, if you'd like to get it included in the features descriptor >>> anyway, the way to do it would be by excluding the JAXP Spec bundle >>> from the kernel in the features' pom.xml (similar to >>> what has been done for the asm bundle). >>> >>> Regards, >>> >>> Gert Vanthienen >>> >>> Open Source SOA: http://fusesource.com >>> Blog: http://gertvanthienen.blogspot.com/ >>> >>> >>> >>> 2009/4/24 Willem Jiang : >>>> Hi Gert, >>>> >>>> I'm try to load the Camel 2.0 SNAPSHOT features from the PAX-Exam. >>>> I got below error when the PAX-Runner load the below bundle >>>> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.1/1.3.0 >>>> >>>> BTW, If I remove the jaxb-api bundle, the camel-context can be start >>>> without any error. >>>> Did I miss some thing ? >>>> >>>> ## DEBUG: errors - FrameworkErrorEvent bundle #7 >>>> ## DEBUG: errors - FrameworkErrorEvent throwable: >>>> org.osgi.framework.BundleException: Unable to resolve bundle: missing >>>> package(s) or can not resolve all of the them: >>>> javax.xml.stream;version=1.0.0 >>>> at >>>> org.knopflerfish.framework.BundleImpl.getUpdatedState(BundleImpl.java:1036) >>>> at org.knopflerfish.framework.BundleImpl.start(BundleImpl.java:312) >>>> at >>>> org.knopflerfish.framework.StartLevelImpl.increaseStartLevel(StartLevelImpl.java:278) >>>> at >>>> org.knopflerfish.framework.StartLevelImpl$1.run(StartLevelImpl.java:210) >>>> at >>>> org.knopflerfish.framework.StartLevelImpl.run(StartLevelImpl.java:171) >>>> at java.lang.Thread.run(Thread.java:595) >>>> org.osgi.framework.BundleException: Failed, missing package(s) or can >>>> not resolve all of the them: javax.xml.stream;version=1.0.0 >>>> at org.knopflerfish.framework.BundleImpl.start(BundleImpl.java:314) >>>> at >>>> org.knopflerfish.framework.StartLevelImpl.increaseStartLevel(StartLevelImpl.java:278) >>>> at >>>> org.knopflerfish.framework.StartLevelImpl$1.run(StartLevelImpl.java:210) >>>> at >>>> org.knopflerfish.framework.StartLevelImpl.run(StartLevelImpl.java:171) >>>> at java.lang.Thread.run(Thread.java:595) >>>> >>>> Willem >>>> >> >> > >
[jira] Commented: (CAMEL-1536) add an integration test for Camel in OSGi containers like Felix and Equinox
[ https://issues.apache.org/activemq/browse/CAMEL-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51321#action_51321 ] Gert Vanthienen commented on CAMEL-1536: These tests were failing on Hudson/TeamCity because they override the Maven local repository location using -Dmaven.repo.local=/some/dir. Unfortunately, Pax Exam doesn't support this yet (cfr. [PAXEXAM-62|http://issues.ops4j.org/browse/PAXEXAM-62] and [PAXEXAM-64|http://issues.ops4j.org/browse/PAXEXAM-64]), so using a workaround using the Pax Exam Maven plugin to generate a config file to point to the right local Maven repo in http://svn.apache.org/viewvc?view=rev&revision=767141 > add an integration test for Camel in OSGi containers like Felix and Equinox > --- > > Key: CAMEL-1536 > URL: https://issues.apache.org/activemq/browse/CAMEL-1536 > Project: Apache Camel > Issue Type: Improvement >Reporter: James Strachan >Assignee: James Strachan > Fix For: 2.0.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1526) Add a ServiceMix Kernel features descriptor to Camel
[ https://issues.apache.org/activemq/browse/CAMEL-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51285#action_51285 ] Gert Vanthienen commented on CAMEL-1526: Claus, thanks for signaling this! Added the missing repo in trunk and branch, so the build should be OK again. > Add a ServiceMix Kernel features descriptor to Camel > > > Key: CAMEL-1526 > URL: https://issues.apache.org/activemq/browse/CAMEL-1526 > Project: Apache Camel > Issue Type: Improvement >Affects Versions: 2.0-M1 > Reporter: Gert Vanthienen > Assignee: Gert Vanthienen > Fix For: 2.0.0 > > > ServiceMix 4 already ships with a features descriptor for Apache Camel, but > it would be better if Camel itself could provide the descriptor instead. > Cfr. > http://cwiki.apache.org/SM/discussion-forums.html#nabble-td22832099|a22843269 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1526) Add a ServiceMix Kernel features descriptor to Camel
[ https://issues.apache.org/activemq/browse/CAMEL-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51262#action_51262 ] Gert Vanthienen commented on CAMEL-1526: Backported to Camel 1.x branch in http://svn.apache.org/viewvc?view=rev&revision=766118 > Add a ServiceMix Kernel features descriptor to Camel > > > Key: CAMEL-1526 > URL: https://issues.apache.org/activemq/browse/CAMEL-1526 > Project: Apache Camel > Issue Type: Improvement >Affects Versions: 2.0-M1 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 2.0.0 > > > ServiceMix 4 already ships with a features descriptor for Apache Camel, but > it would be better if Camel itself could provide the descriptor instead. > Cfr. > http://cwiki.apache.org/SM/discussion-forums.html#nabble-td22832099|a22843269 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1526) Add a ServiceMix Kernel features descriptor to Camel
[ https://issues.apache.org/activemq/browse/CAMEL-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51252#action_51252 ] Gert Vanthienen commented on CAMEL-1526: Initial commit for trunk in http://svn.apache.org/viewvc?view=rev&revision=766016 The list of components reflects those available in 1.6, so I'll backport this first before adding the new 2.0 components. > Add a ServiceMix Kernel features descriptor to Camel > > > Key: CAMEL-1526 > URL: https://issues.apache.org/activemq/browse/CAMEL-1526 > Project: Apache Camel > Issue Type: Improvement >Affects Versions: 2.0-M1 >Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 2.0.0 > > > ServiceMix 4 already ships with a features descriptor for Apache Camel, but > it would be better if Camel itself could provide the descriptor instead. > Cfr. > http://cwiki.apache.org/SM/discussion-forums.html#nabble-td22832099|a22843269 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1539) Upgrade to Jackrabbit 1.5.3
[ https://issues.apache.org/activemq/browse/CAMEL-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-1539. Resolution: Fixed Fixed as part of CAMEL-1526 (cfr. http://svn.apache.org/viewvc?view=rev&revision=766016) > Upgrade to Jackrabbit 1.5.3 > --- > > Key: CAMEL-1539 > URL: https://issues.apache.org/activemq/browse/CAMEL-1539 > Project: Apache Camel > Issue Type: Improvement > Components: camel-jcr >Affects Versions: 1.6.0 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen >Priority: Minor > Fix For: 2.0.0 > > > JackRabbit 1.5.x JARs are OSGi bundles so upgrading to those to make the > component more OSGi-aware. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1527) Upgrade to Scala 2.7.3
[ https://issues.apache.org/activemq/browse/CAMEL-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-1527. Resolution: Fixed Fixed as part of CAMEL-1526 (cfr. http://svn.apache.org/viewvc?view=rev&revision=766016) > Upgrade to Scala 2.7.3 > -- > > Key: CAMEL-1527 > URL: https://issues.apache.org/activemq/browse/CAMEL-1527 > Project: Apache Camel > Issue Type: Improvement > Components: camel-scala >Affects Versions: 2.0-M1 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen >Priority: Trivial > Fix For: 2.0.0 > > > Upgrading to Scala 2.7.3 because that one has an OSGi bundle available for > use in the ServiceMix Kernel features descriptor (CAMEL-1526). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1539) Upgrade to Jackrabbit 1.5.3
Upgrade to Jackrabbit 1.5.3 --- Key: CAMEL-1539 URL: https://issues.apache.org/activemq/browse/CAMEL-1539 Project: Apache Camel Issue Type: Improvement Components: camel-jcr Affects Versions: 1.6.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Minor Fix For: 2.0.0 JackRabbit 1.5.x JARs are OSGi bundles so upgrading to those to make the component more OSGi-aware. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1332) StreamCachingInterceptor can be enabled both as a strategy and as an interceptor -- should only be a strategy
[ https://issues.apache.org/activemq/browse/CAMEL-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51196#action_51196 ] Gert Vanthienen commented on CAMEL-1332: Claus, I don't think enabling it at the start of the route is enough. If you look at CAMEL-1271, the problem there was an InOut style interaction with an external service in the middle of the route. If the response from the service is a streaming data type (e.g. a StreamSource), you would need to cache that as well to ensure proper handling. > StreamCachingInterceptor can be enabled both as a strategy and as an > interceptor -- should only be a strategy > - > > Key: CAMEL-1332 > URL: https://issues.apache.org/activemq/browse/CAMEL-1332 > Project: Apache Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 1.5.0 >Reporter: Gert Vanthienen >Assignee: Claus Ibsen > Fix For: 2.0.0, 1.6.1 > > > Right now, there are two ways of enabling stream caching: > - explicitly enable it through the DSL > - implicitly enable it through e.g. a Multicast or DeadletterChannel > We should make that a single way of enablement or else document the rationale > for the difference properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1527) Upgrade to Scala 2.7.3
Upgrade to Scala 2.7.3 -- Key: CAMEL-1527 URL: https://issues.apache.org/activemq/browse/CAMEL-1527 Project: Apache Camel Issue Type: Improvement Components: camel-scala Affects Versions: 2.0-M1 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Trivial Fix For: 2.0.0 Upgrading to Scala 2.7.3 because that one has an OSGi bundle available for use in the ServiceMix Kernel features descriptor (CAMEL-1526). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1526) Add a ServiceMix Kernel features descriptor to Camel
Add a ServiceMix Kernel features descriptor to Camel Key: CAMEL-1526 URL: https://issues.apache.org/activemq/browse/CAMEL-1526 Project: Apache Camel Issue Type: Improvement Affects Versions: 2.0-M1 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 2.0.0 ServiceMix 4 already ships with a features descriptor for Apache Camel, but it would be better if Camel itself could provide the descriptor instead. Cfr. http://cwiki.apache.org/SM/discussion-forums.html#nabble-td22832099|a22843269 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1523) Update POM for doing releases using Nexus
[ https://issues.apache.org/activemq/browse/CAMEL-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-1523. Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=rev&revision=762935 and backported to 1.x branch in http://svn.apache.org/viewvc?view=rev&revision=762949 > Update POM for doing releases using Nexus > - > > Key: CAMEL-1523 > URL: https://issues.apache.org/activemq/browse/CAMEL-1523 > Project: Apache Camel > Issue Type: Task >Affects Versions: 1.6.0, 2.0-M1 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen >Priority: Minor > Fix For: 2.0.0, 1.6.1 > > > Nexus has been set up to allow releasing using the procedure described in > http://maven.apache.org/developers/release/releasing.html. > We only need a few minor adjustments in our pom -- cfr. > https://issues.apache.org/jira/browse/INFRA-1950 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1523) Update POM for doing releases using Nexus
Update POM for doing releases using Nexus - Key: CAMEL-1523 URL: https://issues.apache.org/activemq/browse/CAMEL-1523 Project: Apache Camel Issue Type: Task Affects Versions: 2.0-M1, 1.6.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Minor Fix For: 2.0.0, 1.6.1 Nexus has been set up to allow releasing using the procedure described in http://maven.apache.org/developers/release/releasing.html. We only need a few minor adjustments in our pom -- cfr. https://issues.apache.org/jira/browse/INFRA-1950 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSS] Move the Camel features into Camel
L.S., Currently, a features descriptor for Camel is being generated in the ServiceMix 4 features projects. This descriptor basically is an XML file that allows you to install any Camel component on ServiceMix Kernel in a single command. The information in the descriptor will be used to determine which others OSGi bundles are required. We now released ServiceMix 4.0.0 with a features descriptor for Camel 1.6.0, but on the Camel project itself we're now working on 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move the generation process of the features descriptor into the Camel project itself, so every release of Camel can come with its own features descriptor. It will also make it easier for people to test a SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up their own descriptor first. If we look at the codebase, it will basically mean that we would have to move the pom.xml and properties file that's currently at https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ to e.g. a /platform/servicemix-kernel directory in the Camel project. Any thoughs? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: BatchProcessor interrupt side effects
L.S.,
First of all, thanks for taking the time to review the code and come
up with these suggestions. Yes, I think it would probably make sense
to leverage the helper classes available in java.util.concurrent
instead of doing Thread.sleep() ourselves and then interrupting the
thread again when an Exchange arrives. Just wonder if we can't just
rely on some thread-safe queue or latch to provide the same semantics,
but anyway you're welcome to raise a JIRA issue and attach your
proposed patch there.
Regards,
Gert Vanthienen
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/4/1 huntc :
>
> I have noticed that the BatchProcessor class uses the Thread class interrupt
> method to wake the run loop from sleeping within the enqueueExchange method.
>
> The unfortunate side effect of this is that if the run loop is in the middle
> of processing exchanges, and the processing involves something slow like
> establishing a JMS connection over SSL, then the processing can become
> interrupted.
>
> This all became apparent during some performance testing that resulted in
> continuously adding exchanges to the aggregator, the threshold becoming
> reached, and then trying to enqueue the aggregated result to a JMS queue.
>
> If my analysis of the BatchProcessor is correct then I would recommend a
> Condition object being used instead of relying upon interrupting a thread.
> Perhaps something like the following (untested - could be mistakes of course
> - assumes present Camel 1.6 trunk):
>
>
> private class BatchSender extends Thread {
>
> private boolean enqueuedExchange = false;
> private Lock runLock = new ReentrantLock();
> private Condition runCondition = runLock.newCondition();
>
> private LinkedBlockingQueue queue;
>
> public BatchSender() {
> super("Batch Sender");
> this.queue = new LinkedBlockingQueue();
> }
>
> �...@override
> public void run() {
> runLock.lock();
> try {
> do {
> try {
> if (!enqueuedExchanged) {
> runCondition.await(batchTimeout,
> TimeUnit.MILLISECONDS);
> if (!enqueuedExchanged) {
> queue.drainTo(collection, batchSize);
> }
> }
>
> if (enqueuedExchanged) {
> enqueuedExchange = false;
>
> runLock.unlock();
> try {
> while (isInBatchCompleted(queue.size())) {
> queue.drainTo(collection, batchSize);
> }
>
> if (!isOutBatchCompleted()) {
> continue;
> }
>
> } finally {
> runLock.lock();
> }
> }
>
> runLock.unlock();
> try {
> try {
> sendExchanges();
> } catch (Exception e) {
> getExceptionHandler().handleException(e);
> }
>
> } finally {
> runLock.lock();
> }
>
> } catch (InterruptedException e) {
> break;
> }
>
> } while (true);
>
> } finally {
> runLock.unlock();
> }
>
> }
>
> public void cancel() {
> interrupt();
> }
>
> public void enqueueExchange(Exchange exchange) {
> queue.add(exchange);
> runLock.lock();
> try {
> enqueuedExchange = true;
> runCondition.signal();
> } finally {
> runLock.unlock();
> }
> }
>
> private void sendExchanges() throws Exception {
> Iterator iter = collection.iterator();
> while (iter.hasNext()) {
> Exchange exchange = iter.next();
> iter.remove();
> processExchange(exchange);
> }
> }
> }
>
>
> I acknowledge that the above is more complex than what is there presently
> but I think the complexity is necessary. Cancellations will still result in
Re: [DISCUSS] Moving Camel releases to Nexus
+1 Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/3/31 Hadrian Zbarcea : > Forwarding to the correct address. > > Begin forwarded message: > >> From: James Strachan >> Date: March 31, 2009 2:31:50 PM EDT >> To: priv...@camel.apache.org >> Subject: Re: [DISCUSS] Moving Camel releases to Nexus >> Reply-To: priv...@camel.apache.org >> >> Shouldn't this be on the Dev list? >> >> >> On 31/03/2009, Hadrian Zbarcea wrote: >>> >>> Hi, >>> >>> Apache has a Nexus repository manager at [1] and a new release >>> procedure described [2]. The new Camel snapshots are already deployed >>> in Nexus thanks to Gert. I'd recommend deploying future camel >>> releases in Nexus. There is an INFRA-1950 [3] issue open that awaits >>> our decision. >>> >>> My +1 >>> Hadrian >>> >>> [1] https://repository.apache.org/index.html >>> [2] http://maven.apache.org/developers/release/releasing.html >>> [3] https://issues.apache.org/jira/browse/INFRA-1950 >>> >>> >> >> >> -- >> James >> --- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ > >
Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
L.S., I'm in favor of disabling error handling by default as well. People should really configure this to suit their environment. And with my ServiceMix hat on, this would be a big improvement as well -- error handling should be configured there based on the properties of the given message flow (e.g. transaction or not, clustered or not, ...). Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/3/31 Claus Ibsen : > Hi > > As we work on the Camel 2.0 I would suggest that we start a discussion > what should be the preferred error handler defaults in Camel 2.0. > What we currently have is the DLC is default and it does 6 retries > with 1 sec apart and then just log an ERROR and ends the exchange. > > We have 3 different error handler types > - no error handler (= disabled) > - DeadLetterChannel (= default in 1.x) > - TransactionErrorHandler (= using Spring TX) > > As people can use Camel in different runtimes and with different needs > for error handling we cannot have a default that fits all situations. > > We could for instance do > > 1) > Disable error handling by default. > > This would be the least surprises for end users. If there is some > exception then it would be propagated back to the caller. > We could even optimize the logic in Camel to avoid adding the > interceptor that adds the noErrorHandler. > > +1 from me > > > 2) > Keep it as is > big -1 from me. We have the luxury of being able to change defaults > before 2.0 is released. So we should do it!!! > > > 3) > Use DeadLetterChannel but add a feature so it avoids failure handling > it by default. So it will be able to do retries but if it fails all > together > it will propagate the exception back to the caller as if the have been > no error handler at all. > > This feature could also be useable for end users in other situations, > eg retry IOExceptions and in case of a all attempts failed then > propgate the excpetion back to the caller. > > What should the option name be: > - moveToDeadLetterQueue=false > - handled=false (like the handled we have at onException) > > +1 as well. We can even do #1 and #3 > > > 4) > For TX its mostly all the Spring XML garbage that is needed to setup > TX that can be a bit hard to get configure correct. > So the JMS component have a transacted=true option to allow to do this > itself or discover if there is a Spring TX manager already. > > Maybe we can default to use transactionErrorHandler if we can find a > Spring TX manager. But this would only work for certain transports > that support TX, and that is mostly only JMS and JDBC. > > So what should happens for routing not involving those, eg camel-cxf, > over file to a mail etc? > Could be confusing, if Camel uses TX for certain routes and the other > for the other routes. > > So what we have now with the transacted=true option is good as end > users need to explicit declare this option. > We could maybe add this for the JDBC based components as well: JPA, JDBC, SQL. > > > Any thoughts? > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus >
Re: [DISCUSS] Snapshot deploy from Hudson to Nexus
Yeah, I'll add SNAPSHOTs for the 1.x branch while I'm at it. It's already being built by Hudson, so it shouldn't be that much trouble to add it. Raised a JIRA for the infrastructure team to get Nexus access for Apache Camel (https://issues.apache.org/jira/browse/INFRA-1950) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/3/24 Willem Jiang : > +1, and we need to setup a same deployment for Camel 1.x. > > Willem > > > Claus Ibsen wrote: >> +1 >> >> Would that apply for both Camel 1.x and trunk? >> >> AFAIR we don't have SNAPSHOT builds of 1.x published any more, >> requested by end users to be published again. >> >> >> On Mon, Mar 23, 2009 at 8:52 PM, Gert Vanthienen >> wrote: >>> L.S., >>> >>> >>> Right now, we have two build servers: >>> - Camel builds for deploying nightly snapshots are running on >>> http://projects.open.iona.com/builds/status >>> - Camel builds are running fine on hudson.zones.apache.org for a few weeks >>> now >>> >>> Apache also has a Nexus repository manager installed at >>> http://repository.apache.org now. >>> I'd like to start deploying our SNAPSHOTs to this repository from >>> Hudson directly instead of using the separate build server. In the >>> future, we should also be able to leverage Nexus for the release >>> process as well, i.e. deploy the artifacts under vote to a Nexus >>> staging repo and then just promote the artifacts into the release repo >>> after teh vote. >>> >>> The major downside would be that the repository url for snapshots >>> would change from >>> http://people.apache.org/repo/m2-snapshot-repository/ to >>> https://repository.apache.org/content/repositories/snapshots. >>> >>> >>> Regards, >>> >>> Gert Vanthienen >>> >>> Open Source SOA: http://fusesource.com >>> Blog: http://gertvanthienen.blogspot.com/ >>> >> >> >> > >
[DISCUSS] Snapshot deploy from Hudson to Nexus
L.S., Right now, we have two build servers: - Camel builds for deploying nightly snapshots are running on http://projects.open.iona.com/builds/status - Camel builds are running fine on hudson.zones.apache.org for a few weeks now Apache also has a Nexus repository manager installed at http://repository.apache.org now. I'd like to start deploying our SNAPSHOTs to this repository from Hudson directly instead of using the separate build server. In the future, we should also be able to leverage Nexus for the release process as well, i.e. deploy the artifacts under vote to a Nexus staging repo and then just promote the artifacts into the release repo after teh vote. The major downside would be that the repository url for snapshots would change from http://people.apache.org/repo/m2-snapshot-repository/ to https://repository.apache.org/content/repositories/snapshots. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
[jira] Created: (CAMEL-1403) Integration tests may stall
Integration tests may stall --- Key: CAMEL-1403 URL: https://issues.apache.org/activemq/browse/CAMEL-1403 Project: Apache Camel Issue Type: Bug Components: tests Reporter: Gert Vanthienen Cfr. http://hudson.zones.apache.org/hudson/job/Camel/35/ -- the build was hanging on the Camel itests -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1386) create a way of loading all of the available components & languages on startup - so that they can be exposed for tooling/reporting
[
https://issues.apache.org/activemq/browse/CAMEL-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50004#action_50004
]
Gert Vanthienen commented on CAMEL-1386:
Do you mean like keeping a ComponentRegistry of some kind to lookup the
component by name instead of doing the lookup with the META-INF file when
reading it from the endpoint URI?
I think filling the registry might be somewhat different, depending on the
runtime environment:
- For a plain Java environment, scanning the classpath for a file like you
suggested would be nice way to handle it
- When using Spring, we could also take a look at the ApplicationContext for
finding other Compent implementations and registering them
- For an OSGi environment, it would be nice to build a BundleListener/Activator
to add components to the registry as soon as the bundle is started.
> create a way of loading all of the available components & languages on
> startup - so that they can be exposed for tooling/reporting
> --
>
> Key: CAMEL-1386
> URL: https://issues.apache.org/activemq/browse/CAMEL-1386
> Project: Apache Camel
> Issue Type: Improvement
>Reporter: James Strachan
> Fix For: 2.1.0
>
>
> There's no way to know what languages or components are available (other than
> looking at all objects in the registry but lots of components/languages are
> never in the registry) - we only know the ones that have been registered
> (used).
> This is because we dynamically create them on the fly by looking up the
> /META-INF/services/.../$name file. The downside is I don't think we can list
> - say - the files in
> {code}/META-INF/services/org/apache/camel/component/*{code} on the classpath
> - due to the ClassLoader API; you can only look up resources by name.
> It might be nice to load them all on startup so we can iterate through them
> all - so from a tooling/UI perspective we can list them all.
> For example in the [Web Console|http://camel.apache.org/] we can then show
> all the available components folks can use if they wish and similarly
> languages.
> To implement this we could maybe hack the maven plugin we mention in
> CAMEL-1385 (which we'll start using in each camel module which defines a
> component/language/converter) so that we generate some canonical file which
> links to the component/language.
> e.g. for JMS we might already have this file on the classpath
> {code}
> /META-INF/services/org/apache/camel/component/jms
> {code}
> but generically we can't auto-discover all the component names. So maybe we
> also generate a little file
> {code}
> /META-INF/services/org/apache/camel/componentName
> {code}
> which just contains the component name (i.e. 'jms').
> Then we can load all of the available
> */META-INF/services/org/apache/camel/componentName* files - read their
> contents and then load the "jms" component along with all the other ones we
> find.
> Ditto for languages too. We don't have this problem for type converters as we
> already load those on startup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Camel 2.0 - Asembly fails on hudson
Claus,
Not sure why it never showed up before, but the component descriptor we
use should be using a tag instead of an tag
according to the docs. I have just modified this and it seems to fix
the build again on my machine. I've just kicked off a new Hudson build
as well...
Regards,
Gert
Claus Ibsen wrote:
Hi
Hudson have reported assembly error with Camel since build #23
http://hudson.zones.apache.org/hudson/job/Camel/23/
I look in the changelog and camel-web-standalone was added in this
build over #22 that is the last good.
The pom.xml file for camel-web-standalone looks a bit odd
- packaging is missing, should it be a bundle / jar?
- osgi exports is missing if bundle
- it has some assembly attach phase in the bottom (that I think could
be the issue)
Could someone with solid Maven expertice look into this?
The error from Hudson is:
===
INFO]
[INFO] Building Camel :: Assembly
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/home/hudson/hudson-slave/workspace/Camel/camel-trunk/apache-camel/target
[INFO] [site:attach-descriptor]
[INFO] [dependency:copy {execution: copy-bundle-jar}]
[INFO] Configured Artifact: org.apache.camel:camel-bundle:2.0-SNAPSHOT:jar
[INFO] snapshot org.apache.camel:camel-bundle:2.0-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Copying camel-bundle-2.0-SNAPSHOT.jar to
/home/hudson/hudson-slave/workspace/Camel/camel-trunk/apache-camel/target/apache-camel-2.0-SNAPSHOT.jar
[INFO] [assembly:single {execution: unix-bin}]
[INFO] Reading assembly descriptor: src/main/descriptors/unix-bin.xml
[HUDSON] Archiving
/home/hudson/hudson-slave/workspace/Camel/camel-trunk/apache-camel/pom.xml
to
/export/home/hudson/hudson/jobs/Camel/modules/org.apache.camel$apache-camel/builds/2009-02-20_12-01-32/archive/org.apache.camel/apache-camel/2.0-SNAPSHOT/pom.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error reading assemblies: Error reading component descriptor
Unrecognised tag: 'assembly' (position: START_TAG seen ... permissions
and\nlimitations under the License.\n-->\n... @18:11)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error reading
assemblies: Error reading component descriptor
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at
org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:42)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at hudson.maven.agent.Main.launch(Main.java:135)
at hudson.maven.MavenBuilder.call(MavenBuilder.java:139)
at
hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:542)
at
hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:488)
at hudson.remoting.UserRequest.perform(UserRequest.java:69)
at hudson.remoting.UserRequest.perform(UserRequest.java:23)
at hudson.remoting.Request$2.run(Request.java:213)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(T
[jira] Resolved: (CAMEL-1349) Remove Scala specific repos as the artifacts are now in central repo too
[ https://issues.apache.org/activemq/browse/CAMEL-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-1349. Resolution: Fixed Fixed in http://svn.eu.apache.org/viewvc?view=rev&revision=745105 and backported to camel-1.x branch in http://svn.eu.apache.org/viewvc?view=rev&revision=745109 > Remove Scala specific repos as the artifacts are now in central repo too > > > Key: CAMEL-1349 > URL: https://issues.apache.org/activemq/browse/CAMEL-1349 > Project: Apache Camel > Issue Type: Improvement > Components: camel-scala, tooling > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen >Priority: Trivial > Fix For: 2.0.0 > > > We don't need the repositories any more, so we'd better remove them as the > only thing they do is slow things down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1349) Remove Scala specific repos as the artifacts are now in central repo too
[ https://issues.apache.org/activemq/browse/CAMEL-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated CAMEL-1349: --- Component/s: tooling camel-scala Priority: Trivial (was: Major) > Remove Scala specific repos as the artifacts are now in central repo too > > > Key: CAMEL-1349 > URL: https://issues.apache.org/activemq/browse/CAMEL-1349 > Project: Apache Camel > Issue Type: Improvement > Components: camel-scala, tooling > Reporter: Gert Vanthienen > Assignee: Gert Vanthienen >Priority: Trivial > Fix For: 2.0.0 > > > We don't need the repositories any more, so we'd better remove them as the > only thing they do is slow things down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1349) Remove Scala specific repos as the artifacts are now in central repo too
Remove Scala specific repos as the artifacts are now in central repo too Key: CAMEL-1349 URL: https://issues.apache.org/activemq/browse/CAMEL-1349 Project: Apache Camel Issue Type: Improvement Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 2.0.0 We don't need the repositories any more, so we'd better remove them as the only thing they do is slow things down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1346) First to commit condition: Error formatting macro: snippet: java.lang.IllegalArgumentException: Invalid url: must begin with a configured prefix.
[
https://issues.apache.org/activemq/browse/CAMEL-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved CAMEL-1346.
Resolution: Fixed
Fix Version/s: 1.6.0
Assignee: Gert Vanthienen
Fixed, it was just a typo in the url.
The snippet url was starting with *{{acamel/}}* instead of *{{camel/}}*
> First to commit condition: Error formatting macro: snippet:
> java.lang.IllegalArgumentException: Invalid url: must begin with a configured
> prefix.
> --
>
> Key: CAMEL-1346
> URL: https://issues.apache.org/activemq/browse/CAMEL-1346
> Project: Apache Camel
> Issue Type: Bug
> Components: website
>Reporter: Charles Moulliard
> Assignee: Gert Vanthienen
> Fix For: 1.6.0
>
>
> Hi,
> The following error
> Then we are ready to fire the tests. First to commit condition:
> Error formatting macro: snippet: java.lang.IllegalArgumentException: Invalid
> url: must begin with a configured prefix.
> is reported in the page :
> http://cwiki.apache.org/CAMEL/transactional-client.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Hudson CI builds for Apache Camel
Claus, How about adding a Continuous Integration page on http://camel.apache.org/developers.html? Regards, Gert Claus Ibsen wrote: Hi Great with the hudson, nice and easy overview of once a day build. I would like to add a link to it from the Camel wiki pages. Where is a good location for such a link? The link should point to: http://hudson.zones.apache.org/hudson/job/Camel/ On Tue, Feb 10, 2009 at 2:12 PM, Jon Anstey wrote: Aha! JIRA has been created :) On Tue, Feb 10, 2009 at 9:37 AM, Gert Vanthienen wrote: Jon, Yes, you can. Instructions can be found on http://wiki.apache.org/general/Hudson. Regards, Gert Jon Anstey wrote: Cool stuff. Thanks for getting this set up! Now I wonder if I can get an account on hudson... :) On Tue, Feb 10, 2009 at 9:04 AM, Gert Vanthienen wrote: L.S., I have set up CI builds for Apache Camel on hudson.zones.apache.org, both for trunk and for the camel-1.x branch. Since our builds are running for over an hour, I have currently configured these to check for svn updates only twice per day -- amounting to a total of approx. 4 hours of build time on the build server per day. The first few builds have run into technical difficulties, but now that those have been resolved, the weather reports should start improving soon. I'll keep an extra eye on things for a few days to iron out any remaining problems in the build setup. Regards, Gert -- Cheers, Jon http://janstey.blogspot.com/
Re: [DISCUSS] Async messages and UOWs
Hadrian, Count me in. Regards, Gert Hadrian Zbarcea wrote: Hi, We are planning a brainstorming session around CAMEL-1336, UOWs and async messaging on irc the #camel channel on Tue 02/17/2009 at 13:00 GMT. Please join us and express your thoughts if interested. We will post the transcript of that discussion on this mailing list as well, in case you'll miss it. Hadrian
Re: [VOTE] Release Apache Camel 1.6.0 (RC1)
+1 Hadrian Zbarcea wrote: A new apache-camel-1.6.0-RC1 is out with 166 new features, improvements and bug fixes. Please find the distro here: http://people.apache.org/~hadrian/apache-camel-1.6.0-RC1/maven2/ The tarballs are here http://people.apache.org/~hadrian/apache-camel-1.6.0-RC1/maven2/org/apache/camel/apache-camel/1.6.0/ Please vote to approve this release binary [ ] +1 Release the binary as Apache Camel 1.6.0 [ ] -1 Veto the release (provide specific comments) Vote is open for 72 hours. Here's my +1 Hadrian
[jira] Updated: (CAMEL-1310) DelegateProcessor should support async message handling
[ https://issues.apache.org/activemq/browse/CAMEL-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated CAMEL-1310: --- Fix Version/s: (was: 1.6.0) 1.6.1 It's OK to move this to 1.6.1 > DelegateProcessor should support async message handling > --- > > Key: CAMEL-1310 > URL: https://issues.apache.org/activemq/browse/CAMEL-1310 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 1.5.0 > Reporter: Gert Vanthienen >Assignee: Gert Vanthienen > Fix For: 2.0.0, 1.6.1 > > > We should improve the default DelegateProcessor to support async Message > handling as well. Right now, adding a Tracer, Delayer, StreamCaching, ... to > a Route breaks the ability to use asynchronous processing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1332) StreamCachingInterceptor can be enabled both as a strategy and as an interceptor -- should only be a strategy
[ https://issues.apache.org/activemq/browse/CAMEL-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated CAMEL-1332: --- Fix Version/s: (was: 1.6.0) 2.0.0 > StreamCachingInterceptor can be enabled both as a strategy and as an > interceptor -- should only be a strategy > - > > Key: CAMEL-1332 > URL: https://issues.apache.org/activemq/browse/CAMEL-1332 > Project: Apache Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 1.5.0 >Reporter: Gert Vanthienen > Assignee: Gert Vanthienen > Fix For: 2.0.0, 1.6.1 > > > Right now, there are two ways of enabling stream caching: > - explicitly enable it through the DSL > - implicitly enable it through e.g. a Multicast or DeadletterChannel > We should make that a single way of enablement or else document the rationale > for the difference properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-973) TypeConverter Exception is thrown in the latest build of camel
[ https://issues.apache.org/activemq/browse/CAMEL-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved CAMEL-973. --- Resolution: Fixed Fixed as part of CAMEL-1271 > TypeConverter Exception is thrown in the latest build of camel > -- > > Key: CAMEL-973 > URL: https://issues.apache.org/activemq/browse/CAMEL-973 > Project: Apache Camel > Issue Type: Bug > Components: camel-jbi >Affects Versions: 1.5.0 >Reporter: Edell Nolan >Assignee: Gert Vanthienen > Fix For: 1.6.0 > > > I have upgraded to the latest of Camel and when I attempt to use the content > based router pattern - its now throwing an error. > The contents of the Message passed is a StringSource object and from > debugging camel - the BodyType is a StringSource but it is attempting to > convert from a StreamCache to a StringSource. > I will try and put a testcase together but if anyone has any ideas of its > cause in the meantime ? > The error it throws it below. > thanks, Edell. > No type converter available to convert from type: class > org.apache.servicemix.camel.JbiMessage to the required type: > org.w3c.dom.Document with value JbiMessage: > org.apache.servicemix.jbi.runtime.impl.normalizedmessagei...@1d03b5b > org.apache.camel.NoTypeConversionAvailableException: No type converter > available to convert from type: class org.apache.servicemix.camel.JbiMessage > to the required type: org.w3c.dom.Document with value JbiMessage: > org.apache.servicemix.jbi.runtime.impl.normalizedmessagei...@1d03b5b > at > org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(DefaultTypeConverter.java:117) > at > org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(DefaultTypeConverter.java:65) > at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:69) > at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:51) > at > org.apache.camel.builder.xml.XPathBuilder.getDocument(XPathBuilder.java:528) > at > org.apache.camel.builder.xml.XPathBuilder.evaluateAs(XPathBuilder.java:420) > at > org.apache.camel.builder.xml.XPathBuilder.matches(XPathBuilder.java:98) > at > org.apache.camel.builder.xml.XPathBuilder.matches(XPathBuilder.java:63) > at > org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:47) > at > org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:75) > at > org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:174) > at > org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:96) > at > org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:63) > at > org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:47) > at > org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:41) > at > org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:66) > at > org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProviderExchange(CamelProviderEndpoint.java:115) > at > org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelProviderEndpoint.java:73) > at > org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:600) > at > org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:554) > at > org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx(AsyncBaseLifeCycle.java:456) > at > org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLifeCycle.java:341) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1271) Can only interact with servicemix-http if logging is at DEBUG
[
https://issues.apache.org/activemq/browse/CAMEL-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved CAMEL-1271.
Resolution: Fixed
This should be fixed now -- there are a few follow-up issues (CAMEL-1310 and
CAMEL-1332)
> Can only interact with servicemix-http if logging is at DEBUG
> -
>
> Key: CAMEL-1271
> URL: https://issues.apache.org/activemq/browse/CAMEL-1271
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-jbi
>Affects Versions: 1.5.0
>Reporter: Darren Davison
>Assignee: Gert Vanthienen
> Fix For: 1.6.0, 2.0.0
>
>
> Given the following camel DSL:
> from("activemq:queue.testJms.in")
>
> .to("jbi:service:urn:oms:testHttp?mep=in-out")
> .to("activemq:queue.testJms.out");
> and the following xbean.xml for the smx (3.3) SU:
>
> service="oms:testHttp"
> endpoint="testHttp"
> role="provider"
>
> locationURI="http://localhost:8080/testP1";>
>
>
> then Camel operates correctly (or at least as desired) only if DEBUG logging
> is enabled in the org.apache.servicemix.http package. This seems to be
> because a DOMSource is returned (which Camel can convert). If the log level
> is reduced (say to WARN) then a StreamSource object is returned instead which
> Camel appears unable to convert. This results in stack traces such as:
> ERROR - DeadLetterChannel - Failed delivery for exchangeId:
>
> ID-davisond-laptop/53380-1232099798317/0-0. On delivery attempt: 0
>
> caught: org.apache.camel.RuntimeCamelException:
>
> javax.xml.transform.TransformerException: java.io.IOException: Attempted
>
> read on closed stream.
>
> org.apache.camel.RuntimeCamelException:
>
> javax.xml.transform.TransformerException: java.io.IOException: Attempted
>
> read on closed stream.
>
> at
>
> org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:441)
>
> at
>
> org.apache.camel.impl.converter.InstanceMethodTypeConverter.convertTo(InstanceMethodTypeCo
> +nverter.java:57)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1332) StreamCachingInterceptor can be enabled both as a strategy and as an interceptor -- should only be a strategy
StreamCachingInterceptor can be enabled both as a strategy and as an interceptor -- should only be a strategy - Key: CAMEL-1332 URL: https://issues.apache.org/activemq/browse/CAMEL-1332 Project: Apache Camel Issue Type: Bug Components: camel-core Affects Versions: 1.5.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: 1.6.0, 1.6.1 Right now, there are two ways of enabling stream caching: - explicitly enable it through the DSL - implicitly enable it through e.g. a Multicast or DeadletterChannel We should make that a single way of enablement or else document the rationale for the difference properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
