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
