On Thu, Jun 26, 2008 at 11:47 AM, Simon Nash <[EMAIL PROTECTED]> wrote:
> 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 > I think you are correct and I've always found the current mechanism imprecise. Imagine the directory structure. adir/ b.composite cdir/ d.composite edir/ f.composite SCANodeFactory.createNodeWithComposite("b.composite"); contribution = adir composites read = b.composite, d.composite, f.composite composite run = b.composite SCANodeFactory.createNodeWithComposite("cdir/d.composite"); contribution = adir composites read = b.composite, d.composite, f.composite composite run =d.composite SCANodeFactory.createNodeWithComposite("edir/f.composite"); contribution = adir composites read = b.composite, d.composite, f.composite composite run = f.composite There are two pieces of information we need. Contribution location, composite identity. If we are to provide a transformation with extracts the two pieces of information from a single string I propose a different algorithm where a string such as "cdir/d.composite" implies contribution = cdir composites read = d.composite composite run = d.composite I would prefer though that we are explicit and provide two strings. Simon
