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



Reply via email to