Re: [IDEA] - camel-cxf, make it easier to enable logging in/out
The attribute (loggingFeatureEnabled) already exists. in camel-cxf endpoint Please check out http://camel.apache.org/cxf.html. On 11/08/2011 05:43 AM, Willem Jiang wrote: Hi Claus, CXF has the log feature can avoid us to configure lots of interceptors. but it could be more handy if we add an attribute on the cxfEndpoint. +1 for this idea. On Tue Nov 8 18:36:27 2011, Claus Ibsen wrote: Hi When working with camel-cxf, you can get pretty fast setup with the Camel cxfEndpoint element as shown: For example to call the famous weather web service cxf:cxfEndpoint id=weatherWebService address=http://www.webservicex.net/globalweather.asmx; endpointName=s:GlobalWeatherSoap serviceName=s:GlobalWeather wsdlURL=http://www.webservicex.net/globalweather.asmx?WSDL; xmlns:s=http://www.webserviceX.NET; However to enabling logging of INBOUND and OUTBOUND messages with CXF, you need to thinker with interceptors. And IMHO that is a bit PITA as its kinda hard to remember all the mighty XML stuff you need to add, just to see what is send out and comes back in the console / logs. Currently you would have to added these 4 interceptors, and remember also what the class names of the interceptor bean is cxf:cxfEndpoint id=weatherWebService address=http://www.webservicex.net/globalweather.asmx; endpointName=s:GlobalWeatherSoap serviceName=s:GlobalWeather wsdlURL=http://www.webservicex.net/globalweather.asmx?WSDL; xmlns:s=http://www.webserviceX.NET; cxf:inInterceptors bean class=org.apache.cxf.interceptor.LoggingInInterceptor/ /cxf:inInterceptors cxf:inFaultInterceptors bean class=org.apache.cxf.interceptor.LoggingInInterceptor/ /cxf:inFaultInterceptors cxf:outInterceptors bean class=org.apache.cxf.interceptor.LoggingOutInterceptor/ /cxf:outInterceptors cxf:outFaultInterceptors bean class=org.apache.cxf.interceptor.LoggingOutInterceptor/ /cxf:outFaultInterceptors /cxf:cxfEndpoint Thats is a lot of XML just to play with a web service. It would be much easier if there was a attribute that could setup these logging interceptors for you out of the box. So all you have to do was set logging attribute to true. cxf:cxfEndpoint id=weatherWebService logging=true address=http://www.webservicex.net/globalweather.asmx; endpointName=s:GlobalWeatherSoap serviceName=s:GlobalWeather wsdlURL=http://www.webservicex.net/globalweather.asmx?WSDL; xmlns:s=http://www.webserviceX.NET; Any thoughts?
[jira] [Commented] (CAMEL-4436) CxfRsProducer clientFactoryBean's bus should be initialized
[ https://issues.apache.org/jira/browse/CAMEL-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102076#comment-13102076 ] William Tam commented on CAMEL-4436: r1167555 - 2.9.0.x r1167556 - 2.8.2.x CxfRsProducer clientFactoryBean's bus should be initialized --- Key: CAMEL-4436 URL: https://issues.apache.org/jira/browse/CAMEL-4436 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.0 Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.8.2, 2.9.0 This defect only manifests itself if an application hosts more than one CamelContext. The first CamelContext contained by a Spring application context that does not have a custom bus (e.g. any http conduit configurations) while the second Spring application/Camel context does have a custom bus. The symptom is when the application sends an message to the cxfrs endpoint in the second context (that contains custom bus), the cxfrs endpoint picks up the wrong bus. It picks up the default cxf in the first application context. Furthermore, this defect only affects cxfrs producer using URI address format. E.g. to uri=cxfrs://https://localhost:8181/CxfRsProducerTest// It does not affect cxfrs addresses defined as a bean. E.g. to uri=cxfrs://bean://rsClientHttps/ cxf:rsClient id=rsClientHttps address=https://localhost:8181/CxfRsProducerTest// -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4436) CxfRsProducer clientFactoryBean's bus should be initialized
CxfRsProducer clientFactoryBean's bus should be initialized --- Key: CAMEL-4436 URL: https://issues.apache.org/jira/browse/CAMEL-4436 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.0 Reporter: William Tam Assignee: William Tam Priority: Minor This defect only manifests itself if an application hosts more than one CamelContext. The first CamelContext contained by a Spring application context that does not have a custom bus (e.g. any http conduit configurations) while the second Spring application/Camel context does have a custom bus. The symptom is when the application sends an message to the cxfrs endpoint in the second context (that contains custom bus), the cxfrs endpoint picks up the wrong bus. It picks up the default cxf in the first application context. Furthermore, this defect only affects cxfrs producer using URI address format. E.g. to uri=cxfrs://https://localhost:8181/CxfRsProducerTest// It does not affect cxfrs addresses defined as a bean. E.g. to uri=cxfrs://bean://rsClientHttps/ cxf:rsClient id=rsClientHttps address=https://localhost:8181/CxfRsProducerTest// -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-4436) CxfRsProducer clientFactoryBean's bus should be initialized
[ https://issues.apache.org/jira/browse/CAMEL-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-4436 started by William Tam. CxfRsProducer clientFactoryBean's bus should be initialized --- Key: CAMEL-4436 URL: https://issues.apache.org/jira/browse/CAMEL-4436 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.0 Reporter: William Tam Assignee: William Tam Priority: Minor This defect only manifests itself if an application hosts more than one CamelContext. The first CamelContext contained by a Spring application context that does not have a custom bus (e.g. any http conduit configurations) while the second Spring application/Camel context does have a custom bus. The symptom is when the application sends an message to the cxfrs endpoint in the second context (that contains custom bus), the cxfrs endpoint picks up the wrong bus. It picks up the default cxf in the first application context. Furthermore, this defect only affects cxfrs producer using URI address format. E.g. to uri=cxfrs://https://localhost:8181/CxfRsProducerTest// It does not affect cxfrs addresses defined as a bean. E.g. to uri=cxfrs://bean://rsClientHttps/ cxf:rsClient id=rsClientHttps address=https://localhost:8181/CxfRsProducerTest// -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4436) CxfRsProducer clientFactoryBean's bus should be initialized
[ https://issues.apache.org/jira/browse/CAMEL-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-4436. Resolution: Fixed Fix Version/s: 2.9.0 2.8.2 Committed revision 1167448 - 2.9.0.x Committed revision 1167458 - 2.8.2.x CxfRsProducer clientFactoryBean's bus should be initialized --- Key: CAMEL-4436 URL: https://issues.apache.org/jira/browse/CAMEL-4436 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.0 Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.8.2, 2.9.0 This defect only manifests itself if an application hosts more than one CamelContext. The first CamelContext contained by a Spring application context that does not have a custom bus (e.g. any http conduit configurations) while the second Spring application/Camel context does have a custom bus. The symptom is when the application sends an message to the cxfrs endpoint in the second context (that contains custom bus), the cxfrs endpoint picks up the wrong bus. It picks up the default cxf in the first application context. Furthermore, this defect only affects cxfrs producer using URI address format. E.g. to uri=cxfrs://https://localhost:8181/CxfRsProducerTest// It does not affect cxfrs addresses defined as a bean. E.g. to uri=cxfrs://bean://rsClientHttps/ cxf:rsClient id=rsClientHttps address=https://localhost:8181/CxfRsProducerTest// -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Discussion] Remove cxf: component
I really don't think so. The CXF component have unique and important features that simply cannot be replaced by other components in camel-cxf. Camel transport is a CXF transport that can be plugged into CXF stack. It is a building block for other components (e.g. cxfbean) and other use case, but it does not replace CXF component all at Cxfbean uses Camel transport to host JAXWS/JAXRS POJO and that's it. The message received cannot be routed to another Camel component and cannot be used to invoke an external REST/SOAP service. Cxfrs is the REST's counterpart of cxf. It is quite verbose. By your logic, we should remove it as well. As you can see, cxf fills a huge hole in terms of features. CXF component features: - consumer (server) to listen for SOAP requests and turn requests into either POJO, XML parts, or RAW HTTP message. The message is then routed to other Camel component. - producer (client) to invoke an external SOAP with given message (again, it can be POJO, XML parts, or RAW HTTP). CXF component follows the standard Camel pattern (Consumer/Producer etc) nicely. The setting up CXF endpoint is pain in the butt but that is because of how CXF endpoint is setup. That (cxf endpoint setup) is really the verbose parts of the configuration which do not have default values. Can the verbose issue be addressed? Anything that is verbose should be removed? The original CXF way is a CXF user experience. You said CXF experience is a good thing in Camel Transport' but not in CXF? On 06/15/2011 09:31 AM, Christian Schneider wrote: Hi all, currently we have several ways of using / offering a CXF service with camel: - Camel transport for CXF - cxf: component - cxfbean: component - cxfrs: component The camel transport is useful as it is a very thin layer compared to the other variants. Additionally it allows to reuse experience from cxf on how to setup an endpoint. The cxfbean: component is quite convenient so it makes sense to have it. The cxfrs: component also seems to be quit econvenient for users. The cxf: component is very verbose and seems to be used almost exactly as the original cxf way to describe a service. So I propose to remove this component. As a migration path I propose users use either the camel transport for cxf or the cxfbean component. What do you think? Christian
[jira] [Created] (CAMEL-4079) Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice
Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice - Key: CAMEL-4079 URL: https://issues.apache.org/jira/browse/CAMEL-4079 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.7.2, 2.6.0, 2.8.0 Reporter: William Tam Assignee: William Tam Fix For: 2.7.3, 2.8.0 Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice. The asyncInvoke should execute one of the conditions (continuation.isNew() or continuation.isResumed(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-4079) Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice
[ https://issues.apache.org/jira/browse/CAMEL-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-4079 started by William Tam. Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice - Key: CAMEL-4079 URL: https://issues.apache.org/jira/browse/CAMEL-4079 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.6.0, 2.7.2, 2.8.0 Reporter: William Tam Assignee: William Tam Fix For: 2.7.3, 2.8.0 Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice. The asyncInvoke should execute one of the conditions (continuation.isNew() or continuation.isResumed(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4079) Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice
[ https://issues.apache.org/jira/browse/CAMEL-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-4079. Resolution: Fixed 2.7.3.x Committed revision 1134060 2.8.0.x Committed revision 1134059. Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice - Key: CAMEL-4079 URL: https://issues.apache.org/jira/browse/CAMEL-4079 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.6.0, 2.7.2, 2.8.0 Reporter: William Tam Assignee: William Tam Fix For: 2.7.3, 2.8.0 Bug in CxfConsumer.asyncInvoke that causes setResponseBack to be called twice. The asyncInvoke should execute one of the conditions (continuation.isNew() or continuation.isResumed(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-3927) CXF's Provider service using the payload data-format may not transfer the payload correctly
[ https://issues.apache.org/jira/browse/CAMEL-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam reassigned CAMEL-3927: -- Assignee: William Tam CXF's Provider service using the payload data-format may not transfer the payload correctly --- Key: CAMEL-3927 URL: https://issues.apache.org/jira/browse/CAMEL-3927 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.7.1 Reporter: Aki Yoshida Assignee: William Tam Fix For: 2.8.0 Attachments: camel-cxf-20110429b-patch.txt Original Estimate: 2h Remaining Estimate: 2h When using the Provider based service (i.e., one using the ProviderSource's invoke(Source m) signature), I observed that the payload content is not correctly extracted in the first call. The reason seems to be that the content is passed as a StaxSource instance to the camel's cxf binding component (DefaultCxfBinding) and this expects currently a DOMSource for the payload data format and therefore it not able to extract the payload content. Some more information is described in a related mail thread at camel-user http://camel.465427.n5.nabble.com/Question-on-RemoveClassTypeInterceptor-in-Camel-Cxf-s-Payload-mode-td4358188.html This problem can be reproduced using CxfConsumerProviderTest when this test is executed using the payload data format. I suppose this test should actually be executed in the payload data format mode. But this is currently not the case. So, I am attaching the modified CxfConsumerProviderTest that uses the payload data format. This test will fail with the current trunk camel-cxf implementation. I am also attatching the patch file of the suggested change in DefaultCxfBinding that can resolve this issue and successfully pass this test. I think we can eventually consider a different CxfPayload implementation that does not require a DOM object at all. But for now, I think we can live with this correction to avoid this payload extraction issue. Thanks. Regards, Aki -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-3927) CXF's Provider service using the payload data-format may not transfer the payload correctly
[ https://issues.apache.org/jira/browse/CAMEL-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-3927. Resolution: Fixed Committed revision 1098630. Thanks Aki Yoshida for the Jira and the patch. CXF's Provider service using the payload data-format may not transfer the payload correctly --- Key: CAMEL-3927 URL: https://issues.apache.org/jira/browse/CAMEL-3927 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.7.1 Reporter: Aki Yoshida Assignee: William Tam Fix For: 2.8.0 Attachments: camel-cxf-20110429b-patch.txt Original Estimate: 2h Remaining Estimate: 2h When using the Provider based service (i.e., one using the ProviderSource's invoke(Source m) signature), I observed that the payload content is not correctly extracted in the first call. The reason seems to be that the content is passed as a StaxSource instance to the camel's cxf binding component (DefaultCxfBinding) and this expects currently a DOMSource for the payload data format and therefore it not able to extract the payload content. Some more information is described in a related mail thread at camel-user http://camel.465427.n5.nabble.com/Question-on-RemoveClassTypeInterceptor-in-Camel-Cxf-s-Payload-mode-td4358188.html This problem can be reproduced using CxfConsumerProviderTest when this test is executed using the payload data format. I suppose this test should actually be executed in the payload data format mode. But this is currently not the case. So, I am attaching the modified CxfConsumerProviderTest that uses the payload data format. This test will fail with the current trunk camel-cxf implementation. I am also attatching the patch file of the suggested change in DefaultCxfBinding that can resolve this issue and successfully pass this test. I think we can eventually consider a different CxfPayload implementation that does not require a DOM object at all. But for now, I think we can live with this correction to avoid this payload extraction issue. Thanks. Regards, Aki -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-3810) At payload model, set soap body element to header uncorrectly
[ https://issues.apache.org/jira/browse/CAMEL-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam reassigned CAMEL-3810: -- Assignee: William Tam (was: Willem Jiang) At payload model, set soap body element to header uncorrectly - Key: CAMEL-3810 URL: https://issues.apache.org/jira/browse/CAMEL-3810 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.4.0 Reporter: ext2 Assignee: William Tam Attachments: CXFMultiPartTest.java, MultiPartInvokeImpl.java, MultiPartTest.wsdl, MultiPartTest.xml if wsdl's operatin's has multi parts and the parts use same xml-element. Camel CXF Payload model, will mixup the xml element in body with header -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-3810) At payload model, set soap body element to header uncorrectly
[ https://issues.apache.org/jira/browse/CAMEL-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam reassigned CAMEL-3810: -- Assignee: Willem Jiang (was: William Tam) At payload model, set soap body element to header uncorrectly - Key: CAMEL-3810 URL: https://issues.apache.org/jira/browse/CAMEL-3810 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.4.0 Reporter: ext2 Assignee: Willem Jiang Attachments: CXFMultiPartTest.java, MultiPartInvokeImpl.java, MultiPartTest.wsdl, MultiPartTest.xml if wsdl's operatin's has multi parts and the parts use same xml-element. Camel CXF Payload model, will mixup the xml element in body with header -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-3808) Restlet Producer to add query to request URI based on runtime information (e.g. Camel header)
Restlet Producer to add query to request URI based on runtime information (e.g. Camel header) - Key: CAMEL-3808 URL: https://issues.apache.org/jira/browse/CAMEL-3808 Project: Camel Issue Type: Improvement Components: camel-restlet Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.8.0 Currently, custom queries to be sent in the request URI must be defined in the route. It is more usable to set the request URI queries at runtime. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-3808) Restlet Producer to add query to request URI based on runtime information (e.g. Camel header)
[ https://issues.apache.org/jira/browse/CAMEL-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-3808. Resolution: Fixed Committed revision 1085543. Restlet Producer to add query to request URI based on runtime information (e.g. Camel header) - Key: CAMEL-3808 URL: https://issues.apache.org/jira/browse/CAMEL-3808 Project: Camel Issue Type: Improvement Components: camel-restlet Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.8.0 Currently, custom queries to be sent in the request URI must be defined in the route. It is more usable to set the request URI queries at runtime. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-3808) Restlet Producer to add query to request URI based on runtime information (e.g. Camel header)
[ https://issues.apache.org/jira/browse/CAMEL-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam updated CAMEL-3808: --- Issue Type: Bug (was: Improvement) It looks we have documented this feature (setting CamelHttpQuery header to add query to request URI). So, it is possibly a regression bug. Restlet Producer to add query to request URI based on runtime information (e.g. Camel header) - Key: CAMEL-3808 URL: https://issues.apache.org/jira/browse/CAMEL-3808 Project: Camel Issue Type: Bug Components: camel-restlet Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.8.0 Currently, custom queries to be sent in the request URI must be defined in the route. It is more usable to set the request URI queries at runtime. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009195#comment-13009195
]
William Tam commented on CAMEL-3778:
@Aki
I don't think the option is confusing (pls suggest a better name if you can
think of something) or unnecessary. Keep in mind that the proposed option is
specific for PAYLOAD mode only. You don't need set any options to send
arbitrary payloads if you are using MESSAGE mode (which I'd recommend and it is
faster).
In PAYLOAD mode, we need to make sure the XML message parts are properly added
to CXF Message Content List. So, obviously the check should be performed by
default. The skipPayloadMessagePartCheck option would allow users to put any
XML elements in the Message Content List if they desire (which I think it is an
abuse). Perhaps, explicit setting the option is a good way to document/remind
users that the endpoint will skip payload message part checking. Do it make
sense?
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009227#comment-13009227
]
William Tam edited comment on CAMEL-3778 at 3/21/11 5:34 PM:
-
@Aki, Here is what I think ... I don't think wsdlURL and serviceClass options
necessarily imply skipPayloadMessagePartCheck (and vice versa). I don't think
explicitly setting the skipPayloadMessagePartCheck is necessarily a bad thing.
was (Author: wtam):
@Aki, Here is what I think ... I don't think wsdlURL and serviceClass
options necessarily imply skipPayloadMessagePartCheck (and vice versa). I
don't think explicit setting the skipPayloadMessagePartCheck is necessarily a
bad thing.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009229#comment-13009229
]
William Tam commented on CAMEL-3778:
BTW, I don't think it has anything to do with Dispatch mode per se. It is more
about to ability to skip payload message checking.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009227#comment-13009227
]
William Tam edited comment on CAMEL-3778 at 3/21/11 5:39 PM:
-
@Aki, Here is what I think ... I don't think wsdlURL and serviceClass options
necessarily imply skipPayloadMessagePartCheck (and vice versa). I don't think
explicitly setting the skipPayloadMessagePartCheck option is necessarily a bad
thing.
was (Author: wtam):
@Aki, Here is what I think ... I don't think wsdlURL and serviceClass
options necessarily imply skipPayloadMessagePartCheck (and vice versa). I
don't think explicitly setting the skipPayloadMessagePartCheck is necessarily a
bad thing.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009238#comment-13009238
]
William Tam commented on CAMEL-3778:
@Aki,
I am OK with killing the endpoint option (skipPayloadMessagePartCheck). A
boolean is maintained internally and it is set to true if the default SEI
(serviceClass) is in effect.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009521#comment-13009521
]
William Tam commented on CAMEL-3778:
@Willem
Not quite sure what you meant. The (Camel CXF) endpoint does not know about
Dispatch Model, right? If you voted for killing the
skipPayloadMessagePartCheck, then we are all in agreement.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-3778:
---
Attachment: CAMEL-3386.patch
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, patch-20110310.txt, tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008874#comment-13008874
]
William Tam commented on CAMEL-3778:
Here is the mail thread related to this issue.
http://camel.465427.n5.nabble.com/camel-cxf-endpoint-without-wsdl-and-serviceClass-possible-td3385901.html#a3387482
@Aki
I made some updates to your patch. Please review CAMEL-3386.patch and provide
your feedbacks.
* I added a boolean option skipPayloadMessagePartCheck to switch on/off the
check for expected message parts in CxfEndpoint.setParameters(). (To other
readers, the enforcement of the check precludes sending arbitrary payload in
PAYLOAD/MESSAGE mode as Aki has found out.) The default should be false (i.e.
do checking). In your patch, to skip the checking when it sees null part name
is probably not a good idea.
* I avoided the hard coded CXF operation info in the CxfEndpoint class by JAXWS
annotations in the Default SEI (i.e. dummy serviceClass), which makes it
cleaner and shielded from CXF model APIs changes.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, patch-20110310.txt, tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008874#comment-13008874
]
William Tam edited comment on CAMEL-3778 at 3/20/11 3:56 AM:
-
Here is the mail thread related to this issue.
http://camel.465427.n5.nabble.com/camel-cxf-endpoint-without-wsdl-and-serviceClass-possible-td3385901.html#a3387482
@Aki
I made some updates to your patch. Please review CAMEL-3386.patch (I messed up
the number) and provide your feedbacks.
* I added a boolean option skipPayloadMessagePartCheck to switch on/off the
check for expected message parts in CxfEndpoint.setParameters(). (To other
readers, the enforcement of the check precludes sending arbitrary payload in
PAYLOAD/MESSAGE mode as Aki has found out.) The default should be false (i.e.
do checking). In your patch, to skip the checking when it sees null part name
is probably not a good idea.
* I avoided the hard coded CXF operation info in the CxfEndpoint class by JAXWS
annotations in the Default SEI (i.e. dummy serviceClass), which makes it
cleaner and shielded from CXF model APIs changes.
was (Author: wtam):
Here is the mail thread related to this issue.
http://camel.465427.n5.nabble.com/camel-cxf-endpoint-without-wsdl-and-serviceClass-possible-td3385901.html#a3387482
@Aki
I made some updates to your patch. Please review CAMEL-3386.patch and provide
your feedbacks.
* I added a boolean option skipPayloadMessagePartCheck to switch on/off the
check for expected message parts in CxfEndpoint.setParameters(). (To other
readers, the enforcement of the check precludes sending arbitrary payload in
PAYLOAD/MESSAGE mode as Aki has found out.) The default should be false (i.e.
do checking). In your patch, to skip the checking when it sees null part name
is probably not a good idea.
* I avoided the hard coded CXF operation info in the CxfEndpoint class by JAXWS
annotations in the Default SEI (i.e. dummy serviceClass), which makes it
cleaner and shielded from CXF model APIs changes.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, patch-20110310.txt, tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-3778:
---
Attachment: CAMEL-3778.patch
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008874#comment-13008874
]
William Tam edited comment on CAMEL-3778 at 3/20/11 4:01 AM:
-
Here is the mail thread related to this issue.
http://camel.465427.n5.nabble.com/camel-cxf-endpoint-without-wsdl-and-serviceClass-possible-td3385901.html#a3387482
@Aki
I made some updates to your patch. Please review CAMEL-3778.patch (ignore
CAMEL-3386.patch) and provide your feedbacks.
* I added a boolean option skipPayloadMessagePartCheck to switch on/off the
check for expected message parts in CxfEndpoint.setParameters(). (To other
readers, the enforcement of the check precludes sending arbitrary payload in
PAYLOAD/MESSAGE mode as Aki has found out.) The default should be false (i.e.
do checking). In your patch, to skip the checking when it sees null part name
is probably not a good idea.
* I avoided the hard coded CXF operation info in the CxfEndpoint class by JAXWS
annotations in the Default SEI (i.e. dummy serviceClass), which makes it
cleaner and shielded from CXF model APIs changes.
was (Author: wtam):
Here is the mail thread related to this issue.
http://camel.465427.n5.nabble.com/camel-cxf-endpoint-without-wsdl-and-serviceClass-possible-td3385901.html#a3387482
@Aki
I made some updates to your patch. Please review CAMEL-3386.patch (I messed up
the number) and provide your feedbacks.
* I added a boolean option skipPayloadMessagePartCheck to switch on/off the
check for expected message parts in CxfEndpoint.setParameters(). (To other
readers, the enforcement of the check precludes sending arbitrary payload in
PAYLOAD/MESSAGE mode as Aki has found out.) The default should be false (i.e.
do checking). In your patch, to skip the checking when it sees null part name
is probably not a good idea.
* I avoided the hard coded CXF operation info in the CxfEndpoint class by JAXWS
annotations in the Default SEI (i.e. dummy serviceClass), which makes it
cleaner and shielded from CXF model APIs changes.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008874#comment-13008874
]
William Tam edited comment on CAMEL-3778 at 3/20/11 5:14 AM:
-
Here is the mail thread related to this issue.
http://camel.465427.n5.nabble.com/camel-cxf-endpoint-without-wsdl-and-serviceClass-possible-td3385901.html#a3387482
@Aki
I made some updates to your patch. Please review CAMEL-3778.patch (ignore
CAMEL-3386.patch) and provide your feedbacks.
* I added a boolean option skipPayloadMessagePartCheck to switch on/off the
check for expected message parts in CxfEndpoint.setParameters(). (To other
readers, the enforcement of the check precludes sending arbitrary payload in
PAYLOAD mode as Aki has found out.) The default should be false (i.e. do
checking). In your patch, to skip the checking when it sees null part name is
probably not a good idea.
* I avoided the hard coded CXF operation info in the CxfEndpoint class by JAXWS
annotations in the Default SEI (i.e. dummy serviceClass), which makes it
cleaner and shielded from CXF model APIs changes.
was (Author: wtam):
Here is the mail thread related to this issue.
http://camel.465427.n5.nabble.com/camel-cxf-endpoint-without-wsdl-and-serviceClass-possible-td3385901.html#a3387482
@Aki
I made some updates to your patch. Please review CAMEL-3778.patch (ignore
CAMEL-3386.patch) and provide your feedbacks.
* I added a boolean option skipPayloadMessagePartCheck to switch on/off the
check for expected message parts in CxfEndpoint.setParameters(). (To other
readers, the enforcement of the check precludes sending arbitrary payload in
PAYLOAD/MESSAGE mode as Aki has found out.) The default should be false (i.e.
do checking). In your patch, to skip the checking when it sees null part name
is probably not a good idea.
* I avoided the hard coded CXF operation info in the CxfEndpoint class by JAXWS
annotations in the Default SEI (i.e. dummy serviceClass), which makes it
cleaner and shielded from CXF model APIs changes.
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.8.0
Attachments: CAMEL-3386.patch, CAMEL-3778.patch, patch-20110310.txt,
tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (CAMEL-3778) Support CXF Dispatch mode at CXF Endpoints
[
https://issues.apache.org/jira/browse/CAMEL-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam reassigned CAMEL-3778:
--
Assignee: William Tam
Support CXF Dispatch mode at CXF Endpoints
--
Key: CAMEL-3778
URL: https://issues.apache.org/jira/browse/CAMEL-3778
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Affects Versions: 2.6.0
Reporter: Aki Yoshida
Assignee: William Tam
Fix For: 2.7.0
Attachments: patch-20110310.txt, tests.zip
Hi,
Sometime ago I asked in this mailing list whether it is possible to use the
dispatch mode of CXF in the Camel's CXF endpoint. The answer was no. But I
wanted to have the CXF dispatch mode so that I can run SOAP
intermediary/gateway scenarios with CXF features enabled and send arbitrary
SOAP messages from a single endpoint.
Now I have implemented this feature and I would like to hear what you think.
In short, I modified CxfSpringEndpoint and CxfEndpoint so that Camel uses the
CXF dispatch mode when no service class nor WSDL is specified in the endpoint
configuration. For example, you can configure the endpoint as:
{code:xml}
cxf:cxfEndpoint id=serviceEndpoint
address=http://localhost:9000/SoapContext/GreeterPort;
endpointName=s:GreeterPort
serviceName=s:GreeterService
bus=#bus
cxf:properties
entry key=dataFormat value=PAYLOAD/
/cxf:properties
/cxf:cxfEndpoint
{code}
In this case, the endpoint is set up for the dispatch mode. The dispatch mode
supports two operations Invoke and InvokeOneWay and the default operation is
Invoke. You can change the operation by simply setting the camel header
operationName.
I added two unit tests classes to show how the dispatch mode works for both
PAYLOAD and MESSAGE data format.
I am attached all the file to this ticket. I would appreciate if you can
comment on this feature.
Thanks.
Regards, Aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache Camel 2.6.0
+1 On 01/24/2011 10:14 PM, Hadrian Zbarcea wrote: A new release apache-camel-2.6.0 is out with approximately 297 issues resolved: new features, improvements and bug fixes. Please find the staging repo here: https://repository.apache.org/content/repositories/orgapachecamel-073/ The tarballs are here https://repository.apache.org/content/repositories/orgapachecamel-073/org/apache/camel/apache-camel/2.6.0/ Please review and vote to approve this release binary. Your vote counts! [ ] +1 Release the binary as Apache Camel 2.6.0 [ ] -1 Veto the release (provide specific comments) Vote is open for 72 hours. Here's my +1 Hadrian
[jira] Created: (CAMEL-3420) CXF component should be smarter in determining the DataFormat based on the Camel message type
CXF component should be smarter in determining the DataFormat based on the Camel message type - Key: CAMEL-3420 URL: https://issues.apache.org/jira/browse/CAMEL-3420 Project: Camel Issue Type: Improvement Components: camel-cxf Reporter: William Tam Priority: Minor Please see the cross reference in org.apache.camel.component.cxf.CxfMixedModeRouterTest. We set the data format in the exchange properties. If we want to support mixed mode in a same route more seamlessly, we should make the component detect data format based on message type to avoid burdening the users to reset the property back to match the from endpoint's data format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-3420) CXF component should be smarter in determining the DataFormat based on the Camel message type
[ https://issues.apache.org/jira/browse/CAMEL-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam updated CAMEL-3420: --- Fix Version/s: 2.6.0 Assignee: William Tam CXF component should be smarter in determining the DataFormat based on the Camel message type - Key: CAMEL-3420 URL: https://issues.apache.org/jira/browse/CAMEL-3420 Project: Camel Issue Type: Improvement Components: camel-cxf Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.6.0 Please see the cross reference in org.apache.camel.component.cxf.CxfMixedModeRouterTest. We set the data format in the exchange properties. If we want to support mixed mode in a same route more seamlessly, we should make the component detect data format based on message type to avoid burdening the users to reset the property back to match the from endpoint's data format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-3386) Support destination address override by CxfProvider and CxfrsProvider
[ https://issues.apache.org/jira/browse/CAMEL-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969030#action_12969030 ] William Tam commented on CAMEL-3386: Hi Willem, Even the interceptor chain is created dynamically, it created based on the service endpoint configured in the route. However, you point is well taken that we probably don't need to maintain client cache if we can set CXF's Exchange.ENDPOINT_ADDRESS in the Request Context to override the address. I'll look into removing the client cache. The new property in Camel was created with the intention that it can be reused by other component. So, that probably will stay. Thanks. Support destination address override by CxfProvider and CxfrsProvider - Key: CAMEL-3386 URL: https://issues.apache.org/jira/browse/CAMEL-3386 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.6.0 Attachments: CAMEL-3386.patch So far, users can only send requests to REST/SOAP service endpoints that have been explicitly defined in Camel routes. Sometimes, it is useful to override the destination address at runtime (eliminating the need of adding an explicit route or the need of knowing about future service endpoint deployment at the configuring time). The assumption is these service endpoints are identical but running at different locations. This feature can greatly simplify the route configuration if there are tens (or hundreds) of identical services to be invoked. With the included patch, CxfProvider and CxfrsProvider will honor the CamelDestinationOverrideUrl header and use the value as the target address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-3386) Support destination address override by CxfProvider and CxfrsProvider
[ https://issues.apache.org/jira/browse/CAMEL-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969066#action_12969066 ] William Tam commented on CAMEL-3386: @Willem I removed the client cache in CxfProducer as suggested. The client factory bean cache in CxfrsProducer provider should probably stay. There is no easy way to get at the request context. If we find a way, It is probably a back door way. The factory bean cache is light weight (not caching the client itself) and it uses SoftReference. Committed revision 1043223. Support destination address override by CxfProvider and CxfrsProvider - Key: CAMEL-3386 URL: https://issues.apache.org/jira/browse/CAMEL-3386 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.6.0 Attachments: CAMEL-3386.patch So far, users can only send requests to REST/SOAP service endpoints that have been explicitly defined in Camel routes. Sometimes, it is useful to override the destination address at runtime (eliminating the need of adding an explicit route or the need of knowing about future service endpoint deployment at the configuring time). The assumption is these service endpoints are identical but running at different locations. This feature can greatly simplify the route configuration if there are tens (or hundreds) of identical services to be invoked. With the included patch, CxfProvider and CxfrsProvider will honor the CamelDestinationOverrideUrl header and use the value as the target address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-3386) Support destination address override by CxfProvider and CxfrsProvider
[ https://issues.apache.org/jira/browse/CAMEL-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-3386. Resolution: Fixed Committed to trunk revision 1042677. Support destination address override by CxfProvider and CxfrsProvider - Key: CAMEL-3386 URL: https://issues.apache.org/jira/browse/CAMEL-3386 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.6.0 Attachments: CAMEL-3386.patch So far, users can only send requests to REST/SOAP service endpoints that have been explicitly defined in Camel routes. Sometimes, it is useful to override the destination address at runtime (eliminating the need of adding an explicit route or the need of knowing about future service endpoint deployment at the configuring time). The assumption is these service endpoints are identical but running at different locations. This feature can greatly simplify the route configuration if there are tens (or hundreds) of identical services to be invoked. With the included patch, CxfProvider and CxfrsProvider will honor the CamelDestinationOverrideUrl header and use the value as the target address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-3386) Support destination address override by CxfProvider and CxfrsProvider
Support destination address override by CxfProvider and CxfrsProvider - Key: CAMEL-3386 URL: https://issues.apache.org/jira/browse/CAMEL-3386 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Priority: Minor Fix For: 2.6.0 So far, users can only send requests to REST/SOAP service endpoints that have been explicitly defined in Camel routes. Sometimes, it is useful to override the destination address at runtime (eliminating the need of adding an explicit route or the need of knowing about future service endpoint deployment at the configuring time). The assumption is these service endpoints are identical but running at different locations. This feature can greatly simplify the route configuration if there are tens (or hundreds) of identical services to be invoked. With the included patch, CxfProvider and CxfrsProvider will honor the CamelDestinationOverrideUrl header and use the value as the target address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-3386) Support destination address override by CxfProvider and CxfrsProvider
[ https://issues.apache.org/jira/browse/CAMEL-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam updated CAMEL-3386: --- Attachment: CAMEL-3386.patch Support destination address override by CxfProvider and CxfrsProvider - Key: CAMEL-3386 URL: https://issues.apache.org/jira/browse/CAMEL-3386 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Priority: Minor Fix For: 2.6.0 Attachments: CAMEL-3386.patch So far, users can only send requests to REST/SOAP service endpoints that have been explicitly defined in Camel routes. Sometimes, it is useful to override the destination address at runtime (eliminating the need of adding an explicit route or the need of knowing about future service endpoint deployment at the configuring time). The assumption is these service endpoints are identical but running at different locations. This feature can greatly simplify the route configuration if there are tens (or hundreds) of identical services to be invoked. With the included patch, CxfProvider and CxfrsProvider will honor the CamelDestinationOverrideUrl header and use the value as the target address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-3386) Support destination address override by CxfProvider and CxfrsProvider
[ https://issues.apache.org/jira/browse/CAMEL-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam reassigned CAMEL-3386: -- Assignee: William Tam Support destination address override by CxfProvider and CxfrsProvider - Key: CAMEL-3386 URL: https://issues.apache.org/jira/browse/CAMEL-3386 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Assignee: William Tam Priority: Minor Fix For: 2.6.0 Attachments: CAMEL-3386.patch So far, users can only send requests to REST/SOAP service endpoints that have been explicitly defined in Camel routes. Sometimes, it is useful to override the destination address at runtime (eliminating the need of adding an explicit route or the need of knowing about future service endpoint deployment at the configuring time). The assumption is these service endpoints are identical but running at different locations. This feature can greatly simplify the route configuration if there are tens (or hundreds) of identical services to be invoked. With the included patch, CxfProvider and CxfrsProvider will honor the CamelDestinationOverrideUrl header and use the value as the target address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-3308) Upgrade CXF version to 2.3.0
[ https://issues.apache.org/activemq/browse/CAMEL-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=63037#action_63037 ] William Tam commented on CAMEL-3308: Just stating the obvious, but please make sure camel-cxf 2.6 is backward compatible (in APIs and config) and fully support CXF 2.2.x if we do upgrade to CXF 2.3 in Camel 2.6. Upgrade CXF version to 2.3.0 Key: CAMEL-3308 URL: https://issues.apache.org/activemq/browse/CAMEL-3308 Project: Apache Camel Issue Type: Task Components: camel-cxf Reporter: Willem Jiang Assignee: Willem Jiang Priority: Minor Fix For: 2.6.0 We could leverage some new features of CXF 2.3.x by doing this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSS] CXF 2.3 upgrade in Camel 2.6?
Willem and I would like to start a discussion regarding which release of Camel should be upgraded to CXF 2.3. There is a lot of good reasons to upgrade to CXF 2.3. However, upgrading it in Camel 2.6 could mean stopping supporting CXF 2.2.x in the future Camel 2.x releases. (see https://issues.apache.org/activemq/browse/CAMEL-3308) It also means that users who upgrade to Camel 2.6 will be forced to upgrade to CXF 2.3. It is almost certain that Camel 3 will have CXF 2.3.x, which (Camel 3) is targeted from 1st quarter of 2011. It is not that far away. So, let's hear your opinion on whether we should upgrade to CXF 2.3 in Camel 2.6 or not? Thanks, Willem and William
[jira] Commented: (CAMEL-3308) Upgrade CXF version to 2.3.0
[ https://issues.apache.org/activemq/browse/CAMEL-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=63054#action_63054 ] William Tam commented on CAMEL-3308: @dan Junit tests only test against CXF 2.3, then? So, testing with CXF 2.2 is pretty much done by hand? Upgrade CXF version to 2.3.0 Key: CAMEL-3308 URL: https://issues.apache.org/activemq/browse/CAMEL-3308 Project: Apache Camel Issue Type: Task Components: camel-cxf Reporter: Willem Jiang Assignee: Willem Jiang Priority: Minor Fix For: 2.6.0 We could leverage some new features of CXF 2.3.x by doing this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] CXF 2.3 upgrade in Camel 2.6?
Thanks. On 11/04/2010 10:21 PM, Willem Jiang wrote: I think the configuration is OK, but there are some big upgrade of Jetty, jaxws, jaxb in the CXF 2.3.x will make the user to do adjustment his runtime evironment. Fortunately camel-cxf have nothing to with it. I just did some work to make camel-cxf work with CXF 2.2.x and CXF 2.3.x at the same time. The user can make their own choice now :) On 11/5/10 4:33 AM, William Tam wrote: I think there are reasons not to (not sure if they are good reasons though) * Don't have to touch Camel 2.x camel-cxf component We can then direct the effort/focus to Camel 3 to make it happen sooner. * We probably still don't know this for sure yet. Besides the runtime, spring configuration and camel-cxf APIs probably should be backward compatible. Otherwise, Camel 2.6 upgrade could mean configuration change exercises for users. On 11/04/2010 03:28 PM, Hadrian Zbarcea wrote: Is there a good reason not to? One would use the camel-cxf component either to expose a route as a ws (from) or to invoke a ws (to). From this point of view, the backward compatibility we require is on the wire, which I am pretty certain we do satisfy. The other issue is deployment, camel having a new set of dependencies would require an app to upgrade. In an osgi environment that should not be a problem. In a webapp it could be a bit problematic, but if the camel piece is in a separate war, that should be fine too. By the way, this is a discussion for dev@, not us...@. Cheers Hadrian On Nov 4, 2010, at 10:40 AM, William Tam wrote: Willem and I would like to start a discussion regarding which release of Camel should be upgraded to CXF 2.3. There is a lot of good reasons to upgrade to CXF 2.3. However, upgrading it in Camel 2.6 could mean stopping supporting CXF 2.2.x in the future Camel 2.x releases. (see https://issues.apache.org/activemq/browse/CAMEL-3308) It also means that users who upgrade to Camel 2.6 will be forced to upgrade to CXF 2.3. It is almost certain that Camel 3 will have CXF 2.3.x, which (Camel 3) is targeted from 1st quarter of 2011. It is not that far away. So, let's hear your opinion on whether we should upgrade to CXF 2.3 in Camel 2.6 or not? Thanks, Willem and William
Re: [VOTE] Release Apache Camel 2.5.0
+1 It looks good. On Mon, Oct 25, 2010 at 5:19 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: A new release apache-camel-2.5.0 is out with approximately 300 issues resolved: new features, improvements and bug fixes. Please find the staging repo here: https://repository.apache.org/content/repositories/orgapachecamel-004/ The tarballs are here https://repository.apache.org/content/repositories/orgapachecamel-004/org/apache/camel/apache-camel/2.5.0/ I did a quick check of the artifacts, the .formatted files are no longer there, signatures look ok. Please review and vote to approve this release binary. Your vote counts! [ ] +1 Release the binary as Apache Camel 2.5.0 [ ] -1 Veto the release (provide specific comments) Vote is open for 72 hours. Here's my +1
[jira] Commented: (CAMEL-3055) camel-cxf component to support SOAP with Attachment in Payload mode
[ https://issues.apache.org/activemq/browse/CAMEL-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=61238#action_61238 ] William Tam commented on CAMEL-3055: svn ci -m [CAMEL-3055] made CxfMtomDisabledProducerPayloadModeTest more reliable by not depending on mailcap setting in the environment Sending camel-cxf/src/test/java/org/apache/camel/component/cxf/mtom/CxfMtomDisabledProducerPayloadModeTest.java Transmitting file data . Committed revision 986392. w...@lenw500:~/repos/apache/camel/trunk/components/camel-cxf$ camel-cxf component to support SOAP with Attachment in Payload mode --- Key: CAMEL-3055 URL: https://issues.apache.org/activemq/browse/CAMEL-3055 Project: Apache Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Assignee: William Tam Fix For: 2.5.0 camel-cxf component to support SOAP with Attachment in Payload mode -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-3055) camel-cxf component to support SOAP with Attachment in Payload mode
camel-cxf component to support SOAP with Attachment in Payload mode --- Key: CAMEL-3055 URL: https://issues.apache.org/activemq/browse/CAMEL-3055 Project: Apache Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Assignee: William Tam Fix For: 2.5.0 camel-cxf component to support SOAP with Attachment in Payload mode -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (CAMEL-3055) camel-cxf component to support SOAP with Attachment in Payload mode
[ https://issues.apache.org/activemq/browse/CAMEL-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-3055 started by William Tam. camel-cxf component to support SOAP with Attachment in Payload mode --- Key: CAMEL-3055 URL: https://issues.apache.org/activemq/browse/CAMEL-3055 Project: Apache Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Assignee: William Tam Fix For: 2.5.0 camel-cxf component to support SOAP with Attachment in Payload mode -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-3055) camel-cxf component to support SOAP with Attachment in Payload mode
[ https://issues.apache.org/activemq/browse/CAMEL-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-3055. Resolution: Fixed Committed revision 985362. camel-cxf component to support SOAP with Attachment in Payload mode --- Key: CAMEL-3055 URL: https://issues.apache.org/activemq/browse/CAMEL-3055 Project: Apache Camel Issue Type: New Feature Components: camel-cxf Reporter: William Tam Assignee: William Tam Fix For: 2.5.0 camel-cxf component to support SOAP with Attachment in Payload mode -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-3001) Endpoints are recreated instead or restarted
Endpoints are recreated instead or restarted
Key: CAMEL-3001
URL: https://issues.apache.org/activemq/browse/CAMEL-3001
Project: Apache Camel
Issue Type: Bug
Components: camel-core
Reporter: William Tam
Fix For: 2.5.0
The change (r979549) made by CAMEL-2991 causes every single endpoint to be
recreated instead of restarted which takes Camel a (quite big) step back. It
is bad for the following reasons:
1) recreating services associated could be expensive (the design should not
assume recreating the services is cheap).
2) states (if any) in Endpoint/Service could not be preserved (stop does not
mean destroy after all).
3) it is unnecessary to recreate to the whole shebank and it is an unexpected
behavior for the users. (Users think stop but it is gone.)
In the code (DefaultCamelContext.doStartCamel()), one can clearly see the
original intent of the author (who even bothered to put in a nice comment) is
to avoid re-initialization the route definition after stopping the camel
context. (Well, things may change but not necessarily for the better.)
{code}
// To avoid initiating the routeDefinitions after stopping the camel
context
if (!routeDefinitionInitiated) {
startRouteDefinitions(routeDefinitions);
routeDefinitionInitiated = true;
}
{code}
But, the change simply reset the routeDefinitionInitiated flag in doStop()
which is the exact opposite of the original intention and
routeDefinitionInitiated is unless pretty much. :-(
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2991) Restart CamelContext won't restart services on CxfBeanEndpoint
[
https://issues.apache.org/activemq/browse/CAMEL-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-2991:
---
Attachment: CAMEL-2991-test-case.txt
Restart CamelContext won't restart services on CxfBeanEndpoint
--
Key: CAMEL-2991
URL: https://issues.apache.org/activemq/browse/CAMEL-2991
Project: Apache Camel
Issue Type: Bug
Components: camel-core, camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.5.0
Attachments: CAMEL-2991-test-case.txt, CAMEL-2991.patch
A route that sends to a CxfBean destination is unusable after the
CamelContext has been stopped and re-started. The following is an example of
a route that demonstrates the problem.
{code}
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from
uri=jetty:http://localhost:9000?matchOnUriPrefix=true; /
to uri=cxfbean:customerServiceBean /
/route
/camelContext
util:list id=customerServiceBean
bean
class=org.apache.camel.component.cxf.jaxrs.testbean.CustomerService /
/util:list
{code}
The follow issues have been identified.
1) SendProcessor should implement the Navigate interface so that its children
(if they are Services) can be managed by the lifecycle methods. This will
address any destination endpoint that requires services to be re-started.
2) CxfBeanEndpoint should be a Service itself. The reason why the start() on
CxfBeanEndpoint gets called during the first start is because
CxfBeanComponent.start() gets invoked during route definition initialization.
The problem is that re-starting doesn't trigger the
CxfBeanComponent.start() method. Therefore, putting the hook in
CxfBeanComponent to start/stop CxfBeanEndpoint was a bug.
3) The default type converter which is a Service won't get re-started' as
the (lazy-instantiation) getTypeConverter() method won't perform addService()
on a created but stopped' typeConverter. We need to discuss the correct
remedy since I am not sure how to fix it. It is kind of strange that the
type converter is a service (which has the start/stop semantics) and yet it
can be used even the CamelContext is stopped (or never started). In the
patch, I just set the type converter to null in DefaultCamelContext doStop()
for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-2991) Restart CamelContext won't restart services on CxfBeanEndpoint
[
https://issues.apache.org/activemq/browse/CAMEL-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam reassigned CAMEL-2991:
--
Assignee: Claus Ibsen (was: William Tam)
@claus I tried your fixes but my route is still unusable after CamelContext is
restarted. I attached the test case and assign to you. Thanks for looking at
it.
Restart CamelContext won't restart services on CxfBeanEndpoint
--
Key: CAMEL-2991
URL: https://issues.apache.org/activemq/browse/CAMEL-2991
Project: Apache Camel
Issue Type: Bug
Components: camel-core, camel-cxf
Reporter: William Tam
Assignee: Claus Ibsen
Fix For: 2.5.0
Attachments: CAMEL-2991-test-case.txt
A route that sends to a CxfBean destination is unusable after the
CamelContext has been stopped and re-started. The following is an example of
a route that demonstrates the problem.
{code}
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from
uri=jetty:http://localhost:9000?matchOnUriPrefix=true; /
to uri=cxfbean:customerServiceBean /
/route
/camelContext
util:list id=customerServiceBean
bean
class=org.apache.camel.component.cxf.jaxrs.testbean.CustomerService /
/util:list
{code}
The follow issues have been identified.
1) SendProcessor should implement the Navigate interface so that its children
(if they are Services) can be managed by the lifecycle methods. This will
address any destination endpoint that requires services to be re-started.
2) CxfBeanEndpoint should be a Service itself. The reason why the start() on
CxfBeanEndpoint gets called during the first start is because
CxfBeanComponent.start() gets invoked during route definition initialization.
The problem is that re-starting doesn't trigger the
CxfBeanComponent.start() method. Therefore, putting the hook in
CxfBeanComponent to start/stop CxfBeanEndpoint was a bug.
3) The default type converter which is a Service won't get re-started' as
the (lazy-instantiation) getTypeConverter() method won't perform addService()
on a created but stopped' typeConverter. We need to discuss the correct
remedy since I am not sure how to fix it. It is kind of strange that the
type converter is a service (which has the start/stop semantics) and yet it
can be used even the CamelContext is stopped (or never started). In the
patch, I just set the type converter to null in DefaultCamelContext doStop()
for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: CamelContext restart issues CAMEL-2991
On 07/26/2010 01:15 AM, Claus Ibsen wrote:
On Mon, Jul 26, 2010 at 1:27 AM, William Tamemail.w...@gmail.com wrote:
On 07/25/2010 01:56 PM, Claus Ibsen wrote:
On Sun, Jul 25, 2010 at 6:18 PM, William Tamemail.w...@gmail.comwrote:
Hi Claus,
Thanks for your response.
* A ProcessorEndpoint is a hybrid between a Processor and a Endpoint.
Therefore, SendProcessor does have a child if the destination is a
ProcessorEndpoint. Please take a look at
RouteService.doGetChildServices().
You will see why Navigate can allow services associated with the
ProcessEndpoint to be restarted.
No it does not have a child. It sends a message to an endpoint, period.
The processor endpoint is just an endpoint which uses an processor
where end users implement the logic what should happen when the
message is being sent to it.
From the route perspective the message is sent to an endpoint, no
matter what. How and where that endpoint is, should not be part of
navigate. Navigate is to be able to traverse the route graph deployed
in the camel context. For example to be used by tooling or the likes.
OK, I don't really care whether it has a child or not (whatever that means).
RouteService.doGetChildServices() is traversing the children using the
Navigate interface in order to start all of their services. It is wrong in
RouteService method that starts all the children services by using Navigate
interface then? This is the only way the services associated with the
ProcessEndpoint can be restarted. Or, you are suggesting ProcessEndpoint
should not implement Service since there is no guarantee the service will be
restarted by design?
Yes I agree that ProcessorEndpoint should be a Service so it has the
start/stop methods, you can leverage.
In fact the Endpoint should be a Service so all endpoints is being
started/stopped when you restart CamelContext.
I am working on adding this right now.
Thanks for the fix. I tried the latest and greatest in trunk.
Unfortunately, I still have problem with my route after the CC is
restarted. I think the problem (as mentioned) is related to
RouteService.doGetChildServices() leveraging the Navigate interface to
traverse the children in order to start services. (I guess what I think
it is not important). So, I attached my test case in the Jira and
assign it to you.
* Yes, when I say 'type converter, I mean the DefaultTypeConverter.
* If I am not mistaken, ShutdownCompleteAllTasksTest is one example that
the
DefaultTypeConverter was accessed after the DefaultTypeConverter has been
shutdown.
* I think you are against lazy loading of DefaultTypeConverter. I am
fine
with that. Then, we should really get rid of the lazy loading (in
DefaultCamelContext.getTypeConverter). That is really what the problem
is
because since it is a service, it gets stopped but the lazy loading does
NOT
re-start it. (Maybe you just fixed it. I haven't got a chance to try
it.)
And believe me, having both (a Service and lazy load and start) is
troublesome.
No the problem is that James S. named the method
forceInitLazyService() or something (the name is
forceLazyInitialization)
The type converter is started when CamelContext starts. And in essence
its not lazy. The getter appears to be lazy because you can plugin a
custom type converter registry and therefore the default instance is
created only if no custom has been assigned.
I (or anyone) can tell that DefaultContextContent.getTypeConverter is
definitely doing lazy initialization. See it for yourself. :-) Yes, I know
getTypeConverter() is called when the CamelContext is started but this is
not the only place getTypeConverter() is called. So, the first time it is
called, the type converter is created. In some cases (although mainly unit
tests), getTypeConverter() is called without CamelContext started is called.
public TypeConverter getTypeConverter() {
if (typeConverter == null) {
synchronized (this) {
// we can synchronize on this as there is only one instance
// of the camel context (its the container)
typeConverter = createTypeConverter();
try {
addService(typeConverter);
} catch (Exception e) {
throw ObjectHelper.wrapRuntimeCamelException(e);
}
}
}
return typeConverter;
}
You can also see addService() (which starts typeConverter) was only called
when a typeConverter was created by createTypeConverter(). Therefore, when
you restart the CamelContext, addService() is not called and therefore
typeConverter is not started. My point earlier was that combining lazy
initialization and addService() is troublesome. (I have not yet read your
latest fix though).
This has been fixed. I commented this on the JIRA ticket
Claus Ibsen added
Re: CamelContext restart issues CAMEL-2991
Hi Claus, Thanks for your response. * A ProcessorEndpoint is a hybrid between a Processor and a Endpoint. Therefore, SendProcessor does have a child if the destination is a ProcessorEndpoint. Please take a look at RouteService.doGetChildServices(). You will see why Navigate can allow services associated with the ProcessEndpoint to be restarted. * Yes, when I say 'type converter, I mean the DefaultTypeConverter. * If I am not mistaken, ShutdownCompleteAllTasksTest is one example that the DefaultTypeConverter was accessed after the DefaultTypeConverter has been shutdown. * I think you are against lazy loading of DefaultTypeConverter. I am fine with that. Then, we should really get rid of the lazy loading (in DefaultCamelContext.getTypeConverter). That is really what the problem is because since it is a service, it gets stopped but the lazy loading does NOT re-start it. (Maybe you just fixed it. I haven't got a chance to try it.) And believe me, having both (a Service and lazy load and start) is troublesome. * IMO, If DefaultTypeConverter is a Service, it should not be usable (throw an error something) in the stopped/not started state when someone tries to use it. Accessing a stopped DefaultTypeConverter is bad to say the least. You don't get an error, you just get different/wrong result. Cheers, William On 07/25/2010 02:46 AM, Claus Ibsen wrote: On Sun, Jul 25, 2010 at 5:55 AM, William Tamemail.w...@gmail.com wrote: I observed some issue regarding restarting Camel Context that I want to discuss. The detail is in the CAMEL-2991. * First off, any objection if SendProcessor implements Navigate? It allows services associated with the destination endpoint to be restarted. Why does navigate allow services associated with the destination to be restarted? Can you be more clear? The idea with navigate is for navigating the process graph. For example a Content Based Router, where you can navigate the when/otherwise processors etc. A SendProcessor doesn't have any children to navigate, and therefore should NOT be navigate. * There is a problem with type converter not getting restarted because the lazy instantiation won't start the services on the type converter unless the type converter is newly created. I notice (in a lot of unit tests) that it is OK to use the type converter even if the CamelContext (its container) is stopped or has never been started. If we want this behavior, then it does not seem to make sense for type converter to be a service. Type converter could be used anytime including during the shutdown cycling. Since type converter has been added to the servicesToClose list, the type converter could be stopped (unpredictably) when it is needed during the shutdown cycle. IMO, type converter probably should not be a service. I assume you mean the DefaultTypeConverter ? The DefaultTypeConverter must be a Service so CamelContext can start/stop it. It's important that it's the CamelContext that starts it on startup so all the type converters can be loaded up-front. Then there is no lazy loading. The problem with a lazy loading would be at runtime you can end up with concurrent access to the type converter registry and then multiple threads need to load the type converters, which enforces locking/synchronization. And you don't want this overhead at runtime. Hence the converters are loaded on startup. And to do this the DefaultTypeConverter MUST be a service so we have the start/stop methods. There is no strict check in several places of the code to check that a service is started before its being used. And therefore you can access code which has been stopped. Can you give an example of an unit test, which uses a type converter after CamelContext has been stopped? And when you say type converter you have to be more precise. There is a TypeConverterRegistry and then there are the 150+ individual type converters. The former is the DefaultTypeConverter which loads all the type converters. The latter is most often not a service because they are @Converter scanned.
Re: CamelContext restart issues CAMEL-2991
On 07/25/2010 01:56 PM, Claus Ibsen wrote:
On Sun, Jul 25, 2010 at 6:18 PM, William Tamemail.w...@gmail.com wrote:
Hi Claus,
Thanks for your response.
* A ProcessorEndpoint is a hybrid between a Processor and a Endpoint.
Therefore, SendProcessor does have a child if the destination is a
ProcessorEndpoint. Please take a look at RouteService.doGetChildServices().
You will see why Navigate can allow services associated with the
ProcessEndpoint to be restarted.
No it does not have a child. It sends a message to an endpoint, period.
The processor endpoint is just an endpoint which uses an processor
where end users implement the logic what should happen when the
message is being sent to it.
From the route perspective the message is sent to an endpoint, no
matter what. How and where that endpoint is, should not be part of
navigate. Navigate is to be able to traverse the route graph deployed
in the camel context. For example to be used by tooling or the likes.
OK, I don't really care whether it has a child or not (whatever that
means). RouteService.doGetChildServices() is traversing the children
using the Navigate interface in order to start all of their services.
It is wrong in RouteService method that starts all the children services
by using Navigate interface then? This is the only way the services
associated with the ProcessEndpoint can be restarted. Or, you are
suggesting ProcessEndpoint should not implement Service since there is
no guarantee the service will be restarted by design?
* Yes, when I say 'type converter, I mean the DefaultTypeConverter.
* If I am not mistaken, ShutdownCompleteAllTasksTest is one example that the
DefaultTypeConverter was accessed after the DefaultTypeConverter has been
shutdown.
* I think you are against lazy loading of DefaultTypeConverter. I am fine
with that. Then, we should really get rid of the lazy loading (in
DefaultCamelContext.getTypeConverter). That is really what the problem is
because since it is a service, it gets stopped but the lazy loading does NOT
re-start it. (Maybe you just fixed it. I haven't got a chance to try it.)
And believe me, having both (a Service and lazy load and start) is
troublesome.
No the problem is that James S. named the method
forceInitLazyService() or something (the name is
forceLazyInitialization)
The type converter is started when CamelContext starts. And in essence
its not lazy. The getter appears to be lazy because you can plugin a
custom type converter registry and therefore the default instance is
created only if no custom has been assigned.
I (or anyone) can tell that DefaultContextContent.getTypeConverter is
definitely doing lazy initialization. See it for yourself. :-) Yes, I
know getTypeConverter() is called when the CamelContext is started but
this is not the only place getTypeConverter() is called. So, the first
time it is called, the type converter is created. In some cases
(although mainly unit tests), getTypeConverter() is called without
CamelContext started is called.
public TypeConverter getTypeConverter() {
if (typeConverter == null) {
synchronized (this) {
// we can synchronize on this as there is only one instance
// of the camel context (its the container)
typeConverter = createTypeConverter();
try {
addService(typeConverter);
} catch (Exception e) {
throw ObjectHelper.wrapRuntimeCamelException(e);
}
}
}
return typeConverter;
}
You can also see addService() (which starts typeConverter) was only
called when a typeConverter was created by createTypeConverter().
Therefore, when you restart the CamelContext, addService() is not called
and therefore typeConverter is not started. My point earlier was that
combining lazy initialization and addService() is troublesome. (I have
not yet read your latest fix though).
The fix will no ensure CamelContext will start the type converter if
CamelContext is started again.
I checked that it worked using the TimerRestartTest unit test.
* IMO, If DefaultTypeConverter is a Service, it should not be usable (throw
an error something) in the stopped/not started state when someone tries to
use it. Accessing a stopped DefaultTypeConverter is bad to say the least.
You don't get an error, you just get different/wrong result.
Well you often use a producer/consumer and access type converters from
those. The producer/consumer should have been stopped before the type
converter (as its one of the last to be stopped). So your logic in the
producer/consumer should have caught that we have stopped.
At least, the system utils stuffs like type converter should be the
last to be stopped. Just adding to servciesToStop List is probably not
ideal.
And there are zillion ways you can access stuff in
Re: CamelContext restart issues CAMEL-2991
Claus, thanks for your experiment.
On 07/25/2010 02:01 PM, Claus Ibsen wrote:
On Sun, Jul 25, 2010 at 6:18 PM, William Tamemail.w...@gmail.com wrote:
Hi Claus,
Thanks for your response.
* A ProcessorEndpoint is a hybrid between a Processor and a Endpoint.
Therefore, SendProcessor does have a child if the destination is a
ProcessorEndpoint. Please take a look at RouteService.doGetChildServices().
You will see why Navigate can allow services associated with the
ProcessEndpoint to be restarted.
* Yes, when I say 'type converter, I mean the DefaultTypeConverter.
* If I am not mistaken, ShutdownCompleteAllTasksTest is one example that the
DefaultTypeConverter was accessed after the DefaultTypeConverter has been
shutdown.
I just added a bit system out to this unit test and
DefaultTypeConverter. When running it, the type converted is only
access when its started.
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
CamelContext status: Started
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
doConvertTo started: true
CamelContext status: Stopped
public void testShutdownCompleteAllTasks() throws Exception {
System.out.println(CamelContext status: + context.getStatus());
// give it 20 seconds to shutdown
context.getShutdownStrategy().setTimeout(20);
MockEndpoint bar = getMockEndpoint(mock:bar);
bar.expectedMinimumMessageCount(1);
assertMockEndpointsSatisfied();
int batch =
bar.getReceivedExchanges().get(0).getProperty(Exchange.BATCH_SIZE,
int.class);
// shutdown during processing
context.stop();
System.out.println(CamelContext status: + context.getStatus());
// should route all 5
assertEquals(Should complete all messages, batch,
bar.getReceivedCounter());
}
And added this to DefaultTypeConverted
@SuppressWarnings(unchecked)
public Object doConvertTo(final Class type, final Exchange
exchange, final Object value) {
System.out.println(doConvertTo started: + isStarted());
So it appears this test only access the DefaultTypeConverter when it's started.
* I think you are against lazy loading of DefaultTypeConverter. I am fine
with that. Then, we should really get rid of the lazy loading (in
DefaultCamelContext.getTypeConverter). That is really what the problem is
because since it is a service, it gets stopped but the lazy loading does NOT
re-start it. (Maybe you just fixed it. I haven't got a chance to try it.)
And believe me, having both (a Service and lazy load and start) is
troublesome.
* IMO, If DefaultTypeConverter is a Service, it should not be usable (throw
an error something) in the stopped/not started state when someone tries to
use it. Accessing a stopped DefaultTypeConverter is bad to say the least.
You don't get an error, you just get different/wrong result.
Cheers,
William
On 07/25/2010 02:46 AM, Claus Ibsen wrote:
On Sun, Jul 25, 2010 at 5:55 AM, William Tamemail.w...@gmail.comwrote:
I observed some issue regarding restarting Camel Context that I want to
discuss. The detail is in the CAMEL-2991.
* First off, any objection if SendProcessor implements Navigate? It
allows
services associated with the destination endpoint to be restarted.
Why does navigate allow services associated with the destination to be
restarted? Can you be more clear?
The idea with navigate is for navigating the process graph.
For example a Content Based Router, where you can navigate the
when/otherwise processors etc.
A SendProcessor doesn't have any children to navigate, and therefore
should NOT be navigate.
* There is a problem with type converter not getting restarted because
the
lazy instantiation won't start the
[jira] Created: (CAMEL-2991) Restart CamelContext won't restart services on CxfBeanEndpoint
Restart CamelContext won't restart services on CxfBeanEndpoint
--
Key: CAMEL-2991
URL: https://issues.apache.org/activemq/browse/CAMEL-2991
Project: Apache Camel
Issue Type: Bug
Components: camel-core, camel-cxf
Reporter: William Tam
Fix For: 2.5.0
A route that sends to a CxfBean destination is unusable after the CamelContext
has been stopped and re-started. The following is an example of a route that
demonstrates the problem.
{code}
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from
uri=jetty:http://localhost:9000?matchOnUriPrefix=true; /
to uri=cxfbean:customerServiceBean /
/route
/camelContext
util:list id=customerServiceBean
bean
class=org.apache.camel.component.cxf.jaxrs.testbean.CustomerService /
/util:list
{code}
The follow issues have been identified.
1) SendProcessor should implement the Navigate interface so that its children
(if they are Services) can be managed by the lifecycle methods. This will
address any destination endpoint that requires services to be re-started.
2) CxfBeanEndpoint should be a Service itself. The reason why the start() on
CxfBeanEndpoint gets called during the first start is because
CxfBeanComponent.start() gets invoked during route definition initialization.
The problem is that re-starting doesn't trigger the CxfBeanComponent.start()
method. Therefore, putting the hook in CxfBeanComponent to start/stop
CxfBeanEndpoint was a bug.
3) The default type converter which is a Service won't get re-started' as the
(lazy-instantiation) getTypeConverter() method won't perform addService() on a
created but stopped' typeConverter. We need to discuss the correct remedy
since I am not sure how to fix it. It is kind of strange that the type
converter is a service (which has the start/stop semantics) and yet it can be
used even the CamelContext is stopped (or never started). In the patch, I just
set the type converter to null in DefaultCamelContext doStop() for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2991) Restart CamelContext won't restart services on CxfBeanEndpoint
[
https://issues.apache.org/activemq/browse/CAMEL-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-2991:
---
Attachment: CAMEL-2991.patch
Restart CamelContext won't restart services on CxfBeanEndpoint
--
Key: CAMEL-2991
URL: https://issues.apache.org/activemq/browse/CAMEL-2991
Project: Apache Camel
Issue Type: Bug
Components: camel-core, camel-cxf
Reporter: William Tam
Fix For: 2.5.0
Attachments: CAMEL-2991.patch
A route that sends to a CxfBean destination is unusable after the
CamelContext has been stopped and re-started. The following is an example of
a route that demonstrates the problem.
{code}
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from
uri=jetty:http://localhost:9000?matchOnUriPrefix=true; /
to uri=cxfbean:customerServiceBean /
/route
/camelContext
util:list id=customerServiceBean
bean
class=org.apache.camel.component.cxf.jaxrs.testbean.CustomerService /
/util:list
{code}
The follow issues have been identified.
1) SendProcessor should implement the Navigate interface so that its children
(if they are Services) can be managed by the lifecycle methods. This will
address any destination endpoint that requires services to be re-started.
2) CxfBeanEndpoint should be a Service itself. The reason why the start() on
CxfBeanEndpoint gets called during the first start is because
CxfBeanComponent.start() gets invoked during route definition initialization.
The problem is that re-starting doesn't trigger the
CxfBeanComponent.start() method. Therefore, putting the hook in
CxfBeanComponent to start/stop CxfBeanEndpoint was a bug.
3) The default type converter which is a Service won't get re-started' as
the (lazy-instantiation) getTypeConverter() method won't perform addService()
on a created but stopped' typeConverter. We need to discuss the correct
remedy since I am not sure how to fix it. It is kind of strange that the
type converter is a service (which has the start/stop semantics) and yet it
can be used even the CamelContext is stopped (or never started). In the
patch, I just set the type converter to null in DefaultCamelContext doStop()
for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
CamelContext restart issues CAMEL-2991
I observed some issue regarding restarting Camel Context that I want to discuss. The detail is in the CAMEL-2991. * First off, any objection if SendProcessor implements Navigate? It allows services associated with the destination endpoint to be restarted. * There is a problem with type converter not getting restarted because the lazy instantiation won't start the services on the type converter unless the type converter is newly created. I notice (in a lot of unit tests) that it is OK to use the type converter even if the CamelContext (its container) is stopped or has never been started. If we want this behavior, then it does not seem to make sense for type converter to be a service. Type converter could be used anytime including during the shutdown cycling. Since type converter has been added to the servicesToClose list, the type converter could be stopped (unpredictably) when it is needed during the shutdown cycle. IMO, type converter probably should not be a service.
[jira] Updated: (CAMEL-2991) Restart CamelContext won't restart services on CxfBeanEndpoint
[
https://issues.apache.org/activemq/browse/CAMEL-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-2991:
---
Attachment: CAMEL-2991.patch
Restart CamelContext won't restart services on CxfBeanEndpoint
--
Key: CAMEL-2991
URL: https://issues.apache.org/activemq/browse/CAMEL-2991
Project: Apache Camel
Issue Type: Bug
Components: camel-core, camel-cxf
Reporter: William Tam
Fix For: 2.5.0
Attachments: CAMEL-2991.patch
A route that sends to a CxfBean destination is unusable after the
CamelContext has been stopped and re-started. The following is an example of
a route that demonstrates the problem.
{code}
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from
uri=jetty:http://localhost:9000?matchOnUriPrefix=true; /
to uri=cxfbean:customerServiceBean /
/route
/camelContext
util:list id=customerServiceBean
bean
class=org.apache.camel.component.cxf.jaxrs.testbean.CustomerService /
/util:list
{code}
The follow issues have been identified.
1) SendProcessor should implement the Navigate interface so that its children
(if they are Services) can be managed by the lifecycle methods. This will
address any destination endpoint that requires services to be re-started.
2) CxfBeanEndpoint should be a Service itself. The reason why the start() on
CxfBeanEndpoint gets called during the first start is because
CxfBeanComponent.start() gets invoked during route definition initialization.
The problem is that re-starting doesn't trigger the
CxfBeanComponent.start() method. Therefore, putting the hook in
CxfBeanComponent to start/stop CxfBeanEndpoint was a bug.
3) The default type converter which is a Service won't get re-started' as
the (lazy-instantiation) getTypeConverter() method won't perform addService()
on a created but stopped' typeConverter. We need to discuss the correct
remedy since I am not sure how to fix it. It is kind of strange that the
type converter is a service (which has the start/stop semantics) and yet it
can be used even the CamelContext is stopped (or never started). In the
patch, I just set the type converter to null in DefaultCamelContext doStop()
for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-2991) Restart CamelContext won't restart services on CxfBeanEndpoint
[
https://issues.apache.org/activemq/browse/CAMEL-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam reassigned CAMEL-2991:
--
Assignee: William Tam
Restart CamelContext won't restart services on CxfBeanEndpoint
--
Key: CAMEL-2991
URL: https://issues.apache.org/activemq/browse/CAMEL-2991
Project: Apache Camel
Issue Type: Bug
Components: camel-core, camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.5.0
Attachments: CAMEL-2991.patch
A route that sends to a CxfBean destination is unusable after the
CamelContext has been stopped and re-started. The following is an example of
a route that demonstrates the problem.
{code}
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from
uri=jetty:http://localhost:9000?matchOnUriPrefix=true; /
to uri=cxfbean:customerServiceBean /
/route
/camelContext
util:list id=customerServiceBean
bean
class=org.apache.camel.component.cxf.jaxrs.testbean.CustomerService /
/util:list
{code}
The follow issues have been identified.
1) SendProcessor should implement the Navigate interface so that its children
(if they are Services) can be managed by the lifecycle methods. This will
address any destination endpoint that requires services to be re-started.
2) CxfBeanEndpoint should be a Service itself. The reason why the start() on
CxfBeanEndpoint gets called during the first start is because
CxfBeanComponent.start() gets invoked during route definition initialization.
The problem is that re-starting doesn't trigger the
CxfBeanComponent.start() method. Therefore, putting the hook in
CxfBeanComponent to start/stop CxfBeanEndpoint was a bug.
3) The default type converter which is a Service won't get re-started' as
the (lazy-instantiation) getTypeConverter() method won't perform addService()
on a created but stopped' typeConverter. We need to discuss the correct
remedy since I am not sure how to fix it. It is kind of strange that the
type converter is a service (which has the start/stop semantics) and yet it
can be used even the CamelContext is stopped (or never started). In the
patch, I just set the type converter to null in DefaultCamelContext doStop()
for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Camel 2.4.0
+1 On 07/12/2010 11:27 AM, Hadrian Zbarcea wrote: A new release apache-camel-2.4.0 is out with approximately 181 issues resolved: new features, improvements and bug fixes. Please find the staging repo here: https://repository.apache.org/content/repositories/orgapachecamel-053/ The tarballs are here https://repository.apache.org/content/repositories/orgapachecamel-053/org/apache/camel/apache-camel/2.4.0/ Please review and vote to approve this release binary. Your vote counts! [ ] +1 Release the binary as Apache Camel 2.4.0 [ ] -1 Veto the release (provide specific comments) Vote is open for 72 hours. Here's my +1 Hadrian
Re: [DISCUSS] Camel 1.x end of life
+1 On 06/12/2010 07:46 AM, Jon Anstey wrote: +1 On Fri, Jun 11, 2010 at 3:22 PM, Hadrian Zbarceahzbar...@gmail.com wrote: Hi, We just released Camel 1.6.3 with only 39 issues resolved in about 6 months. Given that: * 1.x is quite stable * 2.x is more feature rich * most of the projects that use Camel we know of already migrated to 2.x * the api changes and migration effort is not that big I would recommend planning for only one more release of the 1.x branch somewhere in Q4 and then discontinue development/support on the 1.x branch. Thoughts? Hadrian
[jira] Created: (CAMEL-2802) Camel-cxf does not properly populate MessageContentList for PAYLOAD mode
Camel-cxf does not properly populate MessageContentList for PAYLOAD mode
Key: CAMEL-2802
URL: https://issues.apache.org/activemq/browse/CAMEL-2802
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.4.0
Currently, CxfEndpoint.CamelCxfClientImpl does not leave place holder for SOAP
header in MessageContentList. It could be a problem when CXF tries to retrieve
the values in the MessageContentList. Without the placeholder in place, SOAP
body part can be mistakenly retrieved as SOAP header. This patch should fix
the problem. Note: The fix depends on CXF-2837 (Add null pointer check in
SoapOutInterceptor) which will be delivered in CXF 2.2.10.
Index: src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
===
--- src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(revision 43)
+++ src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(working copy)
@@ -513,8 +513,9 @@
MessageContentsList content = new MessageContentsList();
int i = 0;
-for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
-if (elements.size() i) {
+for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
+if (elements.size() i
partInfo.getConcreteName().getLocalPart()
+.equals(elements.get(i).getLocalName())) {
content.put(partInfo, elements.get(i++));
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2802) Camel-cxf does not properly populate MessageContentList for PAYLOAD mode
[
https://issues.apache.org/activemq/browse/CAMEL-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-2802:
---
Description:
Currently, CxfEndpoint.CamelCxfClientImpl does not leave place holder for SOAP
header in MessageContentList. It could be a problem when CXF tries to retrieve
the values in the MessageContentList. Without the placeholder in place, SOAP
body part can be mistakenly retrieved as SOAP header. This patch should fix
the problem. Note: The fix depends on CXF-2837 (Add null pointer check in
SoapOutInterceptor) which will be delivered in CXF 2.2.10.
{code}
Index: src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
===
--- src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(revision 43)
+++ src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(working copy)
@@ -513,8 +513,9 @@
MessageContentsList content = new MessageContentsList();
int i = 0;
-for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
-if (elements.size() i) {
+for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
+if (elements.size() i
partInfo.getConcreteName().getLocalPart()
+.equals(elements.get(i).getLocalName())) {
content.put(partInfo, elements.get(i++));
}
}
{code}
was:
Currently, CxfEndpoint.CamelCxfClientImpl does not leave place holder for SOAP
header in MessageContentList. It could be a problem when CXF tries to retrieve
the values in the MessageContentList. Without the placeholder in place, SOAP
body part can be mistakenly retrieved as SOAP header. This patch should fix
the problem. Note: The fix depends on CXF-2837 (Add null pointer check in
SoapOutInterceptor) which will be delivered in CXF 2.2.10.
Index: src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
===
--- src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(revision 43)
+++ src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(working copy)
@@ -513,8 +513,9 @@
MessageContentsList content = new MessageContentsList();
int i = 0;
-for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
-if (elements.size() i) {
+for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
+if (elements.size() i
partInfo.getConcreteName().getLocalPart()
+.equals(elements.get(i).getLocalName())) {
content.put(partInfo, elements.get(i++));
}
}
Camel-cxf does not properly populate MessageContentList for PAYLOAD mode
Key: CAMEL-2802
URL: https://issues.apache.org/activemq/browse/CAMEL-2802
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.4.0
Currently, CxfEndpoint.CamelCxfClientImpl does not leave place holder for
SOAP header in MessageContentList. It could be a problem when CXF tries to
retrieve the values in the MessageContentList. Without the placeholder in
place, SOAP body part can be mistakenly retrieved as SOAP header. This patch
should fix the problem. Note: The fix depends on CXF-2837 (Add null pointer
check in SoapOutInterceptor) which will be delivered in CXF 2.2.10.
{code}
Index: src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
===
--- src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(revision 43)
+++ src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(working copy)
@@ -513,8 +513,9 @@
MessageContentsList content = new MessageContentsList();
int i = 0;
-for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
-if (elements.size() i) {
+for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
+if (elements.size() i
partInfo.getConcreteName().getLocalPart()
+.equals(elements.get(i).getLocalName())) {
content.put(partInfo
[jira] Work started: (CAMEL-2802) Camel-cxf does not properly populate MessageContentList for PAYLOAD mode
[
https://issues.apache.org/activemq/browse/CAMEL-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-2802 started by William Tam.
Camel-cxf does not properly populate MessageContentList for PAYLOAD mode
Key: CAMEL-2802
URL: https://issues.apache.org/activemq/browse/CAMEL-2802
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.4.0
Currently, CxfEndpoint.CamelCxfClientImpl does not leave place holder for
SOAP header in MessageContentList. It could be a problem when CXF tries to
retrieve the values in the MessageContentList. Without the placeholder in
place, SOAP body part can be mistakenly retrieved as SOAP header. This patch
should fix the problem. Note: The fix depends on CXF-2837 (Add null pointer
check in SoapOutInterceptor) which will be delivered in CXF 2.2.10.
{code}
Index: src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
===
--- src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(revision 43)
+++ src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(working copy)
@@ -513,8 +513,9 @@
MessageContentsList content = new MessageContentsList();
int i = 0;
-for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
-if (elements.size() i) {
+for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
+if (elements.size() i
partInfo.getConcreteName().getLocalPart()
+.equals(elements.get(i).getLocalName())) {
content.put(partInfo, elements.get(i++));
}
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-2802) Camel-cxf does not properly populate MessageContentList for PAYLOAD mode
[
https://issues.apache.org/activemq/browse/CAMEL-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam resolved CAMEL-2802.
Resolution: Fixed
Committed revision 953122.
Camel-cxf does not properly populate MessageContentList for PAYLOAD mode
Key: CAMEL-2802
URL: https://issues.apache.org/activemq/browse/CAMEL-2802
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.4.0
Currently, CxfEndpoint.CamelCxfClientImpl does not leave place holder for
SOAP header in MessageContentList. It could be a problem when CXF tries to
retrieve the values in the MessageContentList. Without the placeholder in
place, SOAP body part can be mistakenly retrieved as SOAP header. This patch
should fix the problem. Note: The fix depends on CXF-2837 (Add null pointer
check in SoapOutInterceptor) which will be delivered in CXF 2.2.10.
{code}
Index: src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
===
--- src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(revision 43)
+++ src/main/java/org/apache/camel/component/cxf/CxfEndpoint.java
(working copy)
@@ -513,8 +513,9 @@
MessageContentsList content = new MessageContentsList();
int i = 0;
-for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
-if (elements.size() i) {
+for (MessagePartInfo partInfo :
boi.getOperationInfo().getInput().getMessageParts()) {
+if (elements.size() i
partInfo.getConcreteName().getLocalPart()
+.equals(elements.get(i).getLocalName())) {
content.put(partInfo, elements.get(i++));
}
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r950506 - in /camel/trunk/components/camel-cxf/src: main/java/org/apache/camel/component/cxf/ test/java/org/apache/camel/component/cxf/
Hi Willem,
I would suggest changing the property names to defaultOperationName and
defaultOperationNamespace to avoid confusion. They are really the
default if the respective headers are not set.
Thanks,
William
On 06/02/2010 07:44 AM, ningji...@apache.org wrote:
Author: ningjiang
Date: Wed Jun 2 11:44:27 2010
New Revision: 950506
URL: http://svn.apache.org/viewvc?rev=950506view=rev
Log:
CAMEL-2780 add operationName and operationNamespace options into CxfEndpoint
Added:
camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfProducerOperationTest.java
(with props)
Modified:
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfConstants.java
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/CxfProducer.java
Modified:
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfConstants.java
URL:
http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfConstants.java?rev=950506r1=950505r2=950506view=diff
==
---
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfConstants.java
(original)
+++
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfConstants.java
Wed Jun 2 11:44:27 2010
@@ -37,7 +37,7 @@ public interface CxfConstants {
String PORT_NAMESPACE = endpointNamespace;
String PROTOCOL_NAME_RES = res;
String OPERATION_NAME = operationName;
-String OPERATION_NAMESPACE = operationNameSpace;
+String OPERATION_NAMESPACE = operationNamespace;
String SPRING_CONTEXT_ENDPOINT = bean:;
String CAMEL_TRANSPORT_PREFIX = camel:;
String CXF_EXCHANGE = org.apache.cxf.message.exchange;
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=950506r1=950505r2=950506view=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
Wed Jun 2 11:44:27 2010
@@ -80,6 +80,8 @@ public class CxfEndpoint extends Default
private String serviceClass;
private String portName;
private String serviceName;
+private String operationName;
+private String operationNamespace;
private DataFormat dataFormat = DataFormat.POJO;
private boolean isWrapped;
private boolean inOut = true;
@@ -412,6 +414,22 @@ public class CxfEndpoint extends Default
public void setPortName(String port) {
portName = port;
}
+
+public String getOperationName() {
+return operationName;
+}
+
+public void setOperationName(String name) {
+operationName = name;
+}
+
+public String getOperationNamespace() {
+return operationNamespace;
+}
+
+public void setOperationNamespace(String namespace) {
+operationNamespace = namespace;
+}
public boolean isInOut() {
return inOut;
Modified:
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfProducer.java
URL:
http://svn.apache.org/viewvc/camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfProducer.java?rev=950506r1=950505r2=950506view=diff
==
---
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfProducer.java
(original)
+++
camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfProducer.java
Wed Jun 2 11:44:27 2010
@@ -259,10 +259,12 @@ public class CxfProducer extends Default
* {...@link BindingOperationInfo}.
*/
private BindingOperationInfo getBindingOperationInfo(Exchange ex) {
-
+CxfEndpoint endpoint = (CxfEndpoint)this.getEndpoint();
BindingOperationInfo answer = null;
String lp = ex.getIn().getHeader(CxfConstants.OPERATION_NAME,
String.class);
-
+if (lp == null) {
+lp = endpoint.getOperationName();
+}
if (lp == null) {
if (LOG.isDebugEnabled()) {
LOG.debug(Try to find a default operation. You should set '
@@ -279,11 +281,14 @@ public class CxfProducer extends Default
} else {
String ns =
ex.getIn().getHeader(CxfConstants.OPERATION_NAMESPACE, String.class);
if (ns == null) {
+ns = endpoint.getOperationNamespace();
+}
+
Re: [VOTE] Release Apache Camel 1.6.3
+1 On 05/31/2010 09:04 PM, Hadrian Zbarcea wrote: A new maintenance release of apache-camel-1.6.3 is out with approximately 39 issues resolved: new features, improvements and bug fixes. Please find the staging repo here: https://repository.apache.org/content/repositories/orgapachecamel-024/ The tarballs are here https://repository.apache.org/content/repositories/orgapachecamel-024/org/apache/camel/apache-camel/1.6.3/ Please review and vote to approve this binary as the final 1.6.3 maintenance release. Your vote counts! [ ] +1 Release the binary as Apache Camel 1.6.3 [ ] -1 Veto the release (provide specific comments) Vote is open for 72 hours. Here's my +1 Hadrian
Re: [VOTE] Release Apache Camel 2.3.0
+1 On 05/25/2010 07:31 AM, Jon Anstey wrote: +1 On Sat, May 22, 2010 at 10:26 PM, Hadrian Zbarceahzbar...@gmail.comwrote: The second release candidate of apache-camel-2.3.0 is out with approximately 276 issues resolved: new features, improvements and bug fixes. Please find the staging repo here: https://repository.apache.org/content/repositories/orgapachecamel-006/ The tarballs are here https://repository.apache.org/content/repositories/orgapachecamel-006/org/apache/camel/apache-camel/2.3.0/ Please review and vote to approve this binary as the final 2.3.0 release. Your vote counts! [ ] +1 Release the binary as Apache Camel 2.3.0 [ ] -1 Veto the release (provide specific comments) Vote is open for 72 hours. Here's my +1 Hadrian
Re: CxfExchange is not anymore available in Camel 2.0.0
I had a quick chat with Willem. (thanks Willem) In this case, the Camel
converter framework will invoke the CxfPayload.toString() method if no
better suit converter is found. The toString method of CxfPayload is as
follow.
public String toString() {
StringBuffer buf = new StringBuffer();
buf.append(getClass().getName());
buf.append( headers: + headers);
buf.append(body: + body);
return buf.toString();
}
If the string output format is not what you expected, you can stick with
snippet that I sent before. Or, you can write a custom Camel converter
(http://camel.apache.org/type-converter.html). I will resolve the Jira
as not fix.
Thanks,
William
On 05/13/2010 08:44 AM, Willem Jiang wrote:
Hi William
Current camel supports to turn the CxfPayLoad object into a String, as
Camel converter will call the CxfPayLoad.toString() method to do this
kind job.
But if you just want to get the payload body, I'm afraid you still
need to use the below code to do the job.
Willem
William Tam wrote:
I need to correct my previous reply. Are you using PAYLOAD or POJO
mode? (I assume you are using PAYLOAD.) The body is a CxfPayload
object which contains a list DOM elements. The snippet would like
this instead.
Message message = exchange.getIn();
String request = message.getBody(String.class);
// We don't need the follow once we have a converter for CxfPayload-
String
if (request == null) {
CxfPayload payload = message.getBody(CxfPayload.class);
if (payload != null) {
request = getRequestFromSource(payload.getBody());
}
}
The getRequestFromSource(ListElement) method takes a list of
Element and convert them to a String. I created a Jira for adding a
converter that converts a CxfPayload to a String so it is not needed
in the future.(https://issues.apache.org/activemq/browse/CAMEL-2714)
On 05/12/2010 11:54 AM, William Tam wrote:
You can do something like this:
Message message = exchange.getIn();
String request = message.getBody(String.class);
if (request == null) {
Source source = message.getBody(Source.class);
if (source != null) {
request = getRequestFromSource(source);
}
}
If we had a converter to covert from CXF payload to string, we
wouldn't the logic in if (request == null).
On 05/12/2010 11:24 AM, fjaouen wrote:
With 1.5.0 I was checking the instance of Exchange in a process
method to
know if I have a CxfMessage or a JMSMessage in order to do different
treatment.
if (aExchange instanceof JmsExchange) {
JmsMessage jmsMessage = (JmsMessage) aExchange.getIn();
String request = jmsMessage.getBody(String.class);
...
}
else if (aExchange instanceof CxfExchange) {
CxfMessage cxfMessage = (CxfMessage) aExchange.getIn();
Source source = cxfMessage.getBody(Source.class);
String request = getRequestFromSource(source);
...
}
So now how can I do this check ? On which object may I determine
that I
receive a CXF or a JMS ?
Thank you !
hzbarcea wrote:
All DefaultExchange specializations were removed in 2.0.0. What
seemed a good idea initially proved to be unnecessary. This has been
communicated in the 2.0.0 Release Note [1]: Exchange api cleanup.
Complete removal of specialized Exchange using generics.
The specialized Messages were preserved as they may deal with
specialized types of body (payloads). You need use the
DefaultExchange instead of CxfExchange. If you have any issues don't
hesitate to ask.
Cheers,
Hadrian
[1] http://camel.apache.org/camel-200-release.html
On Nov 13, 2009, at 1:31 PM, fjaouen wrote:
Hi there,
I am currently using Camel 1.5.0 and I am trying to make a migration
to
2.0.0 version.
It seems that org.apache.camel.component.cxf.CxfExchange class is
not
anymore available in this new version ?
What is its remplacement ?
Is there an easy way to know what has been removed in this new
version or a
documentation explaining how to migrate these changes ?
Thank you !
--
View this message in context:
http://old.nabble.com/CxfExchange-is-not-anymore-available-in-Camel-2.0.0-tp26341178p26341178.html
Sent from the Camel Development mailing list archive at Nabble.com.
[jira] Commented: (CAMEL-2714) Create a converter to convert a CxfPayload to a String
[ https://issues.apache.org/activemq/browse/CAMEL-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=59328#action_59328 ] William Tam commented on CAMEL-2714: email thread: http://old.nabble.com/CxfExchange-is-not-anymore-available-in-Camel-2.0.0-td26341178.html#a26341178 Create a converter to convert a CxfPayload to a String -- Key: CAMEL-2714 URL: https://issues.apache.org/activemq/browse/CAMEL-2714 Project: Apache Camel Issue Type: Improvement Components: camel-cxf Reporter: William Tam Assignee: Willem Jiang Priority: Minor Fix For: 2.3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CxfExchange is not anymore available in Camel 2.0.0
On 05/13/2010 09:20 AM, William Tam wrote:
I had a quick chat with Willem. (thanks Willem) In this case, the
Camel converter framework will invoke the CxfPayload.toString() method
if no better suit converter is found. The toString method of
CxfPayload is as follow.
public String toString() {
StringBuffer buf = new StringBuffer();
buf.append(getClass().getName());
buf.append( headers: + headers);
buf.append(body: + body);
return buf.toString();
}
If the string output format is not what you expected, you can stick
with snippet that I sent before. Or, you can write a custom Camel
converter (http://camel.apache.org/type-converter.html). I will
resolve the Jira as not fix.
Oh, if the string format is not what you expected and you don't want to
write a Camel converter. The snippet needs some slight modification
because the string return is never null.
Message message = exchange.getIn();
String request = null;
CxfPayload payload = message.getBody(CxfPayload.class);
if (payload != null) {
request = getRequestFromSource(payload.getBody());
} else {
request = message.getBody(String.class);
}
Obviously. writing a custom converter is a more elegant solution.
Hopefully, the default string format is acceptable to you already.
Thanks,
William
Thanks,
William
On 05/13/2010 08:44 AM, Willem Jiang wrote:
Hi William
Current camel supports to turn the CxfPayLoad object into a String,
as Camel converter will call the CxfPayLoad.toString() method to do
this kind job.
But if you just want to get the payload body, I'm afraid you still
need to use the below code to do the job.
Willem
William Tam wrote:
I need to correct my previous reply. Are you using PAYLOAD or POJO
mode? (I assume you are using PAYLOAD.) The body is a CxfPayload
object which contains a list DOM elements. The snippet would like
this instead.
Message message = exchange.getIn();
String request = message.getBody(String.class);
// We don't need the follow once we have a converter for
CxfPayload- String
if (request == null) {
CxfPayload payload = message.getBody(CxfPayload.class);
if (payload != null) {
request = getRequestFromSource(payload.getBody());
}
}
The getRequestFromSource(ListElement) method takes a list of
Element and convert them to a String. I created a Jira for adding a
converter that converts a CxfPayload to a String so it is not needed
in the future.
(https://issues.apache.org/activemq/browse/CAMEL-2714)
On 05/12/2010 11:54 AM, William Tam wrote:
You can do something like this:
Message message = exchange.getIn();
String request = message.getBody(String.class);
if (request == null) {
Source source = message.getBody(Source.class);
if (source != null) {
request = getRequestFromSource(source);
}
}
If we had a converter to covert from CXF payload to string, we
wouldn't the logic in if (request == null).
On 05/12/2010 11:24 AM, fjaouen wrote:
With 1.5.0 I was checking the instance of Exchange in a process
method to
know if I have a CxfMessage or a JMSMessage in order to do different
treatment.
if (aExchange instanceof JmsExchange) {
JmsMessage jmsMessage = (JmsMessage) aExchange.getIn();
String request = jmsMessage.getBody(String.class);
...
}
else if (aExchange instanceof CxfExchange) {
CxfMessage cxfMessage = (CxfMessage) aExchange.getIn();
Source source = cxfMessage.getBody(Source.class);
String request = getRequestFromSource(source);
...
}
So now how can I do this check ? On which object may I determine
that I
receive a CXF or a JMS ?
Thank you !
hzbarcea wrote:
All DefaultExchange specializations were removed in 2.0.0. What
seemed a good idea initially proved to be unnecessary. This has
been
communicated in the 2.0.0 Release Note [1]: Exchange api cleanup.
Complete removal of specialized Exchange using generics.
The specialized Messages were preserved as they may deal with
specialized types of body (payloads). You need use the
DefaultExchange instead of CxfExchange. If you have any issues
don't
hesitate to ask.
Cheers,
Hadrian
[1] http://camel.apache.org/camel-200-release.html
On Nov 13, 2009, at 1:31 PM, fjaouen wrote:
Hi there,
I am currently using Camel 1.5.0 and I am trying to make a
migration
to
2.0.0 version.
It seems that org.apache.camel.component.cxf.CxfExchange class
is not
anymore available in this new version ?
What is its remplacement ?
Is there an easy way to know what has been removed in this new
version or a
documentation explaining how to migrate these changes ?
Thank you !
--
View this message in context:
http://old.nabble.com/CxfExchange-is-not-anymore-available-in-Camel-2.0.0-tp26341178p26341178.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: CxfExchange is not anymore available in Camel 2.0.0
You can do something like this:
Message message = exchange.getIn();
String request = message.getBody(String.class);
if (request == null) {
Source source = message.getBody(Source.class);
if (source != null) {
request = getRequestFromSource(source);
}
}
If we had a converter to covert from CXF payload to string, we wouldn't
the logic in if (request == null).
On 05/12/2010 11:24 AM, fjaouen wrote:
With 1.5.0 I was checking the instance of Exchange in a process method to
know if I have a CxfMessage or a JMSMessage in order to do different
treatment.
if (aExchange instanceof JmsExchange) {
JmsMessage jmsMessage = (JmsMessage) aExchange.getIn();
String request = jmsMessage.getBody(String.class);
...
}
else if (aExchange instanceof CxfExchange) {
CxfMessage cxfMessage = (CxfMessage) aExchange.getIn();
Source source = cxfMessage.getBody(Source.class);
String request = getRequestFromSource(source);
...
}
So now how can I do this check ? On which object may I determine that I
receive a CXF or a JMS ?
Thank you !
hzbarcea wrote:
All DefaultExchange specializations were removed in 2.0.0. What
seemed a good idea initially proved to be unnecessary. This has been
communicated in the 2.0.0 Release Note [1]: Exchange api cleanup.
Complete removal of specialized Exchange using generics.
The specialized Messages were preserved as they may deal with
specialized types of body (payloads). You need use the
DefaultExchange instead of CxfExchange. If you have any issues don't
hesitate to ask.
Cheers,
Hadrian
[1] http://camel.apache.org/camel-200-release.html
On Nov 13, 2009, at 1:31 PM, fjaouen wrote:
Hi there,
I am currently using Camel 1.5.0 and I am trying to make a migration
to
2.0.0 version.
It seems that org.apache.camel.component.cxf.CxfExchange class is not
anymore available in this new version ?
What is its remplacement ?
Is there an easy way to know what has been removed in this new
version or a
documentation explaining how to migrate these changes ?
Thank you !
--
View this message in context:
http://old.nabble.com/CxfExchange-is-not-anymore-available-in-Camel-2.0.0-tp26341178p26341178.html
Sent from the Camel Development mailing list archive at Nabble.com.
[jira] Created: (CAMEL-2714) Create a converter to convert a CxfPayload to a String
Create a converter to convert a CxfPayload to a String -- Key: CAMEL-2714 URL: https://issues.apache.org/activemq/browse/CAMEL-2714 Project: Apache Camel Issue Type: Improvement Components: camel-cxf Reporter: William Tam Priority: Minor Fix For: 2.3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CxfExchange is not anymore available in Camel 2.0.0
I need to correct my previous reply. Are you using PAYLOAD or POJO
mode? (I assume you are using PAYLOAD.) The body is a CxfPayload
object which contains a list DOM elements. The snippet would like
this instead.
Message message = exchange.getIn();
String request = message.getBody(String.class);
// We don't need the follow once we have a converter for CxfPayload- String
if (request == null) {
CxfPayload payload = message.getBody(CxfPayload.class);
if (payload != null) {
request = getRequestFromSource(payload.getBody());
}
}
The getRequestFromSource(ListElement) method takes a list of Element
and convert them to a String. I created a Jira for adding a converter
that converts a CxfPayload to a String so it is not needed in the
future.(https://issues.apache.org/activemq/browse/CAMEL-2714)
On 05/12/2010 11:54 AM, William Tam wrote:
You can do something like this:
Message message = exchange.getIn();
String request = message.getBody(String.class);
if (request == null) {
Source source = message.getBody(Source.class);
if (source != null) {
request = getRequestFromSource(source);
}
}
If we had a converter to covert from CXF payload to string, we
wouldn't the logic in if (request == null).
On 05/12/2010 11:24 AM, fjaouen wrote:
With 1.5.0 I was checking the instance of Exchange in a process
method to
know if I have a CxfMessage or a JMSMessage in order to do different
treatment.
if (aExchange instanceof JmsExchange) {
JmsMessage jmsMessage = (JmsMessage) aExchange.getIn();
String request = jmsMessage.getBody(String.class);
...
}
else if (aExchange instanceof CxfExchange) {
CxfMessage cxfMessage = (CxfMessage) aExchange.getIn();
Source source = cxfMessage.getBody(Source.class);
String request = getRequestFromSource(source);
...
}
So now how can I do this check ? On which object may I determine that I
receive a CXF or a JMS ?
Thank you !
hzbarcea wrote:
All DefaultExchange specializations were removed in 2.0.0. What
seemed a good idea initially proved to be unnecessary. This has been
communicated in the 2.0.0 Release Note [1]: Exchange api cleanup.
Complete removal of specialized Exchange using generics.
The specialized Messages were preserved as they may deal with
specialized types of body (payloads). You need use the
DefaultExchange instead of CxfExchange. If you have any issues don't
hesitate to ask.
Cheers,
Hadrian
[1] http://camel.apache.org/camel-200-release.html
On Nov 13, 2009, at 1:31 PM, fjaouen wrote:
Hi there,
I am currently using Camel 1.5.0 and I am trying to make a migration
to
2.0.0 version.
It seems that org.apache.camel.component.cxf.CxfExchange class is not
anymore available in this new version ?
What is its remplacement ?
Is there an easy way to know what has been removed in this new
version or a
documentation explaining how to migrate these changes ?
Thank you !
--
View this message in context:
http://old.nabble.com/CxfExchange-is-not-anymore-available-in-Camel-2.0.0-tp26341178p26341178.html
Sent from the Camel Development mailing list archive at Nabble.com.
[jira] Resolved: (CAMEL-2614) Camel-cxf can't handle multi part message in PAYLOAD mode
[
https://issues.apache.org/activemq/browse/CAMEL-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam resolved CAMEL-2614.
Resolution: Fixed
Camel-cxf can't handle multi part message in PAYLOAD mode
-
Key: CAMEL-2614
URL: https://issues.apache.org/activemq/browse/CAMEL-2614
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.3.0
Attachments: CAMEL-2614.patch
If I have a multi part (bare) message defined in WSDL (such as follow),
camel-cxf component cannot parse the incoming message in PAYLOAD mode.
{code}
wsdl:message name=MultiPartStringIntRequest
wsdl:part name=StringDefaultInput
element=MultiPartStringInt:StringDefaultInputElem /
wsdl:part name=IntParamIn
element=MultiPartStringInt:IntParamInElem /
/wsdl:message
{code}
I get a stack trace similar to this.
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
createDOMMessage
INFO: AbstractMessageInInterceptor Converting Stax Stream to DOM
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
handleMessage
INFO: AbstractRoutingMessageInInterceptor Infer BindingOperationInfo.
Mar 12, 2010 7:15:48 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
WARNING: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not read request. Operation
{urn:MultiPart/resources/wsdl/MultiPartStringInt/MultiPartStringInt/types}StringDefaultInputElem
is unknown.
at
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor.handleMessage(AbstractMessageInInterceptor.java:103)
at
org.apache.camel.component.cxf.interceptors.DOMInInterceptor.handleMessage(DOMInInterceptor.java:43)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2620) Preserve streaming behavior in camel-cxf PAYLOAD mode
[ https://issues.apache.org/activemq/browse/CAMEL-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam updated CAMEL-2620: --- Fix Version/s: (was: 2.3.0) 2.4.0 Preserve streaming behavior in camel-cxf PAYLOAD mode - Key: CAMEL-2620 URL: https://issues.apache.org/activemq/browse/CAMEL-2620 Project: Apache Camel Issue Type: Improvement Components: camel-cxf Reporter: William Tam Assignee: William Tam Fix For: 2.4.0 Dan Kulp pointed out in https://issues.apache.org/jira/browse/CXF-2753 that Camel should preserve the streaming behavior by setting message part type class to Source.class (so the payload object becomes a SAXSource that wraps around a XMLStreamReader). The camel-cxf component currently exposes to the user a List of DOM Elements as payload. Basically, streaming behavior stops there anyway. We probably should provide a parameter to configure the camel-cxf endpoint to opt out of DOM and get a SAXSource as payload and add a converter if the user needs to go from SAXSource to DOM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (CAMEL-1893) camel-cxf - Setting HTTP response code twice
[ https://issues.apache.org/activemq/browse/CAMEL-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-1893 started by William Tam. camel-cxf - Setting HTTP response code twice Key: CAMEL-1893 URL: https://issues.apache.org/activemq/browse/CAMEL-1893 Project: Apache Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.0-M3 Reporter: Claus Ibsen Assignee: William Tam Priority: Minor Fix For: 2.3.0 During CAMEL-1886 I discovered that the camel-cxf component and maybe others as well potentially sets the reponse code twice. As headers are populate from the HTTP request it may already have a Exchange.HTTP_RESPONSE_CODE key key already however in different case, such as lower case only etc. And then in the code later the response code is added using the Exchange.HTTP_RESPONSE_CODE key that have a different case. But CAMEL-1886 can resolve this as we would like to add case insensitive headers in Camel. However the code in camel-cxf should be reviewed to ensure that the response code is set correctly using Exchange.HTTP_RESPONSE_CODE to avoid double values. And most importantly the response code is the correct value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[HEADS UP] Camel-cxf component in Camel 2.3 will require CXF 2.2.8
I just want to point it out (as noted in the release wiki page). As the result of CAMEL-2614, we has eliminated custom CXF interceptors that parse message in PAYLOAD mode will require CXF 2.2.8. However, other modes (POJO and MESSAGE) are unaffected (they will not require CXF 2.2.8). Thanks, William On 05/05/2010 08:28 PM, Willem Jiang wrote: There is a CXF related issue[1] need CXF 2.2.8. It could be great if we release Camel 2.2.3 after CXF 2.2.8. [1] https://issues.apache.org/activemq/browse/CAMEL-2614 Willem William Tam wrote: +1 On 05/05/2010 12:28 PM, Christian Schneider wrote: Hi Claus, one interesting thing could be to wait for CXF 2.2.8 and use this. Dan just proposed a release next week. So it is just a matter of days. Apart from this I am really looking forward to the new release the sooner the better. Greetings Christian Am 05.05.2010 12:37, schrieb Claus Ibsen: Hi I think its time we get Apache Camel 2.3.0 out of the door. So this is just a heads up if you have any critical last minute issues you want to be addressed. New features or major improvements should be scheduled for 2.4. All dependencies is also using a stable release which should be avail in public maven repos. So we should be good to go. And I believe the Apache infrastructure is coming back to life after the recent attack last month.
[jira] Resolved: (CAMEL-1893) camel-cxf - Setting HTTP response code twice
[ https://issues.apache.org/activemq/browse/CAMEL-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-1893. Resolution: Cannot Reproduce camel-cxf - Setting HTTP response code twice Key: CAMEL-1893 URL: https://issues.apache.org/activemq/browse/CAMEL-1893 Project: Apache Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.0-M3 Reporter: Claus Ibsen Assignee: William Tam Priority: Minor Fix For: 2.3.0 During CAMEL-1886 I discovered that the camel-cxf component and maybe others as well potentially sets the reponse code twice. As headers are populate from the HTTP request it may already have a Exchange.HTTP_RESPONSE_CODE key key already however in different case, such as lower case only etc. And then in the code later the response code is added using the Exchange.HTTP_RESPONSE_CODE key that have a different case. But CAMEL-1886 can resolve this as we would like to add case insensitive headers in Camel. However the code in camel-cxf should be reviewed to ensure that the response code is set correctly using Exchange.HTTP_RESPONSE_CODE to avoid double values. And most importantly the response code is the correct value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1893) camel-cxf - Setting HTTP response code twice
[ https://issues.apache.org/activemq/browse/CAMEL-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=59237#action_59237 ] William Tam commented on CAMEL-1893: I checked all three components (cxf, cxfbean, cxfrs) but I did not see Exchange.HTTP_RESPONSE_CODE getting set twice (with different cases). It might have been fixed already. camel-cxf - Setting HTTP response code twice Key: CAMEL-1893 URL: https://issues.apache.org/activemq/browse/CAMEL-1893 Project: Apache Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.0-M3 Reporter: Claus Ibsen Assignee: William Tam Priority: Minor Fix For: 2.3.0 During CAMEL-1886 I discovered that the camel-cxf component and maybe others as well potentially sets the reponse code twice. As headers are populate from the HTTP request it may already have a Exchange.HTTP_RESPONSE_CODE key key already however in different case, such as lower case only etc. And then in the code later the response code is added using the Exchange.HTTP_RESPONSE_CODE key that have a different case. But CAMEL-1886 can resolve this as we would like to add case insensitive headers in Camel. However the code in camel-cxf should be reviewed to ensure that the response code is set correctly using Exchange.HTTP_RESPONSE_CODE to avoid double values. And most importantly the response code is the correct value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Apache Camel 2.3 - Last call
+1 On 05/05/2010 12:28 PM, Christian Schneider wrote: Hi Claus, one interesting thing could be to wait for CXF 2.2.8 and use this. Dan just proposed a release next week. So it is just a matter of days. Apart from this I am really looking forward to the new release the sooner the better. Greetings Christian Am 05.05.2010 12:37, schrieb Claus Ibsen: Hi I think its time we get Apache Camel 2.3.0 out of the door. So this is just a heads up if you have any critical last minute issues you want to be addressed. New features or major improvements should be scheduled for 2.4. All dependencies is also using a stable release which should be avail in public maven repos. So we should be good to go. And I believe the Apache infrastructure is coming back to life after the recent attack last month.
[jira] Assigned: (CAMEL-2638) Restlet component is URL encoding the POST message body. It should encode it based on content-type request header.
[ https://issues.apache.org/activemq/browse/CAMEL-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam reassigned CAMEL-2638: -- Assignee: William Tam Restlet component is URL encoding the POST message body. It should encode it based on content-type request header. --- Key: CAMEL-2638 URL: https://issues.apache.org/activemq/browse/CAMEL-2638 Project: Apache Camel Issue Type: Bug Components: camel-restlet Affects Versions: 2.1.0 Environment: Windows XP Reporter: Rich Bolen Assignee: William Tam Attachments: camel-restlet-CAMEL-2638.patch Original Estimate: 1 week Remaining Estimate: 1 week I attempted to POST a JSON document to couchdb via restlet. The post fails with and Invalid JSON format error from couchdb. This is because the POST data was being URL encoded which substitutes %XX sequences for all the curly braces. I believe the encoding should be done based on the content-type header, or possibly not at all for POST requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-2638) Restlet component is URL encoding the POST message body. It should encode it based on content-type request header.
[ https://issues.apache.org/activemq/browse/CAMEL-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-2638. Fix Version/s: 2.3.0 Resolution: Fixed Patch applied with thanks to Rich Bolen. Committed revision 936136. Restlet component is URL encoding the POST message body. It should encode it based on content-type request header. --- Key: CAMEL-2638 URL: https://issues.apache.org/activemq/browse/CAMEL-2638 Project: Apache Camel Issue Type: Bug Components: camel-restlet Affects Versions: 2.1.0 Environment: Windows XP Reporter: Rich Bolen Assignee: William Tam Fix For: 2.3.0 Attachments: camel-restlet-CAMEL-2638.patch Original Estimate: 1 week Remaining Estimate: 1 week I attempted to POST a JSON document to couchdb via restlet. The post fails with and Invalid JSON format error from couchdb. This is because the POST data was being URL encoded which substitutes %XX sequences for all the curly braces. I believe the encoding should be done based on the content-type header, or possibly not at all for POST requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Restlet url encoding post data?
I guess we do not have to use Form object. If using String yields a more generic solution, we probably should do it. I am comparing the response message which calls the setEntity() with a String and we can specify the media type. The headers are set as attributes in the Restlet message. Bee1000 wrote: I'm working on a patch for this. I have a question. The Camel binding layer appears to be mapping non Restlet message headers into URL parameters via the Restlet Form object. I believe URL parameters are only valid for GET and POST w/content type of application/x-www-form-urlencoded. What should we do with the headers for PUT, DELETE, and non-form POSTs? Should I move this thread to the developers forum? I wasn't sure if only jira stuff went there. William Tam wrote: I see. The method probably should have called request.setEntity(Sting, MediaType) similar to the response message. I'm looking forward to your patch. Thanks, William Bee1000 wrote: You can set the header, but it is not used in the code. The method calls form.getWebRepresentation() which is hard coded to use 'application/x-www-form-urlencoded'. I will look into creating a jira issue and a test case, and possibly provide a fix as well. Rich William Tam wrote: Have you tried setting the Content-Type header (to application/json) in your request Camel message? It looks like DefaultRestletBinding.populateRestletRequestFromExchange() method will add the header to the Form. If it does not work, any chance you are create a Jira with a testcase? A patch would be great, too. :-) Bee1000 wrote: Using http does work, but it still seems like a bug to hard code the encoding of post data for restlet. I thought post data could be any text or binary data. It seems like this reduces the usefulness of the restlet camel component. Just out of curiosity, is there another reason why the encoding is hardcoded? (Perhaps to be more precise, the message body is being encoded in the RESTLET component, which for POST means that post data is being encoded.) willem.jiang wrote: Hi, I think you can try to use Camel-Http component, which is leverage common http client to invoke the http service. Willem Bee1000 wrote: I'm trying to post documents to couchdb using restlet but the restlet component is hard coded to url encode the post data. This makes the JSON text i'm posting invalid. Do I need to use some other component or is there a way around this?
[jira] Created: (CAMEL-2620) Preserve streaming behavior in camel-cxf PAYLOAD mode
Preserve streaming behavior in camel-cxf PAYLOAD mode - Key: CAMEL-2620 URL: https://issues.apache.org/activemq/browse/CAMEL-2620 Project: Apache Camel Issue Type: Improvement Components: camel-cxf Reporter: William Tam Assignee: William Tam Fix For: 2.3.0 Dan Kulp pointed out in https://issues.apache.org/jira/browse/CXF-2753 that Camel should preserve the streaming behavior by setting message part type class to Source.class (so the payload object becomes a SAXSource that wraps around a XMLStreamReader). The camel-cxf component currently exposes to the user a List of DOM Elements as payload. Basically, streaming behavior stops there anyway. We probably should provide a parameter to configure the camel-cxf endpoint to opt out of DOM and get a SAXSource as payload and add a converter if the user needs to go from SAXSource to DOM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-2614) Camel-cxf can't handle multi part message in PAYLOAD mode
Camel-cxf can't handle multi part message in PAYLOAD mode
-
Key: CAMEL-2614
URL: https://issues.apache.org/activemq/browse/CAMEL-2614
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.3.0
If I have a multi part (bare) message defined in WSDL (such as follow),
camel-cxf component cannot parse the incoming message in PAYLOAD mode.
{code}
wsdl:message name=MultiPartStringIntRequest
wsdl:part name=StringDefaultInput
element=MultiPartStringInt:StringDefaultInputElem /
wsdl:part name=IntParamIn
element=MultiPartStringInt:IntParamInElem /
/wsdl:message
{code}
I get a stack trace similar to this.
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
createDOMMessage
INFO: AbstractMessageInInterceptor Converting Stax Stream to DOM
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
handleMessage
INFO: AbstractRoutingMessageInInterceptor Infer BindingOperationInfo.
Mar 12, 2010 7:15:48 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
WARNING: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not read request. Operation
{urn:MultiPart/resources/wsdl/MultiPartStringInt/MultiPartStringInt/types}StringDefaultInputElem
is unknown.
at
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor.handleMessage(AbstractMessageInInterceptor.java:103)
at
org.apache.camel.component.cxf.interceptors.DOMInInterceptor.handleMessage(DOMInInterceptor.java:43)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2614) Camel-cxf can't handle multi part message in PAYLOAD mode
[
https://issues.apache.org/activemq/browse/CAMEL-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-2614:
---
Attachment: CXF-2753.patch
Camel-cxf can't handle multi part message in PAYLOAD mode
-
Key: CAMEL-2614
URL: https://issues.apache.org/activemq/browse/CAMEL-2614
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.3.0
If I have a multi part (bare) message defined in WSDL (such as follow),
camel-cxf component cannot parse the incoming message in PAYLOAD mode.
{code}
wsdl:message name=MultiPartStringIntRequest
wsdl:part name=StringDefaultInput
element=MultiPartStringInt:StringDefaultInputElem /
wsdl:part name=IntParamIn
element=MultiPartStringInt:IntParamInElem /
/wsdl:message
{code}
I get a stack trace similar to this.
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
createDOMMessage
INFO: AbstractMessageInInterceptor Converting Stax Stream to DOM
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
handleMessage
INFO: AbstractRoutingMessageInInterceptor Infer BindingOperationInfo.
Mar 12, 2010 7:15:48 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
WARNING: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not read request. Operation
{urn:MultiPart/resources/wsdl/MultiPartStringInt/MultiPartStringInt/types}StringDefaultInputElem
is unknown.
at
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor.handleMessage(AbstractMessageInInterceptor.java:103)
at
org.apache.camel.component.cxf.interceptors.DOMInInterceptor.handleMessage(DOMInInterceptor.java:43)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2614) Camel-cxf can't handle multi part message in PAYLOAD mode
[
https://issues.apache.org/activemq/browse/CAMEL-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-2614:
---
Attachment: (was: CXF-2753.patch)
Camel-cxf can't handle multi part message in PAYLOAD mode
-
Key: CAMEL-2614
URL: https://issues.apache.org/activemq/browse/CAMEL-2614
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.3.0
If I have a multi part (bare) message defined in WSDL (such as follow),
camel-cxf component cannot parse the incoming message in PAYLOAD mode.
{code}
wsdl:message name=MultiPartStringIntRequest
wsdl:part name=StringDefaultInput
element=MultiPartStringInt:StringDefaultInputElem /
wsdl:part name=IntParamIn
element=MultiPartStringInt:IntParamInElem /
/wsdl:message
{code}
I get a stack trace similar to this.
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
createDOMMessage
INFO: AbstractMessageInInterceptor Converting Stax Stream to DOM
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
handleMessage
INFO: AbstractRoutingMessageInInterceptor Infer BindingOperationInfo.
Mar 12, 2010 7:15:48 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
WARNING: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not read request. Operation
{urn:MultiPart/resources/wsdl/MultiPartStringInt/MultiPartStringInt/types}StringDefaultInputElem
is unknown.
at
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor.handleMessage(AbstractMessageInInterceptor.java:103)
at
org.apache.camel.component.cxf.interceptors.DOMInInterceptor.handleMessage(DOMInInterceptor.java:43)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-2614) Camel-cxf can't handle multi part message in PAYLOAD mode
[
https://issues.apache.org/activemq/browse/CAMEL-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Tam updated CAMEL-2614:
---
Attachment: CAMEL-2614.patch
Camel-cxf can't handle multi part message in PAYLOAD mode
-
Key: CAMEL-2614
URL: https://issues.apache.org/activemq/browse/CAMEL-2614
Project: Apache Camel
Issue Type: Bug
Components: camel-cxf
Reporter: William Tam
Assignee: William Tam
Fix For: 2.3.0
Attachments: CAMEL-2614.patch
If I have a multi part (bare) message defined in WSDL (such as follow),
camel-cxf component cannot parse the incoming message in PAYLOAD mode.
{code}
wsdl:message name=MultiPartStringIntRequest
wsdl:part name=StringDefaultInput
element=MultiPartStringInt:StringDefaultInputElem /
wsdl:part name=IntParamIn
element=MultiPartStringInt:IntParamInElem /
/wsdl:message
{code}
I get a stack trace similar to this.
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
createDOMMessage
INFO: AbstractMessageInInterceptor Converting Stax Stream to DOM
Mar 12, 2010 7:15:48 PM
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor
handleMessage
INFO: AbstractRoutingMessageInInterceptor Infer BindingOperationInfo.
Mar 12, 2010 7:15:48 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
WARNING: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not read request. Operation
{urn:MultiPart/resources/wsdl/MultiPartStringInt/MultiPartStringInt/types}StringDefaultInputElem
is unknown.
at
org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor.handleMessage(AbstractMessageInInterceptor.java:103)
at
org.apache.camel.component.cxf.interceptors.DOMInInterceptor.handleMessage(DOMInInterceptor.java:43)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Camel-cxf in PAYLOAD mode
We discussed in this mailing list that the camel-cxf component (in particularly, the PAYLOAD mode implementation) was unnecessarily complicated. Here is a quick update. Using Dispatch APIs is probably still a long term goal. As fixing the defect https://issues.apache.org/activemq/browse/CAMEL-2614, I am proposing to leverage CXF's SourceDataBinding to facilitate un/marshaling of parameters into XML payload. As a result, we can get rid of the existing interceptors in camel-cxf which do some of the XML parsing. I think more importantly, we remove a hurdle to inherit CXF WS-* supports in PAYLOAD. Please see the patch in the CAMEL-2614 and let me know your feedbacks. Thanks, William
[jira] Created: (CAMEL-2542) Simple Expression Language to access Map value
Simple Expression Language to access Map value
---
Key: CAMEL-2542
URL: https://issues.apache.org/activemq/browse/CAMEL-2542
Project: Apache Camel
Issue Type: Improvement
Components: camel-core
Reporter: William Tam
Users may want to use Simple Expression Language to evaluate an expression that
involves Map header values. For example, the follow expression should evaluate
to the Map entry value by the key bar. The map is the value of an IN message
header by the name of foo.
${in.header.foo[bar]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-2543) Configurable URL schemes to be accepted by DefaultPackageScanClassResolver
Configurable URL schemes to be accepted by DefaultPackageScanClassResolver -- Key: CAMEL-2543 URL: https://issues.apache.org/activemq/browse/CAMEL-2543 Project: Apache Camel Issue Type: Improvement Components: camel-core Reporter: William Tam Currently, the DefaultPackageScanClassResolver hardcodes 3 acceptable schemes (http, https, sonicfs). Everything else is assumed to be local file system location. It would be nice to be able to configure other valid URL schemes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-2544) Application SOAP 12 fault support in camel-cxf PAYLOAD mode
Application SOAP 12 fault support in camel-cxf PAYLOAD mode --- Key: CAMEL-2544 URL: https://issues.apache.org/activemq/browse/CAMEL-2544 Project: Apache Camel Issue Type: Bug Reporter: William Tam Assignee: William Tam Fix For: 2.3.0 This issue is related to https://issues.apache.org/activemq/browse/CAMEL-2495. We need to make sure SOAP 1.2 Fault works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (CAMEL-2544) Application SOAP 12 fault support in camel-cxf PAYLOAD mode
[ https://issues.apache.org/activemq/browse/CAMEL-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-2544 started by William Tam. Application SOAP 12 fault support in camel-cxf PAYLOAD mode --- Key: CAMEL-2544 URL: https://issues.apache.org/activemq/browse/CAMEL-2544 Project: Apache Camel Issue Type: Bug Reporter: William Tam Assignee: William Tam Fix For: 2.3.0 This issue is related to https://issues.apache.org/activemq/browse/CAMEL-2495. We need to make sure SOAP 1.2 Fault works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-2544) Application SOAP 12 fault support in camel-cxf PAYLOAD mode
[ https://issues.apache.org/activemq/browse/CAMEL-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-2544. Resolution: Fixed Committed revision 922420. Application SOAP 12 fault support in camel-cxf PAYLOAD mode --- Key: CAMEL-2544 URL: https://issues.apache.org/activemq/browse/CAMEL-2544 Project: Apache Camel Issue Type: Bug Reporter: William Tam Assignee: William Tam Fix For: 2.3.0 This issue is related to https://issues.apache.org/activemq/browse/CAMEL-2495. We need to make sure SOAP 1.2 Fault works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (CAMEL-1917) DefaultPackageScanClassResolver not able to scan package in jar url
Sorry, let me take a look at how it was broken. The runtime was Sonic ESB container. Claus Ibsen (JIRA) wrote: [ https://issues.apache.org/activemq/browse/CAMEL-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=58144#action_58144 ] Claus Ibsen commented on CAMEL-1917: William this one broke BEA WebLogic support. In what use case did you encounter this problem? We eventually have to restore BEA WebLogic support, so I am curious what runtime you used to load resources like that jar? DefaultPackageScanClassResolver not able to scan package in jar url --- Key: CAMEL-1917 URL: https://issues.apache.org/activemq/browse/CAMEL-1917 Project: Apache Camel Issue Type: Bug Components: camel-core Affects Versions: 2.0-M3 Reporter: William Tam Assignee: William Tam Fix For: 2.1.0 The DefaultPackageScanClassResolver seems to have problem finding packages from URL jar:file:/path/to/my.jar!/
[jira] Commented: (CAMEL-1917) DefaultPackageScanClassResolver not able to scan package in jar url
[ https://issues.apache.org/activemq/browse/CAMEL-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=58154#action_58154 ] William Tam commented on CAMEL-1917: Claus and I have chatted over IM and agreed to add '|| urlPath.startsWith(sonicfs:)' in the if statement in to support Sonic ESB. DefaultPackageScanClassResolver not able to scan package in jar url --- Key: CAMEL-1917 URL: https://issues.apache.org/activemq/browse/CAMEL-1917 Project: Apache Camel Issue Type: Bug Components: camel-core Affects Versions: 2.0-M3 Reporter: William Tam Assignee: William Tam Fix For: 2.1.0 Attachments: camel-1917.patch The DefaultPackageScanClassResolver seems to have problem finding packages from URL jar:file:/path/to/my.jar!/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-2495) Application SOAP fault support in camel-cxf PAYLOAD mode
[ https://issues.apache.org/activemq/browse/CAMEL-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-2495. Resolution: Fixed Committed revision 917539. Application SOAP fault support in camel-cxf PAYLOAD mode Key: CAMEL-2495 URL: https://issues.apache.org/activemq/browse/CAMEL-2495 Project: Apache Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.2.0 Reporter: William Tam Assignee: William Tam Fix For: 2.3.0 Camel-cxf component does not seem to support application SOAP fault in PAYLOAD mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-2495) Application SOAP fault support in camel-cxf PAYLOAD mode
Application SOAP fault support in camel-cxf PAYLOAD mode Key: CAMEL-2495 URL: https://issues.apache.org/activemq/browse/CAMEL-2495 Project: Apache Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.2.0 Reporter: William Tam Assignee: William Tam Fix For: 2.3.0 Camel-cxf component does not seem to support application SOAP fault in PAYLOAD mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-2495) Application SOAP fault support in camel-cxf PAYLOAD mode
[ https://issues.apache.org/activemq/browse/CAMEL-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=57819#action_57819 ] William Tam commented on CAMEL-2495: I should say it is only a problem if no serviceClass/SEI is provided (i.e. WSDL only) in the endpoint. I edited the CXFWsdlOnlyPayloadModeNoSpringTest to throw an application level SOAP fault. I observed this exception and no SOAP fault was sent to the client. org.apache.camel.wsdl_first.UnknownPersonFault: Get the null value of person name at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:131) at $Proxy64.getPerson(Unknown Source) at org.apache.camel.component.cxf.CXFWsdlOnlyPayloadModeNoSpringTest.testApplicationFault(CXFWsdlOnlyPayloadModeNoSpringTest.java:95) 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.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Application SOAP fault support in camel-cxf PAYLOAD mode Key: CAMEL-2495 URL: https://issues.apache.org/activemq/browse/CAMEL-2495 Project: Apache Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.2.0 Reporter: William Tam Assignee: William Tam Fix For: 2.3.0 Camel-cxf component does not seem to support application SOAP fault in PAYLOAD mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
