cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: Systests build problem
Date Tue, 25 Sep 2007 03:31:43 GMT
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
>>>>>           
>
>
>
>   

Mime
View raw message