hi, and thanks for the prompt resonse! I generally agree with you, although I think you misunderstood my objective in this case. I am not creating multiple web services, just the one for now, however these classes are used in other non-web service capacities. sometimes exposed as spring rmi services, and sometimes not a serialised service at all. I have no idea how these classes may be used in the future, nor what transports may carry them, my main point was that these classes are often used where cxf is just irrelevant, so adding the annotations and the associated dependencies just seems mad. Should I someday want to support more web services, It would be nice to be able to support both xfire and cxf and anything else I need, and to that end, endlessly modifying annotations in source code doesn't sit well with me. I much prefer to be able to take an interface and implementation and say, now be a serviceTypeX without ever recompiling, it means my clients can do the same thing with my apps too.
at any rate you indicated that you think I can use " simple front end together with the aegis binding". Examples seem a bit thin on the ground, but thanks for pointing me in a promising direction. Cheers Jason. Quoting Christian Schneider <[EMAIL PROTECTED]>: > Hi Jason, > > if you are planning to create a webservice for several other projects I > would recommend doing contract first. If you share your actual java > classes between several projects you will get into trouble sooner or > later. We have tried this aproach in a SOA project and had problems with > this aproach. > > You should always keep in mind that the soap xml that the service > framework creates from the same set of java classes may differ between > frameworks and beween different versions of the same framework. We had > the problem when we changed from xfire to cxf. The same classes produced > slighty different xml on the wire. So we could neither introduce cxf on > the clients nor on the server spearately. We would have to exchange the > version on all servers and clients at the same time. As you can imagine > this is not prossible in any larger setup. > > To answer your question. I think you can live without annotations when > you use the simple front end together with the aegis binding. But the > problems I described above will sooner or later hit you. > > There is only one use case where I favour true code first: If you are > simply doing remoting betwen a client and a server that belong to the > same release unit. In this case you can make sure that when you roll out > a release you will do so on client and server at the same time. > > I have written an article on how to do contract first and still keep > much of the advantages of code first: > http://cwiki.apache.org/CXF20DOC/defining-contract-first-webservices-with-wsdl-generation-from-java.html > > Greetings > > Christian > > [EMAIL PROTECTED] schrieb: > > Hi, I am using java 1.6 in a mule 2.x project, and need soap support. > > I'd like to use cxf, but it seems that its an 'annotations only' technology > - > > (is this true?) > > The classes I am using are shared amongst other projects and I do not want > to > > annotate them unnecessarily, I'd MUCH prefer to simply configure with an > > external xml config file if its an option. I'd also like not to have to > create > > annotated facades just to support cxf. > > is this possible? > > > > Thanks > > Jason > > > > > > > -- > > Christian Schneider > --- > http://www.liquid-reality.de > >
