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.
When you click on a binding in CASA, the properties editor allows you to disable the consumer and/or provider endpoint by checking the "disableInBC" option. This doesn't seem to work properly right now, as I noticed that instead of removing the corresponding <consumes> or <provides> entry in the service unit jbi.xml, it currently adds the following subelement in the entry: <codegen xmlns="http://www.sun.com/jbi/descriptor/config-endpoint" disableInBC="true"/> There is no "contract" in BCs right now to parse this element and/or disable the endpoint accordingly...
Steps to reproduce: 1. Create SynchronousSample 2. Build SynchronousSampleApplication 3. Open CASA Editor 4. DnD a new SOAP binding from palette 5. Connect the new SOAP port's consume endpoint to the old SOAP port's provide endpoint. This will give the new SOAP port an address on the local host. 6. Delete the connection and keep the new SOAP port around. 7. Deploy SynchronousSampleApplication. The deployment should succeed. 8. Configure the new SOAP port's address to something other than the local host, for example, http://www.google.com 9. Deploy SynchronousSampleApplication. The deployment should fail by design. 10. Select the new SOAP port's consume endpoint, check the "disableInBC" checkbox in the property sheet 11. Deploy SynchronousSampleApplication. The deployment still fails. :-( The expectation is step 11 should succeed.
Fixed in trunk: http://hg.netbeans.org/main?cmd=changeset;node=7f3711ab050e This one should be considered as a candidate for 6.1 patch.
Integrated into 'main-golden', available in NB_Trunk_Production #251 build Changeset: http://hg.netbeans.org/main/rev/7f3711ab050e User: Jun Qian <jqian@netbeans.org> Log: #136868 Do not pass "disableInBC" endpoint extension to runtime. Endpoints with disableInBC=true should be removed from BC SU's jbi.xml.
Testing with NB trunk build Product Version: NetBeans IDE Dev (Build 200806111204) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05 System: SunOS version 5.10 running on x86; ISO646-US; en (nb) Userdir: /Users/lautz/.netbeans/dev When I perform Step 7, CASA/compapp automatically generates a connection between the new SOAP binding and the BPEL SU. I was not expecting that.
Your observed behavior is not a bug. It is by design. Here is why. The interface assigned to the new SOAP port in step 5 matches the interface of the BPEL SU endpoint. Therefore, the compapp build process automatically generates the connection, fulfilling its duty. If the user doesn't want this auto-generated connection, she can simply delete the connection and it will never come back again. However, a variant of the steps could possibly be viewed as a bug. I have filed http://www.netbeans.org/issues/show_bug.cgi?id=137135 To verify the original ticket, two additional steps should be added between #6 and #7: 6.8 Build SynchronousSampleApplication 6.9 Delete the new connection between the new SOAP port and BPEL SU
Verified with Product Version: NetBeans IDE Dev (Build 200806111204) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05 System: SunOS version 5.10 running on x86; ISO646-US; en (nb) Userdir: /Users/lautz/.netbeans/dev The specified scenario now succeeds.
The fix has been ported into the release61_fixes repository. http://hg.netbeans.org/release61_fixes/rev/bd325c75c27f