cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: Tooling Proposal [was Re: tooling and service model]
Date Wed, 27 Sep 2006 04:56:16 GMT
Hi Dan,
>> I still think that Tools should be an independent module, it should 
>> not after rt, the benefit of independence is that you can use tools 
>> any time you want.
>> And ideally the tools can be split as an outside project, so when 
>> someone want to use just tools, what they need is just include the 
>> cxf-tools.jar and cxf-common.jar in their classpath,
>> there will no cxf-rt.jar or others will be needed, one thing i can 
>> imagine is that if you want to use tools in a WebService GUI, i think 
>> STP project already did so, is you include just two jars not a lot.
>>
> I really disagree. There is no way to make it a completely separate 
> module unless we have duplicate code which does wsdl/jax-ws processing 
> in the tools. This causes more maintenance and more bugs in the long 
> run, so I'm pretty -1 against that. And, as I mentioned before, this 
> isn't that much more code to include. We could even put together a 
> bundled jar if people are really concerned about too many jars. I also 
> don't like the current approach because the jax-ws generation isn't 
> associated with the jax-ws module in any way, and it seems to me thats 
> where the generators should be.
>
I think the position of the tools is correct, we should not change this 
position.
The RT could/may depend on tools, but tools should not depend on RT, 
that does not make any sense.

Tools will/should process jax-ws stuff, consider the customization and 
naming collision.

And we already have a good start on that, we have jax-ws profile to 
handle all the jax-ws stuff in the tools and your may add more profiles 
if you want, it could be a plugin style design. and i think all the 
profiles should/could be shared by the tools and rt, so the code 
generated by the jax-ws profile can go through the jax-ws rt. just a 
thought. That profile stuff may need redesign to fit the needs.

You can bundle all the jars into one jar for people just use tools, but 
that also make non-sense. why i need to download all the jars, when i 
just need three of them?

So overall, my point is that tools should not depends on RT, that does 
not make any sense.

I'm not going to
>> About ServiceModel, I think it should also be an independent module, 
>> and for tools or rt, i think it'll be great if we have an plug-able 
>> api, so the tools and rt are not directly reference ServiceModel, and 
>> if you want to replace the ServiceModel with other Model(Wooden) will 
>> be possible.
>> For the builder which build servicemodel should stay in servicemodel, 
>> just like Wsdl4j, they provider a model and also provide a builder.
>
> That misses the whole point of the service model. The point of the 
> service model is that wsdl 1.1, wsdl 2, and classes all get converted 
> into the service model and then artifacts are generated from that.
>
> - Dan
No, You missed my point, my point is that the ServiceModel should/could 
also be an independent module, we should have a decoupled design in our 
mind,
Currently it's tightly coupled with rt, which i don't think it's a good 
design. To support wsdl1.1, wsdl2, classes all get converted into the 
ServiceModel , doesn't mean it have to stay in RT, if there are some 
dependence, we could/should also move that part out of rt.
Ideally you have builder api like that:

ServiceModel build(URL url)  // Use default profile JAX-WS
ServiceModel build(Class cls)
ServiceModel build(Definition def) // wsdl 1.1
ServiceModel build(Definition??? def) // wsdl 1.2
ServiceModel build(URL url, Profile profile)
...

The whole module could be shared by both the Tools and RT

So overall, my point is we could split the ServiceModel from RT.

Then, we have ServiceModel and Tools above the TestUtils/API/RT/..., i 
think all the problems solved.


Cheers,
James.

Mime
View raw message