Created attachment 783037 [details] reproducer I have a simple composite: - BPEL Process with WSDL interface - Bean service with Java interface (matching WSDL) - SOAP binding, promoted service is BPEL process When I try to invoke Bean service from BPEL process, transformation between WSDL message and Java object has to be done, but error is thrown. Problem is, that BPEL process sends message according to WSDL file and corresponding XSD, but JAXB transformer between WSDL and Java bean expects XML document with different tags (according to JAXB annotations of that Java file). Second problem may be, that even if the bean service is called with error, process doesn't know it and waits for response until specified timeout doesn't run out. Example reproducer is attached.
JAXB transformation is for data objects that contain JAXB annotations or include an ObjectFactory in a configured context path. String does not qualify, so using JAXB in this context is invalid. As to the second issue, the transformation error is returned to the BPEL engine and it's up to Riftsaw to decide what to do with it at that point. I don't see a build version being used here, but I noticed Alpha1 as the SY version in the pom.xml. I can't recall whether error reporting on in-only was included for Alpha1 or not, but it's definitely in 1.0.0.Final. I tested your app locally and the error definitely gets back to the engine.
Created attachment 785164 [details] reproducer_v2
I've added new version of reproducer, now the method takes JAXB annotated object as a parameter. But it the outcome is still the same, problem with unmarshalling, because message from BPEL process is formatted according to WSDL with tag representing the method. Anyway, if tooling lets me to configure required transformer between WSDL and Java interface as a JAXB transformer, I expect it will work. It's possible to use JAXB transformer to transform to plain String parameter and it works in other cases (if BPEL process is not involved). It should be documented very properly where to use transformator and which kind and where users should use MessageComposer or any other principal Switchyard is using, now it's not clear and users will be confused.
In terms of the actual failure here, this is no different than a Smooks, Java or XSLT transformation which gets unexpected input. I agree with your point on documentation. I seem to remember someone coming up with a similar issue in the community recently. We can definitely add some text which specifically calls out the expectations for JAXB transformations. It would be nice if the tooling could help constrain this more, but it turns out to be a bit involved. I need to dig up the community thread on this and attach it to the BZ for context. From my POV, I would consider it an interesting usability enhancement, but I don't consider it a bug in the current tooling In summary, I don't think this is a Beta blocker. I do think we can do a better job in the docs of explaining what's expected for JAXB transformers.
It may help if there will be a possibility to set 'unwrap' parameter in BPEL Process as it can be set on SOAP binding. Then it will receive just XML representation of the object, not the method name tag around it.
I don't think any code changes are necessary for this in the 6.2 release provided that the documentation includes the details in "Doc Text" on scenarios where JAXB transformations are problematic. In a future release, it's worth looking at additional validation in the tooling around types used with JAXB transformers.
We're moving to tracking Fuse 6.2.1 issues in JIRA, so I'm closing this issue and have logged https://issues.jboss.org/browse/ENTESB-3610 to more closely track the changes to documentation.
Tom Cunningham <tcunning> updated the status of jira ENTESB-3610 to Closed