I have been following this thread because the fix for https://issues.apache.org/jira/browse/TUSCANY-2408 depends on how this problem is fixed. At the moment, itest/osgi-tuscany is unable to run these two samples since they depend on being run from the samples directory.
On 6/19/08, Raymond Feng <[EMAIL PROTECTED]> 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. I would be very concerned if node APIs used "classpath" to find resources, since "classpath" doesn't have much meaning in an OSGi world. Do we agree? > > 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 >> >> -- Thank you... Regards, Rajini
