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

Reply via email to