On 6/18/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
On 6/18/07, ant elder <[EMAIL PROTECTED]> wrote: > On 6/17/07, Mike Edwards <[EMAIL PROTECTED]> 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
