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]
