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.

Bug 137889 - Service Unit (SU) created is invalid when BPEL project references another project at random location
Summary: Service Unit (SU) created is invalid when BPEL project references another pr...
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Kirill Sorokin
Depends on:
Reported: 2008-06-21 19:36 UTC by Murali Pottlapelli
Modified: 2009-12-09 03:05 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

project for reproducing the issue (34.32 KB, application/octet-stream)
2008-06-21 19:38 UTC, Murali Pottlapelli

Note You need to log in before you can comment on or make changes to this bug.
Description Murali Pottlapelli 2008-06-21 19:36:51 UTC
Service Unit  (SU) created is invalid when BPEL project references another project at random location.It is due to
invalid import URL(s) for the documents imported from the referenced project.

Here are the steps to reproduce the issue 
1. Create SynchronousSample at NetBeansProjects\catalog\oneFolderDeep
2. Create a BPEL project at NetBeansProjects\catalog\refrence, create a WSDL and XSD document
3. Reference WSDL and XSDs generated in the step-2 in the synchronous sample.
4. build the project and deploy it, it fails at the deployment.

On investigation it found the imported URLs are not consistent with the documents packaged by catalog.

Project for reproducing this is attached. Attached project also identifies validation issue with when FLOW activity is
first activity in the business process
Comment 1 Murali Pottlapelli 2008-06-21 19:38:13 UTC
Created attachment 63204 [details]
project for reproducing the issue
Comment 2 Murali Pottlapelli 2008-06-21 19:44:12 UTC
Attached project also identifies validation issue with BPEL project when FLOW activity is
first activity in the business process
Comment 3 Kirill Sorokin 2008-08-07 13:43:07 UTC
From what I can tell (at least after having applied fix for issue 133755), the design time correctly generates the
artifacts. All the required stuff is in the xml catalog. 

However, I was not able to deploy either. The HTTP binding refused to read the catalog and used the systemIds directly
as relative paths. I believe this question had been raised a number of times already. A bug was filed against HTTP BC
and it was marked as fixed. Do we have a regression on the runtime side?

This issue should be marked as INVALID, as the design time behaves properly. Please reopen if you disagree.
Comment 4 ggenipudi 2008-10-15 05:00:38 UTC
tested using Build 200810130101 and got following error while trying to deploy.

ERROR: Successful execution of Start: SynchronousSampleApplication
WARNING: (JBIMA0405) Start of service assembly SynchronousSampleApplication succeeded partially; some service units
failed to start.
    * Component: sun-bpel-engine
      ERROR: (BPJBI-4001:BPELSE) BPJBI-7004:Service unit SynchronousSampleApplication-SynchronousSample failed to load
: BPJBI-6024:Error while loading BPEL file
Exception details are Cannot parse BPEL (see below):
==> Cannot load imported document  (see below):
==> Unable to import wsdl document for import  (see below):
==> Failed to resolve publicId and systemId ../../../../refrence/BpelModule/src/po.wsdl
to a WSDLDocument. (see below):
==> C:\GlassFishESB\glassfish\domains\domain1\jbi\refrence\BpelModule\src\po.wsdl (The system cannot find the path
    * Component: sun-http-binding
      INFO: (JBIMA0409) Lifecycle operation start succeeded for Service Unit SynchronousSampleApplication-sun-http-binding.
Cleaning up...
    Stopping a service assembly...
    Shutting down a service assembly...
    Undeploying a service assembly...
C:\bpprojects\oneFolderDeep\SynchronousSample\SynchronousSampleApplication\nbproject\build-impl.xml:213: Start failure.
BUILD FAILED (total time: 5 seconds)
Comment 5 Kirill Sorokin 2008-10-15 11:48:55 UTC
Ah, OK. The real issue lies in the fact that SynchronousSample project declares a reference on BPELModule1 project, but
the actual import does not use it, importing by a relative URL directly. The latter is not supported unless the
referenced file resides within the sources directory structure of the same project.

After having changed '../../../../refrence/BpelModule/src/po.wsdl' to 'BpelModule/po.wsdl' (which resolves to a project
reference) I've been able to correctly deploy the project. This issue is indeed invalid.
Comment 6 terrybraun 2009-12-07 16:28:33 UTC
Closed as invalid.
Comment 7 senthilprabhu 2009-12-09 01:07:15 UTC
I tried this issue with the GFESB build 20091206-0720. It is still not deploying.

1) When I drag and drop the WSDL from the BPEL Project into the Synchronous Sample Bpel, it automatically adds the project reference. See location attribute in the import statement below. It works for WSDL file

    <import namespace="" location="BpelModule1/newWSDL.wsdl" importType=""/>

2) When I create a BPEL variable and the variable type is an element belonging to XSD from the BPEL project, it DOES NOT add the project reference. See the location attribute in the import statement below.

    <import namespace="" location="../../../../reference/BpelModule1/src/newXmlSchema.xsd" importType=""/>

Because of this, the project is not getting deployed.

So I'm reopening the issue.
Comment 8 senthilprabhu 2009-12-09 01:13:44 UTC
When I manually add the schema to the Synchronous Sample project through Referenced Resources --> Add Local...  and then change the import statement below, the project gets deployed SUCCESSFULLY

    <import namespace="" location="BpelModule1/newXmlSchema.xsd" importType=""/>
Comment 9 Kirill Sorokin 2009-12-09 01:35:22 UTC
So the issue is also (mostly) in the way an import is created when this operation is invoked implicitly upon the creation of a new variable. That is an issue indeed.
Comment 10 Kirill Sorokin 2009-12-09 03:05:06 UTC
Fixing this issue directly and quite error-prone at this stage. Thus We've decided to lower the priority of this issue, replacing it (somewhat) by two enhancements which are more likely to get fixed within GFESB 2.2 timeframe: issue 178340 and issue 178349.