Hi, Jeremy.
Thanks for the clarification.
For the SDO loader, I have posted a patch before (
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03792.html ).
Please review and apply.
Thank you for bringing up the issue on how we support more flexible loader
registrations. There are some potential use cases:
1) Register a loader by one or more element QNames (In the SDO loader impl,
a QName for now is required to create a loader instance for the given
element)
2) Register a loader by one or more type QNames
3) Register a loader by one or more namespaces
4) Register a loader by wildcards against QNames
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, June 21, 2006 3:03 PM
Subject: Re: Tuscany SPI interfaces
Raymond Feng wrote:
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.
I agree that that would be a concern. That wasn't the intention here.
The intention was that the base classes would aid the extension
developer by providing default implementations of parts of the contract
that would be common to typical extensions.
The contracts should be fully defined by the interfaces; the extensions
just happen to provide common implementations.
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.
Not quite - there is a bi-directional contract between the
LoaderRegistry and each StAXElementLoader. Implementations of
StAXElementLoader register with a loader implementation using the
LoaderRegistry interface; in turn the loader implementation calls back
to registered StAXElementLoader implementations to handle an element in
a XML stream.
The contract is fully defined by the StAXElementLoader and
LoaderRegistry interfaces. LoaderExtension does not add anything to
that, it just provides a default implementation of a registration
mechanism.
This is achieved by java annotations.
The way the default works is by using the lifecycle model from the SCA
specification. It starts with the assumption that the extension will be
provided as a composite. When the composite starts, the spec says that
all components inside it designated as "eager-init" are automatically
started. When a Java implementation is started, its "init" method must
be called. Currently the only way an "init" method can be specified is
via an @Init annotation; that's really an omission from the spec - there
should be a way to specify that in the componentType sidefile as well.
LoaderExtension uses this mechanism to register the component with the
LoaderRegistry. As a provider, you just create your loader component as
a subclass of LoaderExtension and include it in your composite - when
the composite is started the init method is called and you automatically
get registered with the LoaderRegistry; when your composite stops you
are automatically unregistered.
Of course, you don't have to use that. You can register a
StAXElementLoader with the LoaderRegistry at any time just by calling
its register method. The bootstrap code does this to register the
primordial set of loaders.
This ties back to the goals we had at the top. The contract here is
specified in the SPI interfaces (LoaderRegistry and StAXElementLoader);
the LoaderExtension base class provides a default implementation based
on the SCA lifecycle model but it is just a default - you can register
in any way supported by the LoaderRegistry contract.
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?
They should - the spec does not have mechanism to represent lifecycle in
XML and that's a problem with the spec. That would be a good proposal to
put forward.
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?
When a loader registers it explicitly specifies the element it wants to
handle (it can actually register multiple times). This is part of the
LoaderRegistry contract.
The default implementation in LoaderExtension gets that from the
sub-class by calling the getXMLType() abstract method. How that method
determines the type is up to the extension developer. The
implementations we have now just return the QName as that seemed really
simple and they are typically specialized to handle one element.
However, how they actually do it is down to them. It certainly would be
possible for a more generic implementation to load it from a resource,
an annotation, having it be injected as a SCA Property value, by parsing
some other XML config file and so on.
For example, I know you were working on a loader implementation that
used SDO. Once you know the set of elements you want SDO to handle you
would just need to register your loader with the LoaderRegistry for each
of them. You probably would not want to use LoaderExtension at all.
If I can help get this SDO loader integrated, please let me know (if you
have posted a patch and I've forgotten please send me a pointer to it).
--
Jeremy
---------------------------------------------------------------------
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]
