Re: camel-cxf endpoint - error : Failed to convert property value of type ...
I have found the error. This is because the address of the cxf endpoint is
defined like this : /incident and not like
http://localhost:8080/camel-exemple/incident
cmoulliard wrote:
The issue is solved but
I have the following error now :
2009-03-04 13:25:55,115 DEBUG DefaultListableBeanFactory - Returning
cached instance of singleton bean
'org.apache.cxf.binding.soap.SoapTransportFactory'
04-mars-2009 13:25:55
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
initializeWSDLOperations
ATTENTION: Could not find a matching method for operation
{http://reportincident.example.camel.apache.org}ReportIncident. Operation
will be unavailable.
2009-03-04 13:25:55,600 ERROR MainSupport - Failed:
org.apache.cxf.service.factory.ServiceConstructionException
org.apache.cxf.service.factory.ServiceConstructionException
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:139)
at
org.apache.camel.component.cxf.CxfConsumer.init(CxfConsumer.java:102)
at
org.apache.camel.component.cxf.CxfEndpoint.createConsumer(CxfEndpoint.java:95)
at
org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:62)
at org.apache.camel.Route.getServicesForRoute(Route.java:74)
at org.apache.camel.impl.RouteService.doStart(RouteService.java:77)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50)
at
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:743)
at
org.apache.camel.spring.SpringCamelContext.maybeDoStart(SpringCamelContext.java:165)
at
org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:160)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50)
at
org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:95)
at
org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:114)
at
org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78)
at
org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76)
at
org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:274)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:736)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:383)
at
org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:139)
at
org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:93)
at
org.apache.camel.spring.Main.createDefaultApplicationContext(Main.java:232)
at org.apache.camel.spring.Main.doStart(Main.java:186)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50)
at org.apache.camel.util.MainSupport.run(MainSupport.java:121)
at org.apache.camel.util.MainSupport.run(MainSupport.java:299)
at org.apache.camel.spring.Main.main(Main.java:98)
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.apache.camel.maven.RunMojo$1.run(RunMojo.java:396)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.MalformedURLException: no protocol: /incident
at java.net.URL.init(URL.java:567)
at java.net.URL.init(URL.java:464)
at java.net.URL.init(URL.java:413)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.init(JettyHTTPDestination.java:91)
at
org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory.createDestination(JettyHTTPTransportFactory.java:116)
at
org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory.getDestination(JettyHTTPTransportFactory.java:103)
at
org.apache.cxf.endpoint.ServerImpl.initDestination(ServerImpl.java:90)
at org.apache.cxf.endpoint.ServerImpl.init(ServerImpl.java:69)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:118)
... 32 more
William Tam wrote:
I submitted a fix (Committed revision 749772). Let me know if you see
other issues. Thanks.
Cheers,
William
On Tue, Mar 3, 2009 at 3:36 PM, William Tam email.w...@gmail.com wrote:
I'm looking into it.
https://issues.apache.org/activemq/browse/CAMEL-1416
On Tue, Mar 3, 2009 at 12:08 PM, Claus Ibsen claus.ib...@gmail.com
wrote:
Hi
Re: camel-cxf dataformat
Can you try not to use # notation but actual SEI class name instead to see if it works for you? !-- webservice endpoint -- cxf:cxfEndpoint id=reportIncident address=http://localhost:8080/camel-exampl/incident; wsdlURL=wsdl/report_incident.wsdl serviceClass=org.apache.camel.example.reportincident.service.ReportIncidentEndpoint endpointName=s:ReportIncidentPort serviceName=s:ReportIncidentService xmlns:s=http://reportincident.example..camel.apache.org; cxf:properties entry key=dataFormat value=PAYLOAD/ /cxf:properties /cxf:cxfEndpoint Yes, the SEI has been generated by the maven plugin : Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Camel type converter question
Hi Willem, Thanks for your reply. The issue in Kohsuke's blog is not the cause of my problem. Let me explain my wsdl in a little more detail. My top level element is defined as following: element name=notifications complexType sequence element name=OrganizationId type=ent:ID/ element name=ActionId type=ent:ID/ element name=SessionId type=xsd:string nillable=true/ element name=EnterpriseUrl type=xsd:string/ element name=PartnerUrl type=xsd:string/ element name=Notification maxOccurs=100 type=tns:Notification/ /sequence /complexType /element jaxb using the simple binding generates the correct bean object (Notifications) with the @XmlRootElement for the top level element. However since the contained element is defined as of type Notification defined below: complexType name=Notification sequence element name=Id type=ent:ID/ element name=sObject type=ens:sObject/ /sequence /complexType The bean for the above complexType (Notification) is generated without the @XmlRootElement. I wish to persist the Notification objects to the disk using the FileEndPoint generated using the following routing snippet: .convertBodyTo(Notification.class).setHeader(FileComponent.HEADER_FILE_NAME).constant(sriram.txt).to(file:/to/my/path) However since the Notification bean is missing the @XmlRootElement, the FallbackTypeConverter is failing to marshall this to XML. This is the problem I am trying to solve. JAXB has the notion of DataTypeAdapters which can be used to specify marshalling rules for jaxb elements and types. I wonder if anybody on this forum has tried using these Adapters in conjunction with the FallbackTypeConverter. Sriram willem.jiang wrote: Hi Sriram, I just used google to do a quick search, the error may relate to the anonymous complexTypes in your wsdl. Here is the link[1] which talks about it. [1] http://weblogs.java.net/blog/kohsuke/archive/2006/03/why_does_jaxb_p.html Willem Sriram C wrote: I have defined a CXF jaxws endpoint. The incoming message to this end point has an element which is defined as a ComplexType in the wsdl. The CXF wsdl2java utility generates this complextype with an @XmlType annotation. Since it is missing the @XmlRootElement annotation, the FallbackTypeConverter is unable to marshall this object. What is a good solution for resolving this issue? Thanks in advance, Sriram -- View this message in context: http://www.nabble.com/Camel-type-converter-question-tp22322333p22335454.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Restlet Component File Upload Handling
Hi Todd, Your usecase seems to justify use of camel-restlet. For example, user code will need to deal with RESTful URI and authentication if it is using camel-jetty. I'll create a Jira to support multipart message. Cheers, William On Tue, Mar 3, 2009 at 5:53 PM, tfredrich tfredr...@yahoo.com wrote: As usual, one thing calls for another... I created a MultipartRestletBinder that simply overrides populateExchangeFromRestletRequest(), checks for multipart content, and leverages the FileUpload extension if applicable. However, once that operated appropriately (for my case of uploading images), I discovered that the download case assumes the body to be a string. Consequently, I overrode populateRestletResponseFromExchange() and serialize a byte array for the case of IMAGE MediaType. See attached http://www.nabble.com/file/p22319865/MultipartRestletBinding.java MultipartRestletBinding.java Quite likely, you might ask (as I now am) why use Camel-Restlet to read/write images... The basic use cases are: Upload: 1) Upload image for user using RESTful URI. 2) Authenticate user. 3) Hash name to make the filename unique. 4) Write the image to the unique filename (on virtual storage). 5) Update user data to reference newly uploaded image. Download: 1) Request image for user via RESTful URI (with hashed filename). 2) Authenticate user 3) Return image. Apache (httpd) is certainly faster for such static content. I'm open to suggestions--especially as to how to better utilize Camel (with or without) the restlet component to localize authentication, present a RESTful service interface (with tidy URIs), etc. Thanks again, --Todd Fredrich -- View this message in context: http://www.nabble.com/Restlet-Component-File-Upload-Handling-tp22250082p22319865.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Re: camel osgi tracing in spring dsl does not work - 2.0 SNAPSHOT
I think there could be some trouble to find the camel-spring's
pre-defined bean in OSGI server. You may work around this issue by
adding the TRACE interceptor yourself.
Please just add this the below bean into your Spring configuration file.
bean id=camelTracer
class=org.apache.camel.processor.interceptor.Tracer/
Willem
cmoulliard wrote:
Yes when I set the log level in the server as TRACE but not when I start
camel outside of an OSGI server.
willem.jiang wrote:
Does it work in a no osgi environment ?
Willem
On Wed, Mar 4, 2009 at 10:10 PM, cmoulliard cmoulli...@gmail.com wrote:
Hi,
It seems that the tracing does not work when activated like this in an
camel
osgi spring dsl route ?
camelContext trace=true xmlns=
http://camel.apache.org/schema/osgi;
camel:packageorg.apache.camel.example.reportincident.routing/camel:package
camel:route
camel:from
uri=file://d:/temp/data/?moveExpression=d:/temp/done/${file:name} /
camel:unmarshal ref=bindyDataformat /
camel:to uri=bean:csv /
/camel:route
camel:route
camel:from uri=cxf:bean:reportIncident /
camel:convertBodyTo
type=org.apache.camel.example.reportincident.domain.InputReportIncident
/
camel:to uri=log:cxf /
camel:transform
camel:constantOK/camel:constant
/camel:transform
/camel:route
/camelContext
Version affected : 2.0-SNAPSHOT
Regards,
-
Charles Moulliard
SOA Architect
My Blog : http://cmoulliard.blogspot.com/
http://cmoulliard.blogspot.com/
--
View this message in context:
http://www.nabble.com/camel-osgi-tracing-in-spring-dsl-does-not-work---2.0-SNAPSHOT-tp22330735p22330735.html
Sent from the Camel - Users mailing list archive at Nabble.com.
-
Charles Moulliard
SOA Architect
My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
Are durable topic subscriptions destroyed?
If I create a durable topic subscription using the jms or activemq components (for example activemq:topic:myTopic?clientId=client1durableSubscriptionName=subscription1), does camel ever cause the durable subscription to be destroyed? In other words will camel ever cause session.unsubscribe to be called? I'm working in a situation where I'm implementing failover of a durable subscription on different machines using camel and I want to be sure the durable subscription does not get destroyed when the camel context is destroyed. Just out of curiosity, I'm also wondering how/if one can indicate he wants the durable subscription to be destroyed when the camel context is destroyed. As an aside there is a small bug on this web page describing durable subscriptions (http://camel.apache.org/jms.html). The first paragraph under Notes states If you wish to use durable topic subscriptions, you need to specify both clientId and durableSubscriberName. durableSubscriberName does not work. The table below has the correct property: durableSubscriptionName. -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22344211.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Re: Are durable topic subscriptions destroyed?
On Thu, Mar 5, 2009 at 3:38 AM, ariekenb aaron.j.riekenb...@lmco.com wrote: If I create a durable topic subscription using the jms or activemq components (for example activemq:topic:myTopic?clientId=client1durableSubscriptionName=subscription1), does camel ever cause the durable subscription to be destroyed? In other words will camel ever cause session.unsubscribe to be called? I'm working in a situation where I'm implementing failover of a durable subscription on different machines using camel and I want to be sure the durable subscription does not get destroyed when the camel context is destroyed. Just out of curiosity, I'm also wondering how/if one can indicate he wants the durable subscription to be destroyed when the camel context is destroyed. Not to my knowledge. But I would advice you to double check the source code of camel-jms to see if there is any code that would call unsubscribe. Usually such code would be in doStop or stop methods. James Strachan who wrote the camel-jms component would be in a better position to clarify this. With your findings we should update the wiki, so please report back. As an aside there is a small bug on this web page describing durable subscriptions (http://camel.apache.org/jms.html). The first paragraph under Notes states If you wish to use durable topic subscriptions, you need to specify both clientId and durableSubscriberName. durableSubscriberName does not work. The table below has the correct property: durableSubscriptionName. Thanks for spotting this. Fixed the typo. -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22344211.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
