You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2007/02/28 17:08:58 UTC
Removing extension baseclasses from SPI
One of the challenges with SPI is the amount of implementation it
contains, particularly in the extension package where we provide
baseclasses for many of the extension points.
The intention here was to provide implementation infrastructure
common to many extension points that they could use. The problem is
maintaining that requires frequent revision to the SPI module
(although not necessarily to the interfaces it defines).
I think we can get around this issue by replacing these with specific
implementation types that are part of the core implementation. For
example, instead of having to write code to implement a loader for
"MyModelObject", we would allow the user to define one declaratively
using something like:
<component name="myLoader">
<t:loader modelObject="com.example.MyModelObject"/>
</component>
I'm going to explore this related to the loaders and if it seems to
work well will see how it extends to other extension points.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Removing extension baseclasses from SPI
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 28, 2007, at 12:42 PM, Scott Kurz wrote:
> IMHO, that sounds like a useful refactoring. I remember it taking
> awhile
> to sink in that these SPI extension classes where providing
> implementations
> in abstract classes since that wasn't what I'd expected from
> browsing the
> rest of the Tuscany source structuring.
>
> On a somewhat related note I was just wondering whether or how the
> function
> in Axis2ServiceBinding.invokeTarget() could be moved into a base
> ServiceBindingExtension.... which I would need to look into more to
> understand. The tie back to Jeremy's point is the fact that this
> abstract function certainly make the job of writing extensions much
> easier.
>
I think a lot of what is in TargetInvoker could be abstracted out but
we'll still need to have extensions provide the code that actually
does the dispatch. I'd also like to refactor the base invoker class
as there are too many concerns in it at present. It would also be
good if we can just introduce the declarative loading mechanism
outlined by Jeremy.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Removing extension baseclasses from SPI
Posted by Scott Kurz <sc...@gmail.com>.
IMHO, that sounds like a useful refactoring. I remember it taking awhile
to sink in that these SPI extension classes where providing implementations
in abstract classes since that wasn't what I'd expected from browsing the
rest of the Tuscany source structuring.
On a somewhat related note I was just wondering whether or how the function
in Axis2ServiceBinding.invokeTarget() could be moved into a base
ServiceBindingExtension.... which I would need to look into more to
understand. The tie back to Jeremy's point is the fact that this
abstract function certainly make the job of writing extensions much easier.
Scott
On 2/28/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> One of the challenges with SPI is the amount of implementation it
> contains, particularly in the extension package where we provide
> baseclasses for many of the extension points.
>
> The intention here was to provide implementation infrastructure
> common to many extension points that they could use. The problem is
> maintaining that requires frequent revision to the SPI module
> (although not necessarily to the interfaces it defines).
>
> I think we can get around this issue by replacing these with specific
> implementation types that are part of the core implementation. For
> example, instead of having to write code to implement a loader for
> "MyModelObject", we would allow the user to define one declaratively
> using something like:
> <component name="myLoader">
> <t:loader modelObject="com.example.MyModelObject"/>
> </component>
>
> I'm going to explore this related to the loaders and if it seems to
> work well will see how it extends to other extension points.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Removing extension baseclasses from SPI
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy Boynes wrote:
> One of the challenges with SPI is the amount of implementation it
> contains, particularly in the extension package where we provide
> baseclasses for many of the extension points.
>
> The intention here was to provide implementation infrastructure common
> to many extension points that they could use. The problem is
> maintaining that requires frequent revision to the SPI module
> (although not necessarily to the interfaces it defines).
>
> I think we can get around this issue by replacing these with specific
> implementation types that are part of the core implementation. For
> example, instead of having to write code to implement a loader for
> "MyModelObject", we would allow the user to define one declaratively
> using something like:
> <component name="myLoader">
> <t:loader modelObject="com.example.MyModelObject"/>
> </component>
>
> I'm going to explore this related to the loaders and if it seems to
> work well will see how it extends to other extension points.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
This is interesting and could help simplify extensions. Do you have a
rough idea of what a loader implementation class will look like?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Removing extension baseclasses from SPI
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 28, 2007, at 1:21 PM, Raymond Feng wrote:
> Hi,
>
> I can see the pain. Two related questions:
>
> 1) To contribute a loader without a base class, I'll have to
> implement all methods in StAXElementLoader interface, right?
>
I don't think that is what Jeremy has in mind but was instead
proposing a declarative loader extension, i.e. no code is written or
generated. I'll let him explain...
> 2) Can the following SCDL declaration achieve the same goal as you
> proposed?
>
> <component name="myLoader">
> <implementation.java
> class="org.apache.tuscany.core.loader.LoaderExtension"/> <!-- this
> class serves as the id of the extension point -->
> <property name="modelObject">com.example.MyModelObject</property>
> </component>
>
I much prefer we model this as an implementation type. Conceptually
it seems more of a fit and will probably be a lot easier for tools to
deal with, including Notepad or TextEdit :-)
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Removing extension baseclasses from SPI
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 28, 2007, at 1:21 PM, Raymond Feng wrote:
> Hi,
>
> I can see the pain. Two related questions:
>
> 1) To contribute a loader without a base class, I'll have to
> implement all methods in StAXElementLoader interface, right?
You would still be able to do that. The LoaderExtension is fairly
simple (really just handling registration) so doing so would not be
too much a PITA but for others I think it would be more complex. The
idea with an loader implementation type would be to avoid writing code.
>
> 2) Can the following SCDL declaration achieve the same goal as you
> proposed?
>
> <component name="myLoader">
> <implementation.java
> class="org.apache.tuscany.core.loader.LoaderExtension"/> <!-- this
> class serves as the id of the extension point -->
> <property name="modelObject">com.example.MyModelObject</property>
> </component>
This assumes the core classes are available to the extension which is
likely to be a problem.
It also requires that the init() method of LoaderExtension do all the
introspection needed to define the loader. That's going to be a PITA
to maintain. It's also going to require that every instance of
LoaderExtension wire to all of the introspection infrastructure which
will mean promoting a bunch of references out the extension's composite.
With a implementation type approach, only the builder needs to be
wired into the introspection infrastructure. It also shields the user
the actual implementation class used which means the builder might be
able to choose different implementations based on the model object
supplied (e.g it could use a simple POJO binding, or it might choose
JAXB for more complex structures).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Removing extension baseclasses from SPI
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I can see the pain. Two related questions:
1) To contribute a loader without a base class, I'll have to implement all
methods in StAXElementLoader interface, right?
2) Can the following SCDL declaration achieve the same goal as you proposed?
<component name="myLoader">
<implementation.java
class="org.apache.tuscany.core.loader.LoaderExtension"/> <!-- this class
serves as the id of the extension point -->
<property name="modelObject">com.example.MyModelObject</property>
</component>
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, February 28, 2007 8:08 AM
Subject: Removing extension baseclasses from SPI
> One of the challenges with SPI is the amount of implementation it
> contains, particularly in the extension package where we provide
> baseclasses for many of the extension points.
>
> The intention here was to provide implementation infrastructure common to
> many extension points that they could use. The problem is maintaining
> that requires frequent revision to the SPI module (although not
> necessarily to the interfaces it defines).
>
> I think we can get around this issue by replacing these with specific
> implementation types that are part of the core implementation. For
> example, instead of having to write code to implement a loader for
> "MyModelObject", we would allow the user to define one declaratively
> using something like:
> <component name="myLoader">
> <t:loader modelObject="com.example.MyModelObject"/>
> </component>
>
> I'm going to explore this related to the loaders and if it seems to work
> well will see how it extends to other extension points.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org