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 [EMAIL PROTECTED] http://www.dankulp.com/blog
