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.
Build: Hula milestone build 8a. Steps to reproduce it: 1. Download and unzip the attached samples.zip. 2. Open EJB project LoanProcessor and BPEL project LoanRequestor. 3. Create a new Composite App CompositeApp1. 4. Add JBI Modules: LoanProcessor and LoanRequestor. 5. Deploy CompositeApp1. In the Output window [build.xml(run)] tab, Will see "BUILD SUCCESSFUL" message. BUT: ==== 1. In the Runtime tab, expand Sun Java System Application Server 9 -> Applications -> EJB Modules, will see LoanProcessor is not deployed. 2. Expand JBI -> Service Assemblies -> CompositeApp1, the status of both"CompositeApp1-LoanProcessor" and "CompositeApp1-sun-http-binding" are "Shutdown". (See attached screen shot) 3. A couple of Exceptions are found in messages.log and server.log file (attached). Note: Everything works fine if: 1. Delete LoanProcessor.jar Java EE Module from CompositeApp1 -> JBI Modules. 2. Deploy project LoanProcessor. 3. Deploy CompositeApp1.
Created attachment 40644 [details] Sample Apps
Created attachment 40645 [details] Screen shot
Created attachment 40646 [details] server.log (partially)
Created attachment 40647 [details] messages.log
Based on the log and Screen shot. There is port conflict, both EJB and Http Soap BC are trying to use the same port 8080. Build used (milestone build 8a) has code generating both Consumer and Provider for the BC's. I think this change was reverted back later in the daily builds, so that BC's will not provision when there is already a provider. In this case EJB WS. Please check with latest daily build.
This issue is still reproduced in the latest Hula build 200704101900.
Hong, There is port conflict, WSDL in BPEL project for calling EJB has HTTP binding with same port address as one used by Glassfish. You could do one of the below, 1. Change the port in BPEL LoanRequestor\src\Partners\LoanProcessor\LoanProcessor.wsdl to other than 8080 Ex: http://localhost:18080/LoanProcessorService/LoanProcessor 2. Or change the address to <soap:address location="REPLACE_WITH_ACTUAL_URL"></soap:address>
Although I can fix it manually, but this is a bug. IDE should handle this port conflict issue, Right?
I am not sure it is bug. You are expecting Http BC not to consume the end-point even WSDL is present with Http Soap binding? Http Soap BC calling EJB WS is a one of the valid Use-case we need to support.
Then why if I deploy the EJB Module separately, it work fine?
Since this is code generated by the IDE, why would we expect the user to do manual workarounds to fix something that should be generated CORRECTLY by the IDE from the start? After all, this is why people use the tools - No?
Hong, When Http-Soap BC is a provider, it will not listen on the port specified in the Http-Soap address. That is the case when you do not include Java EE project in the comp app. awegscheider, Ofcourse it would be nice if tools know what is the intent of the User. Code generated by BPEL WSDL import wizard is valid if EJB project is not part of comp app and you want to go thru the HTTP-SOAP BC. If desired, we should ask for BPEL WSDL import wizard to prompt the user, whether WSDL generated should include concrete part or not.
Hong, From CompApp/CASA point of view, the JavaEE SE is not yet supported. We are working with the JavaEE SE team, but there are a few pending issues that will be resolved and implemented post J1. -- Tientien Li
Ok, since this feature is not supported yet, I am change the type to ENHENCEMENT.
With existing design, I think user needs warning in JBI component project (Ex. BPEL) while importing the WSDL that if the same Java EE project is part of Composite app there may be port conflict. Since this issue of port conflict will remain even after Java EE Svc engine changes their port name.
Accidentally changed the Issue type, reverting it back to "Enhancement".