Jean-Sebastien Delfino [EMAIL PROTECTED] wrote on 09/25/2007 12:24:55
PM:
Florian Rosenberg wrote:
hi raymond,
On Sun, September 23, 2007 2:31 pm, Raymond Feng wrote:
Hi, Florian.
Can you elaborate a bit on why you need the component name during the
read/resolve phase for your implementation.splice? If such
information
is
needed for the runtime behavior, then
org.apache.tuscany.sca.provider.ImplementationProviderFactory.
createImplementationProvider(...)
will pass in the component and implementation objects.
the reason I've asked was my missinterpretation of componentType, I
thought it describes a whole component instance (as Mike said
implementation info is the better name IMHO) no only the
implementation. I
wanted to name the component type file exactly as specified in the name
attribute of the component tag in the composite file. That was
basically
the origin of my question.
I'll go along with the suggestions that Mike provided for now. In the
end
I want to resolve the componentType automatically from the Splice flow
anyway but I want a constistent way to do it for now. I checked some
existing examples in Tuscany and could not figure out a way to name
them
consistently, some componentType names are the same as the composite
file
name, some have the name of the component type. The spec says the name
of
the componentType file and the composite file should match (if I
remember
correctly)/
Thanks,
-Florian
- Original Message -
From: Florian Rosenberg [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Saturday, September 22, 2007 9:23 PM
Subject: retrieve name of component in artifact processor
folks,
I'm writing a component impl type and in my artifact processor I
would
need
the name attribute from a component defined in the composite file to
be
able to use a constistant resolving mechanism for my componentType
files
that describe the component.
Example:
component name=FooComponent
tuscany:implementation.splice
baseDir:=src/test/resources/flowdir/
path=echo url=echo contentType=text/plain /
reference name=... /
/component
Is there a way to get that name (FooComponent) in the read() or
resolve()
method of the StAXArtifactProcessor implementation reading the
implementation.splice attribute? The FooComponent.componentType is
then
used to describe the component, its references, etc.
I could not figure out a way to retrieve it, probably I missed
something.
Thanks,
-Florian
A few thoughts, hoping they'll help the discussion...
As an SCA app developer, I'll need a simple way to point to my component
implementation artifact, because it's what I'm going to reuse in many
components. Having a single or main file for the implementation works
best because people can move it, copy it, edit it by double-clicking on
it.
Once I have clearly identified that implementation file, defining the
.componentType is easy... same path as the implementation artifact with
a .componentType extension.
The .componentType does not describe a component, it describes an
implementation, in other words a class of components.
In the splice case, how about saying:
- The implementation artifact is myFlowdir/echo.splice for example.
- The SCA artifact that describes my implementation (if needed) is
myFlowdir/echo.componentType.
- I'm guessing that echo.splice is an XML file, with a targetNamespace
and name, usually to keep things simple I'll want the XML name to match
the file name:
splice targetNamespace=http://myns; name=echo
.. splice stuff
/splice
- To create a component implemented by myFlowdir/echo.splice I could
write:
(a)
component name=MyEchoComponent
implementation.splice flow=myFlowDir/echo.splice/
/component
currently we go for (a), mainly because of the way the Splice engine works
now. it has its origins in a Web centric environment
(servlet container) thus we are a bit restricted to path names etc.
or (b)
composite ... xmlns:myns=http://myns;
...
component name=MyEchoComponent
implementation.splice flow=myns:echo/
/component
In the rest of SCA assembly we've adopted (b) the more XML oriented
syntax, as pointing to locations tends to be fragile when you move
things around, and also fits well with the SCA contribution packaging
model and the ability to import XML namespaces from other contributions.
we will definitely go for (b) as soon as as the engine supports it. my
tuscany implementation is basically ready for it so I hope to get it done
soon.
thanks,
-Florian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
