Re: header names (sans dots)
On Sun, Jan 18, 2009 at 12:43 PM, Ramon Buckland wrote:
> Hi Dev'sm,
>
> Recently I remember reading about removing dotted notation header names from
> code. (a slow wide reaching change).
>
> I am currently working on CAMEL-1241 and have come across the following.
>
> {{{
>getIn().setHeader("file.remote.host", remoteFile.getHostname());
>getIn().setHeader("file.remote.absoluteName",
> remoteFile.getAbsolutelFileName());
>getIn().setHeader("file.remote.relativeName",
> remoteFile.getRelativeFileName());
>getIn().setHeader("file.remote.name", remoteFile.getFileName());
> }}}
>
>
> With my refactoring, the properties logically change to
>
> remote impl
>getIn().setHeader("file.remote.host", remoteFile.getHostname());
>...
> generic impl
>getIn().setHeader("file.absoluteName",
> remoteFile.getAbsolutelFileName());
>getIn().setHeader("file.relativeName",
> remoteFile.getRelativeFileName());
>getIn().setHeader("file.name", remoteFile.getFileName());
>
> Should I leave the dotted notation properties as is ?
> Or is there a standard to use for this ?
>
Yeah the problem with the dots is really the JMS where some brokers
don't allow dots in keys for JMS properties. So to work seamless with
Camel exchanges over JMS we should avoid the dots. But its such a
common practice in Java to use package prefixes for keys. So they are
hard to get rid of.
James suggested to use CamelComponentNameKeyName as convention, eg.
CamelFileFileName, CamelFileFileAbsoluteName etc.
Keeping the old syntax names in FTP/File component in Camel 2.0 was to
be kinda of backwards compatible and that fact we havent made the big
decision if we should refactor all the kets using the new style.
We have the chance with Camel 2.0 where its not backwards compatible
out-of-the-box in all cases. So its better to fix it now, or we have
to wait until Camel 3.0
Any thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: header names (sans dots)
On Mon, Jan 19, 2009 at 7:54 AM, Ramon Buckland wrote: >> >> We have the chance with Camel 2.0 where its not backwards compatible >> out-of-the-box in all cases. So its better to fix it now, or we have >> to wait until Camel 3.0 >> >> > I would say fix it now. There are other cases also where dotted notation > does not work well either. I can't recall all instances at the moment but > recall groovy I had an issue once, and some other random places. > > I assume there are far more locations than just ftp also, are we brave > enough to do a "change all" task, or just as we find them ? > > I can remove them as part of CAMEL-1241. Yeah we need to refactor all components when we do the name style change. I think you should align your component with the current style in FTP/File component. As the file language is dependent on keys to be consistent. So when we do the big change later we get this sorted at that time. > > regards > ramon > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: camel-flatpack: write to flatpack format?
Hi Please add a ticket for this RFE and use the voting system in JIRA so we know what the community wants. We love contributions so if you are giving it a go to implement it: http://activemq.apache.org/contributing.html One way or the other. For instance doing so research with the flatpack how or if its possible to write back. I think I remember that it wasn't really supported in flatpack itself. I might remember wrong. On Mon, Jan 19, 2009 at 4:12 PM, Matteo Redaelli wrote: > > Hello > > I read in the wiki "[Camel-Flatpack] only supports consuming from flatpack > files to Object model. Any news about You can not (yet) write from Object > model to flatpack format" > > Any news regarding when writing from Object model to flatpack format is > supported? 2.0? > > Thanks in advance > Matteo > -- > View this message in context: > http://www.nabble.com/camel-flatpack%3A-write-to-flatpack-format--tp21544963s22882p21544963.html > Sent from the Camel - Development mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [CONF] Apache Camel: TidyMarkup (page edited)
Hi No need to apologize. Thanks for the contribution. Keep it up and as always family should come first :) On Tue, Jan 20, 2009 at 11:06 PM, Ramon Buckland wrote: > Thanks Claus, apologies I have been stuck between work meetings and my twin > girls to get that doco written. (never did) thanks for writing it .. and Yes > Jon, I thought it very funny (apt) of your fix for the manual .. good work.! > > > r. > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: svn commit: r736287 - in /camel/trunk: camel-core/src/main/java/org/apache/camel/component/browse/ camel-core/src/main/java/org/apache/camel/model/ camel-core/src/main/java/org/apache/camel/model
trategy
>> \ No newline at end of file
>>
>> Modified:
>> camel/trunk/components/camel-spring/src/main/java/org/apache/camel/component/event/EventEndpoint.java
>> URL:
>> http://svn.apache.org/viewvc/camel/trunk/components/camel-spring/src/main/java/org/apache/camel/component/event/EventEndpoint.java?rev=736287&r1=736286&r2=736287&view=diff
>> ==
>> ---
>> camel/trunk/components/camel-spring/src/main/java/org/apache/camel/component/event/EventEndpoint.java
>> (original)
>> +++
>> camel/trunk/components/camel-spring/src/main/java/org/apache/camel/component/event/EventEndpoint.java
>> Wed Jan 21 03:29:52 2009
>> @@ -16,22 +16,22 @@
>> */
>> package org.apache.camel.component.event;
>>
>> +import java.util.ArrayList;
>> +
>> import org.apache.camel.Exchange;
>> import org.apache.camel.NoTypeConversionAvailableException;
>> import org.apache.camel.Processor;
>> import org.apache.camel.Producer;
>> import org.apache.camel.impl.DefaultEndpoint;
>> import org.apache.camel.impl.DefaultProducer;
>> -import org.apache.camel.processor.loadbalancer.LoadBalancer;
>> -import org.apache.camel.processor.loadbalancer.TopicLoadBalancer;
>> +import org.apache.camel.processor.MulticastProcessor;
>> import org.apache.camel.util.ObjectHelper;
>> +import static org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException;
>> import org.springframework.beans.BeansException;
>> import org.springframework.context.ApplicationContext;
>> import org.springframework.context.ApplicationContextAware;
>> import org.springframework.context.ApplicationEvent;
>>
>> -import static org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException;
>> -
>>
>> /**
>> * An http://activemq.apache.org/camel/event.html";>Event
>> Endpoint
>> @@ -40,7 +40,7 @@
>> * @version $Revision$
>> */
>> public class EventEndpoint extends DefaultEndpoint implements
>> ApplicationContextAware {
>> -private LoadBalancer loadBalancer;
>> +private MulticastProcessor processor;
>> private ApplicationContext applicationContext;
>>
>> public EventEndpoint(String endpointUri, EventComponent component) {
>> @@ -82,35 +82,27 @@
>> Exchange exchange = createExchange();
>> exchange.getIn().setBody(event);
>> try {
>> -getLoadBalancer().process(exchange);
>> +getMulticastProcessor().process(exchange);
>> } catch (Exception e) {
>> throw wrapRuntimeCamelException(e);
>> }
>> }
>>
>> -public LoadBalancer getLoadBalancer() {
>> -if (loadBalancer == null) {
>> -loadBalancer = createLoadBalancer();
>> +protected synchronized MulticastProcessor getMulticastProcessor() {
>> +if (processor == null) {
>> +processor = new MulticastProcessor(new ArrayList());
>> }
>> -return loadBalancer;
>> -}
>> -
>> -public void setLoadBalancer(LoadBalancer loadBalancer) {
>> -this.loadBalancer = loadBalancer;
>> +return processor;
>> }
>>
>> // Implementation methods
>> //
>> -
>> public synchronized void consumerStarted(EventConsumer consumer) {
>> -getLoadBalancer().addProcessor(consumer.getProcessor());
>> +
>> getMulticastProcessor().getProcessors().add(consumer.getProcessor());
>> }
>>
>> public synchronized void consumerStopped(EventConsumer consumer) {
>> -getLoadBalancer().removeProcessor(consumer.getProcessor());
>> -}
>> -
>> - protected LoadBalancer createLoadBalancer() {
>> -return new TopicLoadBalancer();
>> +
>> getMulticastProcessor().getProcessors().remove(consumer.getProcessor());
>> }
>>
>> protected ApplicationEvent toApplicationEvent(Exchange exchange) {
>>
>> Modified:
>> camel/trunk/components/camel-spring/src/main/java/org/apache/camel/spring/handler/CamelNamespaceHandler.java
>> URL:
>> http://svn.apache.org/viewvc/camel/trunk/components/camel-spring/src/main/java/org/apache/camel/spring/handler/CamelNamespaceHandler.java?rev=736287&r1=736286&r2=736287&view=diff
>> ==
>> ---
>> camel/trunk/components/camel-spring/src/main/java/org/apache/camel/spring/handler/CamelNamespaceHandler.java
>> (original)
>> +++
>> camel/trunk/components/camel-spring/src/main/java/org/apache/camel/spring/handler/CamelNamespaceHandler.java
>> Wed Jan 21 03:29:52 2009
>> @@ -38,7 +38,6 @@
>> import org.apache.camel.model.loadbalancer.RandomLoadBalanceStrategy;
>> import org.apache.camel.model.loadbalancer.RoundRobinLoadBalanceStrategy;
>> import org.apache.camel.model.loadbalancer.StickyLoadBalanceStrategy;
>> -import org.apache.camel.model.loadbalancer.TopicLoadBalanceStrategy;
>> import org.apache.camel.spi.NamespaceAware;
>> import org.apache.camel.spring.CamelBeanPostProcessor;
>> import org.apache.camel.spring.CamelContextFactoryBean;
>> @@ -91,7 +90,6 @@
>> addBeanDefinitionParser("roundRobin",
>> RoundRobinLoadBalanceStrategy.class);
>> addBeanDefinitionParser("random", RandomLoadBalanceStrategy.class);
>> addBeanDefinitionParser("sticky", StickyLoadBalanceStrategy.class);
>> -addBeanDefinitionParser("topic", TopicLoadBalanceStrategy.class);
>>
>> // jmx agent
>> addBeanDefinitionParser("jmxAgent", CamelJMXAgentType.class);
>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Components setting data on OUT
Hi The OUT message really starts to irritate me. We have various components that set data on the OUT body and then the Pipeline will use this result as IN for then next node. What happens is then whatever headers etc from IN is lost. Then you cant really route and have your headers preserve during the entire route. We might wanna give this a thought in Camel 2.0? - Pipeline to always add headers from IN to OUT, so headers is preserved - Components to enforce MEP and only set data on OUT if its InOut - Components to add headers from IN to OUT if it set OUT as result and what not Currently the SQL component has this flaw. In the past it was Velocity. And I guess there are some other components as well. Just starting a thread to not forget. I only had one cup of coffee this morning. Going to boil water now. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [jira] Updated: (CAMEL-1241) Add camel-commons-vfs component
Hi Ramon Yeah its a big refactor. Looks good. I do think we should consider java generics (the stuff) for the Generic* interfaces, but that is something we can get done later. Looks great and impressive that all the unit tests still passes. Since its a big refactor and the diff is huge we should avoid commiting to FTP/File in the trunk right now. To avoid the diff getting out of hands. Well this is for the Camel committers! To get the stuff into the trunk I think we need multiple diffs to avoid one huge. So if you can provide diffs in multiple steps. A rough plan like this: 1) Generic* that are used by the FTP component 2) When #1 is commited to triunk and you code is aligned with trunk, then move on to 3) Move Generic* from camel-ftp to camel-core 4) When #3 is commited to triunk and you code is aligned with trunk, then move on to 5) You can start on commons-vfs component 6) Then we can take a look at the java generics stuff and get that done in the right way 7) Refactor File in camel-core to use the new generics 8) Add the new commons-vfs component when its ready and done 9) Add wiki doc for the new commons-vfs component Ramon, what do you say? On Fri, Jan 23, 2009 at 7:14 AM, Ramon Buckland wrote: > Claus (and others) > > If you have time, can you please take a cursory glance at my refactoring. I > think there are a few rough edges which I am hoping to sort out when I > implement the commons-vfs from the Generic* > > The crux of the change so far is as follows. > > (a) refactor org.apache.camel.component.file.remote.Remote* so there is a > base that can be extended. > > * All current FTP Remote code resides in > org.apache.camel.component.file.remote > * It's parent Abstract base, interface and superclasses are > org.apache.camel.component.file.Generic* > * FTP and SFTP are now concrete implementations (no sharing of protocol in > same class); common code is pushed to Remote* classes. > > The next part will be to > > (b) Implement commons-vfs undeneath org.apache.camel.component.file.Generic* > (c) move org.apache.camel.component.file.Generic* to camel-core. > (d) Have camel-core:file implement / extend > org.apache.camel.component.file.Generic* > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [jira] Updated: (CAMEL-1241) Add camel-commons-vfs component
On Fri, Jan 23, 2009 at 7:51 AM, Ramon Buckland wrote: > Just had a thought. > > I will put the Generic* into camel-core.. and taylor each patch from there ? > How does that sound ? +1 that is fine as well Its new files into core and thus wont affect anything else. > > by the way. Having all of those test cases for the FTP was fantastic. It > makes me confident in the change as 80% of the tests failed, then minor > fixes and I had it all working again. So good work to all the test makers. Well it have taken quite some time to add all these tests. But yeah its important that we have so many for the file/ftp components. > > On Fri, Jan 23, 2009 at 17:33, Ramon Buckland wrote: > >> > Ramon, what do you say? >> >> Sounds Good. >> >> I will start with (1) very shortly (about to hop on ferry for home). >> >> r. >> > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Question : Naming conventions Abstract and Interfaces
On Fri, Jan 23, 2009 at 8:15 AM, Ramon Buckland wrote: > Hi Guys, > > What is the naming comvention in use for Abstract and Interfaces. > I am used to Abstract* .. and sometimes *Iface. > > What is camel's preference ? > > r. > We do not use I as prefix for interface. We do not use xxxImpl for implementing the interface We use DefaultXXX for the default implementation of an interface I dont think AbstractXXX is what we use. We kinda not use AbstractXXX since many times we use DefaultXXX also for abstract classes as well. In fact we only have one Abstract in camel-core We kinda also use the Spring convention with its xxxSupport for abstract classes. So its usually either DefaultXXX or XXXSupport In fact the AbstractSimpleLanguage we have should be renamed to SimpleLangugeSupport to follow the convention. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Components setting data on OUT
On Fri, Jan 23, 2009 at 8:33 AM, Willem Jiang wrote: > Hi Claus > > I agree the component should take responsible of copy the In message > headers into Out message headers. we could provides util class to do > that copy thing in camel-core. > But the component should also need to make sure some of the out message > header value which is copied from in message should be overrided > according components logical. > > Such as the response context in camel-cxf component message header, it > should be overrided when the camel-cxf producer get the response from > actual web services. > > Just my two cents, > > Willem Spot on Willem. Yeah I think we need to check for components doing exchange.getOut().setBody( And see if they consider copying headers from IN if needed. Yeah a nice helper method in Camel core to *not* override headers in OUT but only copy if not already exists in OUT header > > Claus Ibsen wrote: >> Hi >> >> The OUT message really starts to irritate me. >> >> We have various components that set data on the OUT body and then the >> Pipeline will use this result as IN for then next node. >> What happens is then whatever headers etc from IN is lost. Then you >> cant really route and have your headers preserve during the entire >> route. >> >> We might wanna give this a thought in Camel 2.0? >> - Pipeline to always add headers from IN to OUT, so headers is preserved >> - Components to enforce MEP and only set data on OUT if its InOut >> - Components to add headers from IN to OUT if it set OUT as result >> and what not >> >> Currently the SQL component has this flaw. In the past it was >> Velocity. And I guess there are some other components as well. >> >> Just starting a thread to not forget. I only had one cup of coffee >> this morning. Going to boil water now. >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: component busy ..
Cool Which license does the BouncyCastle use? We cant accept all license at Apache http://www.apache.org/legal/3party.html On Fri, Jan 23, 2009 at 1:33 PM, Ramon Buckland wrote: > Hi All, > > I have a need to create a new dataformat which will de/encrypt a message > using OpenGPG (BouncyCastle). > > The actual details is that a file is on a remote sftp server, and is > encrypted using GnuGPG. It will need to be sftp pulled once a day, decrypted > using our private key and placed in a directory elsewhere. > > That is no problem, I will be putting the pieces of it together shortly. .. > of course it means adding another component. > > My question is: > >Has anyone thought of bundling like components, in order that the > component number (and thus optional 'camel' jars, is reduced) ? > >I can see a plus side of the current way, one project encapsulates all > of that "component's" dependencies. >the downside I (feel) is that there is a heck of a lot of components > going on.. correlating to IDE projects and mvn pom overhead, and will only > grow more so (which is GREAT!) > > I don't really have a thought on any way or form, but was just wondering if > anybody had given it thought as I have over the past few days. > > Specifically to my requirement above, the ZIP and this Encrypt/Decrypt are > kind of related so could both reside in a > >camel-dataformat-encoding-support > > component, which can provide, ZIP, GZIP, OpenGPG, MD5 > summing (and if someother are game, all other manner of BouncyCastle > en/decryption goodness) > > just a thought.. > > cheers > r. > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel archetypes soon to be bundled in maven-archetype-plugin
That is great news. Kudo to you Jonathan for pushing for this. Great when we can write a little tutorial how to get started with Camel and you can just write a maven command to get the project layout Well if only the command was easier to remember and type On Fri, Jan 23, 2009 at 2:43 PM, Jon Anstey wrote: > Hey guys, > > Dan just committed my patch here > http://jira.codehaus.org/browse/ARCHETYPE-225 so for the next version of the > maven-archetype-plugin (probably 2.0-alpha-5) Camel archetypes should be > showing up when anybody runs "mvn archetype:generate". Here's what my output > looks like now (look at the bottom) > > Choose archetype: > 1: internal -> appfuse-basic-jsf (AppFuse archetype for creating a web > application with Hibernate, Spring and JSF) > 2: internal -> appfuse-basic-spring (AppFuse archetype for creating a web > application with Hibernate, Spring and Spring MVC) > 3: internal -> appfuse-basic-struts (AppFuse archetype for creating a web > application with Hibernate, Spring and Struts 2) > 4: internal -> appfuse-basic-tapestry (AppFuse archetype for creating a web > application with Hibernate, Spring and Tapestry 4) > 5: internal -> appfuse-core (AppFuse archetype for creating a jar > application with Hibernate and Spring and XFire) > 6: internal -> appfuse-modular-jsf (AppFuse archetype for creating a modular > application with Hibernate, Spring and JSF) > 7: internal -> appfuse-modular-spring (AppFuse archetype for creating a > modular application with Hibernate, Spring and Spring MVC) > 8: internal -> appfuse-modular-struts (AppFuse archetype for creating a > modular application with Hibernate, Spring and Struts 2) > 9: internal -> appfuse-modular-tapestry (AppFuse archetype for creating a > modular application with Hibernate, Spring and Tapestry 4) > 10: internal -> maven-archetype-j2ee-simple (A simple J2EE Java application) > 11: internal -> maven-archetype-marmalade-mojo (A Maven plugin development > project using marmalade) > 12: internal -> maven-archetype-mojo (A Maven Java plugin development > project) > 13: internal -> maven-archetype-portlet (A simple portlet application) > 14: internal -> maven-archetype-profiles () > 15: internal -> maven-archetype-quickstart () > 16: internal -> maven-archetype-site-simple (A simple site generation > project) > 17: internal -> maven-archetype-site (A more complex site project) > 18: internal -> maven-archetype-webapp (A simple Java web application) > 19: internal -> camel-archetype-component (Creates a new Camel component) > 20: internal -> camel-archetype-activemq (Creates a new Camel project that > configures and interacts with ActiveMQ) > 21: internal -> camel-archetype-java (Creates a new Camel project using Java > DSL) > 22: internal -> camel-archetype-scala (Creates a new Camel project using > Scala DSL) > 23: internal -> camel-archetype-spring (Creates a new Camel project with > added Spring DSL support) > ... > > Pretty neat, I think :) > > -- > Cheers, > Jon > > http://janstey.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel archetypes soon to be bundled in maven-archetype-plugin
Cool Yeah I vague remember something with a interactive mode, but I thought it was just wishlist. It should be on your TODO list for what to blog about when its out there in the public. On Fri, Jan 23, 2009 at 3:12 PM, Jon Anstey wrote: > The new archetype plugin has a neat interactive feature so you only need to > run "mvn archetype:generate" with no parameters and it just prompts you for > everything - nice! I do remember the old "archetype:create" way with a > gazillion parameters... *sudders* > > On Fri, Jan 23, 2009 at 10:36 AM, Claus Ibsen wrote: > >> That is great news. Kudo to you Jonathan for pushing for this. Great >> when we can write a little tutorial how to get started with Camel and >> you can just write a maven command to get the project layout >> >> Well if only the command was easier to remember and type >> >> >> >> On Fri, Jan 23, 2009 at 2:43 PM, Jon Anstey wrote: >> > Hey guys, >> > >> > Dan just committed my patch here >> > http://jira.codehaus.org/browse/ARCHETYPE-225 so for the next version of >> the >> > maven-archetype-plugin (probably 2.0-alpha-5) Camel archetypes should be >> > showing up when anybody runs "mvn archetype:generate". Here's what my >> output >> > looks like now (look at the bottom) >> > >> > Choose archetype: >> > 1: internal -> appfuse-basic-jsf (AppFuse archetype for creating a web >> > application with Hibernate, Spring and JSF) >> > 2: internal -> appfuse-basic-spring (AppFuse archetype for creating a web >> > application with Hibernate, Spring and Spring MVC) >> > 3: internal -> appfuse-basic-struts (AppFuse archetype for creating a web >> > application with Hibernate, Spring and Struts 2) >> > 4: internal -> appfuse-basic-tapestry (AppFuse archetype for creating a >> web >> > application with Hibernate, Spring and Tapestry 4) >> > 5: internal -> appfuse-core (AppFuse archetype for creating a jar >> > application with Hibernate and Spring and XFire) >> > 6: internal -> appfuse-modular-jsf (AppFuse archetype for creating a >> modular >> > application with Hibernate, Spring and JSF) >> > 7: internal -> appfuse-modular-spring (AppFuse archetype for creating a >> > modular application with Hibernate, Spring and Spring MVC) >> > 8: internal -> appfuse-modular-struts (AppFuse archetype for creating a >> > modular application with Hibernate, Spring and Struts 2) >> > 9: internal -> appfuse-modular-tapestry (AppFuse archetype for creating a >> > modular application with Hibernate, Spring and Tapestry 4) >> > 10: internal -> maven-archetype-j2ee-simple (A simple J2EE Java >> application) >> > 11: internal -> maven-archetype-marmalade-mojo (A Maven plugin >> development >> > project using marmalade) >> > 12: internal -> maven-archetype-mojo (A Maven Java plugin development >> > project) >> > 13: internal -> maven-archetype-portlet (A simple portlet application) >> > 14: internal -> maven-archetype-profiles () >> > 15: internal -> maven-archetype-quickstart () >> > 16: internal -> maven-archetype-site-simple (A simple site generation >> > project) >> > 17: internal -> maven-archetype-site (A more complex site project) >> > 18: internal -> maven-archetype-webapp (A simple Java web application) >> > 19: internal -> camel-archetype-component (Creates a new Camel component) >> > 20: internal -> camel-archetype-activemq (Creates a new Camel project >> that >> > configures and interacts with ActiveMQ) >> > 21: internal -> camel-archetype-java (Creates a new Camel project using >> Java >> > DSL) >> > 22: internal -> camel-archetype-scala (Creates a new Camel project using >> > Scala DSL) >> > 23: internal -> camel-archetype-spring (Creates a new Camel project with >> > added Spring DSL support) >> > ... >> > >> > Pretty neat, I think :) >> > >> > -- >> > Cheers, >> > Jon >> > >> > http://janstey.blogspot.com/ >> > >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> > > > > -- > Cheers, > Jon > > http://janstey.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [DISCUSS] target namespace for camel schema
+1 on 2.0 only I assume we can still publish 1.x schemas to the old activemq location at Apache for as Willem said to keep Eclipse and IDEA etc. that can fetch these schemas into the editor for code completion in the XML. When we do the change on 2.0 we must remember there are several spring schema files in the src folder we need to update (camel-spring, camel-cxf and maybe some others) And should we on 2.0 remove the older schema entries for all the Camel 1.x releases? On Fri, Jan 23, 2009 at 4:48 PM, Hadrian Zbarcea wrote: > @Willem, I am working on a set of camel scripts. > Thanks > Hadrian > > On Jan 23, 2009, at 10:29 AM, Willem Jiang wrote: > >> +1 for doing it in 2.0. >> >> Basically , Spring will pick the schema from the jars in the class path. >> So the change will not effect the camel application if we don't publish >> them into the web site. But there are some tools such as Eclipse will >> look up the schema from the target name space. >> >> If we change the target namespace for camel schema , user's old camel >> spring configuration file need to be updated. I think we'd better not >> touch 1.x branch to keep the consistence. >> >> BTW, we also need to update the script[1] which copies the maven >> snapshots schema into the web site when we change the target namespace >> for camel schema. >> >> >> [1]https://svn.apache.org/repos/asf/activemq/scripts/copy_camel_snapshot_xsd.py >> >> Willem. >> >> Hadrian Zbarcea wrote: >>> >>> Hi, >>> >>> In camel schemas >>> targetNamespace="http://activemq.apache.org/camel/schema/spring"; >>> >>> The location however is at http://camel.apache.org/schema/spring/ (but >>> still available at the old activemq location. Do you think it would be >>> a good move to change it now to >>> targetNamespace="http://camel.apache.org/schema/spring"; >>> >>> I personally think we should do it for 2.0, not so sure about the 1.x >>> branch. >>> >>> Thoughts? >>> >>> Hadrian >>> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Question : Naming conventions Abstract and Interfaces
Hi I am not master of bash (yet) but I did a little count on Camel 2.0 davsclaus:(svn)camel[trunk:736917]/camel-core$ find . -name *.java | wc -l 895 davsclaus:(svn)camel[trunk:736917]/camel-core$ find . -name *Abstra*.java | wc -l 0 davsclaus:(svn)camel[trunk:736917]/camel-core$ find . -name *Support*.java | wc -l 27 davsclaus:(svn)camel[trunk:736917]/camel-core$ find . -name *Utils*.java | wc -l 0 davsclaus:(svn)camel[trunk:736917]/camel-core$ find . -name *Utils.java | wc -l 0 davsclaus:(svn)camel[trunk:736917]/camel-core$ find . -name *Util*.java | wc -l 2 davsclaus:(svn)camel[trunk:736917]/camel-core$ find . -name *Helper*.java | wc -l 18 On Fri, Jan 23, 2009 at 5:24 PM, Hadrian Zbarcea wrote: > Yeah :) > > On Jan 23, 2009, at 11:11 AM, William Tam wrote: > >> What about static Helper/Utils class? I notice both XxxHelper and >> XxxUtils names are used? >> >> On Fri, Jan 23, 2009 at 10:01 AM, Hadrian Zbarcea >> wrote: >>> >>> No particular one. We use Abstract* many times. For interfaces, just >>> something suggestive. >>> >>> Cheers >>> Hadrian >>> >>> On Jan 23, 2009, at 2:15 AM, Ramon Buckland wrote: >>> >>>> Hi Guys, >>>> >>>> What is the naming comvention in use for Abstract and Interfaces. >>>> I am used to Abstract* .. and sometimes *Iface. >>>> >>>> What is camel's preference ? >>>> >>>> r. >>> >>> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Components setting data on OUT
On Fri, Jan 23, 2009 at 4:45 PM, William Tam wrote: > On Fri, Jan 23, 2009 at 2:33 AM, Willem Jiang wrote: >> Hi Claus >> >> I agree the component should take responsible of copy the In message >> headers into Out message headers. we could provides util class to do >> that copy thing in camel-core. >> But the component should also need to make sure some of the out message >> header value which is copied from in message should be overrided >> according components logical. >> >> Such as the response context in camel-cxf component message header, it >> should be overrided when the camel-cxf producer get the response from >> actual web services. >> > > Hmm ... that means "Pipeline to always add headers from IN to OUT, so > headers is preserved" > could be problematic. I guess, the pipeline needs to make sure it > does not overwrite headers that already exist in out header. Still, I > think component may not want to get involved. Yeah giving it some thought is like a double edged sword. What we have stored in Headers today in Camel is both: - user headers - and system headers (added by Camel itself). I am starting to be more and more convinced that we should separate the two. So any headers that a users has enforced to be set should be kept in one Map and the others that the components set internally (such as SQL number of rows returned, or whatnot we have, there are many) in another Map. The user headers is always preserved and copied along in the routing. User can always clear/remove unwanted headers. The system headers should be short lived as they are not really useable. So they are "alive" in the next step (process) in the route, and when the pipeline invokes next route thereafter these information is cleared. Separating these will also make the routing/tracing a bit easier as Users can recognize their own headers instead its mixed with all the noise the Camel components add. > > >> Just my two cents, >> >> Willem >> >> Claus Ibsen wrote: >>> Hi >>> >>> The OUT message really starts to irritate me. >>> >>> We have various components that set data on the OUT body and then the >>> Pipeline will use this result as IN for then next node. >>> What happens is then whatever headers etc from IN is lost. Then you >>> cant really route and have your headers preserve during the entire >>> route. >>> >>> We might wanna give this a thought in Camel 2.0? >>> - Pipeline to always add headers from IN to OUT, so headers is preserved >>> - Components to enforce MEP and only set data on OUT if its InOut >>> - Components to add headers from IN to OUT if it set OUT as result >>> and what not >>> >>> Currently the SQL component has this flaw. In the past it was >>> Velocity. And I guess there are some other components as well. >>> >>> Just starting a thread to not forget. I only had one cup of coffee >>> this morning. Going to boil water now. >>> >>> >> >> > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Apache Camel - Ohloh restarted
Hi Looks like it the TLP transition kinda restarted the stats at Ohloh. Maybe we could get in touch with the people behind to get it kinda merged so we are back on track. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Components setting data on OUT
On Sat, Jan 24, 2009 at 9:08 PM, William Tam wrote: >> >> What we have stored in Headers today in Camel is both: >> - user headers >> - and system headers (added by Camel itself). >> >> I am starting to be more and more convinced that we should separate the two. >> So any headers that a users has enforced to be set should be kept in >> one Map and the others that the components set internally (such as SQL >> number of rows returned, or whatnot we have, there are many) in >> another Map. >> > > It means that a component would have to look for header in more than > one place. Besides, the distinction of user vs system header is not > always clear. For example, the operation name header for cxf endpoint > can be set by user but it is also created by cxf component. I am > sure there are many more examples. There is another header category: > protocol headers. A protocol header is not really a user or system > header. Protocol headers are header propagated from protocol like > HTTP, which we do want to preserve in message header. > >> The user headers is always preserved and copied along in the routing. >> User can always clear/remove unwanted headers. >> The system headers should be short lived as they are not really >> useable. So they are "alive" in the next step (process) in the route, >> and when the pipeline invokes next route thereafter these information >> is cleared. >> >> Separating these will also make the routing/tracing a bit easier as >> Users can recognize their own headers instead its mixed with all the >> noise the Camel components add. >> > > I wonder we can leverage/extend the HeaderFilterStrategy mechanism. > Currently, it is only used for filtering unwanted headers (in both > request and response direction) when we propagate headers between > Camel and external messages (like HTTP). HeaderFilterStrategy is (or > will be) associated with an endpoint. We could make > HeaderFilterStrategy available to the exchange object. So, when an > endpoint creates an exchange, the exchange gets a header filter > strategy. Then, pipeline can do something like this to filter > unwanted header: message.filterHeaders(). The header filter strategy > is highly customizable for each endpoint (can have a component wide > default) and it can be looked up from registry. > Good pointers William. Yeah we can revist it after you have moved the header filters to the endpoint. Then we can check up upon how to leverage it as you suggest. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Components setting data on OUT
On Mon, Jan 26, 2009 at 3:37 PM, Roman Kalukiewicz
wrote:
> Why don't we talk about exchange properties here? My feeling here is
> that properties should be used as user-headers, while headers are
> always protocol headers. In fact it works this way right now: If I
> want to keep some value through the whole flow I put it into
> properties.
>
> By current convention if I put something on a header it is sent as
> protocol-specific header (JMS property, HTTP header), and out headers
> are filled also with protocol headers (JSM properties of out emssage,
> HTTP response headers). In this case headers shouldn't be propagated,
> as there is no way to distinguish things propagated, from things
> retrieved. And out headers ARE different than in headers.
>
> It is a matter of naming, but currently headers are (what you call)
> protocol/system headers, while properties are user-headers (work as
> variables). Do we really need to extend it further? If someone mix
> those two concepts then it is problem of documentation, but not lack
> of functionality. I would just extend DSL a little to be able to
> retrieve a property (instead using header()).
>
> What do you think, guys? Maybe we should clearly communicate what
> things are for and what are the consequences of using one or another.
>
> Roman
>
> PS. Pipeline should propagate all headers of course, but I believe an
> endpoint is a place where we shouldn't guarantee that headers will be
> propagated by stating it clearly.
Properties have just lived in the dark and end users does not really
know they exists. We have some builder methods to set/get properties.
I guess we need to document and maybe make sure the Spring DSL also
has support for accessing properties as well.
To my knowledge properties is always preserved so I doubt we have an
issue there.
So users should just start learn using properties as well :)
However then we have the ProducerTemplate that has one liners for
sending an Exchange. We dont have a sendBodyAndProperties method. But
yet again it has too many methods already. They can just use
send("xxx", Exchange) and have exchange populated with the properties
of choice.
>
> 2009/1/26 Claus Ibsen :
>> On Sat, Jan 24, 2009 at 9:08 PM, William Tam wrote:
>>>>
>>>> What we have stored in Headers today in Camel is both:
>>>> - user headers
>>>> - and system headers (added by Camel itself).
>>>>
>>>> I am starting to be more and more convinced that we should separate the
>>>> two.
>>>> So any headers that a users has enforced to be set should be kept in
>>>> one Map and the others that the components set internally (such as SQL
>>>> number of rows returned, or whatnot we have, there are many) in
>>>> another Map.
>>>>
>>>
>>> It means that a component would have to look for header in more than
>>> one place. Besides, the distinction of user vs system header is not
>>> always clear. For example, the operation name header for cxf endpoint
>>> can be set by user but it is also created by cxf component. I am
>>> sure there are many more examples. There is another header category:
>>> protocol headers. A protocol header is not really a user or system
>>> header. Protocol headers are header propagated from protocol like
>>> HTTP, which we do want to preserve in message header.
>>>
>>>> The user headers is always preserved and copied along in the routing.
>>>> User can always clear/remove unwanted headers.
>>>> The system headers should be short lived as they are not really
>>>> useable. So they are "alive" in the next step (process) in the route,
>>>> and when the pipeline invokes next route thereafter these information
>>>> is cleared.
>>>>
>>>> Separating these will also make the routing/tracing a bit easier as
>>>> Users can recognize their own headers instead its mixed with all the
>>>> noise the Camel components add.
>>>>
>>>
>>> I wonder we can leverage/extend the HeaderFilterStrategy mechanism.
>>> Currently, it is only used for filtering unwanted headers (in both
>>> request and response direction) when we propagate headers between
>>> Camel and external messages (like HTTP). HeaderFilterStrategy is (or
>>> will be) associated with an endpoint. We could make
>>> HeaderFilterStrategy available to the exchange object. So, when an
>>> endpoint creates an exchange, the exchange gets a header filter
>>> strategy. Then, pipeline can do something like this to filter
>&
Re: Components setting data on OUT
am saying is if we put user >>> defined header in message headers, filter strategy (or policy if you >>> will) won't have to iterate through the exchange properties for it. >>> It is already in headers where it belongs. All we need to do is to >>> apply filters to headers. It is much cleaner. In your example, if >>> endpoint wants to read a specific property (e.g. >>> org.apache.camel.headers.username) and make a header out of a >>> property, it can certainly do so. >>> >>> (However, I am not sure there are really that many Camel well known >>> properties at least in the presence.) >>> >>> >>>> >>>>> >>>>> >>>>>> >>>>>> Hadrian >>>>>> >>>>>> >>>>>> On Jan 26, 2009, at 1:07 PM, William Tam wrote: >>>>>> >>>>>>> On Mon, Jan 26, 2009 at 10:35 AM, Hadrian Zbarcea >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> This headers business is a bit of a tricky one. I hit it last year >>>>>>>> in >>>>>>>> the >>>>>>>> context of security. >>>>>>>> >>>>>>>> I agree with the view that headers should only exist in the context >>>>>>>> of >>>>>>>> an >>>>>>>> endpoint. I think outside of that there is no guarantee that the >>>>>>>> semantics >>>>>>>> of a header is preserved. I am not sure if headers should be >>>>>>>> propagated >>>>>>>> from one endpoint to another at all. >>>>>>> >>>>>>> There are certainly use cases that protocol headers DO need to be >>>>>>> propagated between endpoints. If users want to integrate with some >>>>>>> management and/or security tools like Actional, users are required to >>>>>>> include custom headers in protocol headers. These custom headers >>>>>>> travel with messages to allow trust zone enforcement and message >>>>>>> correlation. They need to be preserved and propagated across hops >>>>>>> which are potentially over different transport protocols. >>>>>>> >>>>>>>> Properties should be used instead. >>>>>>>> Coming back to security, if http is used for instance there are >>>>>>>> several >>>>>>>> ways >>>>>>>> of handling that. If basic auth is used for instance one gets a >>>>>>>> user/pass, >>>>>>>> but that may need to be translated to something else at endpoint >>>>>>>> boundaries. >>>>>>>> I don't think that the "Authorization" header should exist outside >>>>>>>> the >>>>>>>> http >>>>>>>> endpoint for instance. >>>>>>>> >>>>>>>> Yes, we do propagate properties today, no issue there. But then some >>>>>>>> policies need to be defined per endpoint to deal with known >>>>>>>> headers/properties, and camel specific properties should be defined >>>>>>>> to >>>>>>>> deal >>>>>>>> with know headers. Even better, endpoints should set protocol >>>>>>>> specific >>>>>>>> headers that are known as required to propagate (such as the auth >>>>>>>> stuff) >>>>>>>> as >>>>>>>> properties from start. >>>>>>>> >>>>>>>> My $0.02 >>>>>>>> Hadrian >>>>>>>> >>>>>>>> >>>>>>>> On Jan 26, 2009, at 9:44 AM, Claus Ibsen wrote: >>>>>>>> >>>>>>>>> On Mon, Jan 26, 2009 at 3:37 PM, Roman Kalukiewicz >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Why don't we talk about exchange properties here? My feeling here >>>>>>>>>> is >>>>>>>>>> that properties should be used as user-headers, while headers are >>>>>&g
Re: git mirror
Hi +1 Can git do patch and apply patches properly? Kinda tired of SVN not having a good patch build in. patch -p0 does not handle file rename, delete etc. to well A patch hell when you get bigger patches to get it merged into the codebase Yeah the feature to stove away current code is great. IDEA has such a feature for SVN = shelve changes. On Tue, Jan 27, 2009 at 1:32 PM, Jon Anstey wrote: > +1 > > On Mon, Jan 26, 2009 at 6:28 PM, Aaron Crickenberger < > aaron.crickenber...@intalgent.com> wrote: > >> Hi all, >> >> At the risk of opening up a can of worms, would it be possible and/or is >> anyone interested in having a git mirror of camel's svn repo at >> http://jukka.zitting.name/git/ ? >> >> - aaron >> > > > > -- > Cheers, > Jon > > http://janstey.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [HeadsUp] implementing Dynamic Recipient Lists using annotations
Hi
>From the link in James mail there is a link to the dynamic EIP :)
The entire EIP pattern catalog is here:
http://camel.apache.org/enterprise-integration-patterns.html
There is a menu item to it from the Camel front page
The dynamic recipient list is here:
http://camel.apache.org/recipient-list.html
On Tue, Jan 27, 2009 at 2:33 PM, Nivi shri wrote:
>
> Hi All
>
> It would be helpful if some1 can point out to a link which demonstrates how
> to implement the dynamic recipient list.
>
> Regards
> Nivi
>
>
> James.Strachan wrote:
>>
>> I've just added support for @RecipientList annotation on a bean method
>> to implement a dynamic recipient list.
>>
>> This can be used when using @MesageDriven or @Consume to call the
>> method when messages arrive, or if the bean method is explicitly
>> invoked from a route.
>>
>> e.g.
>>
>> public class RouterBean {
>>
>> @MessageDriven(uri = "activemq:foo")
>> @RecipientList
>> public String[] route(String body) {
>> return new String[]{"activemq:bar", "activemq:whatnot"};
>> }
>> }
>>
>> you can return a single Endpoint or object that can be converted into
>> a String; or a collection or array of such objects.
>>
>> More documentation is here...
>> http://cwiki.apache.org/CAMEL/recipientlist-annotation.html
>>
>> As usual feedback welcome!
>>
>> --
>> James
>> ---
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://open.iona.com
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/-HeadsUp--implementing-Dynamic-Recipient-Lists-using-annotations-tp19763707s22882p21685364.html
> Sent from the Camel - Development mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r738878 - in /camel/trunk/camel-core/src/test/java/org/apache/camel: ./ component/file/ management/
alueofMinProcessingTime =
>> (Double)beanServer.getAttribute(pcob, "MinProcessingTimeMillis");
>> assertNotNull("Expected attribute found. MBean registered under a "
>>+ "':name=Stats,*' key must be of type
>> PerformanceCounter.class",
>> @@ -131,7 +124,6 @@
>>
>> assertNotNull("Expected last completion time to be available",
>> beanServer.getAttribute(pcob,
>> "LastExchangeCompletionTime"));
>> -
>> }
>>
>> protected RouteBuilder createRouteBuilder() {
>>
>> Modified:
>> camel/trunk/camel-core/src/test/java/org/apache/camel/management/JmxInstrumentationWithConnectorTest.java
>> URL:
>> http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/management/JmxInstrumentationWithConnectorTest.java?rev=738878&r1=738877&r2=738878&view=diff
>> ==
>> ---
>> camel/trunk/camel-core/src/test/java/org/apache/camel/management/JmxInstrumentationWithConnectorTest.java
>> (original)
>> +++
>> camel/trunk/camel-core/src/test/java/org/apache/camel/management/JmxInstrumentationWithConnectorTest.java
>> Thu Jan 29 15:03:12 2009
>> @@ -26,21 +26,20 @@
>> * a client.
>> *
>> * @version $Revision$
>> - *
>> */
>> public class JmxInstrumentationWithConnectorTest extends
>> JmxInstrumentationUsingDefaultsTest {
>>
>> protected static final String JMXSERVICEURL =
>> -"service:jmx:rmi:///jndi/rmi://localhost:2000/jmxrmi/camel";
>> +"service:jmx:rmi:///jndi/rmi://localhost:2123/jmxrmi/camel";
>> protected JMXConnector clientConnector;
>>
>> @Override
>> protected void setUp() throws Exception {
>> -sleepForConnection = 2000;
>> -System.setProperty(JmxSystemPropertyKeys.CREATE_CONNECTOR, "True");
>> +sleepForConnection = 3000;
>> +System.setProperty(JmxSystemPropertyKeys.CREATE_CONNECTOR, "true");
>> // need to explicit set it to false to use non-platform mbs
>> -System.setProperty(JmxSystemPropertyKeys.USE_PLATFORM_MBS, "False");
>> -System.setProperty(JmxSystemPropertyKeys.REGISTRY_PORT, "2000");
>> +System.setProperty(JmxSystemPropertyKeys.USE_PLATFORM_MBS, "false");
>> +System.setProperty(JmxSystemPropertyKeys.REGISTRY_PORT, "2123");
>> super.setUp();
>> }
>>
>> @@ -65,8 +64,7 @@
>> protected MBeanServerConnection getMBeanConnection() throws Exception {
>> if (mbsc == null) {
>> if (clientConnector == null) {
>> -clientConnector = JMXConnectorFactory.connect(
>> -new JMXServiceURL(JMXSERVICEURL), null);
>> +clientConnector = JMXConnectorFactory.connect(new
>> JMXServiceURL(JMXSERVICEURL), null);
>> }
>> mbsc = clientConnector.getMBeanServerConnection();
>> }
>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r738999 - in /camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf: CxfEndpoint.java CxfExchange.java CxfMessage.java converter/CxfConverter.java
MessageContentsList list = (MessageContentsList)value;
> +
> +for (int i = 0; i < list.size(); i++) {
> +Object embedded = list.get(i);
> +
> +if (embedded != null) {
> +if (type.isInstance(embedded)) {
> +return (T)embedded;
> +} else {
> + TypeConverter tc = registry.lookup(type,
> embedded.getClass());
> +if (tc != null) {
> +return tc.convertTo(type, exchange, embedded);
> +}
> +}
> +}
> +}
> +}
> +
> +return null;
> +}
> }
>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r738999 - in /camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf: CxfEndpoint.java CxfExchange.java CxfMessage.java converter/CxfConverter.java
On Fri, Jan 30, 2009 at 7:04 AM, William Tam wrote:
> Hi Claus,
>
> The code in CxfMessage#getBody was checking if a message body was a
> org.apache.cxf.message.MessageContentList. If so, it extracted the
> first element and applied converter to the first element. That piece
> of logic now resides in the CxfConverter.convertTo, which is a
> FallbackConverter. Let me know if I am missing something,
>
> Thanks,
> William
Great I kinda forgot from the commit log that you deleted 2 files. The
content of these files is not logged :)
And I just wanted to raise a flag in case there was still something in
the CXF that should be looked at.
>
> On Fri, Jan 30, 2009 at 12:23 AM, Claus Ibsen wrote:
>> Hi Willem
>>
>> There might be some left overs still there. I remember Jiang added
>> something to CxfMessage#getBody (or someplace like that) that would
>> kinda do something like that below.
>>
>> Maybe that code is still there?
>>
>> There is a ticket in JIRA somewhere about it, I can find it if you
>> need it. Ticket reported by me on camel-cxf and fixed by Jiang.
>>
>>
>>
>> On Thu, Jan 29, 2009 at 9:35 PM, wrote:
>>> Author: wtam
>>> Date: Thu Jan 29 20:35:54 2009
>>> New Revision: 738999
>>>
>>> URL: http://svn.apache.org/viewvc?rev=738999&view=rev
>>> Log:
>>> use FallbackConverter in camel-cxf component, which means we can get rid of
>>> CxfMessage and CxfExchange class. Very cool.
>>>
>>> Removed:
>>>
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfExchange.java
>>>
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfMessage.java
>>> Modified:
>>>
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
>>>
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java
>>>
>>> Modified:
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
>>> URL:
>>> http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java?rev=738999&r1=738998&r2=738999&view=diff
>>> ==
>>> ---
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
>>> (original)
>>> +++
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
>>> Thu Jan 29 20:35:54 2009
>>> @@ -25,8 +25,6 @@
>>> import org.apache.camel.CamelContext;
>>> import org.apache.camel.CamelException;
>>> import org.apache.camel.Consumer;
>>> -import org.apache.camel.Exchange;
>>> -import org.apache.camel.ExchangePattern;
>>> import org.apache.camel.HeaderFilterStrategyAware;
>>> import org.apache.camel.Processor;
>>> import org.apache.camel.Producer;
>>> @@ -97,11 +95,6 @@
>>> return new CxfConsumer(this, processor);
>>> }
>>>
>>> -@Override
>>> -public Exchange createExchange(ExchangePattern pattern) {
>>> -return new CxfExchange(this, pattern);
>>> -}
>>> -
>>> public boolean isSingleton() {
>>> return true;
>>> }
>>>
>>> Modified:
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java
>>> URL:
>>> http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java?rev=738999&r1=738998&r2=738999&view=diff
>>> ==
>>> ---
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java
>>> (original)
>>> +++
>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/converter/CxfConverter.java
>>> Thu Jan 29 20:35:54 2009
>>> @@ -22,9 +22,13 @@
>>>
>>> import org.apache.camel.Converter;
>>> import org.apache.camel.Endpoint;
>>> +import org.apache.camel.Exchange;
>>> +import org.apache.camel.FallbackConverter;
>>> +import org.apache.camel.TypeConverter;
>>> import org.apache.camel.component.cxf.CxfSp
[HEADS UP] - File component changes in Camel 2.0
Hi
As some of you know the file component have had a major refactor ...
actually you can nearly consider it as a rewrite in Camel 2.0.
This mail is about a few remaining issues I want to give a heads up
upon and feedback:
Force a filename to be provided when wring a file
I want to force file producer always requiring a header value with the
filename to write.
What we have in Camel 1.x is that if no filename header is provided it
will fallback to use the message id as the filename.
For me that has no use, as its kinda like telling a database here is
some data store it somewhere, without providing, schema, table, column
names.
So I want it to reject writing a file and report an exception that the
filename is missing.
The file language supports you if you want to use the message id as
the filename. Just set the header value as: ${id}
And also remove option: ignoreFileNameHeader
Thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [HEADS UP] - File component changes in Camel 2.0
Hi
Yeah please take a look at the GenericFileExclusiveReadLockStrategy
and see if you can implement it as a implementation of this interface?
Then it can be added into camel 2.0 as an other option to choose.
But beware that the code in trunk is currently have 2 file components.
FileComponent is the old one that is currently active
NewFileComponent is the new one temporary there side by side until its
rock solid and can replace the FileComponent.
The trick is that you can modify the file component file
Index: src/main/resources/META-INF/services/org/apache/camel/component/file
===
--- src/main/resources/META-INF/services/org/apache/camel/component/file
(revision 739943)
+++ src/main/resources/META-INF/services/org/apache/camel/component/file
(working copy)
@@ -15,5 +15,5 @@
# limitations under the License.
#
-class=org.apache.camel.component.file.FileComponent
-strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory
\ No newline at end of file
+class=org.apache.camel.component.file.NewFileComponent
+strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory
\ No newline at end of file
Where you just use the NewFileComponent and the New factory.
On Mon, Feb 2, 2009 at 3:54 PM, Aaron Crickenberger
wrote:
> On a slightly related tangent, I'm partly responsible for the hackish code
> in FileConsumer's (old) isUnchanged() method (
> https://issues.apache.org/activemq/browse/CAMEL-250).
>
> Camel 1.5's exclusiveReadLock feature is unfortunately still picking up
> files too early, so I have to fall back to the deprecated behavior. This
> happens regardless of the file processing strategy (delete, rename, etc.)
> Is there any chance the hackish double-polling stuff can be put back in to
> 2.0 as a non-default file locking strategy? I can take a crack at it, I
> just wasn't sure if the code was still in flux.
>
> - aaron
>
> On Mon, Feb 2, 2009 at 4:44 AM, Claus Ibsen wrote:
>
>> On Fri, Jan 30, 2009 at 5:40 PM, Aaron Crickenberger
>> wrote:
>> > I would hesitate if only because requiring a particular header seems off,
>> > are there other components that do the same?
>> >
>> > I haven't looked much at Camel 2.0's code, but it looks like camel-1.x's
>> > file component's "expression" property could support both scenarios. Use
>> a
>> > default ${id} expression, but allow user to configure w/ a ${in.header}
>> > expression that barks if the header's not present, no?
>> That is correct.
>>
>> Thanks for the feedback. We will leave it as is.
>>
>> >
>> > - aaron
>> >
>> > On Fri, Jan 30, 2009 at 9:49 AM, James Strachan <
>> james.strac...@gmail.com>wrote:
>> >
>> >> So long as files are written in some directory and they are unique and
>> >> preserve order - does it matter if they are generated (from the
>> >> message ID say) or the user explicitly gives some name? Like Jon I'd
>> >> be tempted ot leave the default behaviour?
>> >>
>> >> 2009/1/30 Claus Ibsen :
>> >> > Hi
>> >> >
>> >> > As some of you know the file component have had a major refactor ...
>> >> > actually you can nearly consider it as a rewrite in Camel 2.0.
>> >> >
>> >> > This mail is about a few remaining issues I want to give a heads up
>> >> > upon and feedback:
>> >> >
>> >> >
>> >> > Force a filename to be provided when wring a file
>> >> >
>> >> >
>> >> > I want to force file producer always requiring a header value with the
>> >> > filename to write.
>> >> > What we have in Camel 1.x is that if no filename header is provided it
>> >> > will fallback to use the message id as the filename.
>> >> >
>> >> > For me that has no use, as its kinda like telling a database here is
>> >> > some data store it somewhere, without providing, schema, table, column
>> >> > names.
>> >> >
>> >> > So I want it to reject writing a file and report an exception that the
>> >> > filename is missing.
>> >> >
>> >> > The file language supports you if you want to use the message id as
>> >> > the filename. Just set the header value as: ${id}
>> >> >
>> >> > And also remove option: ignoreFileNameHeader
>> >> >
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > --
>> >> > Claus Ibsen
>> >> > Apache Camel Committer
>> >> >
>> >> > Open Source Integration: http://fusesource.com
>> >> > Blog: http://davsclaus.blogspot.com/
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> James
>> >> ---
>> >> http://macstrac.blogspot.com/
>> >>
>> >> Open Source Integration
>> >> http://fusesource.com/
>> >>
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [HEADS UP] - File component changes in Camel 2.0
On Fri, Jan 30, 2009 at 5:40 PM, Aaron Crickenberger
wrote:
> I would hesitate if only because requiring a particular header seems off,
> are there other components that do the same?
>
> I haven't looked much at Camel 2.0's code, but it looks like camel-1.x's
> file component's "expression" property could support both scenarios. Use a
> default ${id} expression, but allow user to configure w/ a ${in.header}
> expression that barks if the header's not present, no?
That is correct.
Thanks for the feedback. We will leave it as is.
>
> - aaron
>
> On Fri, Jan 30, 2009 at 9:49 AM, James Strachan
> wrote:
>
>> So long as files are written in some directory and they are unique and
>> preserve order - does it matter if they are generated (from the
>> message ID say) or the user explicitly gives some name? Like Jon I'd
>> be tempted ot leave the default behaviour?
>>
>> 2009/1/30 Claus Ibsen :
>> > Hi
>> >
>> > As some of you know the file component have had a major refactor ...
>> > actually you can nearly consider it as a rewrite in Camel 2.0.
>> >
>> > This mail is about a few remaining issues I want to give a heads up
>> > upon and feedback:
>> >
>> >
>> > Force a filename to be provided when wring a file
>> >
>> >
>> > I want to force file producer always requiring a header value with the
>> > filename to write.
>> > What we have in Camel 1.x is that if no filename header is provided it
>> > will fallback to use the message id as the filename.
>> >
>> > For me that has no use, as its kinda like telling a database here is
>> > some data store it somewhere, without providing, schema, table, column
>> > names.
>> >
>> > So I want it to reject writing a file and report an exception that the
>> > filename is missing.
>> >
>> > The file language supports you if you want to use the message id as
>> > the filename. Just set the header value as: ${id}
>> >
>> > And also remove option: ignoreFileNameHeader
>> >
>> >
>> > Thoughts?
>> >
>> > --
>> > Claus Ibsen
>> > Apache Camel Committer
>> >
>> > Open Source Integration: http://fusesource.com
>> > Blog: http://davsclaus.blogspot.com/
>> >
>>
>>
>>
>> --
>> James
>> ---
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [jira] Commented: (CAMEL-1302) Documentation - Add camel-bindy documentation
Hi Bindy is a component donated by Charles Moulliard that choosed that name. I guess its named like this sine it does annotation based POJO binding from other data formats, currently only CSV. On Fri, Jan 30, 2009 at 4:36 PM, William Tam wrote: > BTW, I am curious about the name "bindy". What does it mean? > > On Fri, Jan 30, 2009 at 1:28 AM, Claus Ibsen (JIRA) wrote: >> >>[ >> https://issues.apache.org/activemq/browse/CAMEL-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49034#action_49034 >> ] >> >> Claus Ibsen commented on CAMEL-1302: >> >> >> Charles the wiki page is here you should update: >> http://camel.apache.org/bindy.html >> >> >>> Documentation - Add camel-bindy documentation >>> - >>> >>> Key: CAMEL-1302 >>> URL: https://issues.apache.org/activemq/browse/CAMEL-1302 >>> Project: Apache Camel >>> Issue Type: Sub-task >>> Components: camel-bindy >>>Reporter: Claus Ibsen >>>Assignee: Claus Ibsen >>> 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. >> >> > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Help with camel relaying HTTP msg between .Net web client and .Net service.
Hi
As I read your post. You want Camel to expose a web service that you
can call from a .Net client?
What you need then is a webservice stack to use? Such as Apache CXF.
You can see part 5 of this lengthy tutorial as it an example of
exposing a webservice with CXF from Camel
http://camel.apache.org/tutorial-example-reportincident.html
And you can read from part 1, if you need to get CXF and .wsdl files
setup and all that.
And the camel-cxf component is documented here.
http://camel.apache.org/cxf.html
And we also have a tutorial on using Apache Axis with Camel
http://camel.apache.org/tutorial-axis-camel.html
On Mon, Feb 2, 2009 at 5:26 PM, aliasrob wrote:
>
> Hello, we are using a .NET client to communicate over http: with a .NET web
> service. We are attempting to send a message directly to Camel
> (http://activemq.apache.org/camel/) from the .NET client, and then have
> camel relay that message to the service. Then the service will then reply
> back to Camel and Camel should send that reply message back to the client.
> We wish to do all this over HTTP without adding any of these messages to a
> JMS queue.
> So the process would look something like this
>
> Message sent out
> {Client Machine} --Http Message out --> {Camel Machine} -- Http Message out
> --> {Service Machine}
>
> Message returned
> {Client Machine} <-- Http Message retuned --< {Camel Machine} <-- Http
> Message retuned <-- {Service Machine}
>
>
> Our main problem right now is how to configure the endpoints and which files
> need hold the information. In other words, what HTTP endpoint address does
> the client side send a message to in order to reach Camel? (How do we expose
> Camel as an HTTP endpoint that is reachable by the client?) Also, how do we
> then forward that message from Camel to our .NET service over HTTP? Are
> there any settings in .wsdl we and web.config files which we need to pay
> particular attention to? Any help on how resolve this issue would be greatly
> appreciated. Please provide an example of any xml settings etc.
>
> Thanks
> Rob
>
> --
> View this message in context:
> http://www.nabble.com/Help-with-camel-relaying-HTTP-msg--between-.Net-web-client-and-.Net-service.-tp21792780s22882p21792780.html
> Sent from the Camel - Development mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [DISCUSS] Implement protocol related components in Camel [WAS] Re: [Proposal] New components
Would be cool if SMX and Camel could share more components. A bit silly when we invent the wheels twice. Also the documentation part of the component would be easier. On Mon, Feb 2, 2009 at 7:25 PM, Guillaume Nodet wrote: > This should not be too complicated to implement if needed. > > The idea in JBI is that service assemblies (aka routes un camel) have > three real states: started, stopped and shutdown. > Started means that all endpoints are fully operational. Shutdown > means that no exchanges will be processed. The stopped state is the > interesting one: consumer endpoints will not accept any new requests > from the outside world but will still process existing requests. Other > provider endpoints fully process requets. The goal is to ensure an > orderly shut down of assemblies and not loose any messages. For > example a jms consumer will stop consuming jms messages from the > queue, but will still enqueue responses when they come back from the > route. > > If we are to support that in camel, we should do it in a way that we > can easily control the lifecycle of mixed applications (if you mix > servicemix endpoints and camel routes). > > On 02/02/2009, James Strachan wrote: >> 2009/2/2 Guillaume Nodet : >>> It might be doable. I guess the way to do that would be to define the >>> JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint >>> would be initialized / started, a camel route would be created for it. >>> Not sure how well camel endpoints can handle the JBI lifecycle where >>> new requests are not accepted, but existing exchanges are still >>> processed until completion (for a consumer endpoint). >> >> Could you give an example of a well behaving JBI endpoint that does >> this? I wonder how hard this would be to add; either at the >> Camel-Endpoint-As-JBI-Endpoint wrapper or inside Camel etc >> >> -- >> James >> --- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ >> > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Need example demonstrating camel-mail support of endpoint sending multipart/alternative message
On Tue, Feb 3, 2009 at 9:19 PM, MarkBi wrote: > > Need an example demonstrating camel-mail support of endpoint sending a > multipart/alternative message (plain text body and equivalent html body). > > "./src/test/java/org/apache/camel/component/mail/MimeMessageConsumeTest.java" > is an example using javamail transport to send a multipart/alternative but > not the camel-mail endpoint. If an example is not readily available, does > camel-mail support this or is it a known limitation due to single body > exchange? If it is a limitation then is it possible to send 2nd part as > attachment (but without filename, disposition, etc...) and with the > appropriate alternative content types. > > Many thanks! Hi I dont think we have such an example. Many of the wiki documentation is usually based on real unit tests. And you have looked what we got. We love contributions, so if you feel like it then please give it a stab at it to add this feature/example that you need. http://camel.apache.org/contributing.html > -- > View this message in context: > http://www.nabble.com/Need-example-demonstrating-camel-mail-support-of-endpoint-sending-multipart-alternative-message-tp21818001s22882p21818001.html > Sent from the Camel - Development mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
[Camel 2.0] - Help testing refactored File component
Hi In Camel 2.0 we have refactored the File component to leverage a VFS within Camel itself (common code/interface is named GenericFileXXX) As the file component is used extensivly within Camel itself and to test all camel components it would be great if we could give it a test drive on various OS before making the change permanent. So if you have the time then please test it as: 1) You can change to use NewFileComponent by: Change these lines: class=org.apache.camel.component.file.FileComponent strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory To: class=org.apache.camel.component.file.NewFileComponent strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory In the file: src/main/resources/META-INF/services/org/apache/camel/component/file 2) Run tests in camel-core, camel-spring, camel-ftp, or if you have the time the full package :) mvn clean install For a period of time we will have both file components in Camel 2.0 (the old and the new) side by side. The idea is to keep the old in case something was overlooked and we can switch back for comparison. When everything works and is rock solid then we will remove the old one and make the new the default one. After this test and if it goes well, then we will switch to use the NewFileComponent in Camel trunk code and run with it for a while, and give TeamCity its chance to run extensivly test with it. But before that I would love to iron out any obscure issues on other platforms, than what I use (Mac OS) -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [Camel 2.0] - Help testing refactored File component
On Thu, Feb 5, 2009 at 10:19 AM, Willem Jiang wrote: > Hi Claus, > > I'm monitoring the tests in windows box for a while, now it looks good :) > > I just have th quick note for the NewFileComponent. > > If we plan to rename the newfile component to file component when all > the file tests become stable, we don't need to mark the FileComponent as > deprecated or we should add this information into the FileComponent java > doc. > > Because current user can't change they code to use NewFileComponent now > and the NewFileComponent will finally be rename to FileComponent. > > Am I right? Yes it should eventually be renamed form NewFileComponent to FileComponent. We are in a kind of "in between" state right now. The faster/better we can test it on different OS then faster we can change the default in camel-core to use NewFileComponent, using the service/.../file trick. Then the old File component that is marked as @deprecated will not be used at all. It is just there in case there is a strange bug, then we can swtich over and use it for comparison. After eg a week or so, and Team City is also happy then we can do the big switch and remove the @deprecated and rename the NewFile to File. > > Willem > > > Claus Ibsen wrote: >> Hi >> >> In Camel 2.0 we have refactored the File component to leverage a VFS >> within Camel itself (common code/interface is named GenericFileXXX) >> >> As the file component is used extensivly within Camel itself and to >> test all camel components it would be great if we could give it a test >> drive on various OS before making the change permanent. >> >> So if you have the time then please test it as: >> >> 1) >> You can change to use NewFileComponent by: >> >> Change these lines: >> class=org.apache.camel.component.file.FileComponent >> strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory >> >> To: >> class=org.apache.camel.component.file.NewFileComponent >> strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory >> >> In the file: >> src/main/resources/META-INF/services/org/apache/camel/component/file >> >> 2) >> Run tests in camel-core, camel-spring, camel-ftp, or if you have the >> time the full package :) >> >> mvn clean install >> >> >> For a period of time we will have both file components in Camel 2.0 >> (the old and the new) side by side. The idea is to keep the old in >> case something was overlooked and we can switch back for comparison. >> When everything works and is rock solid then we will remove the old >> one and make the new the default one. >> >> After this test and if it goes well, then we will switch to use the >> NewFileComponent in Camel trunk code and run with it for a while, and >> give TeamCity its chance to run extensivly test with it. >> >> But before that I would love to iron out any obscure issues on other >> platforms, than what I use (Mac OS) >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [Camel 2.0] - Help testing refactored File component
Hi I will change the code in trunk to use the NewFileComponent later this afternoon. Then we have the weekend for the team city servers to crunch on testing as well. Willem fixes the last remaning issues on the windows box, and I think I got the occasional failing ones on the HP/AIX boxes as well. The change is only the META-INF/service/ .../ file trick by setting the "file" scheme to use NewFileComponent, instead of FileComponent. Then we can run with it for a while until we are all happy and can do the last transition and zap the old code. On Thu, Feb 5, 2009 at 11:07 AM, Claus Ibsen wrote: > On Thu, Feb 5, 2009 at 10:19 AM, Willem Jiang wrote: >> Hi Claus, >> >> I'm monitoring the tests in windows box for a while, now it looks good :) >> >> I just have th quick note for the NewFileComponent. >> >> If we plan to rename the newfile component to file component when all >> the file tests become stable, we don't need to mark the FileComponent as >> deprecated or we should add this information into the FileComponent java >> doc. >> >> Because current user can't change they code to use NewFileComponent now >> and the NewFileComponent will finally be rename to FileComponent. >> >> Am I right? > Yes it should eventually be renamed form NewFileComponent to FileComponent. > > We are in a kind of "in between" state right now. The faster/better we > can test it on different OS then faster > we can change the default in camel-core to use NewFileComponent, using > the service/.../file trick. > > Then the old File component that is marked as @deprecated will not be > used at all. It is just there in case there is a strange bug, then we > can swtich over and use it for comparison. > > After eg a week or so, and Team City is also happy then we can do the > big switch and remove the @deprecated and rename the NewFile to File. > > > >> >> Willem >> >> >> Claus Ibsen wrote: >>> Hi >>> >>> In Camel 2.0 we have refactored the File component to leverage a VFS >>> within Camel itself (common code/interface is named GenericFileXXX) >>> >>> As the file component is used extensivly within Camel itself and to >>> test all camel components it would be great if we could give it a test >>> drive on various OS before making the change permanent. >>> >>> So if you have the time then please test it as: >>> >>> 1) >>> You can change to use NewFileComponent by: >>> >>> Change these lines: >>> class=org.apache.camel.component.file.FileComponent >>> strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory >>> >>> To: >>> class=org.apache.camel.component.file.NewFileComponent >>> strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory >>> >>> In the file: >>> src/main/resources/META-INF/services/org/apache/camel/component/file >>> >>> 2) >>> Run tests in camel-core, camel-spring, camel-ftp, or if you have the >>> time the full package :) >>> >>> mvn clean install >>> >>> >>> For a period of time we will have both file components in Camel 2.0 >>> (the old and the new) side by side. The idea is to keep the old in >>> case something was overlooked and we can switch back for comparison. >>> When everything works and is rock solid then we will remove the old >>> one and make the new the default one. >>> >>> After this test and if it goes well, then we will switch to use the >>> NewFileComponent in Camel trunk code and run with it for a while, and >>> give TeamCity its chance to run extensivly test with it. >>> >>> But before that I would love to iron out any obscure issues on other >>> platforms, than what I use (Mac OS) >>> >>> >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [Camel 2.0] - Help testing refactored File component
Hi I enabled it on trunk right now: New Revision: 741515 On Fri, Feb 6, 2009 at 9:39 AM, Claus Ibsen wrote: > Hi > > I will change the code in trunk to use the NewFileComponent later this > afternoon. > Then we have the weekend for the team city servers to crunch on testing as > well. > > Willem fixes the last remaning issues on the windows box, and I think > I got the occasional failing ones on the HP/AIX boxes as well. > > The change is only the META-INF/service/ .../ file trick by setting > the "file" scheme to use NewFileComponent, instead of FileComponent. > > Then we can run with it for a while until we are all happy and can do > the last transition and zap the old code. > > > > On Thu, Feb 5, 2009 at 11:07 AM, Claus Ibsen wrote: >> On Thu, Feb 5, 2009 at 10:19 AM, Willem Jiang wrote: >>> Hi Claus, >>> >>> I'm monitoring the tests in windows box for a while, now it looks good :) >>> >>> I just have th quick note for the NewFileComponent. >>> >>> If we plan to rename the newfile component to file component when all >>> the file tests become stable, we don't need to mark the FileComponent as >>> deprecated or we should add this information into the FileComponent java >>> doc. >>> >>> Because current user can't change they code to use NewFileComponent now >>> and the NewFileComponent will finally be rename to FileComponent. >>> >>> Am I right? >> Yes it should eventually be renamed form NewFileComponent to FileComponent. >> >> We are in a kind of "in between" state right now. The faster/better we >> can test it on different OS then faster >> we can change the default in camel-core to use NewFileComponent, using >> the service/.../file trick. >> >> Then the old File component that is marked as @deprecated will not be >> used at all. It is just there in case there is a strange bug, then we >> can swtich over and use it for comparison. >> >> After eg a week or so, and Team City is also happy then we can do the >> big switch and remove the @deprecated and rename the NewFile to File. >> >> >> >>> >>> Willem >>> >>> >>> Claus Ibsen wrote: >>>> Hi >>>> >>>> In Camel 2.0 we have refactored the File component to leverage a VFS >>>> within Camel itself (common code/interface is named GenericFileXXX) >>>> >>>> As the file component is used extensivly within Camel itself and to >>>> test all camel components it would be great if we could give it a test >>>> drive on various OS before making the change permanent. >>>> >>>> So if you have the time then please test it as: >>>> >>>> 1) >>>> You can change to use NewFileComponent by: >>>> >>>> Change these lines: >>>> class=org.apache.camel.component.file.FileComponent >>>> strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory >>>> >>>> To: >>>> class=org.apache.camel.component.file.NewFileComponent >>>> strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory >>>> >>>> In the file: >>>> src/main/resources/META-INF/services/org/apache/camel/component/file >>>> >>>> 2) >>>> Run tests in camel-core, camel-spring, camel-ftp, or if you have the >>>> time the full package :) >>>> >>>> mvn clean install >>>> >>>> >>>> For a period of time we will have both file components in Camel 2.0 >>>> (the old and the new) side by side. The idea is to keep the old in >>>> case something was overlooked and we can switch back for comparison. >>>> When everything works and is rock solid then we will remove the old >>>> one and make the new the default one. >>>> >>>> After this test and if it goes well, then we will switch to use the >>>> NewFileComponent in Camel trunk code and run with it for a while, and >>>> give TeamCity its chance to run extensivly test with it. >>>> >>>> But before that I would love to iron out any obscure issues on other >>>> platforms, than what I use (Mac OS) >>>> >>>> >>> >>> >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
[HEADS-UP] - Validating unknown options with prefix for lenient endpoints
Hi
As a kinda nice working on CAMEL-1328 I discovered that you could pass
on bogus httpClient parameters in the URI options as the endpoint is
lenient.
So I added feature into camel-core to be able to validate this before
hand and catch if end user have made a type mistake.
eg in this sample we configure httpClient.xxx=true but there are no
xxx options on HttpClient
public void configure() {
from("direct:start").setHeader(HTTP_METHOD,
POST).to("http://www.google.com?httpClient.xxx=true";);
}
If the endpoint is lenient as in the case with Http component, it
would not before hand catch this. So we need to trigger the validation
in the HttpComponent
With this new method in DefaultComponent:
validateUnknownParameters(uri, parameters, "httpClient.");
// http client can be configured from URI options
HttpClientParams clientParams = new HttpClientParams();
IntrospectionSupport.setProperties(clientParams, parameters,
"httpClient.");
// validate that we could resolve all httpClient. parameters
as this component is lenient
validateUnknownParameters(uri, parameters, "httpClient.");
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn change log for JIRA
On Tue, Feb 10, 2009 at 9:27 AM, Willem Jiang wrote: > Hi Team, > > I just found I can't find any svn change logs from newer JIRA, so I > think we need to update the camel FishEye url to reflect the url change > of Camel svn repository. > > Maybe we could add it to the check list of infrastructure for the apache > sub project moving to TLP. :) > > Willem > I assume you mean the Subversion Commits tab in the JIRA? Last time there was an issue James could do some admin config in JIRA and a bit later it picked it up. Maybe its pointing to the old repo? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel 2.0 - namespace issue
Hi Loading this URL from the web browser: http://camel.apache.org/schema/spring/camel-spring.xsd Reveals that the targetnamespace is: targetNamespace="http://activemq.apache.org/camel/schema/spring"; xmlns:tns="http://activemq.apache.org/camel/schema/spring"; Should it not also be changed to the new URL? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [VOTE] Release Apache Camel 1.6.0 (RC1)
+1 yeah On Thu, Feb 12, 2009 at 3:52 PM, Jon Anstey wrote: > Looks good except for a few minor documentation things: > > In the NOTICE.txt I made the following change > -Copyright 2005-2006 The Apache Software Foundation > +Copyright 2007-2009 The Apache Software Foundation > > Its been incorrect since Camel 1.0 so I don't think its a showstopper ;) > > Also there were a few old web site URLs lying around in READMEs. Again no > biggie. > > Here's my +1 > > On Thu, Feb 12, 2009 at 2:16 AM, 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/<http://people.apache.org/%7Ehadrian/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/<http://people.apache.org/%7Ehadrian/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 >> > > > > -- > Cheers, > Jon > > http://janstey.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: svn commit: r743762 - in /camel/trunk/components/camel-restlet/src: main/java/org/apache/camel/component/restlet/ test/java/org/apache/camel/component/restlet/
((RestletComponent)getComponent()).disconnect(restletConsumer);
>> }
>>
>> -/**
>> - * @return the protocol
>> - */
>> +public Method getRestletMethod() {
>> +return restletMethod;
>> +}
>> +
>> +public void setRestletMethod(Method restletMethod) {
>> +this.restletMethod = restletMethod;
>> +}
>> +
>> public String getProtocol() {
>> return protocol;
>> }
>>
>> -/**
>> - * @return the host
>> - */
>> +public void setProtocol(String protocol) {
>> +this.protocol = protocol;
>> +}
>> +
>> public String getHost() {
>> return host;
>> }
>>
>> -/**
>> - * @return the port
>> - */
>> +public void setHost(String host) {
>> +this.host = host;
>> +}
>> +
>> public int getPort() {
>> return port;
>> }
>> -
>> -/**
>> - * @return the uriPattern
>> - */
>> +
>> +public void setPort(int port) {
>> +this.port = port;
>> +}
>> +
>> public String getUriPattern() {
>> return uriPattern;
>> }
>>
>> -/**
>> - * @return the restletBinding
>> - */
>> +public void setUriPattern(String uriPattern) {
>> +this.uriPattern = uriPattern;
>> +}
>> +
>> public RestletBinding getRestletBinding() {
>> return restletBinding;
>> }
>>
>> -/**
>> - * @param restletMethod the restletMethod to set
>> - */
>> -public void setRestletMethod(Method restletMethod) {
>> -this.restletMethod = restletMethod;
>> +public void setRestletBinding(RestletBinding restletBinding) {
>> +this.restletBinding = restletBinding;
>> }
>>
>> -/**
>> - * @return the restletMethod
>> - */
>> -public Method getRestletMethod() {
>> -return restletMethod;
>> +public Map getRealm() {
>> +return realm;
>> }
>>
>> -/**
>> - * @param realm
>> - */
>> public void setRealm(Map realm) {
>> this.realm = realm;
>> }
>> -
>> -/**
>> - * @return the realm
>> - */
>> -public Map getRealm() {
>> -return realm;
>> -}
>> -
>> -
>> }
>>
>> Modified:
>> camel/trunk/components/camel-restlet/src/test/java/org/apache/camel/component/restlet/RestletQueryTest.java
>> URL:
>> http://svn.apache.org/viewvc/camel/trunk/components/camel-restlet/src/test/java/org/apache/camel/component/restlet/RestletQueryTest.java?rev=743762&r1=743761&r2=743762&view=diff
>> ==
>> ---
>> camel/trunk/components/camel-restlet/src/test/java/org/apache/camel/component/restlet/RestletQueryTest.java
>> (original)
>> +++
>> camel/trunk/components/camel-restlet/src/test/java/org/apache/camel/component/restlet/RestletQueryTest.java
>> Thu Feb 12 14:27:53 2009
>> @@ -31,26 +31,21 @@
>> public class RestletQueryTest extends ContextTestSupport {
>> private static final String QUERY_STRING = "foo=bar&test=123";
>>
>> -
>> @Override
>> protected RouteBuilder createRouteBuilder() {
>> -
>> return new RouteBuilder() {
>> @Override
>> public void configure() throws Exception {
>> from("restlet:http://localhost:9080/users/{username}";)
>> .process(new SetUserProcessor());
>> -
>> }
>> -
>> };
>> }
>>
>> class SetUserProcessor implements Processor {
>>
>> public void process(Exchange exchange) throws Exception {
>> -assertEquals(QUERY_STRING,
>> exchange.getIn().getHeader(RestletConstants.QUERY_STRING,
>> -String.class));
>> +assertEquals(QUERY_STRING,
>> exchange.getIn().getHeader(RestletConstants.QUERY_STRING, String.class));
>> }
>>
>> }
>>
>>
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel Event Code - requesting comments
Hi Stephen On Tue, Feb 10, 2009 at 9:18 PM, Stephen J wrote: > > I have written some code to add event handling to camel. The file I've > attached to this post contains the code and a little bit of test code to > explain what I'm trying to do here. > > If someone who is familiar with camel internals would take this code for a > spin and see if the idea will work with the rest of camel architecture, > maybe they can more properly implement some of the functionality I've added > in my code. I'm not familiar enough with the entire camel system to know if > this will work. > > Basically this code enables camel components and processors to send and > receive events through the camel container. > > I've also attempted to add the function of starting and stopping routes with > events, but it doesn't quite work right, and I'm not sure why. I can start > routes with events, but stopping a route doesn't prevent processing which > then causes camel to throw exceptions and stop working. > > There's a more descriptive explanation in the readme included in the zip. > > Hope this is useful. If not, feel free to toss it out. Thanks for sharing your work. Its interesting idea to have a notifcation system. Kinda like the spring event. Starting and stopping routes/consumers/producers and whatelse is certainly something we are looking into improving in Camel 2.x. You can do most of it now, but its not quite there yet. We are also looking into adding new routes dynamically from whatever source: JMX, console, dynamic language, new bundles or whatnot. So an event system within Camel might come handy. Please keep up your work and when the dust settles for Camel 2.0 we can take a peek at this again. > > http://www.nabble.com/file/p21939706/CamelEventCode.zip CamelEventCode.zip > -- > View this message in context: > http://www.nabble.com/Camel-Event-Code---requesting-comments-tp21939706s22882p21939706.html > Sent from the Camel - Development mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Hudson CI builds for Apache Camel
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/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [Camel 2.0] - Help testing refactored File component
Hi I have made the switch. The NewFileComponent is now FileComponent and default in Camel. The old file component has been deleted. Committed revision 744825. Thanks a lot to Willem for help and taking care of the glitches on the Windows platform. On Fri, Feb 6, 2009 at 11:42 AM, Claus Ibsen wrote: > Hi > > I enabled it on trunk right now: > New Revision: 741515 > > > > On Fri, Feb 6, 2009 at 9:39 AM, Claus Ibsen wrote: >> Hi >> >> I will change the code in trunk to use the NewFileComponent later this >> afternoon. >> Then we have the weekend for the team city servers to crunch on testing as >> well. >> >> Willem fixes the last remaning issues on the windows box, and I think >> I got the occasional failing ones on the HP/AIX boxes as well. >> >> The change is only the META-INF/service/ .../ file trick by setting >> the "file" scheme to use NewFileComponent, instead of FileComponent. >> >> Then we can run with it for a while until we are all happy and can do >> the last transition and zap the old code. >> >> >> >> On Thu, Feb 5, 2009 at 11:07 AM, Claus Ibsen wrote: >>> On Thu, Feb 5, 2009 at 10:19 AM, Willem Jiang >>> wrote: >>>> Hi Claus, >>>> >>>> I'm monitoring the tests in windows box for a while, now it looks good :) >>>> >>>> I just have th quick note for the NewFileComponent. >>>> >>>> If we plan to rename the newfile component to file component when all >>>> the file tests become stable, we don't need to mark the FileComponent as >>>> deprecated or we should add this information into the FileComponent java >>>> doc. >>>> >>>> Because current user can't change they code to use NewFileComponent now >>>> and the NewFileComponent will finally be rename to FileComponent. >>>> >>>> Am I right? >>> Yes it should eventually be renamed form NewFileComponent to FileComponent. >>> >>> We are in a kind of "in between" state right now. The faster/better we >>> can test it on different OS then faster >>> we can change the default in camel-core to use NewFileComponent, using >>> the service/.../file trick. >>> >>> Then the old File component that is marked as @deprecated will not be >>> used at all. It is just there in case there is a strange bug, then we >>> can swtich over and use it for comparison. >>> >>> After eg a week or so, and Team City is also happy then we can do the >>> big switch and remove the @deprecated and rename the NewFile to File. >>> >>> >>> >>>> >>>> Willem >>>> >>>> >>>> Claus Ibsen wrote: >>>>> Hi >>>>> >>>>> In Camel 2.0 we have refactored the File component to leverage a VFS >>>>> within Camel itself (common code/interface is named GenericFileXXX) >>>>> >>>>> As the file component is used extensivly within Camel itself and to >>>>> test all camel components it would be great if we could give it a test >>>>> drive on various OS before making the change permanent. >>>>> >>>>> So if you have the time then please test it as: >>>>> >>>>> 1) >>>>> You can change to use NewFileComponent by: >>>>> >>>>> Change these lines: >>>>> class=org.apache.camel.component.file.FileComponent >>>>> strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory >>>>> >>>>> To: >>>>> class=org.apache.camel.component.file.NewFileComponent >>>>> strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory >>>>> >>>>> In the file: >>>>> src/main/resources/META-INF/services/org/apache/camel/component/file >>>>> >>>>> 2) >>>>> Run tests in camel-core, camel-spring, camel-ftp, or if you have the >>>>> time the full package :) >>>>> >>>>> mvn clean install >>>>> >>>>> >>>>> For a period of time we will have both file components in Camel 2.0 >>>>> (the old and the new) side by side. The idea is to keep the old in >>>>> case something was overlooked and we can switch back for comparison. >>>>> When everything works and is rock solid then we will remove the old >>>>> one and make the new the default one. >>>>> >>>>> After this test and if it goes well, then we will switch to use the >>>>> NewFileComponent in Camel trunk code and run with it for a while, and >>>>> give TeamCity its chance to run extensivly test with it. >>>>> >>>>> But before that I would love to iron out any obscure issues on other >>>>> platforms, than what I use (Mac OS) >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> Apache Camel Committer >>> >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Hudson CI builds for Apache Camel
On Mon, Feb 16, 2009 at 8:44 AM, Gert Vanthienen wrote: > Claus, > > How about adding a Continuous Integration page on > http://camel.apache.org/developers.html? +1 And btw add links to both 1.x and trunk > > 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/ >>> >>> >> >> >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel 2.0 - Keys for header problem
Hi
We have a bullet on the Camel 2.0 design page:
http://camel.apache.org/camel-20-design.html
Bullet:
using Camel${component}${name} pattern as header keys instead of using
package names with dots that isn't likely to be transported by JMS or
other transport types
Currently we have mixed content using the old style (using package
names) and the new style.
What I would like to get done before we have a M1 version is to get
this fixed beforehand.
As the change involves looking into all components and fixing it one
by one it would take some time.
If you are in doubt why we should do it, then i will quote what
Jonathan wrote on IRC
"this is CamelCase style"
Well spotted Jon, of course we should have CamelCase in Camel :)
Any thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [DISCUSS] Async messages and UOWs
Hi I am ready On Mon, Feb 16, 2009 at 8:34 AM, Gert Vanthienen wrote: > 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 >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
On Wed, Feb 18, 2009 at 3:07 AM, Willem Jiang wrote:
> I think the component developers should aware these header if they want
> to use them in their component.
>
> I have a quick question about this change of camel-cxf component.
>
> As you know cxf message using the dots name as the header key, like the
> Message.RESPONSE_CODE, Message.PROTOCOL_HEADERS etc. These headers are
> used wildly in camel-cxf component and application user may use them
> direly in their processor if they familiar with CXF.
>
> If we want to support the CamelCase style header key in camel-cxf
> component.Do we need to extract mapping layer between the camel-cxf
> message and cxf message?
>
> I don't know if we can get enough benefits to overcome the inconvenience
> of CamelCase style header.
>
> For the JMS , we map the header key with dot separator to slash
> separator back and forth in the JMS transport binding layer. And we can
> isolate this kind of special in JMS.
>
> Just my 2 cents.
>
> Willem
How do you handle sending SOAP over JMS that CXF support? Do you do
any tricks there as well to conform to the JMS spec?
I do think that any header we expose/set in Camel should be the
CamelCase style. Then whatever other framework does is that framework
choice.
But yeah its some task to look into each and every component and fix
it to the new style.
>
>
>
> William Tam wrote:
>> I agreed with the convention. Just one question, are we going to have
>> component neutral headers that can be understood by more than one
>> component? If we are, what's the convention and where should they go
>> in the source? The obvious reason is the "interoperability" between
>> components. For example, if I am writing a component that needs to
>> understand http headers. my component will then have to check for
>> CamelHttpResponseCode and CamelRestletResponseCode to be able to work
>> with Http and Restlet components.
>>
>> On Tue, Feb 17, 2009 at 2:58 AM, Claus Ibsen wrote:
>>> Hi
>>>
>>> We have a bullet on the Camel 2.0 design page:
>>> http://camel.apache.org/camel-20-design.html
>>>
>>> Bullet:
>>> using Camel${component}${name} pattern as header keys instead of using
>>> package names with dots that isn't likely to be transported by JMS or
>>> other transport types
>>>
>>> Currently we have mixed content using the old style (using package
>>> names) and the new style.
>>> What I would like to get done before we have a M1 version is to get
>>> this fixed beforehand.
>>>
>>> As the change involves looking into all components and fixing it one
>>> by one it would take some time.
>>>
>>> If you are in doubt why we should do it, then i will quote what
>>> Jonathan wrote on IRC
>>>
>>> "this is CamelCase style"
>>>
>>> Well spotted Jon, of course we should have CamelCase in Camel :)
>>>
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
On Tue, Feb 17, 2009 at 4:57 PM, William Tam wrote:
> I agreed with the convention. Just one question, are we going to have
> component neutral headers that can be understood by more than one
> component? If we are, what's the convention and where should they go
> in the source? The obvious reason is the "interoperability" between
> components. For example, if I am writing a component that needs to
> understand http headers. my component will then have to check for
> CamelHttpResponseCode and CamelRestletResponseCode to be able to work
> with Http and Restlet components.
I think each component should keep the headers in its own "namespace".
So yeah you component should check for both.
In fact it can probably just check for endsWith("ResponseCode") to
cater for different prefixes.
>
> On Tue, Feb 17, 2009 at 2:58 AM, Claus Ibsen wrote:
>> Hi
>>
>> We have a bullet on the Camel 2.0 design page:
>> http://camel.apache.org/camel-20-design.html
>>
>> Bullet:
>> using Camel${component}${name} pattern as header keys instead of using
>> package names with dots that isn't likely to be transported by JMS or
>> other transport types
>>
>> Currently we have mixed content using the old style (using package
>> names) and the new style.
>> What I would like to get done before we have a M1 version is to get
>> this fixed beforehand.
>>
>> As the change involves looking into all components and fixing it one
>> by one it would take some time.
>>
>> If you are in doubt why we should do it, then i will quote what
>> Jonathan wrote on IRC
>>
>> "this is CamelCase style"
>>
>> Well spotted Jon, of course we should have CamelCase in Camel :)
>>
>>
>> Any thoughts?
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: minor refactoring - FooHelper -> Foos
On Wed, Feb 18, 2009 at 1:49 PM, James Strachan wrote: > One naming convention I really like from the Google Collections > library is using the plural name of a type/interface/base class as the > helper class for static helper methods. > > So we could rename things like ExchangeHelper to Exchanges, > CamelContextHelper to CamelContexts. Much neater IMHO. > > These helper classes are all internal mostly for Camel implementation > details; so wondering if it'd make sense to refactor them for 2.0? > Thoughts? +1 Like java.util.Collections or java.util.Arrays :) What about those util classes? ResolverUtil (I dislike this name, as its not a light weight util class) And if we had a StringUtil that many framework have, should it be Strings And ObjectHelper should be Objects? A bit close to Object/String maybe hard to spot. > > -- > James > --- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: minor refactoring - FooHelper -> Foos
However we have to be a bit careful when svnmerge from trunk to 1.x if we use a helper etc. as they have different name on trunk On Wed, Feb 18, 2009 at 1:59 PM, Claus Ibsen wrote: > On Wed, Feb 18, 2009 at 1:49 PM, James Strachan > wrote: >> One naming convention I really like from the Google Collections >> library is using the plural name of a type/interface/base class as the >> helper class for static helper methods. >> >> So we could rename things like ExchangeHelper to Exchanges, >> CamelContextHelper to CamelContexts. Much neater IMHO. >> >> These helper classes are all internal mostly for Camel implementation >> details; so wondering if it'd make sense to refactor them for 2.0? >> Thoughts? > +1 > > Like java.util.Collections or java.util.Arrays :) > > What about those util classes? > ResolverUtil (I dislike this name, as its not a light weight util class) > > And if we had a StringUtil that many framework have, should it be Strings > And ObjectHelper should be Objects? > > A bit close to Object/String maybe hard to spot. > > >> >> -- >> James >> --- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: minor refactoring - FooHelper -> Foos
+1 On Wed, Feb 18, 2009 at 3:33 PM, Jon Anstey wrote: > +1 > > On Wed, Feb 18, 2009 at 10:58 AM, Hadrian Zbarcea wrote: > >> +1 >> >> I think the merges back to the camel-1.x are a nuisance we can live with >> and will almost disappear after the fist hump. >> >> Hadrian >> >> >> On Feb 18, 2009, at 8:37 AM, James Strachan wrote: >> >> 2009/2/18 Claus Ibsen : >>> >>>> On Wed, Feb 18, 2009 at 1:49 PM, James Strachan >>>> wrote: >>>> >>>>> One naming convention I really like from the Google Collections >>>>> library is using the plural name of a type/interface/base class as the >>>>> helper class for static helper methods. >>>>> >>>>> So we could rename things like ExchangeHelper to Exchanges, >>>>> CamelContextHelper to CamelContexts. Much neater IMHO. >>>>> >>>>> These helper classes are all internal mostly for Camel implementation >>>>> details; so wondering if it'd make sense to refactor them for 2.0? >>>>> Thoughts? >>>>> >>>> +1 >>>> >>>> Like java.util.Collections or java.util.Arrays :) >>>> >>>> What about those util classes? >>>> ResolverUtil (I dislike this name, as its not a light weight util class) >>>> >>>> And if we had a StringUtil that many framework have, should it be Strings >>>> And ObjectHelper should be Objects? >>>> >>>> A bit close to Object/String maybe hard to spot. >>>> >>> >>> Yeah! Whenever working with Objects in Google collections its actually >>> quite easy to remember after a while. Seems more natural - once you're >>> over the hump - than using Foo[Helper|Utils|Util|WhateverElse] etc I >>> often can't remember if its Helper or Util or Utils :) >>> >>> -- >>> James >>> --- >>> http://macstrac.blogspot.com/ >>> >>> Open Source Integration >>> http://fusesource.com/ >>> >> >> > > > -- > Cheers, > Jon > > http://janstey.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: svn commit: r745589 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/builder/ test/java/org/apache/camel/processor/
> @@ -165,7 +165,7 @@
> }
>
> /**
> - * Replaces all occurrencies of the regular expression with the given
> + * Replaces all occurrences of the regular expression with the given
> * replacement
> */
> public ValueBuilder regexReplaceAll(String regex, String replacement) {
> @@ -174,7 +174,7 @@
> }
>
> /**
> - * Replaces all occurrencies of the regular expression with the given
> + * Replaces all occurrences of the regular expression with the given
> * replacement
> */
> public ValueBuilder regexReplaceAll(String regex, Expression replacement)
> {
>
> Added:
> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RegExRouteTest.java
> URL:
> http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RegExRouteTest.java?rev=745589&view=auto
> ==
> ---
> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RegExRouteTest.java
> (added)
> +++
> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RegExRouteTest.java
> Wed Feb 18 18:15:36 2009
> @@ -0,0 +1,44 @@
> +/**
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.camel.processor;
> +
> +import org.apache.camel.ContextTestSupport;
> +import org.apache.camel.builder.RouteBuilder;
> +import org.apache.camel.component.mock.MockEndpoint;
> +
> +public class RegExRouteTest extends ContextTestSupport {
> +String orignalBody = "Foo";
> +String replacedBody = "Bar";
> +
> +public void testSendingMessage() throws Exception {
> +MockEndpoint result = getMockEndpoint("mock:result");
> +
> +result.expectedBodiesReceived(replacedBody);
> +
> +template.sendBody("direct:start", orignalBody);
> +
> +result.assertIsSatisfied();
> +}
> +
> +protected RouteBuilder createRouteBuilder() {
> +return new RouteBuilder() {
> +public void configure() {
> +from("direct:start").setBody(regexReplaceAll(body(), "Foo",
> "Bar")).to("mock:result");
> +}
> +};
> +}
> + }
> \ No newline at end of file
>
> Propchange:
> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RegExRouteTest.java
> --
>svn:eol-style = native
>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [jira] Created: (CAMEL-1359) no log displayed on the console or file when the command mvn camel:run is launched
:\Dvlpt\Java\workspace-ganymede\camel-source\bindy\src\data\fix\fix.txt,
> Ca
> melFilePath=src\data\fix\fix.txt, CamelFileParent=src\data\fix,
> CamelFileBatchTotal=1}, Body:[{com.xpectis.camel.bindy.m
> odel.fix.Header=8=FIX.4.2, 9=1, 35=D}]
>
> but in my Bean, I have several LOG.DEBUG method
>
>private static final transient Log LOG =
> LogFactory.getLog(HandleFixBean.class);
>
>if (LOG.isDebugEnabled()) {
>LOG.debug("Count : " + count + ", Class type : " +
> model.get(key).getClass());
>}
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
Hi
As part of this change I propose to move the common key constants we
have scattered in the camel-core into Exchange as Willem Jiang have
done for a few ones already.
The we have a single central interface that end users can inspect and
see the constants for the keys if they need to lookup in a
header/property on a Exchange.
If the Exchange interface is not a liked place to store them we can
use a regular Constants class instead.
Any thoughts?
Remember this is just a constant for the key, not the actual string
literal used as key. This issue is still debated, whether CamelCase or
the old dot style.
On Tue, Feb 17, 2009 at 8:58 AM, Claus Ibsen wrote:
> Hi
>
> We have a bullet on the Camel 2.0 design page:
> http://camel.apache.org/camel-20-design.html
>
> Bullet:
> using Camel${component}${name} pattern as header keys instead of using
> package names with dots that isn't likely to be transported by JMS or
> other transport types
>
> Currently we have mixed content using the old style (using package
> names) and the new style.
> What I would like to get done before we have a M1 version is to get
> this fixed beforehand.
>
> As the change involves looking into all components and fixing it one
> by one it would take some time.
>
> If you are in doubt why we should do it, then i will quote what
> Jonathan wrote on IRC
>
> "this is CamelCase style"
>
> Well spotted Jon, of course we should have CamelCase in Camel :)
>
>
> Any thoughts?
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
On Wed, Feb 18, 2009 at 6:12 PM, William Tam wrote:
> On Wed, Feb 18, 2009 at 7:53 AM, Claus Ibsen wrote:
>> On Tue, Feb 17, 2009 at 4:57 PM, William Tam wrote:
>>> I agreed with the convention. Just one question, are we going to have
>>> component neutral headers that can be understood by more than one
>>> component? If we are, what's the convention and where should they go
>>> in the source? The obvious reason is the "interoperability" between
>>> components. For example, if I am writing a component that needs to
>>> understand http headers. my component will then have to check for
>>> CamelHttpResponseCode and CamelRestletResponseCode to be able to work
>>> with Http and Restlet components.
>> I think each component should keep the headers in its own "namespace".
>> So yeah you component should check for both.
>> In fact it can probably just check for endsWith("ResponseCode") to
>> cater for different prefixes.
>
> Checking for endsWith("ResponseCode") is not always safe. I can have
> a header that ends with a same substring but it can have totally
> different semantics.
>
> The issue that I see is that it is promoting components to hardcode to
> only work with a set of components. It implies:
>
> * A component that receives headers has to check for the ALL
> Camel{XXX}ResponseCode. It hardcodes all the senders.
>
> * A new component won't to able to send header to an existing
> component (for it to understand header), unless the new component
> sends the "right" headers. Basically, the sender needs to create
> headers Camel{XXX}ResponseCode for ALL the components can read the
> headers. It hardcodes all the receivers.
>
> Suppose the header we are talking about has well known semantics. If
> the user started with a working route from(a).to(b) and then change it
> to from(c).to(b), component "b" may or may not be able to interpret
> the header from c, but it ought to work. So, it impacts users as well
> not only just the developers.
>
> Just to throw an idea out. What do you think of a header is more than
> a string? If it is an object, it can be embedded with more
> information. Things like actual name to be used in protocol,
> component name, well known semantics (e.g. whether the header is a
> response code, username, password, etc).
Yeah I think you opening a door for something bigger here. To keep it
simple I would like to get the current problem with the KEYS fixed
first.
Then we can tackle your great idea of having a container object for
the value. If the end user wants the plain value we can use type
converters
so he wont have to go throught this container object first.
And in line with my latest proposal to add constants to Exchange for
well known keys we could actually maybe reuse common key name,
so we have a single RESPONSE_CODE, CONTENT_TYPE, USERNAME, PASSWORD.
But lets get the first issue done, then we can focus on the next step
afterwards. BTW: Maybe your ExchangeProperty could be handy here?
>
>>
>>
>>
>>>
>>> On Tue, Feb 17, 2009 at 2:58 AM, Claus Ibsen wrote:
>>>> Hi
>>>>
>>>> We have a bullet on the Camel 2.0 design page:
>>>> http://camel.apache.org/camel-20-design.html
>>>>
>>>> Bullet:
>>>> using Camel${component}${name} pattern as header keys instead of using
>>>> package names with dots that isn't likely to be transported by JMS or
>>>> other transport types
>>>>
>>>> Currently we have mixed content using the old style (using package
>>>> names) and the new style.
>>>> What I would like to get done before we have a M1 version is to get
>>>> this fixed beforehand.
>>>>
>>>> As the change involves looking into all components and fixing it one
>>>> by one it would take some time.
>>>>
>>>> If you are in doubt why we should do it, then i will quote what
>>>> Jonathan wrote on IRC
>>>>
>>>> "this is CamelCase style"
>>>>
>>>> Well spotted Jon, of course we should have CamelCase in Camel :)
>>>>
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r746872 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/converter/stream/ main/java/org/apache/camel/processor/interceptor/ test/java/org/apache/camel/converter/stream/
egy instanceof StreamCaching) {
> +context.getInterceptStrategies().remove(strategy);
> +return;
> +}
> +}
> +}
> }
Shouldnt the javadoc for this one be disable the stream cache?
>
> Modified:
> camel/trunk/camel-core/src/test/java/org/apache/camel/converter/stream/StreamCacheConverterTest.java
> URL:
> http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/converter/stream/StreamCacheConverterTest.java?rev=746872&r1=746871&r2=746872&view=diff
> ==
> ---
> camel/trunk/camel-core/src/test/java/org/apache/camel/converter/stream/StreamCacheConverterTest.java
> (original)
> +++
> camel/trunk/camel-core/src/test/java/org/apache/camel/converter/stream/StreamCacheConverterTest.java
> Mon Feb 23 03:52:43 2009
> @@ -20,6 +20,7 @@
> import java.io.IOException;
> import java.io.InputStream;
>
> +import javax.xml.transform.Source;
> import javax.xml.transform.TransformerException;
> import javax.xml.transform.stream.StreamSource;
>
> @@ -42,13 +43,14 @@
> this.converter = new StreamCacheConverter();
> }
>
> -public void testConvertToStreamCacheStreamSource() throws
> TransformerException, FileNotFoundException {
> +public void testConvertToStreamCacheStreamSource() throws IOException,
> FileNotFoundException, TransformerException {
> StreamSource source = new StreamSource(getTestFileStream());
> -StreamSource cache = (StreamSource)
> converter.convertToStreamCache(source);
> +StreamCache cache = converter.convertToStreamCache(source);
> //assert re-readability of the cached StreamSource
> XmlConverter converter = new XmlConverter();
> -assertNotNull(converter.toString(cache));
> -assertNotNull(converter.toString(cache));
> +assertNotNull(converter.toString((Source)cache));
> +cache.reset();
> +assertNotNull(converter.toString((Source)cache));
> }
>
> public void testConvertToStreamCacheInputStream() throws IOException {
>
> Modified:
> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/interceptor/StreamCachingInterceptorTest.java
> URL:
> http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/interceptor/StreamCachingInterceptorTest.java?rev=746872&r1=746871&r2=746872&view=diff
> ==
> ---
> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/interceptor/StreamCachingInterceptorTest.java
> (original)
> +++
> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/interceptor/StreamCachingInterceptorTest.java
> Mon Feb 23 03:52:43 2009
> @@ -81,7 +81,7 @@
> template.sendBody("direct:b", message);
>
> assertMockEndpointsSatisfied();
> -assertTrue(b.assertExchangeReceived(0).getIn().getBody() instanceof
> StreamCache);
> +assertTrue(b.assertExchangeReceived(0).getIn().getBody() instanceof
> StreamCache);
>
> assertEquals(b.assertExchangeReceived(0).getIn().getBody(String.class),
> MESSAGE);
> }
>
>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Camel 2.0 - Asembly fails on hudson
0) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:159) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) ... 28 more Caused by: org.apache.maven.plugin.assembly.io.AssemblyReadException: Error reading component descriptor at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.mergeComponentsWithMainAssembly(DefaultAssemblyReader.java:463) at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembly(DefaultAssemblyReader.java:366) at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyFromDescriptor(DefaultAssemblyReader.java:332) at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:140) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:296) ... 31 more Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'assembly' (position: START_TAG seen ... permissions and\nlimitations under the License.\n-->\n... @18:11) at org.apache.maven.plugin.assembly.model.io.xpp3.ComponentXpp3Reader.parseComponent(ComponentXpp3Reader.java:467) at org.apache.maven.plugin.assembly.model.io.xpp3.ComponentXpp3Reader.read(ComponentXpp3Reader.java:1662) at org.apache.maven.plugin.assembly.model.io.xpp3.ComponentXpp3Reader.read(ComponentXpp3Reader.java:1676) at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.mergeComponentsWithMainAssembly(DefaultAssemblyReader.java:455) ... 35 more [INFO] [INFO] Total time: 53 minutes 9 seconds [INFO] Finished at: Fri Feb 20 05:04:17 PST 2009 [INFO] Final Memory: 112M/183M [INFO] ---- -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Asembly fails on hudson
Super
I was wondering if we dare to upgrade to maven 2.0.10 ?
On Mon, Feb 23, 2009 at 10:21 AM, Gert Vanthienen
wrote:
>
> 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.
Re: question on HttpMessage.populateInitialHeaders
On Tue, Feb 24, 2009 at 2:34 AM, William Tam wrote:
> In HttpMessage.populateInitialHeaders(), we only propagate parameters
> for GET request. Does anyone see any harm in propagating other
> parameters of HTTP methods?
I was wondering if the API below can return parameters for POST etc?
Maybe the answer is obvious but I thought that API below fetches the
GET URI parameters?
So which other operations can it also get parameters from?
For POST aren't "paramenters" not stored as HTTP headers?
>
> //if the request method is Get, we also populate the http
> request parameters
> if (request.getMethod().equalsIgnoreCase("GET")) {
> names = request.getParameterNames();
> while (names.hasMoreElements()) {
> String name = (String)names.nextElement();
> Object value = request.getParameter(name);
> map.put(name, value);
> }
> }
>
> Thanks,
> William
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Discussion of scope for next Apache Camel 1.x release
Hi I was wondering if we should start a discussion on the scope for the next Apache Camel 1.x release (notice 1.x branch) As we have always done minor versions and no patch releases I was wondering if we should focus on doing a - 1.6.1 patch release so end users have a stable release that should be drop in compatible - or a new 1.7.0 release I am in favor of focusing on a 1.6.1 release. Any thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Where exception handling should set a handled exception?
Hi Roman
Could you add a route example to that.
AFAIR this is *only* with the try .. handle DSLs ?
I can enlighten that on the DeadLetterChannel we store previoysly
occured exception as a property when we do redelivery.
There is a constant KEY for it on the Exchange (Camel 2.0)
String EXCEPTION_CAUGHT = "CamelExceptionCaught";
On Wed, Feb 25, 2009 at 12:10 PM, Roman Kalukiewicz
wrote:
> Hello!
>
> Recently I created an issue (CAMEL-1356) about exception handling and
> now I'm not really sure if it is really a bug or not. So I'm asking
> for your opinions.
>
> The problem is that when exception is caught it is set as a
> 'caught.exception' header on IN message. It means that if an exception
> is thrown on an exchange that already has OUT message it will be lost
> after the first step of a pipeline.
>
> We have few possible solutions here:
> 1) Keep it as it is - then we know where to look for this header in
> the first step of the pipeline - we can also use bean integration and
> @Header annotation to retrieve it)
> 2) Put the exception to header on OUT message if it is present - then
> it will be preserved in the pipeline. But then first step of the
> pipeline has to be clever - it has to look for it in OUT message.
> Moreover it is more general problem - if we allow OUT messages there,
> then you cannot use for example setHeader("foo") (you can, but it is
> useless, as out is propagated anyway)
> 3) Put it into exchange property - maybe the best solution as it is
> propagated, and we always know where to look for the exception. It
> will not be lost at some endpoint also.
>
> I believe this change should by put to 2.0 only as it might break
> someones exception handling completely, shouldn't it?
>
> This time I don't want to start flame about need for in/out messages
> once again, but... ;)
>
> Roman
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
Hi I am working on this now, to change it to CamelCase. I am adding xxxConstants classes to the component where we can put the constants for the key names. This allows end users to easy spot which keys we have. I decided for xxxConstants over Constants when end users work with multiple components and want to import Constants then there is a ambiguity. Hence the component prefix, eg. JmsConstants, HttpConstants And in the future we could merge them into a org.apache.camel.Constants or org.apache.camel.Keys class. In the core the keys are stored on the Exchange that William started with. We can later decide if we want a Constants class as well, or whatever. The values for the keys will be changed to use the new CamelCase syntax. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: starting, stopping, creating & editing routes at runtime now works - CAMEL-1004
On Wed, Feb 25, 2009 at 7:29 PM, James Strachan wrote: > Here's a test case to show the kind of thing we can now do... > http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/impl/StartAndStopRoutesTest.java > > there's now a start/stop route method on CamelContext where you can > start or stop individual routes using the route definition (which lets > you also mutate routes). Routes with the same ID replace old ones, > otherwise its a new route. So you could get a route definition, clear > the ID and start it to clone a route. > > So far it looks like most of the tests still pass. Do folks think the > API seems OK to them? I've tried to hide as much of the internal > details as possible - so the API is primarily dealing with the route > definitions (RouteType classes) Looks great. We can always ponder with the API later. Maybe from a maintenance point of view you would like to be able to stop routes based on the id alone, so you from a web console can stop / start routes and submit the id from the web form. I assume each route has a unique id that can be used for higher level manipulation from scripts (yeah there is a id on the route type and route service as well)? So you can eg. submit a route to be replace an existing route from a script and pass in the route id? And a feature I would love in the future was to be able to pause individual consumers. eg. pause a file consumer temporary to pile up files and you can tamper with the routes, or you were told to pause it since some back end system is not available. So you can say that if you could pause routes then that would be lovely as it can be used as well. However we do have support for routes with multiple inputs (eg multiple from -> same route) so if you pause the route you pause them all, but I guess that could make sense. > > -- > James > --- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Data-driven routing
Hi
BTW: We might consider whit Camel 2.0 to add a sample for a real
dynamic router where you can create
the route in java code and start it for those that are using such thing.
This sample uses the dynamic recipient list that is not totally the same:
http://camel.apache.org/dynamic-router.html
On Fri, Feb 27, 2009 at 11:16 AM, James Strachan
wrote:
> 2009/2/26 jbower1950 :
>>
>> I have tried that approach. It was pretty intuitive and made sense. The
>> problem came when I had two routes from the same source (e.g., a log), one
>> portion of which I wanted to route to one topic, the other part going to
>> another topic. It appeared that, using the DSL with two routes, one message
>> would go to one route (and get resolved properly), then the next would go to
>> the next route (and not get resolved properly).
>>
>> So, graphically:
>>
>> Source 1 --> Xpath 1 --> Process A --> Sink 1
>> Source 1 --> Xpath 2 --> Process A --> Sink 2
>>
>> It seemed that message 1 hit the first route and ended up in the right
>> place. Message 2, which should have been resolved by the first route, went
>> to the second route and did not proceed (no match on the xpath filter).
>
> It depends a little on what the load balancing mechanism used inside
> the endpoint.
>
> For example if Source 1 was a JMS topic the above would work perfectly.
>
> However the general case is going to be you want multiple filters to
> be part of the same route.
>
> If so just change your code to reuse the same route for the same
> source string. e.g.
>
>
> for (Foo foo : foos) {
> String u = foo.getFromEndpointUri();
> String xp = foo.getXPath();
> Class type = foo.getBeanType(); // or processor type
>
> getFromFor(u).
> filter().xpath(xp).bean(type).
> end(); // this is important to close the filter block!
> }
>
> ...
>
> /** returns the route for the given endpoint */
> RouteType getFromFor(String endpoint) {
> RouteType answer = routesMap.get(endpoint);
> if (answer == null) {
> answer = from(endpoint);
> routesMap.put(endpoint, answer);
> }
> return answer;
> }
>
> basically you'd then the concatenating the routes together so all
> filters on a single endpoint are part of the same route. So you'd be
> doing in pseudo code...
>
> from(source1).
> filter().xpath(xpath1).bean(bean1).end().
> filter().xpath(xpath2).bean(bean2).end().
>
> etc
>
> Another approach which is similar - but avoids issues if folks forget
> the 'end()' and so is a little bit more rugged - is to treat each of
> those routes as independent routes with their own URIs - then
> separately chain them together in a separate route on the real
> endpoint.
>
> e.g.
>
> public void configure() {
> Multimap uriMap = ...;
>
>
> List foos = ... // some query
> for (Foo foo : foos) {
> String realUri = foo.getFromEndpointUri();
> String xp = foo.getXPath();
> Class type = foo.getBeanType(); // or processor type
>
> // lets add a route from the uri and filter to the given
> processor
>
> String newUri = createNewUri(); // returns say direct:1234
> from(newUri).filter().xpath(xp).bean(type);
>
> // lets map the newUri to the real uri 'realUri'
> multimap.put(realUri, newUri);
> }
>
> // now lets bind these routes to the real URIs...
> for (Entry entry : multimap.entries()) {
> String realUri = entry.getKey();
> List indiviualUris = entry.getValue();
> from(realUri).to(indvidualUris);
> }
> }
>
>
>
> --
> James
> ---
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r748757 - /camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
On Sat, Feb 28, 2009 at 1:07 AM, wrote:
> Author: hadrian
> Date: Sat Feb 28 00:07:13 2009
> New Revision: 748757
>
> URL: http://svn.apache.org/viewvc?rev=748757&view=rev
> Log:
> Fix assertion to pass when a non-String value matches an expected String
> value.
>
> Modified:
>
> camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
>
> Modified:
> camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
> URL:
> http://svn.apache.org/viewvc/camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java?rev=748757&r1=748756&r2=748757&view=diff
> ==
> ---
> camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
> (original)
> +++
> camel/trunk/camel-core/src/main/java/org/apache/camel/component/mock/MockEndpoint.java
> Sat Feb 28 00:07:13 2009
> @@ -318,7 +318,7 @@
> public void run() {
> assertTrue("No header with name " + headerName + " found.",
> actualHeader != null);
>
> - assertEquals("Header of message", headerValue, actualHeader);
> + assertEquals("Header of message", headerValue,
> actualHeader.toString());
What if the headerValue is Integer (if it can) dont you hit a
assertEquals(Object, Object) instead of (Integer, Integer)
Just wondering?
Maybe we can use Camels type converter to convert both values to a
String instead of .toString() ?
> }
> });
> }
>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Problems in implementing Loadbalance using ActiveMQ and Camel
Hi On Thu, Feb 26, 2009 at 11:05 PM, dasalav wrote: > > Hi > > My requirement is: > > i have an input queue of Active MQ 5.1. the messages keeps adding to it. > These messages are to be consumed by 3 differerent consumers. But each > consumer queue should have a limit to 2. If the consumer queue is full, > the producer should stop sending messages to that queue and proceed with the > others. > > I am trying to implement this functionality using round robin of Camel 1.5 > like this. > > from(fromDest).loadBalance().roundRobin().to(loadbal1,loadbal2,loadbal3); > > Note: > > I haven't found any source to limit the size of consumer queue. > Please help me. A consumer queue only allowing 2 elements is a really harsh SLA. Why cant it be higher? Whats the reason? You need some kind of producer to these queue that can try to put it, and if it fails it will try the next queue in a round robin fashion or some other algorithm. When you try today to put on a full queue do you get a rejection or does it block until there is room? I am wondering how this is supported by JMS. Have you tried asking at the ActiveMQ forum as well? > > Thanks in advance. > -- > View this message in context: > http://www.nabble.com/Problems-in-implementing-Loadbalance-using-ActiveMQ-and-Camel-tp22234799p22234799.html > Sent from the Camel - Development (activemq) mailing list archive at > Nabble.com. > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel 2.0 API - Proposal of new support package to fix bad tangles
Hi I am using Structure 101 to view the Camel API and have found some hot spots to clear. - DataFormatType was implementing DataFormat (fixed) - SPI had a bad tangle (fixed) - Language had a bad tangle (fixed) However we do have some support classes (abstract base classes) in camel.impl that are reused outside .impl. Currently its mostly the ExpressionAdapter to assist impl. Expression. I would like to propose a new package in Camel for such common classes. As the util package is a kinda mixed up package currently org.apache.camel.support And we can move: ExpressionAdapter ExpressionSupport PredicateSupport That are most likely to be used outside camel.impl in eg. processor, language, builder and other packages where Expression/Preidcates is also highly used. Any thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel - Puzzled by this code comment vs. the code
Hi
Looking into MessageSupport getBody(type) I was a bit puzzled with the
code vs. the comment
The code below is from a old version, eg 1 year old. This is highly
what James have coded.
However as I see it we do the opposite, we covert the body = payload
first. And if its null then we do on the message itself.
James, anyone?
PS: The code in trunk is basically the same, except it catches the
NoTypeConverterException as we do not return null for non converters.
protected T getBody(Class type, Object body) {
Exchange e = getExchange();
if (e != null) {
TypeConverter converter = e.getContext().getTypeConverter();
T answer = converter.convertTo(type, body);
if (answer == null) {
// lets first try converting the message itself first
// as for some types like InputStream v Reader its
more efficient to do the transformation
// from the Message itself as its got efficient
implementations of them, before trying the
// payload
answer = converter.convertTo(type, this);
}
return answer;
}
return (T)getBody();
}
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Camel 2.0 - OSGi - loading classes
Hi In Camel we use ObjectHelper.loadClass to load classes on the fly. Could there be some issues with this in OSGi platforms? We got a report today with using camel-jms that tries to load a spring queue browser class on the fly. So we can support Spring 2.0 also as this class was introduced in Spring 2.5.x. I was wondering if we should add API for pluggable class resolvers? Eg. ClassResolver API in SPI and then a getter to it from CamelContext. Or is the ObjectHelper sufficient? Do you need to get hold of some bundle context to load classes in OSGi or is the regular class loading okay? Gertv, Willem you are the ones that are most into OSGi. You thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - OSGi - loading classes
On Tue, Mar 3, 2009 at 2:03 PM, Willem Jiang wrote: > Hi, > > I think we should leverage the ThreadContextClassLoader to load the > right class. > Since OSGI has elegant mechanism to get control of the class's version > and handle the relationship of the classes. I don't want to walk around > this mechanism by looking over all the bundler's context for a class. But this was the problem with the JMS stuff. ObjectHelper.loadClass will use the ThredContextClassLoader first. So I can not see if that would work. > > Just my 2 cents. > > Willem. > > Claus Ibsen wrote: >> Hi >> >> In Camel we use ObjectHelper.loadClass to load classes on the fly. >> >> Could there be some issues with this in OSGi platforms? We got a >> report today with using camel-jms that tries to load a spring queue >> browser class on the fly. So we can support Spring 2.0 also as this >> class was introduced in Spring 2.5.x. >> >> I was wondering if we should add API for pluggable class resolvers? >> Eg. ClassResolver API in SPI and then a getter to it from >> CamelContext. >> Or is the ObjectHelper sufficient? >> >> Do you need to get hold of some bundle context to load classes in OSGi >> or is the regular class loading okay? >> >> Gertv, Willem you are the ones that are most into OSGi. You thoughts? >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - OSGi - loading classes
On Tue, Mar 3, 2009 at 2:26 PM, Willem Jiang wrote: > Hi Claus > > If the ThreadContextClassLoader is the user's bundle's classloader, and > the user bundle doesn't import the org.apache.camel.jms package. > The ObjectHelper can't load the right DefaultQueueBrowseStrategy class > by using the bundle's classlaoder. Ah got it. So by changing to the JMS class we know its gonna find it in camel-jms as its the same bundle as it self :) > > Willem > > Claus Ibsen wrote: >> On Tue, Mar 3, 2009 at 2:03 PM, Willem Jiang wrote: >>> Hi, >>> >>> I think we should leverage the ThreadContextClassLoader to load the >>> right class. >>> Since OSGI has elegant mechanism to get control of the class's version >>> and handle the relationship of the classes. I don't want to walk around >>> this mechanism by looking over all the bundler's context for a class. >> But this was the problem with the JMS stuff. ObjectHelper.loadClass >> will use the ThredContextClassLoader first. >> So I can not see if that would work. >> >>> Just my 2 cents. >> >>> Willem. >>> >>> Claus Ibsen wrote: >>>> Hi >>>> >>>> In Camel we use ObjectHelper.loadClass to load classes on the fly. >>>> >>>> Could there be some issues with this in OSGi platforms? We got a >>>> report today with using camel-jms that tries to load a spring queue >>>> browser class on the fly. So we can support Spring 2.0 also as this >>>> class was introduced in Spring 2.5.x. >>>> >>>> I was wondering if we should add API for pluggable class resolvers? >>>> Eg. ClassResolver API in SPI and then a getter to it from >>>> CamelContext. >>>> Or is the ObjectHelper sufficient? >>>> >>>> Do you need to get hold of some bundle context to load classes in OSGi >>>> or is the regular class loading okay? >>>> >>>> Gertv, Willem you are the ones that are most into OSGi. You thoughts? >>>> >>>> >>> >> >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: svn commit: r749973 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/component/mock/ main/java/org/apache/camel/processor/interceptor/ test/java/org/apache/camel/component/mock/ test
t; for (int counter : counters) {
>> - template.sendBodyAndHeader("direct:a",
>> createTestMessage(counter),
>> - "counter", counter);
>> + template.sendBodyAndHeader("direct:a",
>> createTestMessage(counter), "counter", counter);
>> }
>> }
>>
>> @@ -181,7 +193,7 @@
>> return list;
>> }
>>
>> - protected void sendHeader(String name, String value) {
>> + protected void sendHeader(String name, Object value) {
>> template.sendBodyAndHeader("direct:a", "body", name, value);
>> }
>>
>>
>> Modified:
>> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoutePerformanceTest.java
>> URL:
>> http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoutePerformanceTest.java?rev=749973&r1=749972&r2=749973&view=diff
>> ==
>> ---
>> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoutePerformanceTest.java
>> (original)
>> +++
>> camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoutePerformanceTest.java
>> Wed Mar 4 12:06:11 2009
>> @@ -38,6 +38,7 @@
>>
>> MockEndpoint endpoint = getMockEndpoint("mock:results");
>> endpoint.expectedMessageCount((int) dataSet.getSize());
>> + endpoint.expectedHeaderReceived("foo", 123);
>>
>> assertMockEndpointsSatisfied();
>>
>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: svn commit: r750021 - in /camel/branches/camel-1.x: ./ camel-core/src/main/java/org/apache/camel/util/ components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/ compon
On Thu, Mar 5, 2009 at 2:10 AM, Willem Jiang wrote:
> Hi Claus,
>
> Since Camel 1.x doesn't support the onException, I'd like to revert the
> SpringOnExceptionNotNormalizedClassNameTest part and keep the change of
> ObjectHelper.
Can you explain a bit more, onException is in 1.x? Is there something
that fails?
But yes the ObjectHelper changes should be there, it issue was
reported against 1.x and you get this problem when you use Eclipse to
auto format your XML files.
>
> Willem
>
> davscl...@apache.org wrote:
>> Author: davsclaus
>> Date: Wed Mar 4 14:25:18 2009
>> New Revision: 750021
>>
>> URL: http://svn.apache.org/viewvc?rev=750021&view=rev
>> Log:
>> Merged revisions 750017 via svnmerge from
>> https://svn.apache.org/repos/asf/camel/trunk
>>
>>
>> r750017 | davsclaus | 2009-03-04 15:20:14 +0100 (Wed, 04 Mar 2009) | 1 line
>>
>> CAMEL-1418: Normalizes class names before loading to avoid \n or other
>> chars by Spring DSL configuration with xml tags on newlines or hidden spaces
>> etc.
>>
>>
>> Added:
>>
>> camel/branches/camel-1.x/components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/SpringOnExceptionNotNormalizedClassNameTest.java
>> - copied unchanged from r750017,
>> camel/trunk/components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/SpringOnExceptionNotNormalizedClassNameTest.java
>>
>> camel/branches/camel-1.x/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/onExceptionNotNormalizedClassNameTest.xml
>> - copied unchanged from r750017,
>> camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/onExceptionNotNormalizedClassNameTest.xml
>> Modified:
>> camel/branches/camel-1.x/ (props changed)
>>
>> camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
>>
>> Propchange: camel/branches/camel-1.x/
>> --
>> --- svn:mergeinfo (original)
>> +++ svn:mergeinfo Wed Mar 4 14:25:18 2009
>> @@ -1 +1 @@
>> -/camel/trunk:736980,739733,739904,740251,740295,740306,740596,740663,741848,742231,742705,742739,742854,742856,742898,742906,743613,743762,743773,743920,743959-743960,744123,745105,745367,745541,745751,745826,745978,746269,746872,746895,746962,747258,747678-747704,748392,748436,748821,749563-749564,749574,749628-749629,749956
>> +/camel/trunk:736980,739733,739904,740251,740295,740306,740596,740663,741848,742231,742705,742739,742854,742856,742898,742906,743613,743762,743773,743920,743959-743960,744123,745105,745367,745541,745751,745826,745978,746269,746872,746895,746962,747258,747678-747704,748392,748436,748821,749563-749564,749574,749628-749629,749956,750017
>>
>> Propchange: camel/branches/camel-1.x/
>> --
>> Binary property 'svnmerge-integrated' - no diff available.
>>
>> Modified:
>> camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
>> URL:
>> http://svn.apache.org/viewvc/camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java?rev=750021&r1=750020&r2=750021&view=diff
>> ==
>> ---
>> camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
>> (original)
>> +++
>> camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
>> Wed Mar 4 14:25:18 2009
>> @@ -478,6 +478,9 @@
>> * @return the class or null if it could not be loaded
>> */
>> public static Class loadClass(String name, ClassLoader loader) {
>> + // must clean the name so its pure java name, eg remoing \n or
>> whatever people can do in the Spring XML
>> + name = normalizeClassName(name);
>> +
>> // try context class loader first
>> Class clazz = doLoadClass(name,
>> Thread.currentThread().getContextClassLoader());
>> if (clazz == null) {
>> @@ -843,4 +846,23 @@
>> }
>> }
>>
>> + /**
>> + * Cleans the string to pure java identifier so we can use it for
>> loading class names.
>> + *
>> + * Especially from Sping DSL people can have \n \t or other characters
>> that otherwise
>> + * would result in ClassNotFoundException
>> +
Re: svn commit: r750021 - in /camel/branches/camel-1.x: ./ camel-core/src/main/java/org/apache/camel/util/ components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/ compon
On Thu, Mar 5, 2009 at 2:10 AM, Willem Jiang wrote:
> Hi Claus,
>
> Since Camel 1.x doesn't support the onException, I'd like to revert the
> SpringOnExceptionNotNormalizedClassNameTest part and keep the change of
> ObjectHelper.
Ah I got it, the problem was that onexception did not exists as a
package name for unit testing 1.x.
Yeah that is fine to remove the unit tests. We have them in trunk.
The feature onException for error handling is of course also available
in Camel 1.x
>
> Willem
>
> davscl...@apache.org wrote:
>> Author: davsclaus
>> Date: Wed Mar 4 14:25:18 2009
>> New Revision: 750021
>>
>> URL: http://svn.apache.org/viewvc?rev=750021&view=rev
>> Log:
>> Merged revisions 750017 via svnmerge from
>> https://svn.apache.org/repos/asf/camel/trunk
>>
>>
>> r750017 | davsclaus | 2009-03-04 15:20:14 +0100 (Wed, 04 Mar 2009) | 1 line
>>
>> CAMEL-1418: Normalizes class names before loading to avoid \n or other
>> chars by Spring DSL configuration with xml tags on newlines or hidden spaces
>> etc.
>>
>>
>> Added:
>>
>> camel/branches/camel-1.x/components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/SpringOnExceptionNotNormalizedClassNameTest.java
>> - copied unchanged from r750017,
>> camel/trunk/components/camel-spring/src/test/java/org/apache/camel/spring/processor/onexception/SpringOnExceptionNotNormalizedClassNameTest.java
>>
>> camel/branches/camel-1.x/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/onExceptionNotNormalizedClassNameTest.xml
>> - copied unchanged from r750017,
>> camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/onExceptionNotNormalizedClassNameTest.xml
>> Modified:
>> camel/branches/camel-1.x/ (props changed)
>>
>> camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
>>
>> Propchange: camel/branches/camel-1.x/
>> --
>> --- svn:mergeinfo (original)
>> +++ svn:mergeinfo Wed Mar 4 14:25:18 2009
>> @@ -1 +1 @@
>> -/camel/trunk:736980,739733,739904,740251,740295,740306,740596,740663,741848,742231,742705,742739,742854,742856,742898,742906,743613,743762,743773,743920,743959-743960,744123,745105,745367,745541,745751,745826,745978,746269,746872,746895,746962,747258,747678-747704,748392,748436,748821,749563-749564,749574,749628-749629,749956
>> +/camel/trunk:736980,739733,739904,740251,740295,740306,740596,740663,741848,742231,742705,742739,742854,742856,742898,742906,743613,743762,743773,743920,743959-743960,744123,745105,745367,745541,745751,745826,745978,746269,746872,746895,746962,747258,747678-747704,748392,748436,748821,749563-749564,749574,749628-749629,749956,750017
>>
>> Propchange: camel/branches/camel-1.x/
>> --
>> Binary property 'svnmerge-integrated' - no diff available.
>>
>> Modified:
>> camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
>> URL:
>> http://svn.apache.org/viewvc/camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java?rev=750021&r1=750020&r2=750021&view=diff
>> ==
>> ---
>> camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
>> (original)
>> +++
>> camel/branches/camel-1.x/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java
>> Wed Mar 4 14:25:18 2009
>> @@ -478,6 +478,9 @@
>> * @return the class or null if it could not be loaded
>> */
>> public static Class loadClass(String name, ClassLoader loader) {
>> + // must clean the name so its pure java name, eg remoing \n or
>> whatever people can do in the Spring XML
>> + name = normalizeClassName(name);
>> +
>> // try context class loader first
>> Class clazz = doLoadClass(name,
>> Thread.currentThread().getContextClassLoader());
>> if (clazz == null) {
>> @@ -843,4 +846,23 @@
>> }
>> }
>>
>> + /**
>> + * Cleans the string to pure java identifier so we can use it for
>> loading class names.
>> + *
>> + * Especially from Sping DSL people can have \n \t or other characters
>> that otherwise
>> + * would result in ClassNotFoundException
>&
Re: Edit wiki
On Thu, Mar 5, 2009 at 8:36 AM, Nicolas Bouillon wrote: > Hi, > > I would like to have rights to edit the wiki. I would like to add some > example for mina filters. > > My Confluence username is my email address, and my JIRA username is bouil. I have granted you karma, so you should now be able to edit. > > Regards > Nicolas. > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel in Sonar
On Fri, Mar 6, 2009 at 2:49 PM, Jon Anstey wrote: > The Sonar guys were kind enough to add Camel to their public server. > > http://www.nabble.com/Re%3A-New-projects-in-public-sonar-instance--p22360333.html > > Take a peek at how well we do here > http://nemo.sonar.codehaus.org/project/index/org.apache.camel:camel-parent Very cool Jon. I was about to suggest if we could get that in house at fuse. Very cool. > > -- > Cheers, > Jon > > http://janstey.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel in Sonar
Hi Could you add a link to it somewhere, there is an existing page where Gert added the links to public hudson something with developer On Fri, Mar 6, 2009 at 3:13 PM, Claus Ibsen wrote: > On Fri, Mar 6, 2009 at 2:49 PM, Jon Anstey wrote: >> The Sonar guys were kind enough to add Camel to their public server. >> >> http://www.nabble.com/Re%3A-New-projects-in-public-sonar-instance--p22360333.html >> >> Take a peek at how well we do here >> http://nemo.sonar.codehaus.org/project/index/org.apache.camel:camel-parent > Very cool Jon. > > I was about to suggest if we could get that in house at fuse. Very cool. > > >> >> -- >> Cheers, >> Jon >> >> http://janstey.blogspot.com/ >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 API - Proposal of new support package to fix bad tangles
Hi I fixed the package tangle so we keep the current package structure as is. On Mon, Mar 2, 2009 at 6:42 AM, Claus Ibsen wrote: > Hi > > I am using Structure 101 to view the Camel API and have found some hot > spots to clear. > - DataFormatType was implementing DataFormat (fixed) > - SPI had a bad tangle (fixed) > - Language had a bad tangle (fixed) > > However we do have some support classes (abstract base classes) in > camel.impl that are reused outside .impl. > Currently its mostly the ExpressionAdapter to assist impl. Expression. > > I would like to propose a new package in Camel for such common > classes. As the util package is a kinda mixed up package currently > org.apache.camel.support > > And we can move: > ExpressionAdapter > ExpressionSupport > PredicateSupport > > That are most likely to be used outside camel.impl in eg. processor, > language, builder and other packages where Expression/Preidcates is > also highly used. > > Any thoughts? > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: svn commit: r751659 - in /camel/trunk: apache-camel/pom.xml pom.xml
On Mon, Mar 9, 2009 at 1:29 PM, Jon Anstey wrote:
> Just an FYI why I'm making these assembly plugin changes. There is some
> really weird stuff going on in Hudson. Some builds use maven-assembly-plugin
> version 2.1 (which is what we define in our poms) and others use version
> 2.2-beta-2 (even though 2.1 is used in the pom)... seems kinda random...
>
> 2.1 used
> http://hudson.zones.apache.org/hudson/job/Camel/52/org.apache.camel$apache-camel/executedMojos
> 2.2-beta-2 used
> http://hudson.zones.apache.org/hudson/job/Camel/53/org.apache.camel$apache-camel/executedMojos
>
> Not sure if this is a hudson bug or a maven bug. I know I can't reproduce it
> on my machine so its kinda hard to track down :) Anyone hitting similar
> issues on their local machine?
Yeah I cannot assemble the build at the end. It fails with eg
something with copyright in the common-bin, or is it unix-src file.
>
> On Mon, Mar 9, 2009 at 9:53 AM, wrote:
>
>> Author: janstey
>> Date: Mon Mar 9 12:23:39 2009
>> New Revision: 751659
>>
>> URL: http://svn.apache.org/viewvc?rev=751659&view=rev
>> Log:
>> Put assembly plugin version into parent pom
>>
>> Modified:
>> camel/trunk/apache-camel/pom.xml
>> camel/trunk/pom.xml
>>
>> Modified: camel/trunk/apache-camel/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/camel/trunk/apache-camel/pom.xml?rev=751659&r1=751658&r2=751659&view=diff
>>
>> ==
>> --- camel/trunk/apache-camel/pom.xml (original)
>> +++ camel/trunk/apache-camel/pom.xml Mon Mar 9 12:23:39 2009
>> @@ -417,7 +417,6 @@
>>
>> org.apache.maven.plugins
>> maven-assembly-plugin
>> - 2.1
>>
>>
>> unix-bin
>> @@ -589,7 +588,6 @@
>>
>> org.apache.maven.plugins
>> maven-assembly-plugin
>> - 2.1
>>
>>
>> unix-src
>>
>> Modified: camel/trunk/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/camel/trunk/pom.xml?rev=751659&r1=751658&r2=751659&view=diff
>>
>> ==
>> --- camel/trunk/pom.xml (original)
>> +++ camel/trunk/pom.xml Mon Mar 9 12:23:39 2009
>> @@ -977,6 +977,11 @@
>>
>>
>>
>> + org.apache.maven.plugins
>> + maven-assembly-plugin
>> + 2.1
>> +
>> +
>> org.apache.cxf
>> cxf-codegen-plugin
>> ${cxf-version}
>>
>>
>>
>
>
> --
> Cheers,
> Jon
>
> http://janstey.blogspot.com/
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Camel 2.0 API - Discuss - Exchange.getException() change to Exception
Hi The Exchange.getException() method is based on Throwable. I think this is wrong and we should change it to Exception. We should let the java.lang.Error left alone to the JDK itself to handle it, so end users cannot try .. catch(Throwable) and thus hide java.lang.OutOfMemoryError etc. The camel-core has this issue as well with catching Throwables around its code. It should only catch Exception. And I am prepareing a patch to fix this. Any objections to change it to Exception and fix the camel-core? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Tue, Mar 10, 2009 at 2:39 AM, orton wrote:
>
> Hi,
>
> I've been trying to use the MINA component for UDP data delivery but have
> been having some issues and was wondering if anyone else has seen this
> error.
>
> I'm sending small packets (<100Bytes) as fast as I can (sequentially from a
> single client) but after around 35,000 packets sent, the Camel client
> abruptly stops without any errors/exceptions. I first tried this with the
> 1.6 release and saw this problem and recently downloaded and compiled the
> 2.0 core and components but still have the same issue. When I use MINA with
> TCP, I don't have this problem...
>
> Here's what I have for code:
> -
>
> public void init( String serverIP, int serverPort ) {
> uri = "mina:udp://" + serverIP + ":" + serverPort +
> "?sync=false";
> System.out.println("Camel URI: " + uri);
> }
>
> public void sendMessages(int numOfMessages, int messageSize) throws
> Exception {
>
> CamelContext context = new DefaultCamelContext();
> context.start();
>
> Endpoint endpoint = context.getEndpoint(uri);
> Exchange exchange =
> endpoint.createExchange(ExchangePattern.InOnly);
> Producer producer = endpoint.createProducer();
> producer.start();
>
> for (int i = 0; i < numOfMessages; i++) {
> String s = "[Publisher]: Test Body Message: " + i;
> exchange.getIn().setBody(s);
> producer.process(exchange);
> }
> producer.stop();
> }
>
>
> I looked through various forums and saw some memory leak issues, but wasn't
> sure if this is related?
>
> If anyone can help, would be much appreciated!!
What version of Camel and Mina are you using?
Mina is in the works of doing a Mina 2.0 that might be much better.
When its release we will upgrade it in Camel 2.0 as well.
Yes the memory leaks is interresting? Where did you find them?
And whats the relevanse of you test? Sending 65.000 udp packages to yourself?
Are you using Camel to be the Mina server as well? Or do you send it
to another JVM?
Using TCP that works. Are you using the exact same sample but just
change udp to tcp in the endpoint URI?
>
> Orton
> --
> View this message in context:
> http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22426433.html
> Sent from the Camel - Development (activemq) mailing list archive at
> Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
BTW I think I have seen some UDP issue with camel-mina about
acquiring/releasing mina byte buffer.
Damm that API is not so easy to work with - should be improved in mina 2.0
So it could relate to your issue as well
On Tue, Mar 10, 2009 at 8:43 AM, Claus Ibsen wrote:
> On Tue, Mar 10, 2009 at 2:39 AM, orton wrote:
>>
>> Hi,
>>
>> I've been trying to use the MINA component for UDP data delivery but have
>> been having some issues and was wondering if anyone else has seen this
>> error.
>>
>> I'm sending small packets (<100Bytes) as fast as I can (sequentially from a
>> single client) but after around 35,000 packets sent, the Camel client
>> abruptly stops without any errors/exceptions. I first tried this with the
>> 1.6 release and saw this problem and recently downloaded and compiled the
>> 2.0 core and components but still have the same issue. When I use MINA with
>> TCP, I don't have this problem...
>>
>> Here's what I have for code:
>> -
>>
>> public void init( String serverIP, int serverPort ) {
>> uri = "mina:udp://" + serverIP + ":" + serverPort +
>> "?sync=false";
>> System.out.println("Camel URI: " + uri);
>> }
>>
>> public void sendMessages(int numOfMessages, int messageSize) throws
>> Exception {
>>
>> CamelContext context = new DefaultCamelContext();
>> context.start();
>>
>> Endpoint endpoint = context.getEndpoint(uri);
>> Exchange exchange =
>> endpoint.createExchange(ExchangePattern.InOnly);
>> Producer producer = endpoint.createProducer();
>> producer.start();
>>
>> for (int i = 0; i < numOfMessages; i++) {
>> String s = "[Publisher]: Test Body Message: " + i;
>> exchange.getIn().setBody(s);
>> producer.process(exchange);
>> }
>> producer.stop();
>> }
>>
>>
>> I looked through various forums and saw some memory leak issues, but wasn't
>> sure if this is related?
>>
>> If anyone can help, would be much appreciated!!
> What version of Camel and Mina are you using?
>
> Mina is in the works of doing a Mina 2.0 that might be much better.
> When its release we will upgrade it in Camel 2.0 as well.
>
> Yes the memory leaks is interresting? Where did you find them?
>
> And whats the relevanse of you test? Sending 65.000 udp packages to yourself?
> Are you using Camel to be the Mina server as well? Or do you send it
> to another JVM?
>
> Using TCP that works. Are you using the exact same sample but just
> change udp to tcp in the endpoint URI?
>
>
>
>>
>> Orton
>> --
>> View this message in context:
>> http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22426433.html
>> Sent from the Camel - Development (activemq) mailing list archive at
>> Nabble.com.
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
Hi
I have commited a fix to UPD in camel-mina on both 1.6.1 and 2.0
https://issues.apache.org/activemq/browse/CAMEL-1444
Could you try it out on your system?
2.0-SNAPSHOT is automatic build and published at apache maven snapshot repo.
http://camel.apache.org/download.html
I cant remember if 1.6.1-SNAPSHOT also is, it kinda got lost on in TLP
move recently.
On Tue, Mar 10, 2009 at 11:24 AM, Claus Ibsen wrote:
> BTW I think I have seen some UDP issue with camel-mina about
> acquiring/releasing mina byte buffer.
> Damm that API is not so easy to work with - should be improved in mina 2.0
>
> So it could relate to your issue as well
>
> On Tue, Mar 10, 2009 at 8:43 AM, Claus Ibsen wrote:
>> On Tue, Mar 10, 2009 at 2:39 AM, orton wrote:
>>>
>>> Hi,
>>>
>>> I've been trying to use the MINA component for UDP data delivery but have
>>> been having some issues and was wondering if anyone else has seen this
>>> error.
>>>
>>> I'm sending small packets (<100Bytes) as fast as I can (sequentially from a
>>> single client) but after around 35,000 packets sent, the Camel client
>>> abruptly stops without any errors/exceptions. I first tried this with the
>>> 1.6 release and saw this problem and recently downloaded and compiled the
>>> 2.0 core and components but still have the same issue. When I use MINA with
>>> TCP, I don't have this problem...
>>>
>>> Here's what I have for code:
>>> -
>>>
>>> public void init( String serverIP, int serverPort ) {
>>> uri = "mina:udp://" + serverIP + ":" + serverPort +
>>> "?sync=false";
>>> System.out.println("Camel URI: " + uri);
>>> }
>>>
>>> public void sendMessages(int numOfMessages, int messageSize) throws
>>> Exception {
>>>
>>> CamelContext context = new DefaultCamelContext();
>>> context.start();
>>>
>>> Endpoint endpoint = context.getEndpoint(uri);
>>> Exchange exchange =
>>> endpoint.createExchange(ExchangePattern.InOnly);
>>> Producer producer = endpoint.createProducer();
>>> producer.start();
>>>
>>> for (int i = 0; i < numOfMessages; i++) {
>>> String s = "[Publisher]: Test Body Message: " + i;
>>> exchange.getIn().setBody(s);
>>> producer.process(exchange);
>>> }
>>> producer.stop();
>>> }
>>>
>>>
>>> I looked through various forums and saw some memory leak issues, but wasn't
>>> sure if this is related?
>>>
>>> If anyone can help, would be much appreciated!!
>> What version of Camel and Mina are you using?
>>
>> Mina is in the works of doing a Mina 2.0 that might be much better.
>> When its release we will upgrade it in Camel 2.0 as well.
>>
>> Yes the memory leaks is interresting? Where did you find them?
>>
>> And whats the relevanse of you test? Sending 65.000 udp packages to yourself?
>> Are you using Camel to be the Mina server as well? Or do you send it
>> to another JVM?
>>
>> Using TCP that works. Are you using the exact same sample but just
>> change udp to tcp in the endpoint URI?
>>
>>
>>
>>>
>>> Orton
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22426433.html
>>> Sent from the Camel - Development (activemq) mailing list archive at
>>> Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Tue, Mar 10, 2009 at 2:19 PM, orton wrote: > >> What version of Camel and Mina are you using? > > I tried it out on the Camel 1.6 bin release and I compiled the Camel 2.0 > snapshot in svn and both appeared to have the same problem... mina-core for > both appear to be 1.1.7 > >> Mina is in the works of doing a Mina 2.0 that might be much better. >> When its release we will upgrade it in Camel 2.0 as well. > >> Yes the memory leaks is interresting? Where did you find them? > > I only saw some references in past forums and some of my co-workers have > mentioned them to me also, will look for more details and send to you > >> And whats the relevanse of you test? Sending 65.000 udp packages to >> yourself? >> Are you using Camel to be the Mina server as well? Or do you send it >> to another JVM? > > We're trying to do some simple stress and overhead testing on the Camel > components... We really like what you guys have done with it and find the > patterns extremely useful. We want to see how suitable it is for > applications with high throughput, low latency needs and what the extra cost > for using Camel is. I have separate servers in different VM's but on the > same host for now. > > >> Using TCP that works. Are you using the exact same sample but just >> change udp to tcp in the endpoint URI? > > I send the exact same samples with UDP and TCP... Just tried the multicast > one and it gives me the same issue as the UDP one... Thanks for the info. Have you seen my mails about commit a fix? Could you try again with a version of Camel that has the fix build. The problem would probably not manifest itself if you use 2 separate JVM's - 1 for server, 1 for client > > > -- > View this message in context: > http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22434032.html > Sent from the Camel - Development (activemq) mailing list archive at > Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Tue, Mar 10, 2009 at 2:25 PM, Claus Ibsen wrote: > On Tue, Mar 10, 2009 at 2:19 PM, orton wrote: >> >>> What version of Camel and Mina are you using? >> >> I tried it out on the Camel 1.6 bin release and I compiled the Camel 2.0 >> snapshot in svn and both appeared to have the same problem... mina-core for >> both appear to be 1.1.7 >> >>> Mina is in the works of doing a Mina 2.0 that might be much better. >>> When its release we will upgrade it in Camel 2.0 as well. >> >>> Yes the memory leaks is interresting? Where did you find them? >> >> I only saw some references in past forums and some of my co-workers have >> mentioned them to me also, will look for more details and send to you >> >>> And whats the relevanse of you test? Sending 65.000 udp packages to >>> yourself? >>> Are you using Camel to be the Mina server as well? Or do you send it >>> to another JVM? >> >> We're trying to do some simple stress and overhead testing on the Camel >> components... We really like what you guys have done with it and find the >> patterns extremely useful. We want to see how suitable it is for >> applications with high throughput, low latency needs and what the extra cost >> for using Camel is. I have separate servers in different VM's but on the >> same host for now. >> >> >>> Using TCP that works. Are you using the exact same sample but just >>> change udp to tcp in the endpoint URI? >> >> I send the exact same samples with UDP and TCP... Just tried the multicast >> one and it gives me the same issue as the UDP one... > Thanks for the info. > > Have you seen my mails about commit a fix? Could you try again with a > version of Camel that has the fix build. > > The problem would probably not manifest itself if you use 2 separate > JVM's - 1 for server, 1 for client Oh if you do NOT use the transferExchange=true option. eg if you send regular payload with Camel 1.6.0. But yet again would be nice if you try the comitted fix. > > > >> >> >> -- >> View this message in context: >> http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22434032.html >> Sent from the Camel - Development (activemq) mailing list archive at >> Nabble.com. >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Tue, Mar 10, 2009 at 2:45 PM, orton wrote: > > > ≥Oh if you do NOT use the transferExchange=true option. eg if you send > ≥regular payload with Camel 1.6.0. > > ≥But yet again would be nice if you try the comitted fix. > > Hi Claus, am updating my Camel 2.0 code from repository and compiling now. > > Can you explain the transferExchange comment some more? Sorry, still a > little new to Camel and not sure how that option affects things? It marshal the entire Exchange, eg the container object in Camel used when routing messages. Its an option to use MINA as a kind of bridge between camel instances. So you can keep headers, properties etc. when you send the Exchange using Mina. Normally you only send the payload itself, eg the Body. So when the Exchange is assembled on the other side it could contain stuff mina there could get confused over. But I really doubt it. I put my rely on the fix. But could you test with transferExchange=true and again with it =false > > Thanks again!! > > -- > View this message in context: > http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22434468.html > Sent from the Camel - Development (activemq) mailing list archive at > Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
Hi Can you create a zip with a sample project that demonstrates this issue? I would like to take a look. Its interresting that creating a new producer once in a while resolves it. eg you get a brand new MINA session to work with. On Tue, Mar 10, 2009 at 8:01 PM, orton wrote: > > One more thing... > > Right now, I'm just catching all Exceptions and printing them out. When the > component stops sending, usually no exceptions are thrown... Not sure if > they are getting swallowed up somewhere lower. > > However, one time I ran it, for some reason I did get this: > > Exception caught: Could not write body on the exchange: Exchange[Message: > [Publisher]: Test Body Message: 34535] > org.apache.camel.CamelExchangeException: Could not write body on the > exchange: Exchange[Message: [Publisher]: Test Body Message: 34535] > at > org.apache.camel.component.mina.MinaHelper.writeBody(MinaHelper.java:47) > at > org.apache.camel.component.mina.MinaProducer.process(MinaProducer.java:99) > at > edu.mit.ll.test.clients.UDPCamelClient.sendMessages(UDPCamelClient.java:70) > at > edu.mit.ll.test.clients.UDPCamelClient.main(UDPCamelClient.java:84) > -- > View this message in context: > http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22441278.html > Sent from the Camel - Development (activemq) mailing list archive at > Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 API - Discuss - Exchange.getException() change to Exception
On Wed, Mar 11, 2009 at 12:20 PM, James Strachan wrote: > 2009/3/10 Claus Ibsen : >> Hi >> >> The Exchange.getException() method is based on Throwable. I think this >> is wrong and we should change it to Exception. >> >> We should let the java.lang.Error left alone to the JDK itself to >> handle it, so end users cannot try .. catch(Throwable) and thus >> hide java.lang.OutOfMemoryError etc. >> >> The camel-core has this issue as well with catching Throwables around >> its code. It should only catch Exception. >> And I am prepareing a patch to fix this. >> >> Any objections to change it to Exception and fix the camel-core? > > Sounds fine to me. So long as we can catch programming bugs (e.g. > NullPointerException in some custom processor code) that should be > fine. ? NPE is a RuntimeException so it would be just as it always have been. Its just that we let java.lang.Error to the JDK itself, so when it reports OutOfMemoryError, and that infinite stack trace error and what else then Camel do NOT catch it. > > -- > James > --- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 API - Discuss - Exchange.getException() change to Exception
Committed revision 752465. On Wed, Mar 11, 2009 at 12:58 PM, James Strachan wrote: > 2009/3/11 Claus Ibsen : >> On Wed, Mar 11, 2009 at 12:20 PM, James Strachan >> wrote: >>> 2009/3/10 Claus Ibsen : >>>> Hi >>>> >>>> The Exchange.getException() method is based on Throwable. I think this >>>> is wrong and we should change it to Exception. >>>> >>>> We should let the java.lang.Error left alone to the JDK itself to >>>> handle it, so end users cannot try .. catch(Throwable) and thus >>>> hide java.lang.OutOfMemoryError etc. >>>> >>>> The camel-core has this issue as well with catching Throwables around >>>> its code. It should only catch Exception. >>>> And I am prepareing a patch to fix this. >>>> >>>> Any objections to change it to Exception and fix the camel-core? >>> >>> Sounds fine to me. So long as we can catch programming bugs (e.g. >>> NullPointerException in some custom processor code) that should be >>> fine. >> ? NPE is a RuntimeException so it would be just as it always have been. >> >> Its just that we let java.lang.Error to the JDK itself, so when it >> reports OutOfMemoryError, and that infinite stack trace error and what >> else then Camel do NOT catch it. > > Yes - sorry thats what I meant. That checked & runtime exceptions > should be catchable - but errors like OOM shouldnt. > > -- > James > --- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0
Hi Hadrian will build the 2.0M1 = milestone 1 later today. Then we would love to get as much community feedback. I would then guess that we can build the RC1 in approx 3-4 weeks. And if all is not to bad then it should be out in about 1 month. We could probably do it faster if there is a certain need to release it earlier. However since this is the first next major release I would like to reserve more time to fiddle/change the API at will. Otherwise get out a release with some flaws in the API and we then have to wait for 3.0 to fix it. The only big outstanding is about the default error handler. I will start a new mail on that later. On Wed, Mar 11, 2009 at 3:27 PM, William Tam wrote: > Hi all, > > Any thought on the time frame of 2.0 release? > > Cheers, > William > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
Hi Just for the good sake. We have identified an issue and fixed it in camel-mina on trunk. Thanks to Orton for providing a sample case that surfaced the issue. Now it works like a charm and doesnt stall using UDP. On Wed, Mar 11, 2009 at 10:05 AM, Claus Ibsen wrote: > Hi > > Can you create a zip with a sample project that demonstrates this issue? > I would like to take a look. > > Its interresting that creating a new producer once in a while resolves > it. eg you get a brand new MINA session to work with. > > > On Tue, Mar 10, 2009 at 8:01 PM, orton wrote: >> >> One more thing... >> >> Right now, I'm just catching all Exceptions and printing them out. When the >> component stops sending, usually no exceptions are thrown... Not sure if >> they are getting swallowed up somewhere lower. >> >> However, one time I ran it, for some reason I did get this: >> >> Exception caught: Could not write body on the exchange: Exchange[Message: >> [Publisher]: Test Body Message: 34535] >> org.apache.camel.CamelExchangeException: Could not write body on the >> exchange: Exchange[Message: [Publisher]: Test Body Message: 34535] >> at >> org.apache.camel.component.mina.MinaHelper.writeBody(MinaHelper.java:47) >> at >> org.apache.camel.component.mina.MinaProducer.process(MinaProducer.java:99) >> at >> edu.mit.ll.test.clients.UDPCamelClient.sendMessages(UDPCamelClient.java:70) >> at >> edu.mit.ll.test.clients.UDPCamelClient.main(UDPCamelClient.java:84) >> -- >> View this message in context: >> http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22441278.html >> Sent from the Camel - Development (activemq) mailing list archive at >> Nabble.com. >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 1.6/2.0 MINA UDP issue
On Thu, Mar 12, 2009 at 5:31 PM, orton wrote: > > Hi Again, > > Thanks Claus for the fix! That resolved the issue I was having with the MINA > sender and I can run it a lot longer. > > Unfortunately :( however, I get this problem now after many more messages: > > Messages Sent: [Publisher]: Test Body Message: 2366999 > Messages Sent: [Publisher]: Test Body Message: 2367999 > Messages Sent: [Publisher]: Test Body Message: 2368999 > Exception caught: Cannot write body on the exchange: Exchange[Message: > [Publisher]: Test Body Message: 2369836] > org.apache.camel.CamelExchangeException: Cannot write body on the exchange: > Exchange[Message: [Publisher]: Test Body Message: 2369836] > at > org.apache.camel.component.mina.MinaHelper.writeBody(MinaHelper.java:52) > at > org.apache.camel.component.mina.MinaProducer.process(MinaProducer.java:99) > at > edu.mit.ll.test.clients.UDPCamelClient.sendMessages(UDPCamelClient.java:70) > at edu.mit.ll.test.clients.UDPCamelClient.main(UDPCamelClient.java:133) > > In this case, I'm sending 30 Byte messages one after another as fast as I > can and it gets to 2.3 million messages or so. I'm not sure if I'm running > out of memory (perhaps the garbage collection is cleaning up things fast > enough)? > > Thoughts? Thanks again! You should just catch the exception and continue with sending. It should be able to send the rest. Eg you can do a retry to send it again. You are using UDP so the QoS is not as high as TCP. > > Claus Ibsen-2 wrote: >> >> Hi >> >> Just for the good sake. We have identified an issue and fixed it in >> camel-mina on trunk. >> >> Thanks to Orton for providing a sample case that surfaced the issue. >> Now it works like a charm and doesnt stall using UDP. >> >> >> On Wed, Mar 11, 2009 at 10:05 AM, Claus Ibsen >> wrote: >>> Hi >>> >>> Can you create a zip with a sample project that demonstrates this issue? >>> I would like to take a look. >>> >>> Its interresting that creating a new producer once in a while resolves >>> it. eg you get a brand new MINA session to work with. >>> >>> >>> On Tue, Mar 10, 2009 at 8:01 PM, orton wrote: >>>> >>>> One more thing... >>>> >>>> Right now, I'm just catching all Exceptions and printing them out. When >>>> the >>>> component stops sending, usually no exceptions are thrown... Not sure if >>>> they are getting swallowed up somewhere lower. >>>> >>>> However, one time I ran it, for some reason I did get this: >>>> >>>> Exception caught: Could not write body on the exchange: >>>> Exchange[Message: >>>> [Publisher]: Test Body Message: 34535] >>>> org.apache.camel.CamelExchangeException: Could not write body on the >>>> exchange: Exchange[Message: [Publisher]: Test Body Message: 34535] >>>> at >>>> org.apache.camel.component.mina.MinaHelper.writeBody(MinaHelper.java:47) >>>> at >>>> org.apache.camel.component.mina.MinaProducer.process(MinaProducer.java:99) >>>> at >>>> edu.mit.ll.test.clients.UDPCamelClient.sendMessages(UDPCamelClient.java:70) >>>> at >>>> edu.mit.ll.test.clients.UDPCamelClient.main(UDPCamelClient.java:84) >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22441278.html >>>> Sent from the Camel - Development (activemq) mailing list archive at >>>> Nabble.com. >>>> >>>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> Apache Camel Committer >>> >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> >> > > -- > View this message in context: > http://www.nabble.com/Camel-1.6-2.0-MINA-UDP-issue-tp22426433p22479515.html > Sent from the Camel - Development (activemq) mailing list archive at > Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: [CONF] Apache Camel: Stream caching (page created)
Gert
Do you mind documenting how it can be configured in Spring XML also?
And please add a link to it from [Dead Letter Channel], in see also
and maybe a little {tip:}
On Thu, Mar 12, 2009 at 10:21 PM, wrote:
> Page Created : CAMEL : Stream caching
>
> Stream caching has been created by Gert Vanthienen (Mar 12, 2009).
>
> Content:
>
> Stream caching
>
> While stream types (like StreamSource, InputStream and Reader) are commonly
> used in messaging for performance reasons, they also have an important
> drawback: they can only be read once. In order to be able to work with
> message content multiple times, the stream needs to be cached.
>
> By default, streams are caching in memory. In Camel 2.0, large stream
> messages (over 64 Kb) will be cached in a temporary file instead – Camel
> itself will handle deleting the temporary file once the cached stream is no
> longer necessary.
>
> Using stream caching
>
> Implicitly enabled for multicast and dead letter channel
>
> Some EIPs require that the message content can be read multiple times.
> Stream caching will be automatically enabled when using these EIPs in your
> routes:
>
> Multicast will implicitly cache streams to ensure that all the endpoints can
> access the message content
> Dead Letter Channel uses stream caching to ensure that the message content
> can actually be read again when redelivering a message
>
> Explicitly configure stream caching
>
> In Apache Camel, you can explicitly enable stream caching in a route with
> the streamCaching DSL method:
>
> from("direct:a").streamCaching().to("mock:a");
>
> You can also enable it for all the routes in routebuilder:
>
> streamCaching();
> from("direct:b").to("mock:b");
>
> How it works?
>
> In order to determine if a type requires caching, we leverage the type
> converter feature. Any type that requires stream caching can be converted
> into an org.apache.camel.StreamCache instance.
>
> Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) -
> Bug/feature request
>
> Unsubscribe or edit your notifications preferences
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [VOTE] Release Apache Camel 2.0-M1
+1 On Thu, Mar 12, 2009 at 10:53 PM, Hadrian Zbarcea wrote: > Resending to the right list. Sorry for the duplicate post. > Hadrian > > On Mar 12, 2009, at 5:51 PM, Hadrian Zbarcea wrote: > >> The first milestone build of Camel 2.0, apache-camel-2.0-M1, is out with >> an absolute record 368 new features, improvements and bug fixes. >> With the exception of very late additions that we'll iron out in the next >> release 2.0-M1 is impressively stable. Most of the API changes from the 1.x >> line are already made, so we do not anticipate significant API changes on >> the 2.x line from here on. >> >> Please find the distro here: >> http://people.apache.org/~hadrian/apache-camel-2.0-M1/maven2/ >> >> The tarballs are here >> >> http://people.apache.org/~hadrian/apache-camel-2.0-M1/maven2/org/apache/camel/apache-camel/2.0-M1/ >> >> Please vote to approve this release binary. While only the PMC votes are >> binding we encourage all community members to try it out and cast their >> vote. Your opinion is highly valued and appreciated! >> >> [ ] +1 Release the binary as Apache Camel 2.0-M1 >> [ ] -1 Veto the release (provide specific comments) >> Vote is open for 72 hours. >> >> Here's my +1 >> Hadrian > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 API - Proposal of new support package to fix bad tangles
On Fri, Mar 13, 2009 at 12:22 PM, James Strachan wrote: > Cool - I was gonna suggest putting some of the adapter classes into > the SPI package as a place for folks extending Camel to put things? No > biggie though, seems the issue is resolved now. Yeah they are in util now. Not the best "home" I think. But the response didnt come in, in fact one wasnt in favor of a new package. However I would still consider a support package for Camel related types. And a plain util for JDK core type helpers, such as String manipulation, File IO, and whatelse. > > 2009/3/8 Claus Ibsen : >> Hi >> >> I fixed the package tangle so we keep the current package structure as is. >> >> On Mon, Mar 2, 2009 at 6:42 AM, Claus Ibsen wrote: >>> Hi >>> >>> I am using Structure 101 to view the Camel API and have found some hot >>> spots to clear. >>> - DataFormatType was implementing DataFormat (fixed) >>> - SPI had a bad tangle (fixed) >>> - Language had a bad tangle (fixed) >>> >>> However we do have some support classes (abstract base classes) in >>> camel.impl that are reused outside .impl. >>> Currently its mostly the ExpressionAdapter to assist impl. Expression. >>> >>> I would like to propose a new package in Camel for such common >>> classes. As the util package is a kinda mixed up package currently >>> org.apache.camel.support >>> >>> And we can move: >>> ExpressionAdapter >>> ExpressionSupport >>> PredicateSupport >>> >>> That are most likely to be used outside camel.impl in eg. processor, >>> language, builder and other packages where Expression/Preidcates is >>> also highly used. >>> >>> Any thoughts? >>> >>> >>> -- >>> Claus Ibsen >>> Apache Camel Committer >>> >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> > > > > -- > James > --- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel 2.0 - About type converter degrade performance issue
Hi In Camel 1.6.0 and 2.0 we have had a performance issue that could seriously degrade performance by x2-x10 when you did stress test by sending > 1000 msg/sec. The cause of this is the TypeConverter that will throw a NoSuchTypeConverterExists when Camel cannot converter to the desired type. We do this internally in Camel in some areas of the code where we will ignore this exception and eg. continue. We did a fix for this performance issue in the stream cache but this was just a fix in once place. Lately this issue surfaced again in camel-mina when using UDP. So I have been experimenting with doing a fix once for all. I suggest to: - add 2 new methods to TypeConverter that returns *null* instread of throwing the NoSuchTypeConverterExists exception. I have named them: tryConvertTo. But maybe there is a better name? - add 1 new method on Message to get the body using the try convert to instead. I have named the method: tryGetBody(T). But maybe there is a better name? - Use tryGetBody internally in Camel where we today do try .. catch(NoSuchTypeConverterExists) - Then we can expose the regular getBody(T) for the end users, and let it act as it does today by throwing the exception - We can also optimize the DefaultTypeConverter to let it look in the miss cache first if it have tried to convert this before but could not If the tryGetBody, tryConvertTo are you to your liking we can also do: - add a new method to TypeConvert: boolean canConvertTo(T, value) - add a new method to Message: boolean canGetBody(T, value) - then use that method as guard before doing the regular convertTo/getBody But this requires that you always use this as guard, to be sure that the NoSuchTypeConverterExists is not thrown And it also requires that we use the miss cache to not do 2x convertions, 1 for the boolean check, and then 1 for the actual convertion It also requires that the body can be converted multiple times. Whether solution 1 or 2 we also need to check the other components and fix it internally as well, so we dont have a situation like mina with UDP that was affected by the performance drawback. In my experiment I have the first solution up and running. Any thoughts? I will create a JIRA ticket for this one as well so we wont forget it. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Camel - JMXConnector Thread
Hi
I was working on CAMEL-1462 and I was wondering why the
JMXConnectorThread created in
DefaultInstrumentationAgent#createJmxConnector is not set as daemon?
eg in the code below there should be a: connector.setDaemon(true)
// Start the connector server asynchronously (in a separate thread).
Thread connectorThread = new Thread() {
public void run() {
try {
cs.start();
} catch (IOException ioe) {
LOG.warn("Could not start JMXConnector thread.", ioe);
}
}
};
connectorThread.setName("Camel JMX Connector Thread [" + url + "]");
connectorThread.start();
LOG.info("JMX Connector thread started and listening at: " + url);
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel - JMXConnector Thread
Hi
Another minor note.
We might wanna make sure the threads we create in Camel is using the
same API so end users can be 100% in control of thread creation.
Eg in WebSphere to use its WorkManager API to control threads.
So maybe some ExectutorService is needed as well? Just wondering /
thinking loud.
On Tue, Mar 17, 2009 at 10:24 AM, Claus Ibsen wrote:
> Hi
>
> I was working on CAMEL-1462 and I was wondering why the
> JMXConnectorThread created in
> DefaultInstrumentationAgent#createJmxConnector is not set as daemon?
>
> eg in the code below there should be a: connector.setDaemon(true)
>
>
> // Start the connector server asynchronously (in a separate thread).
> Thread connectorThread = new Thread() {
> public void run() {
> try {
> cs.start();
> } catch (IOException ioe) {
> LOG.warn("Could not start JMXConnector thread.", ioe);
> }
> }
> };
> connectorThread.setName("Camel JMX Connector Thread [" + url + "]");
> connectorThread.start();
> LOG.info("JMX Connector thread started and listening at: " + url);
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - About type converter degrade performance issue
Hi Any thoughts on this one? It all boils down to a suggestion to add 1 methods to the org.apache.camel.Message API new method: - tryGetBody(Class type) or overload existing with a boolean to indicate ignore exception and return null - getBody(Class, true) The same applies for the org.apache.camel.spi.TypeConverter interface as we need a method on the line as above new method: - tryConvertTo(Class type) or overload existing with a boolean to indicate ignore exception and return null - convertTo(Class, true) The boolean thing is maybe a nice one as it have the same method name. On Mon, Mar 16, 2009 at 7:32 AM, Claus Ibsen wrote: > Hi > > In Camel 1.6.0 and 2.0 we have had a performance issue that could > seriously degrade performance by x2-x10 when you did stress test by > sending > 1000 msg/sec. > > The cause of this is the TypeConverter that will throw a > NoSuchTypeConverterExists when Camel cannot converter to the desired > type. > We do this internally in Camel in some areas of the code where we will > ignore this exception and eg. continue. > > We did a fix for this performance issue in the stream cache but this > was just a fix in once place. Lately this issue surfaced again in > camel-mina when using UDP. > > So I have been experimenting with doing a fix once for all. > > I suggest to: > - add 2 new methods to TypeConverter that returns *null* instread of > throwing the NoSuchTypeConverterExists exception. > I have named them: tryConvertTo. But maybe there is a better name? > - add 1 new method on Message to get the body using the try convert to > instead. > I have named the method: tryGetBody(T). But maybe there is a better name? > - Use tryGetBody internally in Camel where we today do try .. > catch(NoSuchTypeConverterExists) > - Then we can expose the regular getBody(T) for the end users, and let > it act as it does today by throwing the exception > - We can also optimize the DefaultTypeConverter to let it look in the > miss cache first if it have tried to convert this before but could not > > If the tryGetBody, tryConvertTo are you to your liking we can also do: > - add a new method to TypeConvert: boolean canConvertTo(T, value) > - add a new method to Message: boolean canGetBody(T, value) > - then use that method as guard before doing the regular convertTo/getBody > But this requires that you always use this as guard, to be sure that > the NoSuchTypeConverterExists is not thrown > And it also requires that we use the miss cache to not do 2x > convertions, 1 for the boolean check, and then 1 for the actual > convertion > It also requires that the body can be converted multiple times. > > Whether solution 1 or 2 we also need to check the other components and > fix it internally as well, so we dont have a situation like mina with > UDP that was affected by the performance drawback. > > In my experiment I have the first solution up and running. > > Any thoughts? > > I will create a JIRA ticket for this one as well so we wont forget it. > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
