Ok so another not so good example. I was not suggesting an implementation for webservices. If you want to use a config file, some IOC technique, you're more than welcome to use a config file.
Also i agree in the ideal world the generated code should not be touched, that is the generated code should be designed to allow for overwriting things via config files and such. It needs to be properly designed code. However this is not always the case. Still back to the example at hand, given wsdl-first (contract first) code generation, in your case the code generator would generate something like the 1) server side web service plumming 2) the service interface 3) a config file(s) and 4) in more sophisticated cases an implementation class which implements the service interface The config file contains things like you describe: an endpoint name, and which class is implementing the endpoint, etc A quick web search shows what such a file may look like with jaxws From: http://www.jroller.com/gmazza/entry/creating_a_wsdl_first_web1 (Metro only) sun-jaxws.xml: <?xml version="1.0" encoding="UTF-8"?> <endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"; version="2.0"> <endpoint name="Endpoint_for_DoubleIt" implementation="com.mycompany.webservice.service.DoubleItPortTypeImpl" wsdl="WEB-INF/wsdl/DoubleIt.wsdl" service="{http://www.example.org/contract/DoubleIt}DoubleItService"; port="{http://www.example.org/contract/DoubleIt}DoubleItPort"; url-pattern="/services/doubleit"/> </endpoints> What happens when you edit the sun-jaxws.xml file to add say more endpoint definitions. I'm assuming it can contain more than 1. The code generator you have written knows only how to write this one entry. Lets say you hand add more entries. Next time you run code gen you will overwrite this file and lose your hand entries. Now what i am suggesting has to do with "jelly" and its use as a code generator. In the above case the file generated would look something like: <?xml version="1.0" encoding="UTF-8"?> <endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"; version="2.0"> <endpoint name="Endpoint_for_DoubleIt" implementation="com.mycompany.webservice.service.DoubleItPortTypeImpl" wsdl="WEB-INF/wsdl/DoubleIt.wsdl" service="{http://www.example.org/contract/DoubleIt}DoubleItService"; port="{http://www.example.org/contract/DoubleIt}DoubleItPort"; url-pattern="/services/doubleit"/> <!-- [[100]]--> where any code written here will be maintained through code gen cycles. <!-- [[100]]--> </endpoints> Similarly you can do the same for method bodies, etc. When people make extensive use of code gen not just to gen the wsdl or java files but other framework code, it becomes important for the user to be able to overwrite/workaround generated code as it is not always correct and what the user wants. A simple workaround is to allow them to plugin a different generator for specific files. Anyway using the same example as before but in this context, lets assume the generator generated this file package com.mycompany.webservice.service; import javax.jws.WebService; import org.example.contract.doubleit.DoubleItPortType; @WebService(targetNamespace = "http://www.example.org/contract/DoubleIt";, portName="DoubleItPort", serviceName="DoubleItService", endpointInterface="org.example.contract.doubleit.DoubleItPortType") public class DoubleItPortTypeImpl implements DoubleItPortType { public int doubleIt(int numberToDouble) { return numberToDouble * 2; } } What i suggest is a way for the user to edit the method body and maintain his her changes over code gen cycles. Of course the user has the option to overwrite if wants. Or in a similar example, instead of getting this package com.mycompany.webservice.service; import javax.jws.WebService; import org.example.contract.doubleit.DoubleItPortType; @WebService(targetNamespace = "http://www.example.org/contract/DoubleIt";, portName="DoubleItPort", serviceName="DoubleItService", endpointInterface="org.example.contract.doubleit.DoubleItPortType") public class DoubleItPortTypeImpl implements DoubleItPortType { public int doubleIt(int numberToDouble) { // enter your code here - but watch out it will be overwritten next time you code gen } } You would get this package com.mycompany.webservice.service; import javax.jws.WebService; import org.example.contract.doubleit.DoubleItPortType; @WebService(targetNamespace = "http://www.example.org/contract/DoubleIt";, portName="DoubleItPort", serviceName="DoubleItService", endpointInterface="org.example.contract.doubleit.DoubleItPortType") public class DoubleItPortTypeImpl implements DoubleItPortType { public int doubleIt(int numberToDouble) { // [[100-usercode]] //enter your code here - it will not be overwritten next time you codegen // [[100-usercode]] } } In fact what i described allows the code generator to flag files which have been modified by users potentially alerting them to incompatible changes they may have made. This is commonly referred to as Roundtripping (which is not necessarily a bad thing) and most code generators do not support it. I have presented a way to support simple roundtripping needs in code generators like "jelly". I appreciate your comments and the discussion you've put forth on your thoughts for good design. > Date: Mon, 20 Jul 2009 23:42:27 +0200 > Subject: Re: New Tag - Looking for Comments (Maintain user code during > regeneration of files) > From: rosenberg.l...@googlemail.com > To: user@commons.apache.org > > I must second Ted on this. > Talking about WSDL - consider IDL compilers, they usually generate an > Interface (operations) and a basic BOA (later POA, which stands for > basic/portable object adapter). You have the choice between extending > the BOA or implementing the operations interface and "tie" your impl > to a standart BOA implementation. In both case you never touch > generated code, which gives you an additional advantage of using same > code with different orbs, even the underlying generated code differs > from orb to orb and from version to version. > > Of course, if you are working with generators and edit generated code > for years, and never had any troubles, this may be a good solution for > you, but generally speaking ... there is some room for improvement... > > Btw, I'm also writing code generators for many different purposes for > years, starting with generating a corba or rmi based code distribution > from a java interface, and up to generating a complete struts > application out of two xml files, so I'm absolutely PRO code > generation, as long as it never touched by the developer :-) > > > best regards > Leon > > On Mon, Jul 20, 2009 at 11:25 PM, Ted Dunning<ted.dunn...@gmail.com> wrote: > > What you describe is exceedingly bad practice. > > > > Much better to take the approach that thrift does where the generated code > > is never touched by the developer. The thrift code generator generates > > portable marshaling code and an interface. The programmer implements the > > interface and injects their implementation and a transport into a server at > > server construction time. Clients inject a transport into a client > > interface. > > > > This separates generated code from hand-written code and is a very effective > > approach. Changes to the thrift IDL are easily propagated into Java (or any > > other supported language). Changes to the implementation are preserved with > > no fancy footwork required. > > > > With the approach you describe it is exceedingly difficult to guarantee that > > the developer's code is preserved. > > > > On Mon, Jul 20, 2009 at 12:09 PM, Jason Weinstein < > > jasonweinst...@hotmail.com> wrote: > > > >> On the server side you generate a set of boilerplate implementation classes > >> which include a set of stubs for the web service interfaces. The developer > >> then codes in the implementation for each method. Quite often changes are > >> made to the wsdl and the files need to be regenerated. In this case it > >> would > >> be nice to maintain the existing developers code. > >> > > > > > > > > -- > > Ted Dunning, CTO > > DeepDyve > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > _________________________________________________________________ Windows Live™ Hotmail®: Celebrate the moment with your favorite sports pics. Check it out. http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009&cat=sports
