Simon Laws wrote:
On Tue, Dec 9, 2008 at 10:36 AM, ant elder <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Tue, Dec 9, 2008 at 10:26 AM, Simon Laws
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
On Mon, Dec 8, 2008 at 9:11 PM, Simon Nash <[EMAIL PROTECTED]
<mailto:[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]
<mailto:[EMAIL PROTECTED]>>
*Sent:* Monday, December 08, 2008 8:44 AM
*To:* [email protected]
<mailto:[email protected]>
<mailto:[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]>
<mailto:[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]
<mailto:[EMAIL PROTECTED]>>
*Sent:* Monday, December 08, 2008 8:26 AM
*To:* tuscany-dev <mailto:[email protected]
<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
>
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
