Re: Tooling Proposal [was Re: tooling and service model]

Tue, 26 Sep 2006 22:28:39 -0700 

Hi Dan,
I think we should define the frontend now, and it also should reflect to the code, do we need a frontend api, 
How many frontend do we have , and will we have?
Currently i know the JAX-WS and javascript are frontends, i guess there are more. maybe have a pojo frontend? 
We'd better define those in advance.
I'm think of having a profile api (or perspective), and all the tools and rt will share this profile. i don't know if the idea is as same as the frontend.
My feeling is that if the tools need to reuse the servicemodel (which now is in api, the builders in rt), we have to move the tools under the rt(which i think is not a good idea though), because we have to always keep the frontend in front. So why not move the frontend before the tools? let the frontend be in front of all. 

Will have a lot of work though.

Cheers,
James.

Daniel Kulp 写道:
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:[EMAIL PROTECTED]
Sent: 2006?9?26? 22:24
To: [email protected]
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:    [email protected]
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:[EMAIL PROTECTED]
Sent:    9/23/2006 (???) 1:55 ??
To:    [email protected]
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: [email protected] <[email protected]>
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:[EMAIL PROTECTED]
Sent: Thursday, September 21, 2006 10:05 PM
To: [email protected]
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

Reply via email to