cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kramer <>
Subject Re: Systests build problem
Date Tue, 25 Sep 2007 04:25:15 GMT
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.

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 :
>>>>>> orderPizza(
>>>>>> OrderPizzaType, in
>>>>>> org.apache.cxf.
>>>>>> pizza.Pizza cannot be applied to
>>>>>> (
>>>>>> trunk/systests have a generated folder where
>>>>>> is located, it has a method :
>>>>>> orderPizza(,org.apache.c
>>>>>> xf .pizza.types.CallerIDHeaderType)
>>>>>> here's code in the :
>>>>>> 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

View raw message