I know that it is the BPEL runtime's problem but there is not a runtime
There is a way to hang a BPEL process. without any error notifications.
Steps to reproduce:
It requires quite complicated preparations but they are described with full
details in the Loan Application tutorial here:
The URL can be not final so it can becumes invalid.
But Sherry (Sherry.Barkodar@Sun.COM) can be asked for an actual location of the
Here is the short description:
-- create a new Enterprise/EJB Module which will be called by the BPEL as a
-- create a new WEB Service there
-- add a new operation to the web service with a parameter(s) of the double
-- compile and deploy the EJB Module to the Java Application Server.
-- create a new BPEL project which will call the EJB Web Service.
-- Drag&Drop the WEB service node (EJB module project) from the Project view to
the BPEL and then press Ok in the Partner Link dialog. The new WSDL is added to
the BPEL project here: Partners/EJB Module Name/WEB Service name.wsdl
-- Add Invoke and tune it to call the operation from the EJB Web service.
-- Then it's necessary to create in the BPEL all other elements like receive
and reply so it can be initiated.
-- Create a new composite application, add the BPEL module there, add a test
case which will call the BPEL and finally deploy the comp app project to the
-- Now you can try to run test case. It will call the BPEL process and the
process will call the EJB Web service. It should work here.
-- Modify the signature of the EJB Web service operation by changing the type
of parameter from double to float and redeploy the EJB project.
-- Run test case of the composite application again.
The BPEL process hangs when it run the Invoke which call the EJB web service
operation. The test case is failed only after the timeout.
The BPEL process should be terminated with a fault here instead of hang.
The application server's console contains some error messages (see attachment)
but they seems not informative enough.
Also it worth to check how the BPEL process will behave in other conditions,
for example, if the EJB WEB service operaton's name is changed or if the
operation throws an exception.
Created attachment 34872 [details]
A fragment of the App Server console output (for the LoanApplication example)
I just tried to add a Fault Handler with the CatchAll element.
I supposed that the execution of the process could be continued there after an
exception. But it didn't managed to stop with the debuger inside of the
I suppose that it is not so difficult to reprodice the same defect with the
Travel Reservation Example because of it also used the EJB web services.
Runtime issue. Created an issue in bugster
CR 6478384. Please close this.
See comments above.
Reopening, so we can track this on the dashboard. This will be fixed with
This is a negative test case. The correct behaviour is to propogate the error
to the user. This will be fixed in the next release as we are running out of
time. The fix is in JavaEE service engine and BPEL Service engine.
In this scenario, the user changed one of the partner's interface. For the
comp app to work now, the user should make the change in the bpel process
(i.e. use the new wsdl).
Given that typically users in the field will make corresponding changes when
interfaces are changed inorder to get the composite applications to work, we
can reduce the priority of this bug for this release.
This bug needs to be documented.
The real bug here is that the error handling and notification in the runtime is
insufficient or broken. The engine should receive a fault when invoking a
service endpoint incorrectly, which should then be propagated to the test client.
I agree with Venkat, at least for the design-time; this is not a high-priority
use case in this release--the user must perform manual refactoring as they would
if any external Web service changed its interface. In a future release, we will
have refactoring between Java EE services and clients so that this problem is
avoided for developers working on both ends of the invocation. However, the real
fix should be in the BPEL runtime.
Also, are there any tell tale error messages in AS log file that can identify
this condition when it occurs?
In order for documentation to proceed, runtime team please indicate what
corrective action, if any, is required on the runtime side.
Assuming user re-imports modified WSDL into BPEL project.
Assume user redeploys project.
Is that sufficient?
Or does user have to restart the BPEL SE? Stop/Shutdown/Restart? What?
Added to RNs.
Use the following link to review the wording and location of the issue in the
staged Release Notes
please analyse this scenario with the current builds
Runtime issue is still present in the latest build.
GF 9.1 B36.
BPEL nighltly build 02/16/2007.
Below information is not relevant to Netbeans tooling support.
This happens with JAX-RPC/J2EE 1.4 EJB project and calls going thru Java EE Svc
Engine. JAX-WS/Java EE 5 EJB project is able to handle data type change from
double to float with out any exception.
Thru debugger and logs, one can see both engines are throwing exception, but
SOAP fault is not sent back to client from BPEL.
There seems to be issue with sending fault message from Java EE Svc engine to
BPEL though ME status is set to "error" .
There is CR 6478384 assigned to Java EE Svc Eng team.
In the latest GF build auto endpoint activation in Java EE Svc Engine is
disabled. To enable, start GF with system proerty
Closing the issue it is not a bug in Netbeans. It is a bug in runtime
exception/fault handling between BPEL and Java EE Svc Engine. There is an issue
already for this CR 6478384.
If any, refactoring or change propagation between Java EE and BPEL projects in
Netbeans should be new feature request.