Re: Abstracting Routes using Components
On 26 October 2010 19:21, Hadrian Zbarcea hzbar...@gmail.com wrote: There are a few issues we need to sort out. One is that with something like this: from(blackboxroute1://out)... You'd have to deal with naming. If everybody will define her blackboxroute1 you'll have to deal with name clashes. Sure - but thats what Spring / Guice / JNDI already do. The scheme names in Camel come from your IoC container which already deal nicely with name clashes. You can do something like route:blackboxroute1://out. How does an extra level of indirection help solve naming clashes? Then the lightweight part I would like not to get lost in this discussion, as in no interceptors, no dlc. Don't follow. We're talking Camel all the way down here; so nothing gets lost. We're just talking about wrapping Camel routes inside a component for 'data hiding' and easier composition. You can then have processing pipelines (as in subroutes, not camel pipelines, I hope not creating confusion) that can be developed by independent groups and reused. Of course something like that can only be done today with direct: and seda: based routes, but we can simplify that. @James, I'll be in London for a couple of days. If you wanna chat about this over beer on Thu evening (your treat :) ), please let me know. Thanks; though I'm out in the sticks these days (125 miles away) and unfortunately its my turn to babysit. Maybe next time! -- James --- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
Re: Using JPA Consumer only once in the Route
On Tue, Oct 26, 2010 at 6:04 PM, Ashwin Karpe aka...@fusesource.com wrote:
Hi,
In your particular case the route would look something like the following if
you adopted the scheduled route policy.
public void configure() {
SimpleScheduledRoutePolicy policy = new SimpleScheduledRoutePolicy();
long startTime = System.currentTimeMillis() + 3000L;
long stopTime = System.currentTimeMillis() + 9000L;
policy.setRouteStartDate(new Date(startTime));
policy.setRouteStartRepeatCount(1);
policy.setRouteStopDate(new Date(stopTime));
policy.setRouteStopRepeatCount(1);
from(jpa)
.routeId(test)
.routePolicy(policy)
.to(databaseProcessor);
}
The side benefit of this is that the route can be stopped and restarted as
many times as you like based on the policy.
I wonder if this would not stop it based on a time? eg looks to me you
got a timespan of 6 seconds between start/stop.
What you should do is to let
- quartz start the route based on the scheduling you want
- stop the route after processing the exchange. Just implement this in
the onExchangeDone method.
Cheers,
Ashwin...
-
-
Ashwin Karpe
Apache Camel Committer Sr Principal Consultant
FUSESource (a Progress Software Corporation subsidiary)
http://fusesource.com http://fusesource.com
Blog: http://opensourceknowledge.blogspot.com
http://opensourceknowledge.blogspot.com
-
--
View this message in context:
http://camel.465427.n5.nabble.com/Using-JPA-Consumer-only-once-in-the-Route-tp3237249p3237307.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Abstracting Routes using Components
Hi Kristof
Just wanted to say great work and a nice debate you have started.
I have only had the time to skim read, but so many great minds is
already debating this.
So keep in there and I am sure we will get some great new feature in
Camel based on your work.
On Sun, Oct 24, 2010 at 11:19 PM, kristofsajdak
kristof.saj...@gmail.com wrote:
Hi,
I'm currently working on a poc for a customer.
As part of their core business they offer a platform which mediates between
trading partners.
What is special about their use case is the fact that they want the actual
routes between
partners to be defined by employees with limited technical knowledge
(solution consultants).
I know there is the xml dsl and the upcoming camel rider which lowers the
threshold for non developers.
But even when using these features, the route configuration would be way too
fine grained for them and
they would still require too much knowledge on the details of the technical
components.
Last week I was at the FUSE community day in Paris and spoke to James
Strachan on the customer
need to abstract some parts of the routes. He mentioned the idea of using a
component as a kind
of proxy for a route.
I believe this is a real nice solution to the problem.
A complex route were a pdf is generated from an xml using xslt and fop and
the result is signed using a
third party service exposed over http could be reduced to the following.
route
from uri={{data.in}}/
to
uri=route:generateAndSignPdf?signatureReason=JustForFunamp;signatureVisible=trueamp;xslUri=com/xti/poc/camel/route/sample1/krusty.xsl/
to uri={{data.out}}/
/route
The route component concept abstracts the route low level technical details
and makes reuse easy.
The solution consultant only needs to define the route:generateAndSignPdf
with the correct parameters.
As this construct would provide great value to the customer I went ahead and
implemented this idea as part of the poc. Attached to this post is my
codebase with a unit test executing the scenario mentioned above.
I would really appreciate some feedback from the community on the code I
wrote.
I tried fitting this in with the component lifecycle the best I could but
still have some doubts on whether it's done correct.
Getting an expert opinion on this would be a big help.
Best regards,
Kristof
http://camel.465427.n5.nabble.com/file/n3234703/camel-route.zip
camel-route.zip
--
View this message in context:
http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-tp3234703p3234703.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: XMPP communication not closed and new message rejected
Hi I havent had time to look into this. But there are some patches on JIRA to improve camel-xmpp. I know it has a some drawbacks a few spots. Maybe you can apply those patches and see if anything still missing. Also if you haven't tried then try the 2.4 or 2.5 release to see how it looks with latest code. Then feel free to create a JIRA. And if possible an unit test or patch. We love contributions at Apache. http://camel.apache.org/contributing On Tue, Oct 26, 2010 at 9:36 AM, vince vincethevi...@hotmail.com wrote: Hi guys I meet a strange error and this is maybe because I do not use Camel in the right way. Here is a quick description of my problem: I have a hornetQ JMS server. There is a queue inside. In this queue, there are two kind of messages : userEvent and systemEvent. -- userEvents are events to send to a specific recipient -- systemEvents are events which are sent to all recipient belonging to a specific domain of a ldap directory So a first Camel route is used to read from this queue, catching events and adding a specific field in the JMS message header to add destination recipient name reading in ldap server. These messages are then written in a JMS topic before delivery to recipients. In a second time, the topic is read and messages are sent to final recipient using recipientList (I used recipient list as I did not know what is the best way to simply retrieve a JMS message header information to build XMPP recipient destination URI. Maybe there is a clever way to send a message to only one destination after having customized the destination URI using a field in the JMS message header ? The main issue I meet with it is that when I send a message to a XMPP recipient, if another message is sent to this recipient, the second one failed. If I use a different resource to the XMPP URI, this works fine but I think this is not clean. When I have a look to the ejabberd server, I can see that communications with xmpp users are not closed, this is why I think, the second message to the same recipient with the same resource cannot be sent. Can somebody help me to find a solution ? Many thanks Vince -- View this message in context: http://camel.465427.n5.nabble.com/XMPP-communication-not-closed-and-new-message-rejected-tp3236657p3236657.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
AW: Calling external webservice using cxf camel endpoint
Hi, it looks like you simply want to convert the xml you receive in the first service to xml that is suitable for the other service. I think in this case you should not use the cxf component. Instead you should route from a jetty endpoint that receives the request to a http endpoint that sends the converted request. If the service is request reply then you will also have to convert the response. Best regards Christian Christian Schneider Informationsverarbeitung Business Solutions Handel und Dispatching Tel : +49-(0)721-63-15482 EnBW Systeme Infrastruktur Support GmbH Sitz der Gesellschaft: Karlsruhe Handelsregister: Amtsgericht Mannheim HRB 108550 Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck Geschäftsführer: Jochen Adenau, Hans-Günther Meier -Ursprüngliche Nachricht- Von: Madhav Bhargava [mailto:unmarsh...@gmail.com] Gesendet: Mittwoch, 27. Oktober 2010 11:03 An: users@camel.apache.org Betreff: Calling external webservice using cxf camel endpoint Hi All, I am using Camel 2.4 and cxf 2.2.11 for a prototype that i am developing at present. I have created a bunch of JAX-WS webservices and they are hosted on my local tomcat installation. I am trying to configure a CXF endpoint in Camel which will bind to the external webservice and post the soap request message to it. Following is the Spring CXF configuration: *!-- CXF consumer endpoint - This will be the entry point. --* !-- --- -- cxf:cxfEndpoint id=endpoint1 address=/sales wsdlURL=sales.wsdl endpointName=ns0:HTTP_Port serviceName=ns0:SalesService cxf:properties entry key=dataFormat value=PAYLOAD/ entry key=setDefaultBus value=true/ /cxf:properties /cxf:cxfEndpoint *!-- This is the externally hosted webservice --* !-- --- -- cxf:cxfEndpoint id=endpoint2 address=http://localhost:8080/jaxws-demows/SalesOrder; wsdlURL=http://localhost:8080/jaxws-demows/SalesOrder?wsdl; serviceName=ns2:SalesOrderService endpointName=ns2:SalesOrderPort cxf:properties entry key=dataFormat value=PAYLOAD/ /cxf:properties /cxf:cxfEndpoint *!-- camel route --* !-- --- -- camel:camelContext trace=true id=pipeline.example.camel-examples-cxf-composite-enrich camel:route camel:from uri=cxf:bean:endpoint1/ camel:convertBodyTo type=java.lang.String / camel:to uri=xslt:convertForEndpoint2.xslt/ camel:to uri=cxf:bean:endpoint2/ camel:to uri=file:/c:/tmp?fileName=result.xml / /camel:route /camel:camelContext For the external webservice represented by endpoint2 i only have one operation defined so ideally i do not have to specify the operationName and operationNamespace explicitly. When i submit a soap request using SOAP UI then the first 3 endpoints in the above route run just fine, the response from the first endpoint (consumer) is then converted to request for endpoint 2 using xslt endpoint successfully. However when the 4th endpoint in the route (external webservice) is invoked then the following exception is thrown: org.apache.cxf.interceptor.Fault: BindingOperationInfo must be specified at org.apache.camel.component.cxf.CxfConsumer$1.checkFailure(CxfConsumer.java:123) ~[na:na] at org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:102) ~[na:na] at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) ~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11] at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.6.0_21] at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.6.0_21] at java.util.concurrent.FutureTask.run(Unknown Source) ~[na:1.6.0_21] at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) ~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11] at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) ~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243) ~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11] at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:111) ~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11] at org.apache.cxf.transport.http_osgi.OsgiDestination.doMessage(OsgiDestination.java:80) ~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11] at org.apache.cxf.transport.http_osgi.OsgiServletController.invokeDestination(OsgiServletController.java:321)
Re: Abstracting Routes using Components
Great discussion Kristof! More inline...
On 26 October 2010 22:12, kristofsajdak kristof.saj...@gmail.com wrote:
jstrachan wrote:
Or to say that a slightly different way; if you just want a
parameterised RouteBuilder, well thats just a bean; no need for
anything new, Camel can do that nicely today
I considered using a parameterized RouteBuilder, however it failed to
address some specific
needs.
When using a solution based on parameterized RouteBuilders it requires you
to reference all
RouteBuilder used in the CamelContext.
This becomes complex when nesting route abstractions within route
abstractions several levels
deep. When using a top level RouteBuilder like
generateAndSignPdfRouteBuilder you are required
to also declare the signPdfRouteBuilder reference which exposes the
direct:signPdf endpoint.
E.g.
camelContext ...
routeBuilder ref=generateAndSignPdfRouteBuilder/
routeBuilder ref=signPdfRouteBuilder/
public class GenerateAndSignPdfRouteBuilder extends RouteBuilder {
�...@override
public void configure() throws Exception {
from(direct:generateAndSignPdf)
...
to(direct:signPdf);
}
}
public class SignPdfRouteBuilder extends RouteBuilder {
�...@override
public void configure() throws Exception {
from(direct:signPdf)
...
}
}
In other words, you would have to know how GenerateAndSignPdfRouteBuilder is
implemented
in order to use it.
Agreed. If you kinda squint a bit and think of the route builders as
'objects' and you want to compose 2 different routes together with
shared dependencies its a bit like 'constructors' and 'data hiding'.
We have protocol A and B and we need to route the output of A to the
input of B; so rather than B needing to know the implementation detail
of A; we add a constructor parameter for B's input...
class A extends ProtocolBuilder {...}
class B extends ProtocolBuilder {
public B(String inputUri) { ... }
}
// lets use Java code to simulate DI...
ProtocolBuilder a = new A();
ProtocolBuilder b = new B(b.getOutputUri());
we've now wired A and B together without B knowing anything about the
implementation detail of A.
Its quite common for lots of protocols to be 'unix pipe-ish' with an
input and output; so we could have helper classes where there's
standard input/output endpoints like this to create a pipeline...
CompositeProtocol composite = Protocols.pipeline(A.class, B.class, C.class);
where A:out - B:in and B:out - C:in. Indeed that could return a new
protocol; where composite:in maps to A:in and composite:out maps to
C:out
But then this is sounding like just treating A, B and C as endpoints :)
The Route Component solution (II) doesn't require the RouteBuilders used to
be referenced
in the camelContext. It instantiates an endpoint which adds the Route
information to the
camelcontext at runtime whenever a producer or consumer is started.
Would this concept be available in the ProtocolBuilder construct as well ?
I do see the added value of using a ProtocolBuilder and declaring it as a
bean in spring
but wouldn't you need to use some kind of generic component in the middle to
instantiate
and add those builders on demand ?
E.g.
route
from uri=route:standardActions://out/
to uri=route:generateAndSignPdf://in/
to uri=mock:result/
/route
Another reason why I didn't consider the Parameterized RouteBuilder is the
risk of name clashes
. When nesting components several levels deep and/or reusing the same
RouteBuilder beans multiple times
yet with different properties, this could lead to impredictable behaviour
when direct endpoints and routeIds are not unique within the CamelContext.
Thats a great point! Just like with OO, we probably need some kind of
data hiding; or in this case its 'endpoint hiding'. So maybe using
nested CamelContexts is a good thing.
Another random idea; imagine if we had a ProtocolBuilder which created
a child CamelContext - so all direct:foo and seda:bar endpoints
were totally private. Then imagine, as a simple implementation option
- we map all URIs within the ProtocolBuilder's URI space to the
direct: endpoint within the nested CamelContext.
So rather than having to add the alias() method I mentioned in the
other thread - we could just use URIs inside the route for the
'input/output/error' URIs...
http://camel.465427.n5.nabble.com/implementing-Protocols-or-a-way-to-make-it-easier-to-black-box-routes-and-compose-them-with-other-ros-td3218777.html#a3218777
e.g. imagine...
class A extends ProtocolBuilder {
public void configure() {
from(direct:in).
beanRef(foo).
to(direct:out);
}
}
class B extends ProtocolBuilder {
public void configure() {
from(direct:in).
unmarshal().jaxb().
to(direct:out);
}
}
// now lets wire A and B
// kinda like Foo | A | B | Bar on a unix command line
Re: AW: Calling external webservice using cxf camel endpoint
Hi Christian,
Thanks for your response. I have already tried the following, i replaced the
endpoint2 (which was pointing to the external webservice) with:
camel:setHeader headerName=CamelHttpMethod
camel:constantPOST/camel:constant
/camel:setHeader
camel:to
uri=http://localhost:8080/jaxws-demows/SalesOrderItemByBuyerAndProductQuery/
To test if the starting endpoint was working fine i commented out the rest
of the endpoints and only added a file endpoint. The starting endpoint
(endpoint1) was working as expected. So i kept it as it is.
When i used Http endpoint for endpoint2 then i got the following error:
] Exception: org.apache.camel.component.http.HttpOperationFailedException:
HTTP operation failed invoking
http://localhost:8080/jaxws-demows/SalesOrderItemByBuyerAndProductQuery with
statusCode: 500
15:18:25.370 WARN [693106...@qtp-346216967-0 -
/cxf/salesOrderDetailsForClaimsProcessing]
o.a.cxf.phase.PhaseInterceptorChain [Slf4jLogger.java:92] - Interceptor for
{http://www.example.com/cmservices}SalesOrderDetailsForClaimProcessingQueryResponse_In_SAService#{http://www.example.com/cmservices}ReadSalesOrderDetailsForClaimProcessing
has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: HTTP operation failed invoking
http://localhost:8080/jaxws-demows/SalesOrderItemByBuyerAndProductQuery with
statusCode: 500
at
org.apache.camel.component.cxf.CxfConsumer$1.checkFailure(CxfConsumer.java:123)
~[na:na]
at
org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:102)
~[na:na]
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) ~[na:1.6.0_21]
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
~[na:1.6.0_21]
at java.util.concurrent.FutureTask.run(Unknown Source)
~[na:1.6.0_21]
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:111)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.OsgiDestination.doMessage(OsgiDestination.java:80)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.OsgiServletController.invokeDestination(OsgiServletController.java:321)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.OsgiServletController.invoke(OsgiServletController.java:145)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.OsgiServlet.invoke(OsgiServlet.java:53)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.SpringOsgiServlet.invoke(SpringOsgiServlet.java:48)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
~[org.apache.geronimo.specs.geronimo-servlet_2.5_spec-1.1.1.jar:1.1.1]
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
~[org.mortbay.jetty.jetty-6.1.23.jar:na]
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
~[org.mortbay.jetty.jetty-6.1.23.jar:na]
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:64)
~[na:na]
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
~[org.mortbay.jetty.jetty-6.1.23.jar:na]
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
~[org.mortbay.jetty.jetty-6.1.23.jar:na]
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.handle(HttpServiceContext.java:111)
~[na:na]
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:64)
~[na:na]
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
~[org.mortbay.jetty.jetty-6.1.23.jar:na]
at org.mortbay.jetty.Server.handle(Server.java:322)
AW: AW: Calling external webservice using cxf camel endpoint
Status code 500 means internal server error. I guess the endpoint you sent the
request to was not able to process the request. Perhaps you will have more
details in the log of this endpoint.
It could be some invalid soap for that service...
Best regards
Christian
Christian Schneider
Informationsverarbeitung
Business Solutions
Handel und Dispatching
Tel : +49-(0)721-63-15482
EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier
-Ursprüngliche Nachricht-
Von: unmarshall [mailto:unmarsh...@gmail.com]
Gesendet: Mittwoch, 27. Oktober 2010 11:49
An: users@camel.apache.org
Betreff: Re: AW: Calling external webservice using cxf camel endpoint
Hi Christian,
Thanks for your response. I have already tried the following, i replaced the
endpoint2 (which was pointing to the external webservice) with:
camel:setHeader headerName=CamelHttpMethod
camel:constantPOST/camel:constant
/camel:setHeader
camel:to
uri=http://localhost:8080/jaxws-demows/SalesOrderItemByBuyerAndProductQuery/
To test if the starting endpoint was working fine i commented out the rest
of the endpoints and only added a file endpoint. The starting endpoint
(endpoint1) was working as expected. So i kept it as it is.
When i used Http endpoint for endpoint2 then i got the following error:
] Exception: org.apache.camel.component.http.HttpOperationFailedException:
HTTP operation failed invoking
http://localhost:8080/jaxws-demows/SalesOrderItemByBuyerAndProductQuery with
statusCode: 500
15:18:25.370 WARN [693106...@qtp-346216967-0 -
/cxf/salesOrderDetailsForClaimsProcessing]
o.a.cxf.phase.PhaseInterceptorChain [Slf4jLogger.java:92] - Interceptor for
{http://www.example.com/cmservices}SalesOrderDetailsForClaimProcessingQueryResponse_In_SAService#{http://www.example.com/cmservices}ReadSalesOrderDetailsForClaimProcessing
has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: HTTP operation failed invoking
http://localhost:8080/jaxws-demows/SalesOrderItemByBuyerAndProductQuery with
statusCode: 500
at
org.apache.camel.component.cxf.CxfConsumer$1.checkFailure(CxfConsumer.java:123)
~[na:na]
at
org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:102)
~[na:na]
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) ~[na:1.6.0_21]
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
~[na:1.6.0_21]
at java.util.concurrent.FutureTask.run(Unknown Source)
~[na:1.6.0_21]
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:111)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.OsgiDestination.doMessage(OsgiDestination.java:80)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.OsgiServletController.invokeDestination(OsgiServletController.java:321)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.OsgiServletController.invoke(OsgiServletController.java:145)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.OsgiServlet.invoke(OsgiServlet.java:53)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.http_osgi.SpringOsgiServlet.invoke(SpringOsgiServlet.java:48)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
~[org.apache.geronimo.specs.geronimo-servlet_2.5_spec-1.1.1.jar:1.1.1]
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
~[org.apache.cxf.cxf-bundle-2.2.11.jar:2.2.11]
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
~[org.mortbay.jetty.jetty-6.1.23.jar:na]
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
~[org.mortbay.jetty.jetty-6.1.23.jar:na]
at
Re: Abstracting Routes using Components
Hi all,
Long time listener, first time caller...
Currently I have a similar issue on a project I am working on. Taking some
hints from this discussion I am wondering if it is possible, and makes sense,
to extend a Camel Context to provide the IN, OUT and ERROR Endpoints.
Then you could nest this context inside a top level context and use nested
context ID as it's namespace reference.
{bean definition}
blackboxContext
in
out
error
routerContext
from:seda
to:blackboxContext
from:blackboxContext
to:mock
This isolates the namespaces and would allow abstraction of the desired
capabilities.
Thoughts?
Thanks,
Scott
On Oct 27, 2010, at 4:28 AM, James Strachan james.strac...@gmail.com wrote:
Great discussion Kristof! More inline...
On 26 October 2010 22:12, kristofsajdak kristof.saj...@gmail.com wrote:
jstrachan wrote:
Or to say that a slightly different way; if you just want a
parameterised RouteBuilder, well thats just a bean; no need for
anything new, Camel can do that nicely today
I considered using a parameterized RouteBuilder, however it failed to
address some specific
needs.
When using a solution based on parameterized RouteBuilders it requires you
to reference all
RouteBuilder used in the CamelContext.
This becomes complex when nesting route abstractions within route
abstractions several levels
deep. When using a top level RouteBuilder like
generateAndSignPdfRouteBuilder you are required
to also declare the signPdfRouteBuilder reference which exposes the
direct:signPdf endpoint.
E.g.
camelContext ...
routeBuilder ref=generateAndSignPdfRouteBuilder/
routeBuilder ref=signPdfRouteBuilder/
public class GenerateAndSignPdfRouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
from(direct:generateAndSignPdf)
...
to(direct:signPdf);
}
}
public class SignPdfRouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
from(direct:signPdf)
...
}
}
In other words, you would have to know how GenerateAndSignPdfRouteBuilder is
implemented
in order to use it.
Agreed. If you kinda squint a bit and think of the route builders as
'objects' and you want to compose 2 different routes together with
shared dependencies its a bit like 'constructors' and 'data hiding'.
We have protocol A and B and we need to route the output of A to the
input of B; so rather than B needing to know the implementation detail
of A; we add a constructor parameter for B's input...
class A extends ProtocolBuilder {...}
class B extends ProtocolBuilder {
public B(String inputUri) { ... }
}
// lets use Java code to simulate DI...
ProtocolBuilder a = new A();
ProtocolBuilder b = new B(b.getOutputUri());
we've now wired A and B together without B knowing anything about the
implementation detail of A.
Its quite common for lots of protocols to be 'unix pipe-ish' with an
input and output; so we could have helper classes where there's
standard input/output endpoints like this to create a pipeline...
CompositeProtocol composite = Protocols.pipeline(A.class, B.class, C.class);
where A:out - B:in and B:out - C:in. Indeed that could return a new
protocol; where composite:in maps to A:in and composite:out maps to
C:out
But then this is sounding like just treating A, B and C as endpoints :)
The Route Component solution (II) doesn't require the RouteBuilders used to
be referenced
in the camelContext. It instantiates an endpoint which adds the Route
information to the
camelcontext at runtime whenever a producer or consumer is started.
Would this concept be available in the ProtocolBuilder construct as well ?
I do see the added value of using a ProtocolBuilder and declaring it as a
bean in spring
but wouldn't you need to use some kind of generic component in the middle to
instantiate
and add those builders on demand ?
E.g.
route
from uri=route:standardActions://out/
to uri=route:generateAndSignPdf://in/
to uri=mock:result/
/route
Another reason why I didn't consider the Parameterized RouteBuilder is the
risk of name clashes
. When nesting components several levels deep and/or reusing the same
RouteBuilder beans multiple times
yet with different properties, this could lead to impredictable behaviour
when direct endpoints and routeIds are not unique within the CamelContext.
Thats a great point! Just like with OO, we probably need some kind of
data hiding; or in this case its 'endpoint hiding'. So maybe using
nested CamelContexts is a good thing.
Another random idea; imagine if we had a ProtocolBuilder which created
a child CamelContext - so all direct:foo and seda:bar endpoints
were totally private. Then imagine, as a simple implementation
Re: AW: AW: Calling external webservice using cxf camel endpoint
Hi Christian, Thanks for your response. Camel Http component worked but that is not what we are looking for. Following are the reasons: 1. The routes are usually created by the clients and they range from simple to complex. Along with the routes they provide XSLT mappings which will essentially only work on payloads. For using HTTP component i had to change the XSLT to add a soap envelop so that when a HTTP call is made to the external webservice it does not fail because after application of XSLT on the payload there is no soap envelop. 2. If we use ServiceMix along with CXF we can easily do this by creating cxf consumers and producers so i am not sure why is this so difficult to do using cxf and camel. I am planning to debug the Camel CXF codebase to see why OperationBindingInfo is not found even when we explicitly set it on the producer. Thanks Regards, Madhav Schneider Christian wrote: Status code 500 means internal server error. I guess the endpoint you sent the request to was not able to process the request. Perhaps you will have more details in the log of this endpoint. It could be some invalid soap for that service... Best regards Christian Christian Schneider Informationsverarbeitung Business Solutions Handel und Dispatching Tel : +49-(0)721-63-15482 EnBW Systeme Infrastruktur Support GmbH Sitz der Gesellschaft: Karlsruhe Handelsregister: Amtsgericht Mannheim HRB 108550 Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck Geschäftsführer: Jochen Adenau, Hans-Günther Meier -- View this message in context: http://camel.465427.n5.nabble.com/Calling-external-webservice-using-cxf-camel-endpoint-tp3238383p3238726.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel 2.4 with spring 2.5.6 TaskExecutor issue
We are using an instance of org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor and setting it on the JmsComponent. -- View this message in context: http://camel.465427.n5.nabble.com/camel-2-4-with-spring-2-5-6-TaskExecutor-issue-tp3237897p3238749.html Sent from the Camel - Users mailing list archive at Nabble.com.
MINA component startup error
I have the following route defined in an XML file: route from uri=mina:tcp://localhost:?decoderMaxLineLength=8192textline=truesync=false/ process ref=blah / to uri=seda:junk / /route I am getting the following error on ActiveMQ startup. I assume the string is not properly escaped or something weird like that, but not sure. ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 40 in XML document from URL [file:home/someguy/dev/camel.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The reference to entity textline must end with the ';' delimiter. java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 40 in XML document from URL [file:home/someguy/dev/camel.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The reference to entity textline must end with the ';' delimiter. at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:98) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:143) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.activemq.console.Main.runTaskClass(Main.java:251) at org.apache.activemq.console.Main.main(Main.java:107) Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 40 in XML document from URL [file:home/someguy/dev/camel.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The reference to entity textline must end with the ';' delimiter. at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader.importBeanDefinitionResource(XBeanBeanDefinitionDocumentReader.java:120) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader.parseDefaultElement(XBeanBeanDefinitionDocumentReader.java:95) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader.parseBeanDefinitions(XBeanBeanDefinitionDocumentReader.java:81) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.registerBeanDefinitions(XBeanXmlBeanDefinitionReader.java:79) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:111) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:104) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130) at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467) at
Re: Abstracting Routes using Components
Hi All, Based on this requirement/desire expressed by multiple users, I have added a JIRA entry for this https://issues.apache.org/activemq/browse/CAMEL-3285 https://issues.apache.org/activemq/browse/CAMEL-3285 I have also assigned this to yours truly and will make you wish my command... :) Cheers, Ashwin... - - Ashwin Karpe Apache Camel Committer Sr Principal Consultant FUSESource (a Progress Software Corporation subsidiary) http://fusesource.com http://fusesource.com Blog: http://opensourceknowledge.blogspot.com http://opensourceknowledge.blogspot.com - -- View this message in context: http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-tp3234703p3239365.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: MINA component startup error
I ended up using the following XML to get things working. bean id=myMinaFactory class=org.apache.camel.component.mina.MinaComponent constructor-arg index=0 ref=case / /bean bean id=myMinaEndpoint factory-bean=myMinaFactory factory-method=createEndpoint constructor-arg index=0 ref=myMinaConfig/ /bean bean id=myMinaConfig class=org.apache.camel.component.mina.MinaConfiguration property name=protocol value=tcp / property name=host value=0.0.0.0 / property name=port value= / property name=sync value=false / property name=minaLogger value=false / property name=textline value=true / property name=decoderMaxLineLength value=8192 / /bean ... ... ... route from ref=myMinaEndpoint / process ref=blah / to uri=seda:junk / /route On Wed, Oct 27, 2010 at 3:30 PM, Mark Webb elihusma...@gmail.com wrote: I have the following route defined in an XML file: route from uri=mina:tcp://localhost:?decoderMaxLineLength=8192textline=truesync=false/ process ref=blah / to uri=seda:junk / /route I am getting the following error on ActiveMQ startup. I assume the string is not properly escaped or something weird like that, but not sure. ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 40 in XML document from URL [file:home/someguy/dev/camel.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The reference to entity textline must end with the ';' delimiter. java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 40 in XML document from URL [file:home/someguy/dev/camel.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The reference to entity textline must end with the ';' delimiter. at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:98) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:143) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.activemq.console.Main.runTaskClass(Main.java:251) at org.apache.activemq.console.Main.main(Main.java:107) Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 40 in XML document from URL [file:home/someguy/dev/camel.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The reference to entity textline must end with the ';' delimiter. at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader.importBeanDefinitionResource(XBeanBeanDefinitionDocumentReader.java:120) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader.parseDefaultElement(XBeanBeanDefinitionDocumentReader.java:95) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader.parseBeanDefinitions(XBeanBeanDefinitionDocumentReader.java:81) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.registerBeanDefinitions(XBeanXmlBeanDefinitionReader.java:79) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
Re: Abstracting Routes using Components
On Wed, Oct 27, 2010 at 5:54 PM, James Strachan
james.strac...@gmail.com wrote:
On 27 October 2010 11:48, Scott England-Sullivan sully6...@yahoo.com wrote:
Hi all,
Long time listener, first time caller...
Welcome Scott!
Currently I have a similar issue on a project I am working on. Taking some
hints from this discussion I am wondering if it is possible, and makes
sense, to extend a Camel Context to provide the IN, OUT and ERROR Endpoints.
Then you could nest this context inside a top level context and use nested
context ID as it's namespace reference.
{bean definition}
blackboxContext
in
out
error
routerContext
from:seda
to:blackboxContext
from:blackboxContext
to:mock
This isolates the namespaces and would allow abstraction of the desired
capabilities.
Agreed! I think we're all on about the same page; there's just a few
devils in the details on exactly how this all works.
* we want to wrap up a set of routes as either an Endpoint (kinda like
the route:foo examples from Kristof which have a natural in/out type
approach), or as a Component with internal named endpoints
* we either use a local: component for local only endpoints inside
nested routes; or just nest an inner CamelContext inside them to get
the same kind of effect
I would assume the local: thing would be the easiest.
Having a nested CamelContext, we would maybe have to strip it down
from some features to keep it lighter (loading type converters, JMX
management, event notification, OSGi complexity, lifecycle etc.).
* there are a few options as to how we should export or declare the
'public endpoints' for a Protocol (e.g. maybe component:in maps to
local:in inside the route - or is there some explicit mapping of a
public name component:in to some implementation endpoint URI?
Maybe we just need to build a prototype of this feature and kick the
tyres a bit and see which approaches seem to work the best?
Yeah kick on the tires from Kristof :)
--
James
---
FuseSource
Email: ja...@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/
Open Source Integration
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Abstracting Routes using Components
On Wed, Oct 27, 2010 at 11:08 PM, kristofsajdak
kristof.saj...@gmail.com wrote:
Great feedback guys, much appreciated !
jstrachan wrote:
Agreed. If you kinda squint a bit and think of the route builders as
'objects' and you want to compose 2 different routes together with
shared dependencies its a bit like 'constructors' and 'data hiding'.
We have protocol A and B and we need to route the output of A to the
input of B; so rather than B needing to know the implementation detail
of A; we add a constructor parameter for B's input...
class A extends ProtocolBuilder {...}
class B extends ProtocolBuilder {
public B(String inputUri) { ... }
}
// lets use Java code to simulate DI...
ProtocolBuilder a = new A();
ProtocolBuilder b = new B(b.getOutputUri());
we've now wired A and B together without B knowing anything about the
implementation detail of A.
Its quite common for lots of protocols to be 'unix pipe-ish' with an
input and output; so we could have helper classes where there's
standard input/output endpoints like this to create a pipeline...
CompositeProtocol composite = Protocols.pipeline(A.class, B.class,
C.class);
where A:out - B:in and B:out - C:in. Indeed that could return a new
protocol; where composite:in maps to A:in and composite:out maps to
C:out
But then this is sounding like just treating A, B and C as endpoints :)
Indeed that is adding more flexibility and will be quite usefull when
nesting protocolBuilders several levels deep.
However, I do have another point which relates to the specific use case of
the customer I mentioned.
Developers - provide ProtocolBuilder implementations
Solution consultants - use ProtocolBuilders abstractions to wire the route.
Yeah this sounds like a great use case and in demand in more and more companies.
This is something that we hear more often and often.
Practically, it seems to me that the easiest way of achieving that is to
create one or more modules
which contain the ProtocolBuilders implementation classes and the spring xml
files which configure them.
Whenever a solution consultant starts working on a new customer
implementation he could use an archetype to create a module which has the
dependencies to the ProtocolBuilder modules preconfigured.
The solution consultant would then create the route in xml dsl and use
camel:run to execute the route, this plugin goal would in turn bootstrap all
the ProtocolBuilder configurations located in
classpath*:META-INF/spring/.xml, making them available to the route at
runtime.
Now my question is: When you define a ProtocolBuilder in the spring xml,
would it get initialized and added to the CamelContext at that point ? I
mean I don't think it's a good idea to initialize and add all the
ProtocolBuilders which are available in classpath*:META-INF/spring, but
neither do I want to leave it up to the solution consultant to explicitly
define which builders get initialized.
E.g. Like with the Parameterized RouteBuilder concept I mentioned earlier
camelContext ...
routeBuilder ref=generateAndSignPdfRouteBuilder/
routeBuilder ref=signPdfRouteBuilder/
Which is just way to complex for non developers in my opinion.
You can use annotations, for example the Spring @Component annotation.
You would then @Component annotate the RouteBuilder to be included.
Then you can use the contextScan/ tag
See http://camel.apache.org/spring.html
This means its standard Spring stuff to annotate and use the spring
XML tag to enable its context scanner.
All you do in Camel is to add this contextScan/ inside the camelContext tag.
Maybe there are other ways to make this easier? Any suggestions?
It sure would be nice if you could initialize and add the ProtocolBuilder
route configuration on demand.
Saving overhead on startup and runtime, yet making it easy for a low tech
guy to use all of the available
ProtocolBuilders - no explicit declaration of ProtocolBuilders nor any
fiddling with dependencies in the pom.xml.
The concept of the shorthand notation could add value here as well.
The global properties + tech dependencies like a datasource could be
configured by developers using spring di in the xml. Wheras the parameters,
which make sense in the context of the route, are defined by the solution
consultant using the shorthand notation.
E.g.
?signatureReason=JustForFunsignatureVisible=truexslUri=com/xti/poc/camel/route/sample1/krusty.xsl
jstrachan wrote:
Thats a great point! Just like with OO, we probably need some kind of
data hiding; or in this case its 'endpoint hiding'. So maybe using
nested CamelContexts is a good thing.
Another random idea; imagine if we had a ProtocolBuilder which created
a child CamelContext - so all direct:foo and seda:bar endpoints
were totally private. Then imagine, as a simple implementation option
- we map all URIs within the ProtocolBuilder's URI space to the
direct: endpoint within the
Re: camel 2.4 with spring 2.5.6 TaskExecutor issue
Hi I have created a ticket to track this bug https://issues.apache.org/activemq/browse/CAMEL-3286 Lets see if we can get it to support both out of the box. On Wed, Oct 27, 2010 at 5:13 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Wed, Oct 27, 2010 at 3:52 PM, ndjensen ndjen...@gmail.com wrote: We are using an instance of org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor and setting it on the JmsComponent. -- If you can avoid using that then it should work out of the box. If not you will have to compile the camel-jms against spring 2.5 yourself. View this message in context: http://camel.465427.n5.nabble.com/camel-2-4-with-spring-2-5-6-TaskExecutor-issue-tp3237897p3238749.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/ -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
