cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Controlling generated source compilation in WSDLToJava
Date Thu, 24 Jan 2013 14:45:58 GMT

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 <asoldano@redhat.com> 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

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message