Russel, many thanks. This should get us started. I will be passing your information on to someone on my team and you should then be hearing something when we get deeper into this.
Matthew -- Open Source Group sunShine - Lighting up e:Business ================================================================= Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de ================================================================= -----Ursprungliche Nachricht----- Von: Russell Butek [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 30. Januar 2002 18:49 An: [EMAIL PROTECTED] Betreff: Re: Client side generation Matthew, WSDL2Java is sort of designed in a number of pieces. I say sort of because there are certain goals to the whole thing, but the priority has been simply getting it to work, and getting it to work in a clean, pluggable, reusable manner is quite a ways down the priority stack. There are 3 layers - framework: SymbolTable, Emitter, WriterFactory - WSDL2Java plugin to the framework: WSDL2Java (the main), JavaWriterFactory, and all the WSDL-relative writers: JavaPortTypeWriter, JavaBindingWriter, etc. - The actual WSDL2Java emitters, one for each file generated: JavaInterfaceWriter, JavaStubWriter, etc. It sounds like you want to write an emitter that does almost the same as WSDL2Java but with some extra stuff. Say you want to emit something along with a stub (your transformer?). Here's what you'd do: - write MyTransformerWriter which extends JavaWriter and emits your transformer. - write MyBindingWriter which extends JavaBindingWriter. This lets the parent class do all of its thing plus instantiates and invokes your new MyTransformerWriter. - write MyWriterFactory which extends JavaWriterFactory. This overrides "public Writer getWriter(Binding binding, SymbolTable symbolTable);". This method now instantiates your MyBindingWriter. - write MyWSDL2Java, your main class, which processes the command line arguments and instantiates your MyWriterFactory and gives it to Emitter. That's how it's supposed to work, anyway. If you go down this path I'd like to have your feedback. I haven't put much work into the whole framework thing in a while. Russell Butek [EMAIL PROTECTED] "Matthew Langham" <[EMAIL PROTECTED]> on 01/30/2002 10:50:30 AM Please respond to [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> cc: Subject: Client side generation Hi, we are currently looking into ways of integrating Axis into our Cocoon based solution and in particular how we can get Axis to generate the necessary client-side components for us. At the moment the process is as follows: We use Wsdl2java out of Axis to generate the stubs etc. and then write a transformer (the cocoon component) that then uses the stub. This works well - but we feel it would be way neat if we could somehow combine these steps. So in the end it would be great if there was some way of being able to extend Wsdl2java and/or Axis so that we can influence the actual classes it emits (or hook into their generation). The end result being a one step process to generate Cocoon components from WSDL using Axis. Hope you see what I am getting at. Any suggestions? Regards Matthew Langham -- Open Source Group sunShine - Lighting up e:Business ================================================================= Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de =================================================================
