It looks like a reasonable proposal. I'll try to implement the changes and
hopefully we can make into 1.3 release.
Thanks,
Raymond
--------------------------------------------------
From: "Jean-Sebastien Delfino (JIRA)" <[email protected]>
Sent: Monday, July 07, 2008 3:50 PM
To: <[email protected]>
Subject: [jira] Commented: (TUSCANY-2409) Major consumability issues with
new Node and Domain APIs
[
https://issues.apache.org/jira/browse/TUSCANY-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611385#action_12611385 ]
Jean-Sebastien Delfino commented on TUSCANY-2409:
-------------------------------------------------
Here's what I think we should do:
1. Emphasize that in general authors of an SCA application should not /
should not have to write a main method(). Bootstrapping a node in code in
your main method should be reserved to advanced scenarios.
2. Explain that people who want to bootstrap a node themselves should in
general favor:
SCANode2Factory.createSCANode(String compositeURI, SCAContribution...
contributions) but not hardcode these paths in their code and externalize
them. BTW that's what they do when they externalize their classpath
definition and run java -cp <paths to their JARs>.
2. Make SCANode2Factory.SCAContribution a top level SCAContribution class
3. Add a method createSCANodeFromClassLoader(String compositeURI,
myClassLoader). That method should search for compositeURI using
myClassLoader.getResource(compositeURI), and determine the root of the SCA
contribution to use from that (same algorithm as the current
SCADomain.newInstance()). We should make it really really clear that SCA
contributions should not be confused with a Java classpath and that this
method is only there for convenience in limited use cases (one
contribution containing everything, put on the classpath, which is really
not the best practice with SCA).
4. Change createSCANode(String configurationURI) to
createSCANodeFromURL(String configurationURL)
5. Have createSCANode(String compositeURI, SCAContribution...
contributions) do the equivalent of
createSCANodeFromClassLoader(compositeURI,
Thread.currentThread().getContextClassLoader()) when no contributions are
passed in, also equivalent to the current
SCADomain.newInstance(compositeURI). Again we should document that this is
just a shortcut allowing a not so good SCA contribution development
practice.
At some point I thought about another approach:
- add an SCAContribution.createSCAContributionFromClassLoader(ClassLoader
cl)
- or add an SCAContribution(ClassLoader cl) constructor
allowing app developers to do:
factory.createSCANode("my composite", new SCAContribution(myClassLoader))
but that would have been confusing... as a ClassLoader alone is not
sufficient to find the root of a Contribution (we need another piece of
information like the path of a composite file available in the ClassLoader
for example to really find that root) so new
SCAContribution(myClassLoader) would not create a properly initialized
object (for example, we wouldn't know what to return from
SCAContribution.getLocation()).
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.
