Camel context not active when calling a bean?!

[mbernloehr]

Hey guys,

i'm facing a little problem. I'm using SwitchYard 2.0.0.Beta1 deployed on Wildfly 8.1.0.Final

My application is deployed as an EAR-Container.

BirtReportEngine.ear

---- BirtReportEngine-ejb (which consists of the business logic for generating reports and the BIRT framework)

---- BirtReportEngine-web (admin interface)

In the picture you can see my SwitchYard context in the EJB conext. The upper SOAP webservice is for generating reports.

But from my admin interface i'm injecting the ReportGenerationServiceBean. So i don't need to call the webservice.

However. i'm thinking that the Camel context is not properly initialized, because when i'm trying to send an email from the MailSendService i'm getting an exception.

I debugged in several stages and saw that when calling the SOAP Webservice there are much more headers initialized in the Camel context than when calling the bean directly from the admin interface.

Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: smtp://smtp-server.com:25?from=NoReply%40BirtReportEngine&password=password&subject=subject&to=useremail&username=user due to: No component found with scheme: smtp
    at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:551)
    at org.apache.camel.impl.DefaultProducerTemplate.resolveMandatoryEndpoint(DefaultProducerTemplate.java:453)
    at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:109)
    at org.switchyard.component.camel.common.handler.OutboundHandler.handleInOnly(OutboundHandler.java:157)
    at org.switchyard.component.camel.common.handler.OutboundHandler.handleMessage(OutboundHandler.java:145)
    at org.switchyard.handlers.ProviderHandler.handleMessage(ProviderHandler.java:77)
    at org.switchyard.bus.camel.processors.HandlerProcessor.process(HandlerProcessor.java:61)
    at org.apache.camel.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:63)
    at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
    at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:91)
    at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:91)
    at org.switchyard.bus.camel.audit.FaultProcessor.process(FaultProcessor.java:45)
    at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:91)
    at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
    at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
    at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
    ... 133 more

This is the stackstrace when sending an email. I'm i have all required dependencies. When calling the SOAP webservice from SoapUI sending an email works like a charm.

@Inject
    private ReportGenerationServiceBean reportGenerationServiceBean;

I'm injecting the bean in the admin interface like this.

I hope you understand my problem and sorry for my bad english ;-)

Do you need any further information?

Regards

Matthias

[jorgemoralespou_2]

Hi Matthias,

Usually that error appears when you are trying to use a camel component that is not directly usable by SwitchYard due to not having an extension being made to SwitchYard to support it. Some of the camel components are added through SwitchYard abstractions, and some are directly usable from switchyard.

This is just a guess, but I have similar issues like this before.

The mail binding should work, and there is a quickstart showing how to use it: quickstarts/camel-mail-binding at master · jboss-switchyard/quickstarts · GitHub Look at that quickstart and test it in your environment. If it doesn't work either, and you hit same error, then there is a bug in SwitchYard and you should raise a JIRA for that, if it works, then it might be the way you ar eusing the mail component, and probably the best way to nail down the problem would be for you to post the relevant bits of the ReportFileRoutingService camel route and the Switchyard.xml related to MailSendService reference. With that we might be able to help further.

Cheers,

[mbernloehr]

I debugged the mail reference binding. I found huge differenced in the camel message headers when calling the SOAP webservice instead of directly calling the bean from the web package.

So for example the headers in the camel message when calling it from the webservice looks like:

{org.switchyard.messageId=ID-B31XX4J-50520-1422952177725-5-47, content-type=[text/xml;charset=UTF-8], org.switchyard.contentType={urn:com.trw.dalfde.evc.reportengine:ReportEngineCore:1.0}generateReport, org.switchyard.bus.camel.messageSent=true, connection=[Keep-Alive], Host=[localhost:8082], Content-Length=[2059], org.switchyard.soap.messageName=generateReport, SOAPAction=["generateReport"], breadcrumbId=ID-B31XX4J-50520-1422952177725-5-47, User-Agent=[Apache-HttpClient/4.1.1 (java 1.5)], accept-encoding=[gzip,deflate], org.switchyard.bus.camel.labels={content-type=[org.switchyard.label.endpoint.http, org.switchyard.label.component.soap], org.switchyard.contentType=[org.switchyard.label.behavior.transient], org.switchyard.bus.camel.messageSent=[org.switchyard.label.behavior.transient], connection=[org.switchyard.label.endpoint.http, org.switchyard.label.component.soap], Host=[org.switchyard.label.endpoint.http, org.switchyard.label.component.soap], Content-Length=[org.switchyard.label.endpoint.http, org.switchyard.label.component.soap], SOAPAction=[org.switchyard.label.endpoint.http, org.switchyard.label.component.soap], User-Agent=[org.switchyard.label.endpoint.http, org.switchyard.label.component.soap], accept-encoding=[org.switchyard.label.endpoint.http, org.switchyard.label.component.soap]}}

When calling the bean directly the headers from the camel message looks like:

{org.switchyard.messageId=ID-B31XX4J-50520-1422952177725-5-43, org.switchyard.bus.camel.messageSent=true, CamelFileName=new_report_generated_on_2015y.02m.03d_09h.39m.30s.pdf, breadcrumbId=ID-B31XX4J-50520-1422952177725-5-39, outputLocation=MAIL, org.switchyard.bus.camel.labels={org.switchyard.bus.camel.messageSent=[org.switchyard.label.behavior.transient]}}

Because of that i thought it might be the camel context or something like that.

[mbernloehr]

Btw, the FileSaveService works like a charm, wether the generation gets called from the SOAP webservice or directly by the bean.

[igarashitm]

Did you mean your mail reference depend on headers produced by SOAP binding? then you should add it somehow if you skip the SOAP binding. Otherwise, I don't think mail reference binding itself depend on any header produced by SOAP. And CamelContext is always active after deployment, if not any SwitchYard exchange doesn't work.

[mbernloehr]

I thought that it perhaps depend on that headers, because that's the only difference i found so far. As i said the mail reference binding works like expected when the generation gets called via the SOAP service.

I only get the exception when injecting the ReportGenerationServiceBean in my web-application and calling the generation directly and not via the SOAPwebservice.

<sca:reference name="MailSendService" multiplicity="0..1" promote="ReportFileRoutingServiceRoute/MailSendService">
      <sca:interface.java interface="com.trw.dalfde.evc.reportengine.birt.sw.core.MailSendService"/>
      <mail:binding.mail name="mail1">
        <mail:host>smtp-server</mail:host>
        <mail:port>25</mail:port>
        <mail:username>user</mail:username>
        <mail:password>password</mail:password>
        <mail:produce>
          <mail:subject>subject</mail:subject>
          <mail:from>NoReply@BirtReportEngine</mail:from>
          <mail:to>user email address</mail:to>
        </mail:produce>
      </mail:binding.mail>
    </sca:reference>

That's the mail binding from the switchyard.xml file. But like i said, it works when calling the SOAP webservice.

[jorgemoralespou_2]

Hi,

I guess this could be related to how SwitchYard injects the correct context. Could you create a small reproducer. Just the bits needed to be able to invoke it like you do? Then we could probably triage better the problem, and if there is an issue fix it, or provide a workaround.

This should be not too much work.