John, I've looked at the JIRAs you mentioned. Can you add some more detail about what the "more generic API" will look like and its impact on the existing extensions?
I agree with your point below that it's not necessary to subclass WSDLFactory to register user-defined extensions. The problem that I ran into was that, in Axis2 codegen, there wasn't a way to access the WSDLReader and update its ExtensionRegistry before parsing begins. (I didn't want to change that part of Axis2 just to register extensions). I then thought that because Woden can't guarantee that the environment in which it's used will allow access to the WSDLReader, it would be better to have this capability provided by Woden explicitly and the WSDLFactory seemed like a good place to do it. If you think this warrants a new JIRA, I can open one and attach some code based on the existing statically typed extensions model. If you think it's covered by those you mentioned, I can hold off. Peter On 5/8/07, John Kaputin <[EMAIL PROTECTED]> wrote:
Hi Peter, I've just been catching up on this thread. Sounds interesting. I'm working on a couple of JIRAs to address the extension programming model. WODEN-47 will provide a more generic API that the existing statically typed extensions model used for SOAP and HTTP extensions. WODEN-56 will eliminate the need to specify Woden 'internal' classes when registering extensions, as is currently done in the PopulatedExtensionRegistry constructor. One point to note, it's not strictly necessary to subclass WSDLFactory to register user-defined extensions. This can be done by getting the ExtensionRegistry object from the WSDLReader and using the registerXXXX methods it provides. PopulatedExtensionRegistry is just a mechanism used by Woden to 'pre-register' the WSDL 2.0 defined extensions by calling these methods in its constructor for the SOAP and HTTP binding extensions. A limitation of this approach is that it requires the Woden client application to know all of the extension types that must be registered. As you point out - there may be multiple sets of independently created extensions, possibly introduced at different times to the client app. Pluggable extensions, configurable at deployment are a good solution. The ExtensionRegistrar approach is basically wrapping the calls to ExtensionRegistry in a single class and providing a callback method for Woden to invoke them at the appropriate time (at start up). Different implementations of ExtensionRegistrar could be configured via a Woden list property as you suggest or perhaps via a config file or perhaps 'discovered' on the class path. We've had some discussion a while back on the dev list about configuring user-defined extensions that didn't identify the ExtensionRegistrar type interface explicitly, but did deal with the plugin approach. I like your suggestions and will consider them when working on the two JIRAs. If you have some code you'd like to post, great. We are always eager to find out requirements needs from Woden users, so keep the ideas coming. thanks, John Kaputin [EMAIL PROTECTED] wrote on 04/05/2007 17:31:50: > Hi this sounds like a great idea. Do you have some code? If so would > you be able to attach it to a new JIRA? If it works out, sounds like > the the extensions Woden supplies itself should be designed in the > same way. > > If you have a test case to show ExtensionRegistrar in action that > would be nice too. > > Thanks, > Jeremy > > On 04/05/07, Peter Danielsen <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I've been experimenting with Woden and Axis2 a bit trying to exercise > > Woden's extensibility features. I've created some extensions and have > > been trying to find the best way to register them and their error > > message formats without having to change Woden or Axis2 code. I'm > > wondering if any thought has been given to the idea of Woden "plugins" > > that would be a way to package extensions, their message formats, and > > a means of registering both with the core? > > > > It looks like the current, expected way to register extensions is to > > sub-class WSDLFactory and override the newPopulatedExtensionRegistry() > > method, then set the "org.apache.woden.WSDLFactory" property to the > > sub-class' name. This works, but if multiple sets of > > independently-developed extensions (not part of Woden distribution) > > need to be registered, a user will need to create a "composite" > > sub-class that will register their extensions and those developed by > > others. > > > > I'd like to offer a suggestion that would eliminate the need for > > different users to write their own composite sub-classes and would > > help modularize the registration of extensions. The idea is to create > > a new interface, ExtensionRegistrar, with a single method: > > void registerExtensions(ExtensionRegistry registry) > > Each set of extensions provides a class that implements this > > interface. The implementation registers all extensions belonging to > > its set. A new property contains a list of ExtensionRegistrar classes > > whose "registerExtensions" methods are called after the standard > > PopulatedExtensionRegistry has been created. Using the property > > achieves the effect of the composite sub-class without having to write > > it. > > > > With respect to error message formats, it looks like the current way > > to do this is to add them directly to Woden's Messages.properties > > file. Would it instead be possible to modify MessageFormatter to > > allow the registration of additional resource bundles containing the > > message formats for extension sets? MessageFormatter's "format" > > method would then look for the format key in each of the registered > > bundles. An ExtensionRegistrar would be responsible for registering > > the resource bundle for its extension set. > > > > The net result of the above might be that a set of extensions could be > > packaged in a jar file containing: > > - the extension set's classes > > - the ExtensionRegistrar implementation > > - the extension set's message format resource bundle > > > > I think the use of an ExtensionRegistrar could be fairly easily > > incorporated into DOMWSDLFactory. I have more thoughts on this, > > including error handling, please let me know if you're interested in > > pursuing this further. I hope this is a useful suggestion. > > > > > > Peter > > > > --------------------------------------------------------------------- > > 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] > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU --------------------------------------------------------------------- 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]
