You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2007/06/17 13:14:39 UTC
Finding the .componentType file
I'm struggling with how to define and locate the .componentType side file in
the implementation SPI. The assembly spec says:
"A component type file has the same name as the implementation file but has
the extension ".componentType"...The location of the component type file
depends on the type of the component implementation..." (page 13 line 445).
The problem is "the implementation file" is not specific enough and there
isn't a standard way for the runtime to know which implementation attribute
is the "implementation file". Eg, for implementation.java its the 'class'
attribute, for implentation.script its the 'script' attribute, for
implementation.das its the 'config' attribute etc.
Any one have any ideas on how to do this? Would it be be terribly
non-compliant if the default used by the runtime was "A component type file
has the same name as the _component_ with the extension ".componentType"?
...ant
Re: Finding the .componentType file
Posted by ant elder <an...@apache.org>.
On 6/17/07, Venkata Krishnan <fo...@gmail.com> wrote:
<snip>
I'd say that we leave the componentType resolution to the implementation
> types upto to locating and loading the resource as input stream after
> which
> the artifact processing can be done generically.
But how exactly to do this? What would the interfaces or methods be to make
this happen?
...ant
Re: Finding the .componentType file
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Yes, I'd feel that it could end up being non-compliant and we might lose a
bit on portability as well. Since an implementation could be reused across
a bunch of components, having the componentType go after the component may
not work.
I'd say that we leave the componentType resolution to the implementation
types upto to locating and loading the resource as input stream after which
the artifact processing can be done generically.
- Venkat
On 6/17/07, ant elder <an...@gmail.com> wrote:
>
> I'm struggling with how to define and locate the .componentType side file
> in
> the implementation SPI. The assembly spec says:
>
> "A component type file has the same name as the implementation file but
> has
> the extension ".componentType"...The location of the component type file
> depends on the type of the component implementation..." (page 13 line
> 445).
>
> The problem is "the implementation file" is not specific enough and there
> isn't a standard way for the runtime to know which implementation
> attribute
> is the "implementation file". Eg, for implementation.java its the 'class'
> attribute, for implentation.script its the 'script' attribute, for
> implementation.das its the 'config' attribute etc.
>
> Any one have any ideas on how to do this? Would it be be terribly
> non-compliant if the default used by the runtime was "A component type
> file
> has the same name as the _component_ with the extension ".componentType"?
>
> ...ant
>
Re: Finding the .componentType file
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 6/17/07, Mike Edwards <mi...@gmail.com> wrote:
>
> <snip>
>
> The component name may be nothing like the implementation name
>
>
> How does that fit with the spec saying - ""A component type file has the
> same name as the implementation file but has the extension
> ".componentType""
> ? I'm looking for a way to make the default case easy, it doesn't have to
> deal with every edge case.
Here's an example:
component name: CalculatorServiceComponent
implementation class: calculator.CalculatorImpl
implementation file: src/main/java/calculator/CalculatorImpl.java
componentType file:
src/main/resources/calculator/CalculatorImpl.componentType
another one:
component name: CalculatorServiceComponent
implementation class: calculator.CalculatorImpl$AnotherImpl
implementation file: calculator.CalculatorImpl.java
componentType file suggestion:
src/main/resources/calculator/CalculatorImpl.AnotherImpl.componentType
a third one with two components:
component 1 name: CalculatorServiceComponent
component 2 name: AnotherCalculatorComponent
implementation class: calculator.CalculatorImpl
implementation file: src/main/java/calculator/CalculatorImpl.java
componentType file:
src/main/resources/calculator/CalculatorImpl.componentType
This shows that:
- the component type file path cannot always be automatically derived
from the implementation file without implementation specific logic
- the component type file path cannot be derived from the component
name at all
>
> The componentType file is really to be thought of as an extension of the
>> implementation for those (hopefully few) cases where introspection of
>> the implementation cannot provide the required information.
>
>
> Maybe "implementationType" would have been be a better name :-)
Here's my understanding of the relationships between component,
component type, implementation and implementation type:
- componentType describes a type of component
- implementation is a concrete representation of a component type
- a componentType describes an implementation
- a component is an instance of a component type
- implementation type characterizes a type of implementation, a
programming language or technology, "java", "bpel", "script" for example.
>
> My suggestion is that the SPI should put the burden on the
>> implementation module - for example a special method on the
>> xxxImplementation class with a name like "locateComponentTypeFile".
>> Actual loading of the componenttype file can be generic, but finding the
>> file is definitely a job for the implementation-handling code.
>
Implementation.getURI() already exists and seems the right method for this.
>
> The problem with this is some don't want the simple xxxImplementation
> class
> to even be implementing any interface
Making more difficult to replace these classes by others.
> so ideally as much generic function
> would be built in the runtime, and thats what I'm trying to find a way of
> doing.
>
> I was wondering if the contribution service could help here. It could
> discover all the .componentType files in a contribution making their
> names
> available,
Doesn't it do it already?
> the values of all the attributes of the xxxImplementation class
> are also known so it could compare all the attribute values against
> all the
> found .componentType file names ignoring the file extension and when
> there's
> a match thats the .componentType for the implementation. How does that
> sound?
>
> ...ant
>
It sounds unpredictable :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Finding the .componentType file
Posted by ant elder <an...@gmail.com>.
On 6/18/07, ant elder <an...@apache.org> wrote:
>
>
>
> On 6/18/07, Venkata Krishnan <fo...@gmail.com> wrote:
> >
> > On 6/18/07, ant elder <antelder@apache.org > wrote:
> >
> > > On 6/17/07, Mike Edwards <mi...@gmail.com> wrote:
> > >
> > > <snip>
> > >
> > > The component name may be nothing like the implementation name
> > >
> > >
> > > How does that fit with the spec saying - ""A component type file has
> > > the
> > > same name as the implementation file but has the extension
> > > ".componentType""
> > > ? I'm looking for a way to make the default case easy, it doesn't have
> > > to
> > > deal with every edge case.
> > >
> > > The componentType file is really to be thought of as an extension of
> > > the
> > > > implementation for those (hopefully few) cases where introspection
> > > of
> > > > the implementation cannot provide the required information.
> > >
> > >
> > > Maybe "implementationType" would have been be a better name :-)
> > >
> > > My suggestion is that the SPI should put the burden on the
> > > > implementation module - for example a special method on the
> > > > xxxImplementation class with a name like "locateComponentTypeFile".
> > > > Actual loading of the componenttype file can be generic, but finding
> > > the
> > > > file is definitely a job for the implementation-handling code.
> > >
> > >
> > > The problem with this is some don't want the simple xxxImplementation
> > > class
> > > to even be implementing any interface so ideally as much generic
> > > function
> > > would be built in the runtime, and thats what I'm trying to find a way
> > > of
> > > doing.
> > >
> > > I was wondering if the contribution service could help here. It could
> > > discover all the .componentType files in a contribution making their
> > > names
> > > available, the values of all the attributes of the xxxImplementation
> > > class
> > > are also known so it could compare all the attribute values against
> > > all the
> > > found .componentType file names ignoring the file extension and when
> > > there's
> > > a match thats the .componentType for the implementation. How does that
> > >
> > > sound?
> >
> >
> > That could be quite a gamble in my opinion. There is a possibility that
> > some attribute value of an implementation type instance could end up
> > matching a componentType that corresponds to some other implementation.
> >
>
> Its xxx/yyy.componentType matching xxx/yyy.zzz, so "xxx/yyy." matching
> some other attribute value would be pretty rare wouldn't it? So for that
> rare case it could just throw some exception if the implementation type impl
> tries to use the default discovery mechanism.
>
I've committed a strawman impl that works as described above (the code is
rough, its just the design I'm trying to get pinned down for now). I'm
completely open to alternative ways of doing this, either code contributions
or just rough idea suggestions and I'll code it up. But all the tests are
passing like this now (and specifically the script testcases using
references which require the .componentType side file) so hopefully that can
help focus concrete suggestion which keep all the existing functionality
working.
...ant
Re: Finding the .componentType file
Posted by ant elder <an...@apache.org>.
On 6/18/07, Venkata Krishnan <fo...@gmail.com> wrote:
>
> On 6/18/07, ant elder <an...@apache.org> wrote:
>
> > On 6/17/07, Mike Edwards <mi...@gmail.com> wrote:
> >
> > <snip>
> >
> > The component name may be nothing like the implementation name
> >
> >
> > How does that fit with the spec saying - ""A component type file has the
> > same name as the implementation file but has the extension
> > ".componentType""
> > ? I'm looking for a way to make the default case easy, it doesn't have
> > to
> > deal with every edge case.
> >
> > The componentType file is really to be thought of as an extension of the
> > > implementation for those (hopefully few) cases where introspection of
> > > the implementation cannot provide the required information.
> >
> >
> > Maybe "implementationType" would have been be a better name :-)
> >
> > My suggestion is that the SPI should put the burden on the
> > > implementation module - for example a special method on the
> > > xxxImplementation class with a name like "locateComponentTypeFile".
> > > Actual loading of the componenttype file can be generic, but finding
> > the
> > > file is definitely a job for the implementation-handling code.
> >
> >
> > The problem with this is some don't want the simple xxxImplementation
> > class
> > to even be implementing any interface so ideally as much generic
> > function
> > would be built in the runtime, and thats what I'm trying to find a way
> > of
> > doing.
> >
> > I was wondering if the contribution service could help here. It could
> > discover all the .componentType files in a contribution making their
> > names
> > available, the values of all the attributes of the xxxImplementation
> > class
> > are also known so it could compare all the attribute values against all
> > the
> > found .componentType file names ignoring the file extension and when
> > there's
> > a match thats the .componentType for the implementation. How does that
> > sound?
>
>
> That could be quite a gamble in my opinion. There is a possibility that
> some attribute value of an implementation type instance could end up
> matching a componentType that corresponds to some other implementation.
>
Its xxx/yyy.componentType matching xxx/yyy.zzz, so "xxx/yyy." matching some
other attribute value would be pretty rare wouldn't it? So for that rare
case it could just throw some exception if the implementation type impl
tries to use the default discovery mechanism.
Even if the specs changed to have an attribute called 'implArtifact' or
> 'implResource' so that you can pick up the implementation resource
> information, it would still not help to deal generically if implementation
> types have their own means of loading this and the associated componentType
> info. And then what is implementation types decide to add their extensions
> to a ComponentType. ?
>
Then they have to override the default behaviour and implement this
themselves. This is for the "simple" implementation type impl so it doesn't
have to cope with every possibility...and after nearly two years there's
been no Tuscany extension yet that adds to the ComponentType...
...ant
Re: Finding the .componentType file
Posted by Venkata Krishnan <fo...@gmail.com>.
On 6/18/07, ant elder <an...@apache.org> wrote:
>
> On 6/17/07, Mike Edwards <mi...@gmail.com> wrote:
>
> <snip>
>
> The component name may be nothing like the implementation name
>
>
> How does that fit with the spec saying - ""A component type file has the
> same name as the implementation file but has the extension
> ".componentType""
> ? I'm looking for a way to make the default case easy, it doesn't have to
> deal with every edge case.
>
> The componentType file is really to be thought of as an extension of the
> > implementation for those (hopefully few) cases where introspection of
> > the implementation cannot provide the required information.
>
>
> Maybe "implementationType" would have been be a better name :-)
>
> My suggestion is that the SPI should put the burden on the
> > implementation module - for example a special method on the
> > xxxImplementation class with a name like "locateComponentTypeFile".
> > Actual loading of the componenttype file can be generic, but finding the
> > file is definitely a job for the implementation-handling code.
>
>
> The problem with this is some don't want the simple xxxImplementation
> class
> to even be implementing any interface so ideally as much generic function
> would be built in the runtime, and thats what I'm trying to find a way of
> doing.
>
> I was wondering if the contribution service could help here. It could
> discover all the .componentType files in a contribution making their names
> available, the values of all the attributes of the xxxImplementation
> class
> are also known so it could compare all the attribute values against all
> the
> found .componentType file names ignoring the file extension and when
> there's
> a match thats the .componentType for the implementation. How does that
> sound?
That could be quite a gamble in my opinion. There is a possibility that
some attribute value of an implementation type instance could end up
matching a componentType that corresponds to some other implementation.
Even if the specs changed to have an attribute called 'implArtifact' or
'implResource' so that you can pick up the implementation resource
information, it would still not help to deal generically if implementation
types have their own means of loading this and the associated componentType
info. And then what is implementation types decide to add their extensions
to a ComponentType. ?
> ...ant
>
- Venkat
Re: Finding the .componentType file
Posted by Pete Robbins <ro...@googlemail.com>.
In Tuscany C++ the language implementation (C++, Python, etc) defines the
location of the .componentType file. For C++ we use the header=".." and
path=" .." attributes of implementation.cpp:
in fred.composite:
<implementation.cpp library="Calculator" header="CalculatorImpl.h"
path="abc/xyz"/>
The implementation library is abc/xyz/Calcualtor.dll (or
abc/xyz/libCalculator.so for linux). The compnentType file is named from the
implentation interface (header) so in the above will be located at
abc/xyz/CalculatorImpl.componentType.
The paths are relative to the composite root (location of the .composite
file).
Cheers,
On 20/06/07, Mike Edwards <mi...@gmail.com> wrote:
> Ant,
>
> In general, I would agree that there should be a simple and obvious
> relationship between implementation artifact and componentType file.
>
> However, consider the case of languages like C or C++ where multiple
> implementations are bundled into a DLL. The runtime file is the DLL,
> but there must be multiple componentType files. So now, what is the
> relationship between them....
>
> In these more complex cases, the implementation type defines the
> relationship.
>
> Yours, Mike.
>
> ant elder wrote:
> > On 6/18/07, Mike Edwards <mi...@gmail.com> wrote:
> >
> > <snip>
> >
> >> How does that fit with the spec saying - ""A component type file has
> the
> >> > same name as the implementation file but has the extension
> >> > ".componentType""
> >> > ? I'm looking for a way to make the default case easy, it doesn't
> have
> >> to
> >> > deal with every edge case.
> >> <snip>
> >>
> >> Unfortunately, this is no edge case. There is no reason to expect the
> >> component name to be even close to the implementation name.
> >
> >
> >
> > AFAICT, unless there's an attribute in the SCDL to explicitly point to
> it
> > there has to be a way to find these things programatically, and for
> humans
> > to understand whats going on in a contribution it must be reasonably
> > obvious
> > which .componentType side file is associated with which implementation
> just
> > by eyeballing the files. Otherwise, what does this line in the spec
> mean:
> >
> > 'A component type file has the same name as the implementation file but
> has
> > the extension ".componentType"'
> >
> > ...ant
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Pete
Re: Finding the .componentType file
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mike Edwards wrote:
>
> Jean-Sebastien Delfino wrote:
>
>>
>> Nobody picked up my earlier post to this thread, I thought that my
>> concrete examples were interesting though :) so I'll repeat a
>> concrete example again here:
>>
>> <implementation.java class="calculator.CalculatorImpl">
>>
>> componentType file: calculator/CalculatorImpl.componentType
>>
>> - The relationship is obvious to a human
>> - There is no SCDL attribute pointing to the componentType
>> - The relationship class name -> .componentType file location is
>> specific to the Java implementation type.
>>
>> IMHO you need implementation specific code to derive the
>> .componentType file location from the attributes of the
>> <implementation>.
>>
> I think that I'm agreeing with you very strongly - I just said it a
> different way.
>
> The C++ example I gave was a more stark example of the problem of why
> there is no direct relationship between component and componentType
> file independent from the implementation type itself.
>
> You are right - the SCDL does not point to the componentType file. If
> we had called componentType files "implementationInfo" files instead,
> this would perhaps have made the situation clearer - that
> componentType side files are there to provide extra information about
> an implementation for those situations where you can't get the
> information directly from the implementation (ie via introspection).
>
>
> Yours, Mike.
>
To illustrate what we've been discussing here, I added code to the
implementation-pojo2-extension sample to show how to get the model
representing a .componentType file (if there is one) corresponding to a
POJO class, and merge it into the POJO implementation model in the model
resolution phase.
See the resolve() method in [1]. That code takes the POJO implementation
class name, replaces '.' by '/', adds .componentType and calls the
ModelResolver as usual to resolve the ComponentType.
The POJO2 sample just uses the info from the .componentType as-is but
other component implementation extensions can obviously implement more
useful merging rules. If I remember correctly the Java API and
Annotations spec describes the merging rules for Java components, there
may be slightly different rules for BPEL etc.
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/implementation-pojo2-extension/src/main/java/pojo2/extension/POJOImplementationProcessor.java
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Finding the .componentType file
Posted by Mike Edwards <mi...@gmail.com>.
Jean-Sebastien Delfino wrote:
>
> Nobody picked up my earlier post to this thread, I thought that my
> concrete examples were interesting though :) so I'll repeat a concrete
> example again here:
>
> <implementation.java class="calculator.CalculatorImpl">
>
> componentType file: calculator/CalculatorImpl.componentType
>
> - The relationship is obvious to a human
> - There is no SCDL attribute pointing to the componentType
> - The relationship class name -> .componentType file location is
> specific to the Java implementation type.
>
> IMHO you need implementation specific code to derive the .componentType
> file location from the attributes of the <implementation>.
>
I think that I'm agreeing with you very strongly - I just said it a
different way.
The C++ example I gave was a more stark example of the problem of why
there is no direct relationship between component and componentType file
independent from the implementation type itself.
You are right - the SCDL does not point to the componentType file. If
we had called componentType files "implementationInfo" files instead,
this would perhaps have made the situation clearer - that componentType
side files are there to provide extra information about an
implementation for those situations where you can't get the information
directly from the implementation (ie via introspection).
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Finding the .componentType file
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mike Edwards wrote:
> Ant,
>
> In general, I would agree that there should be a simple and obvious
> relationship between implementation artifact and componentType file.
>
> However, consider the case of languages like C or C++ where multiple
> implementations are bundled into a DLL. The runtime file is the DLL,
> but there must be multiple componentType files. So now, what is the
> relationship between them....
>
> In these more complex cases, the implementation type defines the
> relationship.
>
> Yours, Mike.
>
> ant elder wrote:
>> On 6/18/07, Mike Edwards <mi...@gmail.com> wrote:
>>
>> <snip>
>>
>>> How does that fit with the spec saying - ""A component type file has
>>> the
>>> > same name as the implementation file but has the extension
>>> > ".componentType""
>>> > ? I'm looking for a way to make the default case easy, it doesn't
>>> have
>>> to
>>> > deal with every edge case.
>>> <snip>
>>>
>>> Unfortunately, this is no edge case. There is no reason to expect the
>>> component name to be even close to the implementation name.
>>
>>
>>
>> AFAICT, unless there's an attribute in the SCDL to explicitly point
>> to it
>> there has to be a way to find these things programatically, and for
>> humans
>> to understand whats going on in a contribution it must be reasonably
>> obvious
>> which .componentType side file is associated with which
>> implementation just
>> by eyeballing the files. Otherwise, what does this line in the spec
>> mean:
>>
>> 'A component type file has the same name as the implementation file
>> but has
>> the extension ".componentType"'
>>
>> ...ant
>>
>
Nobody picked up my earlier post to this thread, I thought that my
concrete examples were interesting though :) so I'll repeat a concrete
example again here:
<implementation.java class="calculator.CalculatorImpl">
componentType file: calculator/CalculatorImpl.componentType
- The relationship is obvious to a human
- There is no SCDL attribute pointing to the componentType
- The relationship class name -> .componentType file location is
specific to the Java implementation type.
IMHO you need implementation specific code to derive the .componentType
file location from the attributes of the <implementation>.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Finding the .componentType file
Posted by Mike Edwards <mi...@gmail.com>.
Ant,
In general, I would agree that there should be a simple and obvious
relationship between implementation artifact and componentType file.
However, consider the case of languages like C or C++ where multiple
implementations are bundled into a DLL. The runtime file is the DLL,
but there must be multiple componentType files. So now, what is the
relationship between them....
In these more complex cases, the implementation type defines the
relationship.
Yours, Mike.
ant elder wrote:
> On 6/18/07, Mike Edwards <mi...@gmail.com> wrote:
>
> <snip>
>
>> How does that fit with the spec saying - ""A component type file has the
>> > same name as the implementation file but has the extension
>> > ".componentType""
>> > ? I'm looking for a way to make the default case easy, it doesn't have
>> to
>> > deal with every edge case.
>> <snip>
>>
>> Unfortunately, this is no edge case. There is no reason to expect the
>> component name to be even close to the implementation name.
>
>
>
> AFAICT, unless there's an attribute in the SCDL to explicitly point to it
> there has to be a way to find these things programatically, and for humans
> to understand whats going on in a contribution it must be reasonably
> obvious
> which .componentType side file is associated with which implementation just
> by eyeballing the files. Otherwise, what does this line in the spec mean:
>
> 'A component type file has the same name as the implementation file but has
> the extension ".componentType"'
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Finding the .componentType file
Posted by ant elder <an...@apache.org>.
On 6/18/07, Mike Edwards <mi...@gmail.com> wrote:
<snip>
> How does that fit with the spec saying - ""A component type file has the
> > same name as the implementation file but has the extension
> > ".componentType""
> > ? I'm looking for a way to make the default case easy, it doesn't have
> to
> > deal with every edge case.
> <snip>
>
> Unfortunately, this is no edge case. There is no reason to expect the
> component name to be even close to the implementation name.
AFAICT, unless there's an attribute in the SCDL to explicitly point to it
there has to be a way to find these things programatically, and for humans
to understand whats going on in a contribution it must be reasonably obvious
which .componentType side file is associated with which implementation just
by eyeballing the files. Otherwise, what does this line in the spec mean:
'A component type file has the same name as the implementation file but has
the extension ".componentType"'
...ant
Re: Finding the .componentType file
Posted by Mike Edwards <mi...@gmail.com>.
Ant,
Yes, sometimes the terminology can get confusing.
<snip>
>
> The component name may be nothing like the implementation name
>
>
> How does that fit with the spec saying - ""A component type file has the
> same name as the implementation file but has the extension
> ".componentType""
> ? I'm looking for a way to make the default case easy, it doesn't have to
> deal with every edge case.
<snip>
Unfortunately, this is no edge case. There is no reason to expect the
component name to be even close to the implementation name.
>
> The componentType file is really to be thought of as an extension of the
>
>> implementation for those (hopefully few) cases where introspection of
>> the implementation cannot provide the required information.
>
>
>
> Maybe "implementationType" would have been be a better name :-)
>
One name that we dearly wanted for "componentType" was
"implementationInfo". We tried hard to get that name but failed. That
alternative makes it clearer that the file contains metadata about the
implementation.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Finding the .componentType file
Posted by ant elder <an...@apache.org>.
On 6/17/07, Mike Edwards <mi...@gmail.com> wrote:
<snip>
The component name may be nothing like the implementation name
How does that fit with the spec saying - ""A component type file has the
same name as the implementation file but has the extension ".componentType""
? I'm looking for a way to make the default case easy, it doesn't have to
deal with every edge case.
The componentType file is really to be thought of as an extension of the
> implementation for those (hopefully few) cases where introspection of
> the implementation cannot provide the required information.
Maybe "implementationType" would have been be a better name :-)
My suggestion is that the SPI should put the burden on the
> implementation module - for example a special method on the
> xxxImplementation class with a name like "locateComponentTypeFile".
> Actual loading of the componenttype file can be generic, but finding the
> file is definitely a job for the implementation-handling code.
The problem with this is some don't want the simple xxxImplementation class
to even be implementing any interface so ideally as much generic function
would be built in the runtime, and thats what I'm trying to find a way of
doing.
I was wondering if the contribution service could help here. It could
discover all the .componentType files in a contribution making their names
available, the values of all the attributes of the xxxImplementation class
are also known so it could compare all the attribute values against all the
found .componentType file names ignoring the file extension and when there's
a match thats the .componentType for the implementation. How does that
sound?
...ant
Re: Finding the .componentType file
Posted by Mike Edwards <mi...@gmail.com>.
Ant,
The idea of using the component name is completely wrong and
unacceptable, I'm afraid.
The component name may be nothing like the implementation name - and an
implementation can be used multiple times by different components. The
componentType file is really to be thought of as an extension of the
implementation for those (hopefully few) cases where introspection of
the implementation cannot provide the required information.
My suggestion is that the SPI should put the burden on the
implementation module - for example a special method on the
xxxImplementation class with a name like "locateComponentTypeFile".
Actual loading of the componenttype file can be generic, but finding the
file is definitely a job for the implementation-handling code.
PS I suspect that it may be wise to allow the implementation to hook out
the loading of the componentType file. With extensibility allowed, the
componentType file might conceivably contain extra information in the
case of some implementation types....
Yours, Mike.
ant elder wrote:
> I'm struggling with how to define and locate the .componentType side
> file in
> the implementation SPI. The assembly spec says:
>
> "A component type file has the same name as the implementation file but has
> the extension ".componentType"...The location of the component type file
> depends on the type of the component implementation..." (page 13 line 445).
>
> The problem is "the implementation file" is not specific enough and there
> isn't a standard way for the runtime to know which implementation attribute
> is the "implementation file". Eg, for implementation.java its the 'class'
> attribute, for implentation.script its the 'script' attribute, for
> implementation.das its the 'config' attribute etc.
>
> Any one have any ideas on how to do this? Would it be be terribly
> non-compliant if the default used by the runtime was "A component type file
> has the same name as the _component_ with the extension ".componentType"?
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org