Hi,
Let's step back and look at the use case first.
Here is a set of assumptions I have:
1) This is a standalone application and there is a deployable composite file
on the classpath.
2) There is only one contribution which contains the deployable composite
file physically in its packaging hierarchy.
3) The application developer doesn't want to write
META-INF/sca-contribution.xml (so we don't have a well-known index to begin
with).
Then what we want to achieve is that:
1) Have a simple way to discover the composite file and contribution root
from the classpath based on the java resource name of the composite file.
2) Create a node for this embedded image (deployable composite +
contribution) and start it.
The only input is the resource name of the deployable composite.
I guess the key to design this API is to figure out what input can be
reasonably provided by the application developer and that input will be
sufficient to create a node for the "on classpath" image.
Do we agree?
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[EMAIL PROTECTED]>
Sent: Thursday, June 19, 2008 10:25 AM
To: <[email protected]>
Subject: Re: [jira] Created: (TUSCANY-2409) Major consumability issues with
new Node and Domain APIs
On Thu, Jun 19, 2008 at 5:54 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
A few comments:
1) I agree that the following is too complicated and even problematic as
we
hard code the locations based on the file system. In a jar, we don't have
the target/classes.
SCANode2 node =
SCANode2Factory.newInstance().createSCANode("target/classes/myapp.composite",
new SCAContribution("test", "target/classes"));
With the above API, we need to use the classloader to find the correct
URLs
for the composite and contributions to make it working inside a jar.
2) What about this?
SCANode2 node = SCANode2Factory.newInstance().discoverSCANode(String
pathToTheCompositeFile);
or
SCANode2 node = SCANode2Factory.newInstance().findSCANode(String
pathToTheCompositeFile);
3) Should we rename SCANode2/SCANode2Factory back to
SCANode/SCANodeFactory?
Thanks,
Raymond
--------------------------------------------------
From: "Simon Nash (JIRA)" <[email protected]>
Sent: Thursday, June 19, 2008 5:27 AM
To: <[email protected]>
Subject: [jira] Created: (TUSCANY-2409) Major consumability issues with
new
Node and Domain APIs
Major consumability issues with new Node and Domain APIs
--------------------------------------------------------
Key: TUSCANY-2409
URL: https://issues.apache.org/jira/browse/TUSCANY-2409
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.3
Environment: All
Reporter: Simon Nash
Fix For: Java-SCA-1.3
The recent change to remove the previous domain/node implementation has
created severe usabliity issues for the callback-ws-client and
callback-ws-server samples.
1. In callback-ws-client, MyClientImpl, the line
SCANode node =
SCANodeFactory.createNodeWithComposite("myapp.composite");
was changed to
SCANode2 node =
SCANode2Factory.newInstance().createSCANode("target/classes/myapp.composite",
new SCAContribution("test", "target/classes"));
2. In callback-ws-client, CallbackClientTestCase, the line
node =
SCANodeFactory.createNodeWithComposite("callbackws.composite");
was changed to
node =
SCANode2Factory.newInstance().createSCANode("jar:file:../callback-ws-service/target/sample-callback-ws-service.jar!/callbackws.composite",
new SCAContribution("server",
"../callback-ws-service/target/sample-callback-ws-service.jar"));
3. In callback-ws-server, CallbackServer, the line
SCANode node =
SCANodeFactory.createNodeWithComposite("callbackws.composite");
was changed to
SCANode2 node =
SCANode2Factory.newInstance().createSCANode("target/classes/callbackws.composite",
new SCAContribution("test", "target/classes"));
4. In callback-ws-server, CallbackServerTestCase, the line
node =
SCANodeFactory.createNodeWithComposite("callbackws.composite");
was changed to
node =
SCANode2Factory.newInstance().createSCANode("target/classes/callbackws.composite",
new SCAContribution("test", "target/classes"));
The complexity of these APIs, and the need to embed hard-wired paths and
jar names, is unacceptable for a simple sample. This is "must fix" for
the
1.3 release.
It would also be good to convert more samples from the previous
host-embedded APIs to the new domain/node APIs, but this can't happen
until
the consumability problems are fixed.
Ideally we would have a "convenience" API similar to the previous
createNodeWithComposite() API. This API would call the other more
complex
APIs under the covers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Logically I would prefer
SCANode2 node = SCANode2Factory.newInstance().createSCANode(composite
QName,
contribution location );
To remove any doubt about where the composite is coming from.
Simon
