On 6/18/07, ant elder <[EMAIL PROTECTED]> wrote:
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.
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
