Proxy BeanInvocations turning into first-class payloads?
Hi all, Quick question, at which point does the BeanInvocation transform into a first-class payload as documented here: http://camel.apache.org/using-camelproxy.html ? From the examples in the docs it looks like it leaves the proxy endpoint as the first-class payload. I ask because I'm proxying a service that should meet the requirements for the implicit transform from BeanInvocation to the first-class argument, but it's entering the route as a BeanInvocation. The problem is manifesting at the GSON marshalling stage - the bean invocation is being marshalled, not the method call argument, so when it arrives in the service, all the fields of the argument are null. The interface (and concrete implementation) being proxied are here: https://gist.github.com/4410704 The Spring / Camel context is here: https://gist.github.com/4410713 You can see that I've got a commented out explicit transform there - it is working around the problem by pulling the argument out of the BeanInvocation explicitly, but it'd be nice if I could used the existing functionality in Camel. Any thoughts / criticisms welcomed, I'm quite new to Camel and I'm amazed at how powerful it can be, but I do worry about using it inefficiently. Regards, Liam Clarke
Re: MalformedObjectNameException when starting camel context
Hi Tim,
It's trying to get an mbean or similar with a name derived from (I
guess) your machine's IP - which is in IPV6, hence lots of colons.
However, if you look at the documentation for ObjectName
(http://docs.oracle.com/javase/1.5.0/docs/api/javax/management/ObjectName.html)
you'll see it states:
> An ObjectName can be written as a String with the following elements in order:
> The domain.
> A colon (:).
> A key property list as defined below.
And also
>An unquoted value is a possibly empty string of characters which may not
>contain any of the characters comma, equals, colon, quote, asterisk, or
>question mark.
So it's hitting the first colon, starts interpreting the rest of the
IP as a property, hits the next colon while parsing it as a property
value, and blows up because colons aren't allowed.
Looking at what DefaultManagementNamingStrategy.createObjectName does,
it ultimately calls java.net.InetAddress#getLocalHost() to get that
IP. Maybe you need to alias localhost in your /etc/hosts?
Regards,
Liam Clarke
On Mon, Dec 31, 2012 at 2:38 PM, Willem Jiang wrote:
>
> Hi,
> It looks something is wrong with you host name. Can you just change it?
>
> Willem
>
>
>
> 在 2012-12-30，下午11:45，Tim Dudgeon 写道：
>
> > I'm seeing a strange error when starting a camel context. Its dependent on
> > the machine I'm running on. On one machine (Windows) the same context and
> > simple route runsfine, but on a different machine (Mac) the context fails
> > to start. The key part seems to be this:
> >
> > javax.management.MalformedObjectNameException: Could not create ObjectName
> > from:
> > org.apache.camel:context=unknown-00:25:4b:c4:94:f4.home/camel-1,type=context,name="camel-1".
> > Reason: javax.management.MalformedObjectNameException: Invalid character
> > ':' in value part of property
> >
> > The context and route is very simple:
> >
> > def camelContext = new DefaultCamelContext()
> > camelContext.addRoutes(new RouteBuilder() {
> >def void configure() {
> >from("timer://jdkTimer?period=3000")
> >.to("log://camelLogger?level=INFO")
> >}
> > })
> >
> > This is using Camel 2.10.3.
> > Any ideas what might be going wrong?
> >
> > The full error is here:
> >
> > /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java
> > -Dtools.jar=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/tools.jar
> > -Dgroovy.home=/Users/timbo/etc/groovy/groovy-1.8.8
> > -Dgroovy.starter.conf=/Users/timbo/etc/groovy/groovy-1.8.8/conf/groovy-starter.conf
> > -Didea.launcher.port=7532 "-Didea.launcher.bin.path=/Applications/IntelliJ
> > IDEA 11 CE.app/bin" -Dfile.encoding=UTF-8 -classpath
> > "/Users/timbo/etc/groovy/groovy-1.8.8/lib/groovy-1.8.8.jar:/Applications/IntelliJ
> > IDEA 11 CE.app/lib/idea_rt.jar"
> > com.intellij.rt.execution.application.AppMain
> > org.codehaus.groovy.tools.GroovyStarter --conf
> > /Users/timbo/etc/groovy/groovy-1.8.8/conf/groovy-starter.conf --main
> > groovy.ui.GroovyMain --classpath
> > /Users/timbo/tmp/TestingCamel/out/production/TestingCamel:/Users/timbo/etc/groovy/groovy-1.8.8/lib/ant-1.8.3.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/ant-antlr-1.8.3.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/ant-junit-1.8.3.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/ant-launcher-1.8.3.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/antlr-2.7.7.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/asm-3.2.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/asm-analysis-3.2.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/asm-commons-3.2.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/asm-tree-3.2.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/asm-util-3.2.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/bsf-2.4.0.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/commons-cli-1.2.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/commons-logging-1.1.1.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/gpars-1.0-beta-3.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/groovy-1.8.8.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/hamcrest-core-1.1.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/ivy-2.2.0.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/jansi-1.6.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/jline-1.0.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/jsp-api-2.0.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/jsr166y-1.7.0.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/junit-4.10.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/servlet-api-2.4.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/xmlpull-1.1.3.1.jar:/Users/timbo/etc/groovy/groovy-1.8.8/lib/xstream-1.4.1.jar:/Users/timbo/tmp/TestingCamel/lib/camel-core-2.10.3.jar:/Users/timbo/tmp/TestingCamel/lib/slf4j-api-1.6.6.jar:/Users/timbo/tmp/TestingCamel/lib/slf4j-simple-1.6.6.jar
> > --encoding=UTF-8 /Users/timbo/tmp/TestingCamel/src/Simple.groovy
> > 2347 [main] INFO org.apache.camel.impl.DefaultCamelContext - Apache Camel
> > 2.10.3 (CamelContext: camel-1) is starting
> > 3832 [main] INFO org.apache.camel.management.ManagementStrateg
Re: Proxy BeanInvocations turning into first-class payloads?
Hmm, I think I've figured this out. The CamelProxyFactoryBean uses ProxyHelper to create the proxied service - but the "convert a bean invocation with one arg to just the arg" logic requires using the PojoProxyHelper to create the proxied service, as it's using a different invocation handler. So, using a camel proxy in a Spring xml file will never have this behaviour. It also means that documentation on here: http://camel.apache.org/using-camelproxy.html may be wrong, as it's using the ProxyHelper to create the proxy that demos this feature. I'll have to create an account and log a bug, I think. Regards, Liam Clarke On Sun, Dec 30, 2012 at 3:56 PM, Liam Clarke-Hutchinson wrote: > Hi all, > > Quick question, at which point does the BeanInvocation transform into a > first-class payload as documented here: > http://camel.apache.org/using-camelproxy.html ? From the examples in the > docs it looks like it leaves the proxy endpoint as the first-class payload. > > I ask because I'm proxying a service that should meet the requirements for > the implicit transform from BeanInvocation to the first-class argument, but > it's entering the route as a BeanInvocation. The problem is manifesting at > the GSON marshalling stage - the bean invocation is being marshalled, not > the method call argument, so when it arrives in the service, all the fields > of the argument are null. > > The interface (and concrete implementation) being proxied are here: > https://gist.github.com/4410704 > The Spring / Camel context is here: https://gist.github.com/4410713 > > You can see that I've got a commented out explicit transform there - it is > working around the problem by pulling the argument out of the BeanInvocation > explicitly, but it'd be nice if I could used the existing functionality in > Camel. > > Any thoughts / criticisms welcomed, I'm quite new to Camel and I'm amazed at > how powerful it can be, but I do worry about using it inefficiently. > > Regards, > > Liam Clarke > > > > >
Camel proxies using Activemq queues
Hi, I have a camel proxy defined using the Spring DSL that I'd like to communicate synchronously with the implementing service via an ActiveMQ queue, and while the service does receive the BeanInvocation, the response never makes it back to the proxy and the request-reply times out. My route is as follows: and the proxy's service URL is set to "activemq:queue:PRODUCTS_SEEN". The request is received, and processed within the service, and we can see the reply value being set on the out body of the exchange, but we can't figure out what's going wrong after that. Could it be because our proxy bean and the service bean are using different camel contexts? I understand (from somewhere) that a temporary response queue is created by Camel, is there a way I can explicitly specify a response queue? Regards, Liam Clarke
Re: Camel proxies using Activemq queues
Hi Claus, I apologise for not giving useful information in my previous email. I've resolved my issue - it was PEBKAC, the message was failing to return because what I was returning was not serializable. I'd forgotten that inner classes (in this case, a comparator) retained references to their owning classes - so my 'serializable' tree-set was also trying to serialize the containing service. As the Camel book says, it's the #1 rule of camel proxies. :/ Thank you for your quick response though. Regards, Liam Clarke On Fri, Feb 1, 2013 at 8:38 PM, Claus Ibsen wrote: > On Fri, Feb 1, 2013 at 6:25 AM, Liam Clarke-Hutchinson > wrote: >> Hi, >> >> I have a camel proxy defined using the Spring DSL that I'd like to >> communicate synchronously with the implementing service via an >> ActiveMQ queue, and while the service does receive the BeanInvocation, >> the response never makes it back to the proxy and the request-reply >> times out. My route is as follows: >> >> >> >> >> and the proxy's service URL is set to "activemq:queue:PRODUCTS_SEEN". >> >> The request is received, and processed within the service, and we can >> see the reply value being set on the out body of the exchange, but we >> can't figure out what's going wrong after that. >> > > Maybe post more details such as the route, XML etc. Also what Camel > and ActiveMQ version do you use? > > >> Could it be because our proxy bean and the service bean are using >> different camel contexts? >> I understand (from somewhere) that a temporary response queue is >> created by Camel, is there a way I can explicitly specify a response >> queue? >> > > Yes see the JMS docs > http://camel.apache.org/jms > > > > >> Regards, >> >> Liam Clarke > > > > -- > Claus Ibsen > - > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
