On Tue, Dec 9, 2008 at 10:36 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Tue, Dec 9, 2008 at 10:26 AM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> >> >> On Mon, Dec 8, 2008 at 9:11 PM, Simon Nash <[EMAIL PROTECTED]> wrote: >> >>> Raymond Feng wrote: >>> >>>> I meant Extension. Some projects such as Axis2 and Woodstox use this >>>> suffix for extended API/SPI. >>>> Thanks, >>>> Raymond >>>> >>>> *From:* Simon Laws <mailto:[EMAIL PROTECTED]> >>>> *Sent:* Monday, December 08, 2008 8:44 AM >>>> *To:* [email protected] <mailto:[email protected]> >>>> *Subject:* Re: [1.4] ComponentContext changes >>>> >>>> >>>> >>>> On Mon, Dec 8, 2008 at 4:38 PM, Raymond Feng <[EMAIL PROTECTED]<mailto: >>>> [EMAIL PROTECTED]>> wrote: >>>> >>>> Hi, >>>> I'm looking into this area in the 2.x stream. What I have done is >>>> to >>>> define a ComponentContextExt interface which extends from the >>>> ComponentContext interface and provides Tuscany specific SPIs. I >>>> also plan to consolidate RuntimeComponentContext and >>>> ComponentContextExt into one interface. >>>> In 1.4, the case is slightly different because we are trying to >>>> "enhance" the API. What module do you plan to add such an API? I >>>> think "ComponentContextExt" is still a good name for the extended >>>> API. >>>> Thanks, >>>> Raymond >>>> >>>> *From:* Simon Laws <mailto:[EMAIL PROTECTED]> >>>> *Sent:* Monday, December 08, 2008 8:26 AM >>>> *To:* tuscany-dev <mailto:[email protected]> >>>> *Subject:* [1.4] ComponentContext changes >>>> >>>> A while back I checked the patch for TUSCANY-2281 in and part of >>>> this change was the extension of the ComponentContext API. This >>>> would seem to be incompatible with the spec license so I would like >>>> to propose a further change; >>>> >>>> 1/ Create a TuscanyComponentContext interface which extends >>>> ComponentContext and holds the new APIs for retrieving reference >>>> collections. >>>> 2/ Have the RuntimeComponentContext extend the >>>> TuscanyCompoentContext interface >>>> 3/ When you need to use the new APIs you have to cast to the >>>> TuscanyComponentContext >>>> >>>> Collection<Crawler> crawlers = >>>> >>>> ((TuscanyComponentContext)componentContext).getServices(Crawler.class, >>>> "crawlers"); >>>> >>>> As an optimization we could look at having the injectors inject >>>> TuscanyComponentContext if this is specified to remove the need to >>>> do the cast. >>>> >>>> Thoughts? >>>> >>>> Regards >>>> >>>> Simon >>>> >>>> >>>> By Ext do you mean Extension/External? ComponentContextExtentsion sounds >>>> ok to me. I think it could happily live in the sca api package as long as >>>> it >>>> is clear that it isn't part of the specified api. Maybe the addition of the >>>> word Tuscany makes that clearer? I should point out that the particular >>>> problem that 2281 fixes has been corrected in the OASIS specs so this >>>> change >>>> won't be needed in the OASIS SCA APIs that are added to trunk. >>>> >>>> Whatever name we choose, I don't think this interface should be part of >>> the sca-api module or the org.osoa.sca package. We should add another >>> module and package for Tuscany API extensions. >>> >>> Simon >>> >>> Simon >>>> >>>> >>> >>> >> Hi Simon >> >> I agree it shouldn't be part of the org.osoa.sca package. But do we need >> to add a new module just to hold these extensions? >> >> Simon >> > > Not so long ago there was some reluctance to put even the spec defined JSP > taglib into the sca-api module so while thats the approach then i don't > think Tuscany classes should go in the sca-api module either. I do think it > would be easier for users to have a single jar they can use which has all > the API classes that they might be needed to compile an SCA application, > that was the intention for the api module which aggregated all the API > classes in to one easy to use jar. > > ...ant > > > > > > Looking back over the mail list I see I would be swimming against the tide on this. In 1.x/1.4 I'll create a new module called sca-api-extension and put the tuscany specific API in there. I would hope that OASIS actually ship the api jar themselves and we wouldn't want to insert new content in there so I could be persuaded that this is a consistent story going forward in 2.x. Simon
