This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I know that it is the BPEL runtime's problem but there is not a runtime category. 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: http://bookshelf.sfbay.sun.com/jets/JavaStudio/Coke/postbeta/loanprocessing4.htm 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 tutorial. Here is the short description: -- create a new Enterprise/EJB Module which will be called by the BPEL as a partner. -- create a new WEB Service there -- add a new operation to the web service with a parameter(s) of the double type. -- 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 application server. -- 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 CatchAll.
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 6478384
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 http://nbstaging.czech/community/releases/55/entpack_relnotes.html#86499
Girish, 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 "com.sun.enterprise.jbi.se.autoendpointenabling=true".
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.
Removed EP551_WAIVER_APPROVED