You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/12/08 17:26:43 UTC
[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
Re: [1.4] ComponentContext changes
Posted by Simon Nash <na...@apache.org>.
Simon Laws wrote:
>
>
> On Tue, Dec 9, 2008 at 10:36 AM, ant elder <ant.elder@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Tue, Dec 9, 2008 at 10:26 AM, Simon Laws
> <simonslaws@googlemail.com <ma...@googlemail.com>> wrote:
>
>
>
> On Mon, Dec 8, 2008 at 9:11 PM, Simon Nash <nash@apache.org
> <ma...@apache.org>> 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:simonslaws@googlemail.com
> <ma...@googlemail.com>>
> *Sent:* Monday, December 08, 2008 8:44 AM
> *To:* dev@tuscany.apache.org
> <ma...@tuscany.apache.org>
> <mailto:dev@tuscany.apache.org
> <ma...@tuscany.apache.org>>
>
> *Subject:* Re: [1.4] ComponentContext changes
>
>
>
> On Mon, Dec 8, 2008 at 4:38 PM, Raymond Feng
> <enjoyjava@gmail.com <ma...@gmail.com>
> <mailto:enjoyjava@gmail.com
> <ma...@gmail.com>>> 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:simonslaws@googlemail.com
> <ma...@googlemail.com>>
> *Sent:* Monday, December 08, 2008 8:26 AM
> *To:* tuscany-dev <mailto:dev@tuscany.apache.org
> <ma...@tuscany.apache.org>>
> *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
>
I'll raise the API jar question with OASIS. So far the sca-j TC has not
produced an API jar as a formal deliverable. I think it would be a very
good idea for OASIS to do that.
Simon
Re: [1.4] ComponentContext changes
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Dec 9, 2008 at 10:36 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Tue, Dec 9, 2008 at 10:26 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Mon, Dec 8, 2008 at 9:11 PM, Simon Nash <na...@apache.org> 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 <ma...@googlemail.com>
>>>> *Sent:* Monday, December 08, 2008 8:44 AM
>>>> *To:* dev@tuscany.apache.org <ma...@tuscany.apache.org>
>>>> *Subject:* Re: [1.4] ComponentContext changes
>>>>
>>>>
>>>>
>>>> On Mon, Dec 8, 2008 at 4:38 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>>>> enjoyjava@gmail.com>> 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 <ma...@googlemail.com>
>>>> *Sent:* Monday, December 08, 2008 8:26 AM
>>>> *To:* tuscany-dev <ma...@tuscany.apache.org>
>>>> *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
Re: [1.4] ComponentContext changes
Posted by ant elder <an...@gmail.com>.
On Tue, Dec 9, 2008 at 10:26 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Mon, Dec 8, 2008 at 9:11 PM, Simon Nash <na...@apache.org> 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 <ma...@googlemail.com>
>>> *Sent:* Monday, December 08, 2008 8:44 AM
>>> *To:* dev@tuscany.apache.org <ma...@tuscany.apache.org>
>>> *Subject:* Re: [1.4] ComponentContext changes
>>>
>>>
>>>
>>> On Mon, Dec 8, 2008 at 4:38 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>>> enjoyjava@gmail.com>> 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 <ma...@googlemail.com>
>>> *Sent:* Monday, December 08, 2008 8:26 AM
>>> *To:* tuscany-dev <ma...@tuscany.apache.org>
>>> *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
Re: [1.4] ComponentContext changes
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Dec 8, 2008 at 9:11 PM, Simon Nash <na...@apache.org> 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 <ma...@googlemail.com>
>> *Sent:* Monday, December 08, 2008 8:44 AM
>> *To:* dev@tuscany.apache.org <ma...@tuscany.apache.org>
>> *Subject:* Re: [1.4] ComponentContext changes
>>
>>
>>
>> On Mon, Dec 8, 2008 at 4:38 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>> enjoyjava@gmail.com>> 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 <ma...@googlemail.com>
>> *Sent:* Monday, December 08, 2008 8:26 AM
>> *To:* tuscany-dev <ma...@tuscany.apache.org>
>> *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
Re: [1.4] ComponentContext changes
Posted by Simon Nash <na...@apache.org>.
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 <ma...@googlemail.com>
> *Sent:* Monday, December 08, 2008 8:44 AM
> *To:* dev@tuscany.apache.org <ma...@tuscany.apache.org>
> *Subject:* Re: [1.4] ComponentContext changes
>
>
>
> On Mon, Dec 8, 2008 at 4:38 PM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> 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 <ma...@googlemail.com>
> *Sent:* Monday, December 08, 2008 8:26 AM
> *To:* tuscany-dev <ma...@tuscany.apache.org>
> *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
>
Re: [1.4] ComponentContext changes
Posted by Raymond Feng <en...@gmail.com>.
I meant Extension. Some projects such as Axis2 and Woodstox use this suffix for extended API/SPI.
Thanks,
Raymond
From: Simon Laws
Sent: Monday, December 08, 2008 8:44 AM
To: dev@tuscany.apache.org
Subject: Re: [1.4] ComponentContext changes
On Mon, Dec 8, 2008 at 4:38 PM, Raymond Feng <en...@gmail.com> 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
Sent: Monday, December 08, 2008 8:26 AM
To: tuscany-dev
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.
Simon
Re: [1.4] ComponentContext changes
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Dec 8, 2008 at 4:38 PM, Raymond Feng <en...@gmail.com> 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 <si...@googlemail.com>
> *Sent:* Monday, December 08, 2008 8:26 AM
> *To:* tuscany-dev <de...@tuscany.apache.org>
> *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.
Simon
Re: [1.4] ComponentContext changes
Posted by Raymond Feng <en...@gmail.com>.
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
Sent: Monday, December 08, 2008 8:26 AM
To: tuscany-dev
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