Raymond,
These are all good issues and they all need fixing.
I've raised JIRAs for them, grouped logically, I hope, in a way that means that they can be tackled
independently one-by-one. The JIRA numbers are inline below.
HOWEVER, these items are nowhere near the top of my list for work on the BPEL code right now. I am
focussed on getting the Assembly TestSuite to work 100% using BPEL implementations. The major work
on implementation-bpel code to support that is:
a) add support for References with multiplicities 0..n and 1..n
b) add support for Properties with Complex types
Longer term but (much) higher cost:
c) Upgrade the ODE Compiler and Runtime to support the SCA extensions directly, which will enable
the Tuscany code to avoid the dynamic update of the source BPEL process before it is compiled. This
is a major piece of work that will require the use of ODE 2.x. I want the test suite complete and
running before we go there.
Yours, Mike.
Raymond Feng wrote:
Hi,
I run into a lot of issues related to the location of the BPEL process
when the .bpel file is contained in a JAR file (or an OSGi bundle).
The current code only handles the artifacts on the file system:
* It doesn't handle the URLs that are not appropriately escaped (such as
file:/C:/My Folder/a.bpel).
TUSCANY-3158
* It makes the assumption that the BPEL file is on the file system (in
my case, it's packaged in a jar file)
TUSCANY-3159
* It uses the containing directory of the BPEL file as the working
directoy to create deploy.xml, save the modified bpel file and compile
the bpel files. This can be quite invasive as the directory can be in
the cache of the OSGi bundle data or the maven repo.
TUSCANY=3160
* It uses a classloader to search for JPADB with the assumption that the
database is a unzipped folder.
I suggest that we improve the story as follows:
1) select a working directory from the java.io.tmpdir [1]
2) copy the content of the bpel file into the working directory
3) copy the jpadb from the tuscany-implementation-ode.jar into the
working directoy too
This I think is incorrect. There should be 1 database for a single installation of Tuscany - this
idea would lead to many copies. Ideally, when Tuscany is installed, the database should be placed
in a well known location alongside the implementation-bpel-runtime code. The user should be able to
override this location with a pointer to another location, specified as a property. We should
also in principle think about allowing Databases other than Derby to be used, if specified by the user.
TUSCANY-3161 raised to cover the problem with the database.
4) create deploy.xml
5) update the bpel file if necessary
6) compile the bpel files under the working directory and collect the
.cbp files
[1]
http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#createTempFile(java.lang.String,
java.lang.String, java.io.File)
Thanks,
Raymond
---
Raymond Feng
Apache Tuscany PMC Member: http://tuscany.apache.org
Co-author of Tuscany In Action: http://www.manning.com/laws
