cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Systests build problem
Date Tue, 25 Sep 2007 18:33:34 GMT
On Tuesday 25 September 2007, Adam Kramer wrote:
> Might want to put the resource cleanup (bus shutdown) in a runtime
> shutdown hook if jvm exits and interrupts are a valid concern for
> program exits.

In this case, I'm not too concerned about program exits right now.   What 
I'm more concerned about is multi-module builds.   If one module uses 
the plugin and creates a bus, I want to make sure that is shutdown so if 
another module uses the plugin, a new bus is created with the proper 
dependencies and such for that module.   I was running into situations 
where one module used it, but didn't have a "SOAP" dependency so didn't 
do any of the soap extended header stuff.    The next module wanted it, 
but was using the bus from the first one so it didn't work.    


Dan


>
> James Mao wrote:
> > Awesome
> >
> >> I've gone ahead an implemented much of this for the wsdl2java Mojo.
> >> It now uses the project dependencies to create a URLClassloader and
> >> sets that into the Thread context classloader.   I've updated a
> >> bunch of code in CXF to properly use the context classloader for
> >> loading classes, grabbing resources, etc....
> >> The result is that you don't need to put the soap binding as a
> >> plugin dependency anymore.   If the project itself depends on it,
> >> (transitively or directly) it will get loaded and the extended
> >> header processing then works.  I've updated the systests to go
> >> ahead and turn on the soap header processing for that one wsdl.
> >> The other things this now allows is to use things like
> >> "classpath:blah.wsdl" entries in the wsdls, etc....
> >> Another note: I'm making sure (in a finally) that the bus that the
> >> plugin creates is properly shutdown.   That's important.
> >> Dan
> >>
> >> On Thursday 06 September 2007, Daniel Kulp wrote:
> >>> I think the proper fix would be to update the wsdl2java (and
> >>> java2wsdl) maven plugin to use the project dependencies itself in
> >>> addition to it's own plugin dependencies.   We already buildup a
> >>> "classpath" in the tools for the tool to look up the java classes
> >>> for java2wsdl.   We should just go ahead and use it for everything
> >>> including the "plugins".
> >>>
> >>> Probably the best option would be to change the plugin to create a
> >>> full classpath (project + plugin jars/deps) and fork the code
> >>> gen/wsdl gen. That would avoid some memory issues in Maven as
> >>> well.
> >>>
> >>> Dan
> >>>
> >>> On Thursday 06 September 2007, James Mao wrote:
> >>>> Hi Sergey,
> >>>>
> >>>> I struggled a day, and still can not figure out how to solve it,
> >>>> I've upgraded to mvn 2.0.7, but still can not solve the problem.
> >>>>
> >>>> In systests, if you print the classpath, you will find the jar
> >>>> cxf-rt-bindings-soap-2.1-incubator-SNAPSHOT.jar  is in your
> >>>> classpath,
> >>>>
> >>>> However, if you build from the top level, in the classpath it
> >>>> include the
> >>>> C:\src\java\apache\cxf\rt\bindings\soap\target\classes
> >>>>
> >>>> And for some unknown reason, the code-gen plugin just can not
> >>>> load the soap binding even though you defined the soap in the
> >>>> dependencies, very strange.
> >>>>
> >>>> I felt that this's a bug in maven.
> >>>>
> >>>> There's one solution to solve this problem, that's define the
> >>>> soap binding in the code-gen plugin,
> >>>> but then we'll have the cyclic dependencies:
> >>>> soap->jaxb->testutil->codegen->soap
> >>>> To solve the cyclic dependency, we have to move the tests to
> >>>> systests module, or create a new test module...
> >>>>
> >>>> Any good suggestions?
> >>>>
> >>>> James
> >>>>
> >>>>> If you build from top level, you'll not have the problem,  the
> >>>>> maven code-gen plugin , just can not load the soap module,
> >>>>> I'll take look at it tomorrow, maybe disable the test, and will
> >>>>> re-enable it later, if we resolve the dependencies.
> >>>>>
> >>>>> Cheers,
> >>>>> James
> >>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> I can not build CXF on Windows. The failure occurs in the
> >>>>>> systests module :
> >>>>>>
> >>>>>> HeaderClientServerTest.java:[62,41]
> >>>>>> orderPizza(org.apache.cxf.pizza.types.
> >>>>>> OrderPizzaType,org.apache.cxf.pizza.types.CallerIDHeaderType)
> >>>>>> in org.apache.cxf.
> >>>>>> pizza.Pizza cannot be applied to
> >>>>>> (org.apache.cxf.pizza.types.OrderPizzaType)
> >>>>>>
> >>>>>> trunk/systests have a generated folder where
> >>>>>> org.apache.cxf.pizza.Pizza is located, it has a method :
> >>>>>>
> >>>>>> orderPizza(org.apache.cxf.pizza.types.OrderPizzaType,org.apache
> >>>>>>.c xf .pizza.types.CallerIDHeaderType)
> >>>>>>
> >>>>>>
> >>>>>> here's code in the HeaderClientServerTest.java :
> >>>>>>
> >>>>>> OrderPizzaResponseType res = port.orderPizza(req);
> >>>>>> System.out.println(res);
> >>>>>>
> >>>>>> //OrderPizzaResponseType res =  port.orderPizza(req, header);
> >>>>>> //assertEquals(208, res.getMinutesUntilReady());
> >>>>>>
> >>>>>> The test is basically disabled and it also doesn't compile.
> >>>>>> Uncommenting the above two lines makes the test compile and
> >>>>>> pass. Not sure what the story with test is, but as far as the
> >>>>>> compliation is concerned I reckon I'm picking up some stale
> >>>>>> module which affects the wsdl generation ?
> >>>>>>
> >>>>>> can someone please advise on how to deal with issues like this
> >>>>>> one ? I've removed a cxf directory in the local repo, created
a
> >>>>>> new snapshot, no luck....
> >>>>>>
> >>>>>> Thanks, Sergey
> >>>>>>
> >>>>>> ----------------------------
> >>>>>> IONA Technologies PLC (registered in Ireland)
> >>>>>> Registered Number: 171387
> >>>>>> Registered Address: The IONA Building, Shelbourne Road, Dublin
> >>>>>> 4, Ireland



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message