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.
This for found in the latest soa-dev builds based on NB6.1 patch 4. There is a regression introduced in file bc wsdl extension and its run-time. Old use cases that were working few weeks ago are failing with the latest file bc run-time. Please use the following steps to reproduce this problem: - create a SOA Synchrous sample project. - edit SynchrousApplication compapp in CASA - remove bpel process - add a file binding - connect soap input to file output - save and deploy this project. This example works before, but the latest file bc run-time generates a deployment exception: ERROR: Successful execution of Start: SynchronousApplication WARNING: (JBIMA0405) Start of service assembly SynchronousApplication succeeded partially; some service units failed to start. * Component: sun-file-binding ERROR: (FBC_INIT_1) FILEBC-E00202: Service unit SynchronousApplication-sun-file-binding failed to initialize, an exception was raised. FILEBC-E00308: Service unit SynchronousApplication-sun-file-binding initialization failed, an exception was raised. FILEBC-E00808: Provider (outbound) Endpoint: '{'SynchronousApplication}casaService1:casaPort1, has a request-response operation: operation1, but the verb attribute of the <file:operation> is either not defined or has a value other than "read". * Component: sun-http-binding INFO: (JBIMA0409) Lifecycle operation start succeeded for Service Unit SynchronousApplication-sun-http-binding. Cleaning up...
Created attachment 72726 [details] bc2bc project (test case)
Observations: It looks like as long as the consume endpoint of a file binding is connected, then the compapp project deployes OK. Not sure if unconnected consume endpoint of a file binding ever worked before. Or maybe there is some changes in the file BC component itself recently?
I think the problem here is that the file binding wsdl extension added several sub templates that does not work with the existing wsdl binding generator and validation framework. If these templates are implemented correctly, the invalidate file binding configuration should be rejected at the design time.
Jun, after our discussion with Kini, it seems that an additional logic needs to be added to check if there is an interface defined by the ports being linked together?
Fix logic on whether a BC endpoint is configurable or not: http://hg.netbeans.org/soa-dev/rev/e53df5d854d6
Configuration dialog shows up now with the logic fix. The exception below will still fail because the model passed in is of Inbound/Outbound type which is not correct. So currently we ask the user if this should be configured as a Synchronous Read but the 'verb' attribute is not being set to reflect this. Added code to set the 'verb' to 'read' if user chooses to do so: changeset: 86907:c1eb90fa6463 user: jonelle@netbeans.org date: Thu Oct 30 17:11:52 2008 -0700 summary: IZ#151532 reset the verb attribute to 'read' if user is prompted for it changeset: 86945:df467b4b32e2 tag: tip parent: 86944:690ebc937671 parent: 86907:c1eb90fa6463 user: jonelle@netbeans.org date: Thu Oct 30 17:13:35 2008 -0700 summary: Automated merge with http://hg.netbeans.org/soa-dev
Fixes checked into soa-dev. Requested QE to help test before posting fixes to soarelease.
tested this in the dev build and it worked OK, please integrate this into release.
Ported over fixes to soarelease: changeset: 160:ab22643e303c user: jonelle@netbeans.org date: Tue Nov 04 11:35:16 2008 -0800 summary: IZ#151532 reset the verb attribute to 'read' if user is prompted for it changeset: 200:45369fd58ca7 tag: tip parent: 199:c4e220fbd685 parent: 160:ab22643e303c user: jonelle@netbeans.org date: Tue Nov 04 11:36:36 2008 -0800 summary: Automated merge with http://hg.netbeans.org/soarelease Stephen Schmandt wrote: > > since i have tested, if there is no actual lock, pls > assume you have julio's approval and integrate it. > > i thought there was an actual lock, but i > know kini was able to integrate his fix, so maybe it's > just a verbal ok required..... > > thx, > Steve
Fix in soa-dev e53df5d854d6 transplanted into soarelease as f689d43a8f91.
this was verified in 1109 build. (note: earlier release builds had build issues and were not picking up 1103 jbi components hence did not include this fix & could not verify until after 1107).