cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Tooling Proposal [was Re: tooling and service model]
Date Tue, 26 Sep 2006 20:41:24 GMT

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