Re: XStream CannotResolveClassException
I'm not sure how did you deploy your camel application.
It looks like camel-xstream have some trouble to mapping the alias this
time.
Can you try to put the aliases like this ?
On 5/9/12 11:33 PM, eismeraldo wrote:
Hi
Im using camel version 2.9.2. with spring
I try to unmarshal the message1.xml from the example by mvn
archetype:generate #150.
the spring/camel-context.xml looks like
---
http://camel.apache.org/schema/spring";>
---
and the bean:
@XStreamAlias("person")
public class PersonBom {
@XStreamAlias("city")
private String m_city;
@XStreamAlias("firstName")
private String m_firstName;
@XStreamAlias("lastName")
private String m_lastName;
with standard getter and setter
The the system throws the exception:
[l) thread #1 - file://src/data] DefaultErrorHandlerERROR Failed
delivery for (MessageId: ID-CHM05048977-50590-1336575506837-0-1 on
ExchangeId: ID-CHM05048977-50590-1336575506837-0-2). Exhausted after
delivery attempt: 1 caught:
com.thoughtworks.xstream.mapper.CannotResolveClassException: beans
com.thoughtworks.xstream.mapper.CannotResolveClassException: beans
at
com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:56)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:55)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:79)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:74)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:45)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.core.util.HierarchicalStreams.readClassType(HierarchicalStreams.java:29)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:133)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1035)[xstream-1.4.1.jar:]
at
com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1007)[xstream-1.4.1.jar:]
at
org.apache.camel.dataformat.xstream.AbstractXStreamWrapper.unmarshal(AbstractXStreamWrapper.java:211)[camel-xstream-2.9.2.jar:2.9.2]
at
org.apache.camel.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:58)[camel-core-2.9.2.jar:2.9.2]
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[camel-core-2.9.2.jar:2.9.2]
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)[camel-core-2.9.2.jar:2.9.2]
at
org.apache.camel
Re: diagram generator
can you retry? note: using site (or pre-site phase) you need target/classes to exist so run package before - Romain 2012/5/11 Nestor Urquiza > And in my real project I get a weird behavior when I try to use package > instead of input: > > > [INFO] One or more required plugin parameters are invalid/missing for > 'diagram-generator:diagram' > > [0] Inside the definition for plugin 'diagram-generator-maven-plugin' > specify the following: > > > ... > VALUE > > > -OR- > > on the command line, specify: '-Ddiagram.input=VALUE' > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5701843.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: CXF webservice asyn
On 11/05/12 04:05, Willem Jiang wrote: As CXF doesn't provides the async invocation client for JAXRS, current camel-cxfrs doesn't have async producer support. Indeed. Will be coming later on after JAX-RS 2.0 is out, still some time away though, so if it were critical to offer such a support on the client side then of course we'd provide it earlier... Sergey The document is updated. On 5/10/12 10:46 PM, Claus Ibsen wrote: On Thu, May 10, 2012 at 4:11 PM, Willem Jiang wrote: Hi Current camel-cxfrs supports the async out of box. Please check the code of CxfRsInvoker, it leverages the continuation to invoke the async processors. Willem, can you update the Camel docs at http://camel.apache.org/asynchronous-routing-engine.html To include the producer for cxfrs. I am not sure which Camel version that happened. On 5/9/12 4:09 PM, Claus Ibsen wrote: Hi Are you using the CXF-RS producer from Camel, eg you do from file to cxfrs The cxfrs currently doesn't support the async routing engine by nature http://camel.apache.org/asynchronous-routing-engine.html And therefore it blocks while waiting for the reply message. Frankly it ought to be possible, but I think we need to improve the camel-cxfrs code to support that. If it did, then no threads is blocking, and the file consumer thread would be able to pickup the next file while the previous CXFRS is in progress. As mention you can use the threads EIP in Camel to force async behavior as well. On Wed, May 9, 2012 at 6:05 AM, Deepthi wrote: Hi Yogesh, Thanks for ur response. Yes, I am looking for a thread pool for from point as well. Appreciate your help Thanks -- View this message in context: http://camel.465427.n5.nabble.com/CXF-webservice-asyn-tp5695918p5696434.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Willem -- CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Web: http://www.fusesource.com Blog: http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang
Re: diagram generator
Latest code built and still I get the same for my real project ( seems to be mandatory) however in the pet project I shared with you it works partially as it generates only one of the two routes expected. You can check it out yourself from http://nestorurquiza.googlecode.com/svn/trunk/camelinaction-based-samples/chapter2/cbr -- View this message in context: http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5702944.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: diagram generator
Input IS mandatory. Not sure what it mean you expected Le 11 mai 2012 14:45, "Nestor Urquiza" a écrit : > Latest code built and still I get the same for my real project ( > seems to be mandatory) however in the pet project I shared with you it > works > partially as it generates only one of the two routes expected. You can > check > it out yourself from > > http://nestorurquiza.googlecode.com/svn/trunk/camelinaction-based-samples/chapter2/cbr > > -- > View this message in context: > http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5702944.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: diagram generator
Not sure why it works with and not in the example I shared with you but in any case certainly when I changed to it did generate diagrams for the two classes inside the package. And yet in my real project there is something going on, any idea why? [INFO] [ERROR] FATAL ERROR [INFO] [INFO] can't find route inside com.nestorurquiza.orchestration.camel.route package. [INFO] [INFO] Trace fr.rmannibucau.loader.spi.DiagramGeneratorRuntimeException: can't find route inside com.nestorurquiza.orchestration.camel.route package. at fr.rmannibucau.camel.loader.CamelLoader.camelContextToDiagram(CamelLoader.java:147) at fr.rmannibucau.camel.loader.CamelLoader.load(CamelLoader.java:41) at fr.rmannibucau.DiagramGeneratorMojo.execute(DiagramGeneratorMojo.java:97) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.lang.Exception: can't find route inside com.nestorurquiza.orchestration.camel.route package. ... 22 more [INFO] -- View this message in context: http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703237.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: diagram generator
Not sure why it works with and not in the example I shared with you but in any case certainly when I changed to it did generate diagrams for the two classes inside the package. And yet in my real project there is something going on, any idea why? [INFO] [ERROR] FATAL ERROR [INFO] [INFO] can't find route inside com.nestorurquiza.orchestration.camel.route package. [INFO] [INFO] Trace fr.rmannibucau.loader.spi.DiagramGeneratorRuntimeException: can't find route inside com.nestorurquiza.orchestration.camel.route package. at fr.rmannibucau.camel.loader.CamelLoader.camelContextToDiagram(CamelLoader.java:147) at fr.rmannibucau.camel.loader.CamelLoader.load(CamelLoader.java:41) at fr.rmannibucau.DiagramGeneratorMojo.execute(DiagramGeneratorMojo.java:97) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.lang.Exception: can't find route inside com.nestorurquiza.orchestration.camel.route package. ... 22 more [INFO] -- View this message in context: http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703238.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: diagram generator
Package is not supported. In fact input can now be a path (xml), a class or a package. If it finds nothing it can mean your classes are not loaded (plugin classpath or target/classes missing) - Romain Le 11 mai 2012 16:46, "Nestor Urquiza" a écrit : > Not sure why it works with and not in the example I > shared with you but in any case certainly when I changed to it did > generate diagrams for the two classes inside the package. > > And yet in my real project there is something going on, any idea why? > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] can't find route inside com.nestorurquiza.orchestration.camel.route > package. > [INFO] > > [INFO] Trace > fr.rmannibucau.loader.spi.DiagramGeneratorRuntimeException: can't find > route > inside com.nestorurquiza.orchestration.camel.route package. >at > > fr.rmannibucau.camel.loader.CamelLoader.camelContextToDiagram(CamelLoader.java:147) >at fr.rmannibucau.camel.loader.CamelLoader.load(CamelLoader.java:41) >at > fr.rmannibucau.DiagramGeneratorMojo.execute(DiagramGeneratorMojo.java:97) >at > > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) >at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) >at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) >at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) >at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) >at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) >at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) >at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) >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:597) >at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: java.lang.Exception: can't find route inside > com.nestorurquiza.orchestration.camel.route package. >... 22 more > [INFO] > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703238.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: diagram generator
I am running just 'mvn clean install' just as with the pet project. Below is
my xml:
fr.rmannibucau
diagram-generator-maven-plugin
0.0.1-SNAPSHOT
route1
package
diagram
com.nestorurquiza.orchestration.camel.route
false
480
640
${basedir}/src/main/javadoc/com/nestorurquiza/orchestration/camel/route/doc-files
camel
java
png
true
fr.rmannibucau
camel-loader
0.0.1-SNAPSHOT
--
View this message in context:
http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703403.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Load Balancing
Thank you Claus, I read both before sending the mail. I will try to explain myself better. I do not understand why, with load balancing between two HTTP nodes, if I have a client route starting with a timer with certain configuration, the client makes "independent" continuous requests switching connections instead of start request only when the timer says so. Is this a Camel thing or what do I have to configure for the route? Why this happens? In the server I have a route that consumes messages, that why I need to consume message at intervals and not continuously. Do I make myself clear or I'm still fuzzy?? On Fri, May 11, 2012 at 1:14 AM, Claus Ibsen wrote: > Hi > > I am not sure people can follow what your problem is? > > If you want error handling then read about Camel error handling, and > the links from this page > http://camel.apache.org/error-handling-in-camel.html > > And there is also a failover load balancer > http://camel.apache.org/load-balancer.html > > See if those links help you a bit. > And then come back later if you still have some questions. > > > On Thu, May 10, 2012 at 5:09 PM, Rocco Gallo Citera > wrote: >> Hello, sorry to bother but I have a problem understanding how load >> balancing works with some endpoints. >> Basically, I have the following route in a client: >> from(timer endpoint) >> .loadbalance().roundrobin() (with other types of load balancing the >> problem is similar) >> .to(http endpoint 1, http endpoint 2) >> .end; >> >> from(http endpoint) // both endpoints have the same behavior >> .to(file endpoint) >> >> In the server, I have >> from(jetty endpoint). >> .process(my process) >> .to(hazelcast endpoint) >> >> If I don't use the load balance, the example works great, but with it, >> any onException are not caught (I can see them on a logging console). >> If I use a TCPMon in between the client and the server, I see a >> continuous flow with a connection switch every time the starting timer >> triggers, but I expected the timer to start the exchange and write now >> it just switch connection, so I don't understand why. I tried to find >> any documentation about that but none was found. Can anyone please >> help me to understand why this behavior happens? I'm using Camel >> 2.9.2. >> >> Thank you very much. > > > > -- > Claus Ibsen > - > CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/
Re: diagram generator
Are the routes in target/classes? If not add a dependency to the plugin
- Romain
Le 11 mai 2012 17:59, "Nestor Urquiza" a écrit :
> I am running just 'mvn clean install' just as with the pet project. Below
> is
> my xml:
>
>
>fr.rmannibucau
>diagram-generator-maven-plugin
>0.0.1-SNAPSHOT
>
>
>route1
>package
>
>diagram
>
>
>
>
>
>
> com.nestorurquiza.orchestration.camel.route
>
>false
>
>480
>
>640
>
>
>
> ${basedir}/src/main/javadoc/com/nestorurquiza/orchestration/camel/route/doc-files
>
>camel
>
>java
>
>png
>
>true
>
>
>
>
>
>
>
>fr.rmannibucau
>camel-loader
>0.0.1-SNAPSHOT
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703403.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: diagram generator
OK I got it. The problem is related to how you look for classes. I believe you are looking from the running folder. That will work for a simple project where you build from the root of that project but it won't where you build that project from a multipom where you basically build several dependencies first. Here is how to replicate: Consider a core jar and an app war containing the Camel routes. I build core before app as app depends on it but to automate I use a project from where I called them both (multipom). Folder structure is then: core app multipom The multipom pom.xml relevant bits: ... ../core ../app If I build from ../app it works but it won't if I build from ./ -- View this message in context: http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703462.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: diagram generator
Yep, because it needs it as a plugin dependency. Le 11 mai 2012 18:20, "Nestor Urquiza" a écrit : > OK I got it. The problem is related to how you look for classes. I believe > you are looking from the running folder. That will work for a simple > project > where you build from the root of that project but it won't where you build > that project from a multipom where you basically build several dependencies > first. Here is how to replicate: > > Consider a core jar and an app war containing the Camel routes. I build > core > before app as app depends on it but to automate I use a project from where > I > called them both (multipom). Folder structure is then: > core > app > multipom > > The multipom pom.xml relevant bits: > ... > ../core > ../app > > > > If I build from ../app it works but it won't if I build from ./ > > -- > View this message in context: > http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703462.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: camel-jaxb namespace prefix
See http://docs.oracle.com/javase/6/docs/api/javax/xml/bind/annotation/XmlSchema.html how to customize the namespace prefix. Use the "-npa" option from the xjc compiler or maven-jaxb2-plugin to prevent to update the package-info.java file. -- View this message in context: http://camel.465427.n5.nabble.com/camel-jaxb-namespace-prefix-tp5685354p5703483.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: diagram generator
I am sorry. I am lost. Bare with me please. You mean I have to include the
same project as a dependency? My project is a WAR file. I believe there is a
bug as default classes to search for should be those in ${basedir}/target
and not in ./target. Don't you think?
--
View this message in context:
http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703499.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: ExchangePattern InOnly for JMS component
Which version of Camel do you use?
Which JMS provider do you use?
Best,
Christian
On Thu, May 3, 2012 at 5:30 PM, bjacob wrote:
> Hello -
>
> Is there a difference between the following 2 pieces of code?
>
> I get "The OUT message was not received within: 2 millis." error for
> the
> second one.
>
> It seems like setting the exchange pattern in the URL doesn't work.
>
> first
> from("jms:queue:CallBackListNotification.Request")
> .setExchangePattern(ExchangePattern.InOnly)
> .to("jms:queue:CallBackListNotification.Response?exchangePattern=InOnly");
>
>
>
> second
> from("jms:queue:CallBackListNotification.Request")
> .to("jms:queue:CallBackListNotification.Response?exchangePattern=InOnly");
>
>
> Thanks & Regards
> Boney Jacob
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/ExchangePattern-InOnly-for-JMS-component-tp5683515.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: diagram generator
That could certainly be configurable but even for a war classes are in
target/classes not target.
Le 11 mai 2012 18:36, "Nestor Urquiza" a écrit :
> I am sorry. I am lost. Bare with me please. You mean I have to include the
> same project as a dependency? My project is a WAR file. I believe there is
> a
> bug as default classes to search for should be those in ${basedir}/target
> and not in ./target. Don't you think?
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703499.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: diagram generator
That is what I meant to say ./target/classes versus
${basedir}/target/classes. Using the latter is the correct approach in my
opinion.
In terms of the war it won't work anyway as a dependency so at this point my
project cannot generate the route diagrams unless I explicitly instruct so
from its root folder. Not big deal, after all I won't be generating them
unless I have to generate the site and that commonly happens in the CI
server.
--
View this message in context:
http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703786.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: diagram generator
Hmm you are right but i still dont see why it could be mandatory to be able
to load the class. Simply put the war as dependency.
Le 11 mai 2012 20:30, "Nestor Urquiza" a écrit :
> That is what I meant to say ./target/classes versus
> ${basedir}/target/classes. Using the latter is the correct approach in my
> opinion.
>
> In terms of the war it won't work anyway as a dependency so at this point
> my
> project cannot generate the route diagrams unless I explicitly instruct so
> from its root folder. Not big deal, after all I won't be generating them
> unless I have to generate the site and that commonly happens in the CI
> server.
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703786.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: diagram generator
The war as dependency won't work. First it will ignore the type and will
append just jar to the artifactId, then it will ignore the version and will
use the plugin version (in this case 0.0.1-SNAPSHOT) which is most likely
another bug.
I think ${basedir}/target/classes is the correct default because you are
adding the plugin to a specific project just to generate the routes for that
project which are in that project target/classes folder. To correctly
reference that project you will use ${basedir} as it "represents the
directory containing pom.xml"
--
View this message in context:
http://camel.465427.n5.nabble.com/diagram-generator-tp4375588p5703889.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: AW: JAXB classpath issue with camel-jaxb 2.9.2
It looks like you are using
org.apache.camel.model.dataformat.JaxbDataFormat and not
org.apache.camel.converter.jaxb.JaxbDataFormat.
I added a test which shows that marshalling partial classes works in
generall:
https://svn.apache.org/repos/asf/camel/trunk/components/camel-jaxb/src/test/java/org/apache/camel/converter/jaxb/JaxbDataFormatPartClassTest.java
Best,
Christian
On Fri, May 4, 2012 at 5:11 PM, gehdan wrote:
> gah.. damn HTML mails... sorry for that, I'm trying again:
>
> my route looks like this:
> VeytonProxy proxy = new VeytonProxy(
> new URL("http://shop.example.com/index.php?page=soap_api_wsdl";));
>
>
> JaxbDataFormat d = new JaxbDataFormat(); d.setDataFormatName("jaxb");
> d.setContextPath("com.xt_commerce.types");
> d.setPartClass("com.xt_commerce.types.Order");
> d.setPartNamespace("{http://www.xt-commerce.com/types}order";);
> d.setPrettyPrint(true);
> from("timer://fetchOrderTimer?period=5000")
> .setBody(simple("1"))
> .bean(proxy, "getOrderIds")
> .split(body(String[].class))
> .log("fetching order '${body}' from shop.")
> .bean(proxy, "getOrder")
> .setHeader("identifier",
> simple("order-${body.orderId}-${body.customerId}"))
> .log("order '${body.orderId}' successfully loaded, customer:
> ${body.customerId}")
> .marshal(d)
> .to("file://c:/temp?fileName=${header[identifier]}.txt");
>
> Using camel-jaxb instead of jaxb-* as dependency in both projects doesn't
> help - as expected. Since I already used the versions of jaxb-* that were
> defined as dependency of camel-jaxb.
>
> This seems to be a problem of version 2.1.13 of jaxb-impl.
>
> Thanks,
> Daniel
>
> -
> --
> Daniel Geh
> BIZOLUTION GmbH
> Web: http://www.bizolution.de
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/JAXB-classpath-issue-with-camel-jaxb-2-9-2-tp5678527p5686166.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
