[
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.
