You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by kelvin goodson <kg...@thegoodsons.org.uk> on 2010/04/28 15:37:41 UTC
extension spi investigations
I've been looking at the extension code we have, to try to understand
by reverse engineering, what might be considered SPIs that are
available to an extension developer. I've just finished a pass
through the extension code, marking the classes that each extension
directly depends on as extension spi. (Some results at [1]) Some of
this was clear cut, but other dependencies were not so clear to
categorize. In particular, some extensions depend on others, and it
wasn't clear to me whether there are a set of core extensions that can
be considered to contain SPI, whether there are a set of special
relationships between some extensions or whether there are code
tangles that ought to be unravelled. I suspect there is a combination
of all three.
Below are some examples. If anyone can offer an insights as to
whether these relationships suggest that the dependencies should be
marked as extension SPI I'd be very grateful.
implementation.web and implementation.widget use interfacedef.java
implementation.spring uses implementation.java
binding-atom-runtime depends on binding-http
jms-runtime dependence on binding.ws
jms-runtime dependence on databinding-xml
jsonrpc-provider & runtime dependency on interface-java
rmi-runtime depends on interface-java
binding-ws-wsdlgen depends on databinding.jaxb
binding-ws dependends on interfacedef.wsdl
interfacef-java-jaxws depends on interfacedef.java
databinding.axiom and db.json depends on databinding.javabeans
I've also currently skipped binding-sca-runtime, as it wasn't clear to
me whether this was a special extension that was itself SPI or whether
it should be treated as all the rest.
Kelvin
[1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SPI+Investigations
Re: extension spi investigations
Posted by kelvin goodson <ke...@gmail.com>.
Thanks Luciano and Raymond. I'll take another quick swing through on
the basis of your comments.
Kelvin.
On Thu, Apr 29, 2010 at 6:48 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Wed, Apr 28, 2010 at 9:26 AM, Luciano Resende <lu...@gmail.com> wrote:
>> On Wed, Apr 28, 2010 at 8:27 AM, Raymond Feng <en...@gmail.com> wrote:
>>> binding-atom-runtime depends on binding-http
>>>
>>> binding-atom-runtime is built on top of binding-http. It's a specialization.
>>>
>>
>> Looks like the only thing here is related to Atom bindings usage of
>> HTTPCacheContext to handle ETags, LastModified and other cache control
>> stuff and this should be moved to the new http-common module. I'll fix
>> that in my next commits some time today.
>>
>
> HTTPCacheContext refactored to common-http under svn revision #939202.
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: extension spi investigations
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Apr 28, 2010 at 9:26 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Wed, Apr 28, 2010 at 8:27 AM, Raymond Feng <en...@gmail.com> wrote:
>> binding-atom-runtime depends on binding-http
>>
>> binding-atom-runtime is built on top of binding-http. It's a specialization.
>>
>
> Looks like the only thing here is related to Atom bindings usage of
> HTTPCacheContext to handle ETags, LastModified and other cache control
> stuff and this should be moved to the new http-common module. I'll fix
> that in my next commits some time today.
>
HTTPCacheContext refactored to common-http under svn revision #939202.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: extension spi investigations
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Apr 28, 2010 at 8:27 AM, Raymond Feng <en...@gmail.com> wrote:
> binding-atom-runtime depends on binding-http
>
> binding-atom-runtime is built on top of binding-http. It's a specialization.
>
Looks like the only thing here is related to Atom bindings usage of
HTTPCacheContext to handle ETags, LastModified and other cache control
stuff and this should be moved to the new http-common module. I'll fix
that in my next commits some time today.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: extension spi investigations
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please see my comments inline.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Apr 28, 2010, at 6:37 AM, kelvin goodson wrote:
> I've been looking at the extension code we have, to try to understand
> by reverse engineering, what might be considered SPIs that are
> available to an extension developer. I've just finished a pass
> through the extension code, marking the classes that each extension
> directly depends on as extension spi. (Some results at [1]) Some of
> this was clear cut, but other dependencies were not so clear to
> categorize. In particular, some extensions depend on others, and it
> wasn't clear to me whether there are a set of core extensions that can
> be considered to contain SPI, whether there are a set of special
> relationships between some extensions or whether there are code
> tangles that ought to be unravelled. I suspect there is a combination
> of all three.
>
> Below are some examples. If anyone can offer an insights as to
> whether these relationships suggest that the dependencies should be
> marked as extension SPI I'd be very grateful.
>
> implementation.web and implementation.widget use interfacedef.java
interfacedef.java should be SPI. We use java interface models in many modules.
> implementation.spring uses implementation.java
implementation.spring extends implementation.java to some extent. We adds the SCA annotation support for Spring. Some potential refactoring could happen to extract the common base for all POJO based implementation types.
> binding-atom-runtime depends on binding-http
binding-atom-runtime is built on top of binding-http. It's a specialization.
> jms-runtime dependence on binding.ws
Not sure.
> jms-runtime dependence on databinding-xml
We may be able to refactor the code to use the databinding Mediator SPI instead of the specific transformer classes.
> jsonrpc-provider & runtime dependency on interface-java
> rmi-runtime depends on interface-java
Again, interface-java should be SPI.
> binding-ws-wsdlgen depends on databinding.jaxb
We have cases that some modules are friends. We can view them as internal SPIs.
> binding-ws dependends on interfacedef.wsdl
interface-wsdl should be SPI.
> interfacef-java-jaxws depends on interfacedef.java
interface-java-jaxws is the specialization of interface-java.
> databinding.axiom and db.json depends on databinding.javabeans
Some transformers deal with multiple databindings.
>
> I've also currently skipped binding-sca-runtime, as it wasn't clear to
> me whether this was a special extension that was itself SPI or whether
> it should be treated as all the rest.
>
> Kelvin
>
> [1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SPI+Investigations