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.
Deployment fails when a wsdl document imports an xsd document from reference project. Steps to reproduce 1. Create a synchronous sample project from SOA->samples 2. Create a BPEL project 3. Create an XSD document in BPEL project 4. Import the xsd document created in step -3 into SynchronousSample.wsdl as schema import 5. build and deply. It fails in deployment due to error in generation of URI in catalog file for HTTP binding. catalog file in bpel module is good.
Kirill, it looks like the change you made in BuildServiceAssembly.java on 3/28 (http://hg.netbeans.org/main?cmd=changeset;node=e2218d0e86a4) breaks BC SU generation in CompApp. I am reverting your change in BuildServiceAssembly.java and fixing a duplicate catalog.xml issue (<BCSU>/catalog.xml and <BCSU>/META-INF/catalog.xml) in compapp project build script stylesheet now. Please check to make sure this change is OK with you. Changeset: http://hg.netbeans.org/main?cmd=changeset;node=f75afb0b9a82 With this change, deploy and start of the HTTP SU on HTTP BC works fine. (Note that at this point, there is still an issue when starting the BPEL SU on BPEL SE. See https://open-jbi-components.dev.java.net/issues/show_bug.cgi?id=419 .) Hong, please make sure the cross-project reference use cases are retested with this change.
Hi Jun, thanks for fixing it. Kirill we need to verify the fix and to check in the whole solution into release61 branch.
Jun, the changes I made were done in order to accommodate to the use case with a 'retrieved' catalog (for an example, take a look at driver-tests/bpelse/dynamicpartnerlinks/sendCallBackInfo). In this case, after building the BPEL module's catalog has a <nextCatalog> entry, but the URIs are not corrected as it is read (i.e. the fact that the referenced catalog is located elsewhere is not reflected in the URIs). Just try to build the composite application -- the generated catalog for http binding will be incorrect. (I don't exactly know how to make the retriever create another catalog, however...) I'm not sure what we should do to satisfy both use cases, given that we can only provide a quick patch, not fix the catalog handling stuff completely.. P.S. Reopening to revive the discussion. ;)
Is it really stopper? Is there some workaround here?
Kirill, If by trying to resolve one ticket, you created a regression and caused another issue, then you should go back and examine both issues together. Please let us know which ticket you were trying to fix with the change set e2218d0e86a4? It was not listed with the HG check-in you submitted. These two tickets should be linked. Thanks, -- Tientien Li
Petr, looks like the bug blocks cross project reference feature. So I agree it is a stopper issue. The workaround may exist. mpottlapelli, Will the application be deployed if the XSD file is copied into the synchronous sample project, and be imported from there?
If there is the workaround then the bug isn't release stopper. Why the bug was originally reported as P3?
As I can see this is kind of duplicate of 128701 just another sample used. Am I wrong?
Hi, I checked into this issue a little more.. Looks like the root cause was due to a design change on cross project reference support made by the bpel project. In the original cross-project reference implementation, the project catalog was not used when creating SU. All referenced project files are copied directly over to the referencing project. There was a change made recently by the bpel project that moved cross-project reference files to a different location and use the catalog to map the references. I think the bpel project team needs to test this change and make sure it works with run-time components before checking the change in. The problem we have now is a regression introduced by this change made in the bpel project. -- Tientien Li
Tien, you're right. I made this change a while ago (about two months, IIRC). The old strategy was to plain copy _all_ files from dependent projects to the root project files hierarchy. So it seemed to work more or less automagically for simpler use-cases. However, besides being a plain wrong thing to do, it also caused issue 107908, as the catalog was NOT used @ runtime at all (surprise-surprise).. Then I filed issue 419 against HTTP BC to make it actually start using the catalog, it propagated to BPEL SE and who knows where else (as the runtime was plagued by this all the way through). The last part, of this story, which led to this passionate reiteration, was my attempting to provide a fix for another use-case, that I was not previously aware of. This, apparently caused a regression, which Jun has just reverted. Now I'm back investigating all the possible use-cases and the possible solution which would satisfy all of them. Given enough luck we'll have the solution within this business day.
Okay, I've ruminated a bit about the catalog usage scenarios. I've identified 5 and attached samples to illustrate each: 1) "In-project" catalog usage (Sample1.zip). This is best achieved by creating a new "External WSDL Document", in this case the project catalog will contain entries which help resolving the external URIs to the locally cached files, the cached files are stored within the sources directory of the project. 2) "Simple" cross-project reference (Sample2.zip). This case is reached by establishing a dependency between two projects and importing a resource from the referenced project. The resource does _NOT_ have any imports. 3) "Complex" cross-project reference (Sample3.zip). This is very similar to 2), but the referenced resource contains imports via _relative_ path. 4) Retriever-based catalog usage (Sample4.zip). This is reached when the retriever is used to fetch external resources. They are stored _outside_ the sources directory (nbproject/private/cache/retriever) and the respective catalog is referenced from the project one via nextCatalog entry. 5) "Ubercomplex" cross-project reference (no sample). This is essentially the same as 3), but in order to resolve an import from the referenced resource, we need to use the catalog of respective project. We will not be supporting this use-case for 6.1 or CAPS 6. This will be release-noted and a workaround will be provided.
Created attachment 59907 [details] "In-project" catalog usage
Created attachment 59908 [details] "Simple" cross-project reference
Created attachment 59909 [details] "Complex" cross-project reference
Created attachment 59910 [details] Retriever-based catalog usage
Also note, that use case 3) does not deploy due to HTTP BC's issue 476.
I've committed my changed to trunk, they cover use-cases 1), 2), 3) and 4): http://hg.netbeans.org/main/rev/e42a2f1077b4 They were transplanted to release61 (that includes Jun's fix as well): http://hg.netbeans.org/release61/rev/26300cb24fbb http://hg.netbeans.org/release61/rev/d81e806da643 Please verify, that the issue is indeed resolved.
Looks good.