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 155784 - support externally updated casa file
Summary: support externally updated casa file
Status: REOPENED
Alias: None
Product: soa
Classification: Unclassified
Component: Composite Application (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jun Qian
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-18 17:58 UTC by Tientien Li
Modified: 2009-04-24 01:09 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
scad project, needs to replace camelHome in profiles.xml (14.77 KB, text/plain)
2008-12-18 21:10 UTC, Tientien Li
Details
casa image showing 1 consume to 2 provides (26.04 KB, text/plain)
2008-12-18 21:14 UTC, Tientien Li
Details
extra connection generated by compapp (22.60 KB, text/plain)
2008-12-19 16:42 UTC, Tientien Li
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tientien Li 2008-12-18 17:58:13 UTC
Currently, the CompApp build process does not support the use case of external modification of casa file. However, 
there are several scenarios that requires such support, e.g.,

1. In a multi-user environment, a compapp project may be changed by different users.
2. In SCAD, the casa file is generated outside of the compapp project.

In order to fix this, the content of casa needs to be loaded earlier in the compapp build process.
Comment 1 Jun Qian 2008-12-18 21:01:35 UTC
Please attach the SCAD project that exposes this problem.
Comment 2 Tientien Li 2008-12-18 21:10:29 UTC
Created attachment 75154 [details]
scad project, needs to replace camelHome in profiles.xml
Comment 3 Tientien Li 2008-12-18 21:14:54 UTC
Created attachment 75155 [details]
casa image showing 1 consume to 2 provides
Comment 4 Jun Qian 2008-12-19 00:12:17 UTC
Fixed in soa-dev: http://hg.netbeans.org/soa-dev/rev/6fd872f378b0
Comment 5 Tientien Li 2008-12-19 16:42:06 UTC
Jun,

Looks like there is another problem with this test case. There is a new connection (from monitorPort to orderPT), not 
in the scad design, but generated by CompApp. This connection created an infinit loop, file -> xslt -> iep -> xslt -> 
file, after the first write. 

--
Tientien Li
Comment 6 Tientien Li 2008-12-19 16:42:50 UTC
Created attachment 75195 [details]
extra connection generated by compapp
Comment 7 Tientien Li 2008-12-19 17:08:40 UTC
To support the scad use case, we can add a command line flag asking compapp to skip the connection generation step and 
to use connections from casa instead. This will ensure that the resulting SA generated by compapp has only scad 
connections.
Comment 8 Tientien Li 2008-12-19 17:26:18 UTC
The flag should probably be set as a compapp project properties so that scad generated compapp projects will not auto-
generate new connections.
Comment 9 Jun Qian 2008-12-19 19:56:59 UTC
Sure.
Comment 10 Jun Qian 2008-12-19 21:37:56 UTC
Fixed in soa-dev: http://hg.netbeans.org/soa-dev/rev/d745b75bb9c3

Introduced a new compapp project property ('com.sun.jbi.routing.bc.autoconnect') to control auto connection generation
involving BC endpoints. This property is set to false for SCAD-generated compapp projects. 
Comment 11 fmartinez1 2009-04-24 01:09:41 UTC
Checked with Developer Jun Qian on this issue. The property added is for supporting SCAD which is currently on hold. 
Not available in GF ESB v2.1. Reopening ticket.