Component external dependency

[Márcio Guedes]

What is the correct way to include external dependencies in a component?
After deploying it on ServiceMix and trying to start it I'm getting
the following error:
org.osgi.framework.BundleException: Unresolved constraint in bundle
camel-amqptest-spring [288]: Unable to resolve 288.0: missing
requirement [288.0] package; (package=amqp.spring.converter)

amq.spring.converter is provided by com.bluelock:camel-spring-amqp and
referenced by the following maven dependency:


com.bluelock
camel-spring-amqp
1.5


I want to know the best way to include that dependency or feature on
my final jar to deploy on ServiceMix so that the component starts
without problems.

--
Marcio Guedes

Re: Routing from servlet to CXF JAXRS via direct

[Sergey Beryozkin]

Hi
On 10/06/13 20:05, Todd Orr wrote:

I spoke too soon. I have been trying to figure out why the CXF service's
JAXB unmarshalling has been throwing EOF in prolog errors. I created a
processor to get some idea as to what the messages are looking like before
getting sent off to CXF. My routes are configured as such:

 
   http://0.0.0.0:8099/api/rest?matchOnUriPrefix=true";
/>
   
   
   
 

streamCache is set to true. The processor has the following code:

 HttpServletRequest request =
exchange.getIn(HttpMessage.class).getRequest();
 String something = IOUtils.toString(request.getInputStream());
 String requestBody =
IOUtils.toString(exchange.getIn().getBody(InputStream.class));

The request's inputStream, something, is "". The requestBody, however,
contains the entire XML structure that I am posting. I believe that the
problem is that Camel reads the incoming Http request's input stream and
copies the data to the Camel message body, but leaves the request's input
stream as read and therefore un-rereadable. Correct me if I'm wrong, but it
is this request, I believe, that gets routed to the CXF service. Then CXF
has nothing to read and the unmarshalling fails.

Am I right? Is this a bug?


I'm not sure, we have a demo where this kind of routing works.
I wonder if enabling 'streamCache' can explain why the original 
InputStream is empty, may be you should not enable that property ?


That said, I wonder if CXFRS (and CXF) component should check

exchange.getIn().getBody(InputStream.class)

first ? And if it is set, then register HTTPServletRequestWrapper with 
this stream returned instead ? I can do a patch if it makes sense...


Sergey



On Mon, Jun 3, 2013 at 4:13 PM, Todd Orr  wrote:


That works perfectly. Thanks!


On Mon, Jun 3, 2013 at 4:09 PM, Sergey Beryozkin wrote:


Hi

On 03/06/13 20:53, Todd Orr wrote:


I'm relatively new to Camel. I did research what I am attempting to do,
but
did not find much help.

The goal is to take an existing standalone CXF rest service (with many
service beans) and split it into multiple independent CXF rest services
coordinated by Camel.

As an initial step, I am attempting to front the existing service with
Camel. So to be clear, at this stage, I only want to pass HTTP requests
from Camel down to the CXF service. To this end I have run into multiple
issues. I am currently unable to route the HTTP message received by Camel
to the CXF service.

My route:


  


**CamelHttpServletRequest


  

I have configured CXF using camel's transport factory using:


  
  
  
  

  
http://cxf.apache.org/**transports/camel


  


This was required to get around some earlier issues I ran into. My CXF
service is configured like:



  
...

Startup is fine. On attempting to hit the servlet via RESTClient I can
see
the message I passed in logged correctly. However, the CXF service cannot
receive the message. The error is:

No consumers available on endpoint: Endpoint[direct://api] to process:
Exchange ...

Any help is greatly appreciated.

  This is an interesting idea, to try to use a 'direct' URI scheme as

jaxrs server endpoint. I don't think it works right now, and I'm not sure
what has to be done yet, but definitely worth investigating...
In meantime, using Camel transport scheme will do, try something like
this:





 
 http://camel.apache.**
org/schema/spring " trace="false">
 
 
 
 
 


HTH, Sergey


T

Incompatible types in Object mailBody = template.sendBody()

[fvillavi]

I am trying to run Apache Camel Tutorial Example Report incident Part 2.
Here are the instructions:

mvn test

And the result:

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 4.690s
[INFO] Finished at: Mon Jun 10 12:12:58 ECT 2013
[INFO] Final Memory: 14M/83M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.0:compile (default-compile)
on project camel-example-reportincident: Compilation failure: Compilation
failure:
[ERROR]
/var/lib/jetty/webapps/camel-example-reportincident/src/main/java/ReportIncidentEndpointImpl.java:[33,43]
error: incompatible types

The segment of java code:

 public OutputReportIncident reportIncident(InputReportIncident parameters)
{
// transform the request into a mail body
  ...
  
Object mailBody = template.sendBody("velocity:MailBody.vm",
parameters);

Browsing the documentation, sendBody () is defined as void so it can't
return an object.

Software I am using:
Fedora 17
jdk 1.7
Apache Camel 2.11.0
Apache cxf 2.7.5
Apache maven 3.0.5
Spring 94.11

I don't know how to solve this problem, can some body help me?
Thanks.




--
View this message in context: 
http://camel.465427.n5.nabble.com/Incompatible-types-in-Object-mailBody-template-sendBody-tp5734074.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Routing from servlet to CXF JAXRS via direct

[Todd Orr]

I spoke too soon. I have been trying to figure out why the CXF service's
JAXB unmarshalling has been throwing EOF in prolog errors. I created a
processor to get some idea as to what the messages are looking like before
getting sent off to CXF. My routes are configured as such:


  http://0.0.0.0:8099/api/rest?matchOnUriPrefix=true";
/>
  
  
  


streamCache is set to true. The processor has the following code:

HttpServletRequest request =
exchange.getIn(HttpMessage.class).getRequest();
String something = IOUtils.toString(request.getInputStream());
String requestBody =
IOUtils.toString(exchange.getIn().getBody(InputStream.class));

The request's inputStream, something, is "". The requestBody, however,
contains the entire XML structure that I am posting. I believe that the
problem is that Camel reads the incoming Http request's input stream and
copies the data to the Camel message body, but leaves the request's input
stream as read and therefore un-rereadable. Correct me if I'm wrong, but it
is this request, I believe, that gets routed to the CXF service. Then CXF
has nothing to read and the unmarshalling fails.

Am I right? Is this a bug?



On Mon, Jun 3, 2013 at 4:13 PM, Todd Orr  wrote:

> That works perfectly. Thanks!
>
>
> On Mon, Jun 3, 2013 at 4:09 PM, Sergey Beryozkin wrote:
>
>> Hi
>>
>> On 03/06/13 20:53, Todd Orr wrote:
>>
>>> I'm relatively new to Camel. I did research what I am attempting to do,
>>> but
>>> did not find much help.
>>>
>>> The goal is to take an existing standalone CXF rest service (with many
>>> service beans) and split it into multiple independent CXF rest services
>>> coordinated by Camel.
>>>
>>> As an initial step, I am attempting to front the existing service with
>>> Camel. So to be clear, at this stage, I only want to pass HTTP requests
>>> from Camel down to the CXF service. To this end I have run into multiple
>>> issues. I am currently unable to route the HTTP message received by Camel
>>> to the CXF service.
>>>
>>> My route:
>>>
>>>
>>>  
>>>>> uri="servlet:///rest?**servletName=CamelAPI&**matchOnUriPrefix=true"
>>> />
>>>
>>>**CamelHttpServletRequest
>>>
>>>
>>>  
>>>
>>> I have configured CXF using camel's transport factory using:
>>>
>>>>> class="org.apache.camel.**component.cxf.transport.**
>>> CamelTransportFactory">
>>>  
>>>  
>>>  
>>>  
>>>
>>>  
>>> http://cxf.apache.org/**transports/camel
>>> 
>>>
>>>  
>>>
>>>
>>> This was required to get around some earlier issues I ran into. My CXF
>>> service is configured like:
>>>
>>>
>>>
>>>  
>>>...
>>>
>>> Startup is fine. On attempting to hit the servlet via RESTClient I can
>>> see
>>> the message I passed in logged correctly. However, the CXF service cannot
>>> receive the message. The error is:
>>>
>>> No consumers available on endpoint: Endpoint[direct://api] to process:
>>> Exchange ...
>>>
>>> Any help is greatly appreciated.
>>>
>>>  This is an interesting idea, to try to use a 'direct' URI scheme as
>> jaxrs server endpoint. I don't think it works right now, and I'm not sure
>> what has to be done yet, but definitely worth investigating...
>> In meantime, using Camel transport scheme will do, try something like
>> this:
>>
>> 
>> 
>> 
>>
>> 
>> http://camel.apache.**
>> org/schema/spring " trace="false">
>> 
>> 
>> 
>> 
>> 
>>
>>
>> HTH, Sergey
>>
>>> T
>>>
>>>
>>
>

Re: Camel Mustache & Handlebars components

[Chris Wolf]

Oh, I see, ok.  Actually, upon further thinking, instead of wrapping
the in-memory
object graph in "SimpleHash" - there's an interface called
"TemplateModelIterator",
where, I think I could implement it such that the iterator returned would be an
iterator whose next() could return a "TemplateModel" representing the
current record and have a special end-of-group record that signals next()
to return null, thus closing the file.I haven't tried that, but hopefully it
will work.

I see what you're saying about having a single client-side and
server-side template
language.


Thanks,

Chris

On Mon, Jun 10, 2013 at 11:52 AM, gquintana  wrote:
> No these components won't help you, they work exactly like FreeMarker. On
> Mustache Java, I think you can customize the way your object graph is walked
> when rendering the template (see BaseObjectHandler). But the whole message
> must fit in memory.
>
> I produced theses components because I am using Handlebars on the client
> side (in JavaScript) and I didn't want to introduce another templating
> language.
>
>
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-Mustache-Handlebars-components-tp5734043p5734068.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Communication between Camel and JBoss AS7

[Chris Wolf]

We use JBoss-6 and HornetQ MDBs.  (i.e. JMS)

On Mon, Jun 10, 2013 at 11:55 AM, ak-dak  wrote:
> Hi all,
>
> I want to develop a camel route which processes a xml message. Below a
> simple route to demonstrate my use case.
>
> 
> 
> 
> 
> 
> 
> 
>
> I want to do all business JPA persist logic by EJB's within a JBoss AS 7.
> See the methods of "jbossService" within my example.
>
> And now my question. What's the "best" solution to communicate with a JBoss
> AS 7 to invoke EJB's synchronously? Wrapping of the EJB calls within
> Soap-Webservices could be a solution but I'am concerned about the
> performance. When the system goes into production we have to process 1
> and more messages as fast as possible.
>
> Maybe someone has a more faster solution?
>
> Best regards
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Communication-between-Camel-and-JBoss-AS7-tp5734069.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Communication between Camel and JBoss AS7

[ak-dak]

Hi all,

I want to develop a camel route which processes a xml message. Below a
simple route to demonstrate my use case.









I want to do all business JPA persist logic by EJB's within a JBoss AS 7.
See the methods of "jbossService" within my example.

And now my question. What's the "best" solution to communicate with a JBoss
AS 7 to invoke EJB's synchronously? Wrapping of the EJB calls within
Soap-Webservices could be a solution but I'am concerned about the
performance. When the system goes into production we have to process 1
and more messages as fast as possible.

Maybe someone has a more faster solution?

Best regards 



--
View this message in context: 
http://camel.465427.n5.nabble.com/Communication-between-Camel-and-JBoss-AS7-tp5734069.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel Mustache & Handlebars components

[gquintana]

No these components won't help you, they work exactly like FreeMarker. On
Mustache Java, I think you can customize the way your object graph is walked
when rendering the template (see BaseObjectHandler). But the whole message
must fit in memory.

I produced theses components because I am using Handlebars on the client
side (in JavaScript) and I didn't want to introduce another templating
language.





--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-Mustache-Handlebars-components-tp5734043p5734068.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel Mustache & Handlebars components

[Chris Wolf]

I'm just curious - how is this any better/different that
camel-freemarker?  What are the advantages?  I ask because am using
camel-freemarker and am having the following issue with Freemarker:

POJOs correspond to records in a document, normally you pass a
collection of POJOs into Freemarker to get the output document.

The issue I face is the size of the document could be
gigantic/undetermined, so in my route, everything is streamed
record-by-record - reading in the whole document into memory is not an
option, therefore I was not able to use the "freemarker://" component
and had to write yet another custom processor which opens (with
append=true) writes and closes the output file on every record, since
the number of records is unknown - this works except it's probably not
efficient and I get spurious blank lines.

Would your "Handlerbar" and/or "Mustache" template solution handle
this record-streaming scenario, or does the whole input have to be
read into memory also?

Thanks,

Chris

On Sat, Jun 8, 2013 at 4:21 PM, gquintana  wrote:
> Hi all,
>
> Just for the fun, I wrote Camel components using Mustache or Handlebars
> templating engines:
> https://github.com/gquintana/camel-stuff
>
> Cheers,
> Gérald
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-Mustache-Handlebars-components-tp5734043.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

How to get JMX-wrapped Component, Endpoint and Consumer?

[Chris Wolf]

I notice the standard, "out-of-the-box" components automatically get
the Component, Endpoint and Consumer/Producer wrapped in JMX-managed
wrappers - all without the JMX annotations.   Poking around in the
code, I see:

DefaultManagementLifecycleStrategy.onRoutesAdd(...)

..but I don't know how this ties into normal RouteBuilder usages..

I see also:

ManagedCamelContext.createEndpoint(...)

...but, again,  I don't know how this ties into normal RouteBuilder usage.

So how would I do that?

Thanks,

Chris

Re: Cannot get SFTP component to stop polling

[Chris Wolf]

Thanks for the suggestions.  So far, I have not done anything
programmatically - just tried suspending the route via JMX (jconsole)
and when that didn't work, tried stopping the route - that didn't work
either.  I can't remove the route since it is declarative from
Spring-DSL, however, I guess I could resort to changing it to dynamic
with yet another custom Processor to add/remove the route.

Regards,

Chris

On Fri, Jun 7, 2013 at 5:15 PM, swwyatt  wrote:
> We are doing something similar. How are you stopping the route?
>
> I ended up doing this:
>
> camelContext.stopRoute(routeId);
> camelContext.removeRoute(routeId);
>
> We are having several dynamic consumer routes in the same context, so we
> additionally call camelContext.stop(), hopefully this would just stop the
> single route.
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Cannot-get-SFTP-component-to-stop-polling-tp5734021p5734023.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Camel website: typo in cxfrs endpoint adress?

[Wim Verreydt]

Hi everyone,

Last week I was trying to create an example with the cxfrs Simple Binding 
Style. On the webpage http://camel.apache.org/cxfrs.html the example code 
mentions the the following endpoint (a few times): 

cxf:bean:rsServer?bindingStyle=SimpleConsumer

After a while I figured it should be cxfrs: … instead of cxf: … as used in the 
other cxfrs examples (at least in camel 2.11). I think this is just a typing 
error?

Sincerely
Wim Verreydt

jetty consumer: cannot set minThreads and maxThreads from uri.

[kuro]

I cannot set minThreads and maxThreads values when the endpoint is defined
for the following uri .

JettyHttpComponent (minThreads = null)



http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="...">
  http://camel.apache.org/schema/spring";
autoStartup="true" id="camel">
http://0.0.0.0:12000/test?minThreads=3&maxThreads=5"; />

  
  
  

  


I'm using Camel 2.10.4,  2.11.0.





--
View this message in context: 
http://camel.465427.n5.nabble.com/jetty-consumer-cannot-set-minThreads-and-maxThreads-from-uri-tp5734060.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Regarding request routing through camel web app

[indrayani]

hi,
are you talking about the servlet that i have mentioned in the from URI??
if that is the case, then the from URI shows a web application that is
deployed on tomcat.

I checked the link that you have provided, but that did not helped me.

my requirement is Web application A gives a call to camel web application ,
and camel web application contains routes defined  as From URI contains
application A's URI and the to URI contains application B's URI.
So, what I want is, camel web application should understand that the request
has come from Application A and it should route it to web application B.



--
View this message in context: 
http://camel.465427.n5.nabble.com/Regarding-request-routing-through-camel-web-app-tp5734013p5734058.html
Sent from the Camel - Users mailing list archive at Nabble.com.