tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Laws" <simonsl...@googlemail.com>
Subject Re: [jira] Created: (TUSCANY-2409) Major consumability issues with new Node and Domain APIs
Date Wed, 02 Jul 2008 13:24:16 GMT
On Thu, Jun 26, 2008 at 11:47 AM, Simon Nash <nash@apache.org> wrote:

> Simon Laws wrote:
>
>> On Sat, Jun 21, 2008 at 9:47 PM, Simon Nash <nash@apache.org> 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" <simonslaws@googlemail.com>
>>>> Sent: Thursday, June 19, 2008 10:25 AM
>>>> To: <dev@tuscany.apache.org>
>>>> 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 <enjoyjava@gmail.com>
>>>>
>>>>> 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)" <dev@tuscany.apache.org>
>>>>>> Sent: Thursday, June 19, 2008 5:27 AM
>>>>>> To: <dev@tuscany.apache.org>
>>>>>> 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

Mime
View raw message