Hi,
I guess one of the concerns is that some of the base classes create
additional contracts which are not captured by the interfaces. It ends up
that the extension developers have to understand more.
Let's use the "StAXElementLoader" and "LoaderExtension" as an example.
Interface StAXElementLoader only requires the "load" method to be
implemented while "LoaderExtension" defines a contract on how a
StAXElementLoader register/deregister with the LoaderRegistry. This is
achieved by java annotations.
For this particular case, I can see two ways to get an extension picked up
by the runtime: declarative or programmatic. Some further questions will be:
1) Should the extension developers have a choice to use either java
annotations or external XML configuration?
2) Should the extension metadata (for example, the XML element name that a
loader can handle) be captured in a model and java annotation is just a
convenient way to supply the value?
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, June 21, 2006 2:08 AM
Subject: Re: Tuscany SPI interfaces
Jim Marino wrote:
I think you missed something. With core2, most people will extend from
the helper abstract classes in the SPI extension package (this was also
the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying to
avoid. I want to implement the SPI interfaces without having to extend
base implementation classes.
public class FooAtomicComponent extends AtomicComponentExtension<Object>{
public FooAtomicComponent(String name, CompositeComponent<?> parent,
ScopeContainer scopeContainer, WireService wireService) {
super(name, parent, scopeContainer, wireService);
}
public Object getServiceInstance() throws TargetException {
return null;
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws TargetException
{
return null;
}
public List<Class<?>> getServiceInterfaces() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName, Method
operation) {
return null;
}
}
I generally don't like to "count" methods without looking at what they do
(e.g. some could just be setter/getter types). The above class contains 5
methods, which I believe are reasonable and we don't want to separate
out. Invoker is very simple too:
- Two methods to invoke, one for "message" invocations, and one for raw
payloads. Generally, the first will just pull the payload and invoke the
second
- A setter/getter pair for whether the invocation is cacheable
- A boolean if the invoker can be optimized away and the target can be
called through straight invocation without a proxy. Generally false.
- A clone method
The Spring and Groovy samples in the sandbox demonstrate both of these.
Jim
On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino wrote:
I'm trying to implement the sample ruby extension and running into some
issues.
I'm implementing an AtomicComponentContext (with the code in the head
stream) and also trying the equivalent AtomicComponent with some of the
code in the sandbox. I want to be able to implement my extension class
without having to depend on base Tuscany runtime implementation classes,
so I'm just implementing the SPI interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the builders or
invokers yet... I think that in both cases this is too much.
It looks like the experiment in the sandbox is attempting to provide a
simpler programming model for these extensions by hiding some of the
complexity in base implementation classes, but I think it will be better
to define a set of independent interfaces and make some of them
optional. In other words if my extension does not wish to implement one
of the interfaces, then it just doesn't need to, and the runtime should
assume some default behavior, instead of forcing me to implement all the
25 methods...
Another thought is to allow the contract to be implemented with multiple
objects specialized in each aspect instead of one big object with 25
methods.
As I'm going through the implementation of the ruby component
implementation extension, I'm trying to come up with a short list of
requirements and methods that I think we really need to implement, and
with that list I'd like us to prototype simpler SPI interfaces. If
anybody is interested in helping, please feel free to jump in, it would
really be great if we could do a binding extension in parallel, and also
if the people who actually developed some of the existing extensions
could come up with the requirements they've seen in terms of SPI and
proposals to improve our extensibility story.
Thanks,
--Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
