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