commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Weinstein <jasonweinst...@hotmail.com>
Subject RE: New Tag - Looking for Comments (Maintain user code during regeneration of files)
Date Mon, 20 Jul 2009 23:23:26 GMT

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.leon@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.dunning@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 <
> > jasonweinstein@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message