Thanks Dan, I've created https://issues.apache.org/jira/browse/CXF-4777 and will be committing a patch soon.
Cheers Alessio On 01/24/2013 03:45 PM, Daniel Kulp wrote: > > Chatted with Alessio a bit about this on IRC just to get a handle on what > this means. It's not really an area I've dug too deep into before. > However, I did want to check to see what the full use case was and > requirements and what the java compiler restrictions are, mostly so if we > want to add support for having the maven-codegen-plugin handle the compiling > when running within m2e, we could leverage the same solution. > > In anycase, I think his first solution below is the simplest and cleanest. > The compiler class will probably have to have some minor refactoring to make > some of the methods protected instead of private and have getter methods and > such for various things, but it should then allow future m2e changes to be > leveraged as well. > > Dan > > > > On Jan 24, 2013, at 8:06 AM, Alessio Soldano <[email protected]> wrote: > >> Hi, >> I need to control the way generated sources are compiled when running >> WSDLToJava. The reason for that comes from the need of running the tool >> in-container on JBoss AS 7, which has a full modular classloading and >> does not rely on java.endorsed.dirs env prop for overriding JAXWS api in >> JDK (6) and always use JAXWS 2.2 apis. I've managed to do that by using >> the Java Compiler API to write a small extension of >> javax.tools.ForwardingJavaFileManager that I can successfully pass to >> the CompilationTask which is called in >> org.apache.cxf.common.util.Compiler::useJava6Compiler(String[] file) . >> My JavaFileManager properly controls the way the compiler retrieve >> classes' bytecode so that JAXWS stuff is loaded from JBoss modules >> instead of directly from the JDK boot classpath. >> >> Now, I'm looking for a proper way to extend the CXF WSDLToJava tool for >> configuring the java6 compiler, iow allowing me to pass in the >> JavaFileManager mentioned above; I currently see 2 options: >> 1) allow extending org.apache.cxf.common.util.Compiler class and setting >> an instance of it into the ToolContext that's passed to WSDL2Java; >> org.apache.cxf.tools.common.ClassUtils would check for provided instance >> of Compiler and use that if available, otherwise the current Compiler >> will still be created and used; I would then provide into the >> ToolContext my extension of cxf Compiler that uses my JavaFileManager >> 2) pass a ForwardingJavaFileManager builder (interface to be defined) >> into the ToolContext, add a member into Compiler for storing that and >> let org.apache.cxf.tools.common.ClassUtils set it; the builder will then >> be used to create the ForwardingJavaFileManager instance given the >> StandardJavaFileManager computed in Compiler::useJava6Compiler(...) . >> >> Do you see any other option / have any suggestion? I would likely go for >> 1 if nobody has preferences. >> >> Thanks >> Alessio >> >> -- >> Alessio Soldano >> Web Service Lead, JBoss > -- Alessio Soldano Web Service Lead, JBoss
