Simon Laws wrote:
On Sat, Jun 21, 2008 at 9:47 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
Raymond Feng wrote:
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?
Yes, this is what we had before with createNodeWithComposite(), and
it's also what host-embedded provides with SCADomain.newInstance().
For simple tests and samples, we need something as simple as this.
I'm willing to try to port the previous code from createNodeWithComposite()
over to the new Node2 world. This will also have the benefit of helping
me understand more about how the new Node2 APIs work.
Simon
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
Hi Simon
Could you say a little more about what you think the semantics of the
contribution location process should be with an interface such as
SCANode node =
SCANodeFactory.createNodeWithComposite("callbackws.composite");
Simon
I believe the current code looks on the classpath for the specified
composite file and computes the containing contribution location
based on that. It's smart enough to deal with jar files as well
as regular directories containing classes.
Simon
