cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: Tooling Proposal [was Re: tooling and service model]
Date Wed, 27 Sep 2006 03:29:25 GMT
Hi Dan K, I am completely on your side too. :-) I believe we can all agree with followings:

1. The tools module is the framework and should not bind into specific data bindings and frontends
in its core. Data bindings and frondends specific generators are loaded in the runtime as
plugins.  Tools module does not need to depend on databinding and frontend during building.
This feature is already in tools, see DataBindingGenerator.java and FrontEndGeneratorsProfile.java.

2. The plugins for the tools that actually do the generation work should live in the appropriate
place. JAXB code goes in the JAXB databinding. JAX-WS stuff goes into the JAX-WS frontend.

3. We do need to fix those non-jaxws modules that use any JAX-WS specific generated codes.

However, this does not answer two questions below:

1. How to use JAX-WS generated code in JAX-WS froentend test if tools depend on rt?

2. Can we refactor tools to use serviceModel while still keeping tools module as a top level
module? I still believe it does NOT make sense to make tools depend on the whole cxf core
just because it needs serviceModel. 

Can we do sth to serviceModul similiar as what we have done in tools? I.e., make serviceModel
itself a generic model so that anything using serviceModel does not need to depend on specific
databindings and frontend during build time. In the run time, serviceModel acquires specific
binding/frontend capabilities through plugin loader. For example, a JaxwsServiceModelBuilder
that can decorate serviceModel using info from Jax-ws annotations can be loaded by serviceModel
in the runtime. JaxwsServiceModelBuilder should live in Jax-ws frontend.

If this is doable, would it solve all the problems we have? 

Cheers,
Jervis



> -----Original Message-----
> From: Kulp, John Daniel 
> Sent: Wednesday, September 27, 2006 4:41 AM
> To: cxf-dev@incubator.apache.org
> Cc: Liu, Jervis
> Subject: Re: Tooling Proposal [was Re: tooling and service model]
> 
> 
> 
> I have to admit, I'm COMPLETELY on Dan's side on this argument.  
> 
> On Tuesday September 26 2006 2:58 pm, Liu, Jervis wrote:
> > a). testuitls will be a big headache. Using non-generated 
> test artifacts
> > for testing is not only a Big work to do, but also a bad 
> work to do. 
> 
> No, I think using JAX-WS specific generated code in any place 
> other than the 
> JAX-WS frontend and the system tests is bad.   The fact that 
> we do it all 
> over the place is very bad work that we have done.   I would 
> like to see this 
> as an opportunity to fix the junk we've started and prevent it from 
> spreading.
> 
> > Those 
> > pre-written java artifacts (actually in most cases, they 
> still have to be
> > pre-generated using wsdltojava - do you really want to 
> write a SEI class
> > manually?) can potentially be out of sync with their wsdl 
> counter-part, and
> > we might lose the opportunity to catch newly introduced 
> bugs in this area.
> 
> The point is that the unit tests (other than in the JAX-WS 
> module) should NOT 
> be using an SEI class at all.   If it needs that type of thing, it's 
> definitely more of a system test and thus it shouldn't be in 
> the unit tests.    
> The unit tests should be unit tests and be able to mock 
> anything specific 
> that they need.
> 
> 
> > b). Tools, as it stands, should really be a top level 
> module that has
> > minimal dependencies.
> 
> Right.   That's fine.  But the plugins for the tools that 
> actually do a lot of 
> the work should live in the appropriate place.   JAXB code 
> goes in the JAXB 
> databinding.   JAX-WS stuff goes into the JAX-WS frontend.   
> The "tools" 
> module is the framework and plugin loader and such.   It 
> could even work 
> similar to the "core" in that it looks for all the 
> META-INF/cxf-tools.xml 
> files and loads tool plugins as found.
> 
> 
> > I suggest we look further for alternatives, and there is an 
> alternative.
> > Dan D is right to say that we can not simply abstract 
> serviceModel as a top
> > level module because its builder (e.g.. 
> ReflectionServiceFactoryBean) is in
> > frontend. But this can be fixed. The whole idea of 
> ServiceModel, as Dan D
> > said, is having wsdl 1.1, wsdl 2, or classes, they all get 
> converted into
> > the service model. Just think about this in general, I do 
> not see why rt is
> > absolutely required in order to build service model from 
> wsdl or classes.
> > Frontend might need to decorate the serviceModel with 
> frontend specific
> > info, for example, if the input is an Jax-ws SEI, the 
> serviceModel needs to
> > fill in extra Jax-ws meta-data into model using Jax-ws annotations
> > contained in SEI. Having a Jax-ws ServiceModel extension is 
> not that bad, 
> > this does make serviceModel depends on Jax-ws, but not rt core.
> 
> But if the core depends on the service model, then it also 
> depends on JAX-WS.   
> That is exactly what we don't want.    All the JAX-WS 
> specific stuff NEEDS to 
> stay in the JAX-WS frontend.  
> 
> 
> Dan
> 
> 
> 
> 
> > I am not that familiar with this part of code, but based on 
> my initial look
> > I think it is doable to move ServiceModel as a top level 
> modul, then make
> > both tools and rt depends on serviceModel. Sth like below 
> should work:
> >
> > public class ServiceModelBuilder {
> >     public void setWsdlURL(URL wsdlURL) {
> >     }
> >
> >     public void setServiceClass(Class<?> serviceClass) {
> >     }
> >
> >     public ServiceInfo getServiceInfo() {
> >     }
> >
> >     protected void initServiceModel() {
> >         //if wsdl is provided, build serviceModel from WSDL
> >             //if it is wsdl11
> >             //if it is wsdl20
> >
> >         //if no wsdl, but serviceClass, build model from class
> >
> >         //if both wsdl and class are provide, build model from
> >         //wsdl first, then retrieve extra meta-data from class
> >     }
> >
> >     //some other methods allow decorating serviceModel with 
> extra info
> >     //after the model is created.
> > }
> >
> > public class JaxwsServiceModelBuilder {
> >
> >     protected void initServiceModel() {
> >             super.initServiceModel();
> >             //adding extra jaxws info
> >     }
> > }
> >
> > We will run into some problems, for example, when building 
> model from WSDL,
> > we currently have WSDLManager and BindingFactory involved, 
> which are from
> > rt. I hope those problems can be resolved case by case. But 
> I might miss
> > sth completely, so please do shout out if anyone has any 
> insight that knows
> > this approach is completely broken.
> >
> > Cheers,
> > Jervis
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 2006?9?26? 22:24
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Tooling Proposal [was Re: tooling and service model]
> > >
> > >
> > > Hiya,
> > >
> > > James Mao wrote:
> > > > 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.
> > >
> > > > 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
> > >
> > > > Cheers.
> > > > James.
> > > >
> > > > Daniel Kulp ??:
> > > >> The BIGGEST change, and probably the one requiring the
> > >
> > > most work, is
> > >
> > > >> regarding the testutils module.
> > > >> We currently build the testutils modules before the API and RT
> > > >> modules so that tests in those modules can access the
> > >
> > > stuff that is
> > >
> > > >> generated "once" in the testutils.    If the code
> > >
> > > generators are not
> > >
> > > >> available until after rt, ALL the tests in the rt and 
> api packages
> > > >> will need to be updated to use non-generated stuff.
> > >
> > > That will be a
> > >
> > > >> lot of work, although not a bad idea to completely remove
> > >
> > > the jax-ws
> > >
> > > >> dependencies....
> > > >>
> > > >> That's something that DEFINITELY needs to be thought about and
> > > >> addressed in the proposal.
> > > >>
> > > >>
> > > >> Dan
> > > >>
> > > >> On Monday September 25 2006 3:29 pm, Dan Diephouse wrote:
> > > >>> The current dependency path will change as part of the
> > >
> > > proposal. The
> > >
> > > >>> path will then be API <- RT <- Tools. The JAX-WS 
> module would then
> > > >>> contain a default plugin profile for the tools to 
> generate JAX-WS
> > > >>> artifacts. This is why I said we should copy tools to
> > >
> > > tools2: that way
> > >
> > > >>> we can change the dependency path without breaking the
> > >
> > > build for a
> > >
> > > >>> week :-)
> > > >>>
> > > >>> - Dan
> > > >>>
> > > >>> Liu, Jervis wrote:
> > > >>>> Hi Dan, one more question, I am not sure how its going
> > >
> > > to work if
> > >
> > > >>>> tools
> > > >>>> depened on core. Based on our current dependency path,
> > >
> > > tools <- API <-
> > >
> > > >>>> rt, if  we make tools depending on rt, isnt it a
> > >
> > > circular dependency?
> > >
> > > >>>> -----Original Message-----
> > > >>>> From:    Liu, Jervis
> > > >>>> Sent:    Sat 9/23/2006 3:57 PM
> > > >>>> To:    cxf-dev@incubator.apache.org
> > > >>>> Cc:
> > > >>>> Subject:    RE: Tooling Proposal [was Re: tooling and
> > >
> > > service model]
> > >
> > > >>>> Hi Dan, The plan looks good to me. I had a chat with Jim,
we
> > > >>>> estimate the
> > > >>>> item 1 to 5 should be no more than a week's work (or 
> sth around
> > > >>>> that). In
> > > >>>> a previous thread, James and Jim already mentioned 
> that they are
> > > >>>> interested in working on this, I may also want to 
> pick up some
> > > >>>> taskes in
> > > >>>> the area once I get the JAW-WS handler stories done.
> > >
> > > Regarding item 6,
> > >
> > > >>>> the replacement of code model, the work itself should be
> > > >>>> straightforward,
> > > >>>> just a lot of changes involved, so its a bit hard to give
an
> > > >>>> estimate at
> > > >>>> this moment, but we shall know once we are starting
> > >
> > > working on this.
> > >
> > > >>>> BTW, are we still planing anything for next month's
> > >
> > > Apache-con? I
> > >
> > > >>>> am not
> > > >>>> sure how this can be done without being able to publish CXF
> > > >>>> snapshot to
> > > >>>> public repository.
> > > >>>>
> > > >>>> Cheers,
> > > >>>> Jervis
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> -----Original Message-----
> > > >>>> From:    Dan Diephouse [mailto:dan@envoisolutions.com]
> > > >>>> Sent:    9/23/2006 (???) 1:55 ??
> > > >>>> To:    cxf-dev@incubator.apache.org
> > > >>>> Cc:
> > > >>>> Subject:    Re: Tooling Proposal [was Re: tooling and
> > >
> > > service model]
> > >
> > > >>>> I don't know why it would be considered taboo to bring
> > >
> > > up reasons for
> > >
> > > >>>> not refactoring the tools like that. There are perfectly
> > >
> > > valid reasons
> > >
> > > >>>> to want to avoid doing this - like having limited
> > >
> > > resources or just
> > >
> > > >>>> not
> > > >>>> caring about the feature or having a schedule the
> > >
> > > project is trying to
> > >
> > > >>>> adhere to. I think its best to bring them up and 
> discuss them.
> > > >>>>
> > > >>>> With that said, I do think there are significant 
> benefits from a
> > > >>>> longer
> > > >>>> term point of view to refactor the tooling like I've
> > >
> > > proposed - like
> > >
> > > >>>> reduction of code[1] and extensibility. I also don't
> > >
> > > think it would be
> > >
> > > >>>> that hard for someone to do. I am even willing to work
> > >
> > > on it myself...
> > >
> > > >>>> Cheers,
> > > >>>> - Dan
> > > >>>>
> > > >>>> 1. While XFire tooling doesn't have quite as many
> > >
> > > features as the
> > >
> > > >>>> Celtix
> > > >>>> tooling, it does come in at 2K lines of code, compared
> > >
> > > to 20K with
> > >
> > > >>>> Celtix. Thats a significant difference that I dont' 
> think can be
> > > >>>> accounted for by features alone.
> > > >>>>
> > > >>>> Bacon, Stephanos wrote:
> > > >>>>> So I'm guessing that by bringing iona's rationale for
not
> > > >>>>> refactoring the
> > > >>>>> tools, you probably broke some kind of apache taboo.
> > > >>>>>
> > > >>>>> I get the impression that in Apache the normal kind of
> > >
> > > "why waste
> > >
> > > >>>>> time
> > > >>>>> rewriting something that works" kind of argument doeant
> > >
> > > hold water
> > >
> > > >>>>> because there is no concept of schedule.  If the result
> > >
> > > is cleaner
> > >
> > > >>>>> code,
> > > >>>>> then there is a good arument for doing it.
> > > >>>>>
> > > >>>>> I suspect you'll get flamed :-)
> > > >>>>>
> > > >>>>> -steph
> > > >>>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: Lin, Bozhong
> > > >>>>> To: cxf-dev@incubator.apache.org 
> <cxf-dev@incubator.apache.org>
> > > >>>>> Sent: Fri Sep 22 02:22:39 2006
> > > >>>>> Subject: RE: Tooling Proposal [was Re: tooling and
> > >
> > > service model]
> > >
> > > >>>>> I also agree that it makes a lot of sense to leverage
> > >
> > > current Celtix
> > >
> > > >>>>> tooling implementation and to do any refactoring only
> > >
> > > for meeting new
> > >
> > > >>>>> requirements. These tools are fundamental to
> > >
> > > application users and
> > >
> > > >>>>> IONA
> > > >>>>> has spent tremendous effort in the past year to
> > >
> > > maintain and tune the
> > >
> > > >>>>> Celtix tools, making sure that it passes all kinds of
> > >
> > > complex WSDL
> > >
> > > >>>>> and
> > > >>>>> Schema, including many issues reported by Celtix users.
[1].
> > > >>>>>
> > > >>>>> Cheers,
> > > >>>>> Bo
> > > >>>>>
> > > >>>>> [1]
> > >
> > > 
> http://forge.objectweb.org/tracker/index.php?group_id=192&atid=350241
> > >
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > >>>>>> Sent: Thursday, September 21, 2006 10:05 PM
> > > >>>>>> To: cxf-dev@incubator.apache.org
> > > >>>>>> Subject: Tooling Proposal [was Re: tooling and 
> service model]
> > > >>>>>>
> > > >>>>>>> 2. If we are to write a new tool from scratch,

> what are the
> > > >>>>>>
> > > >>>>>> feature list we have in mind, and how long do we expect
to
> > > >>>>>> reach this feature list.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> This is not what I'm proposing at all. I too feel
this
> > >
> > > would be
> > >
> > > >>>>>> silly.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Here is what I'm proposing:
> > > >>>>>>
> > > >>>>>>  1. Rewrite the generation part of the tooling to
use
> > >
> > > the Service
> > >
> > > >>>>>>     model instead of the wsdl. This would involve
using the
> > > >>>>>>     ServiceFactory to build a ServiceModel and then
writing
> > > >>>>>> out class
> > > >>>>>>     files from there.
> > > >>>>>>  2. Have tools depend on the core for the service
> > >
> > > model and put each
> > >
> > > >>>>>>     frontend's generation plugins in the frontend
> > >
> > > themselves. Moving
> > >
> > > >>>>>>     the service model to a separate module or common
> > > >>>>>> doesn't make any
> > > >>>>>>     sense whatsoever because we still need to depend
on the
> > > >>>>>>     ServiceFactorys which are in the frontend, so
> > >
> > > there will be a
> > >
> > > >>>>>>     dependency on core.
> > > >>>>>>  3. Add SOAP 1.2 support to the SoapBindingFactory
> > > >>>>>>  4. Add WSDL 2 support to the core 
> (WSDL2ServiceBuilder, etc)
> > > >>>>>>  5. Do this refactoring in a tools2 module. While
I
> > >
> > > don't anticipate
> > >
> > > >>>>>>     that this is a lot of work, this will help us
get
> > >
> > > around the
> > >
> > > >>>>>>     circular dependency issues and allow us to temporarily
> > > >>>>>> break a few
> > > >>>>>>     things.
> > > >>>>>>  6. Extra credit: use the CodeModel from Sun instead
> > >
> > > of our own.
> > >
> > > >>>>>>     Having our own creates unnecessary work and it
is also
> > > >>>>>> too tied to
> > > >>>>>>     JAX-WS to be useful outside of it. If you look
at
> > >
> > > JAXB, a whole
> > >
> > > >>>>>>     host of plugins have arose partly because they
use this
> > > >>>>>> code model
> > > >>>>>>     that anyone can plug into. As its really not a
lot of
> > > >>>>>> work to use
> > > >>>>>>     it instead of our, I think we should.
> > > >>>>>>
> > > >>>>>> I think we can do this relatively easily and its 
> not as big a
> > > >>>>>> deal as
> > > >>>>>> people are making it out to be. The Celtix tooling
is good,
> > > >>>>>> and I don't
> > > >>>>>> want to rewrite it all, I merely want to evolve it.
> > > >>>>>>
> > > >>>>>> Cheers,
> > > >>>>>> - Dan
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Dan Diephouse
> > > >>>>>> (616) 971-2053
> > > >>>>>> Envoi Solutions LLC
> > > >>>>>> http://netzooid.com
> > >
> > > --
> > > Dan Diephouse
> > > (616) 971-2053
> > > Envoi Solutions LLC
> > > http://netzooid.com
> 
> -- 
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> daniel.kulp@iona.com
> 

Mime
View raw message