You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Alessio Soldano <as...@redhat.com> on 2013/01/24 14:06:37 UTC
Controlling generated source compilation in WSDLToJava
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
Re: Controlling generated source compilation in WSDLToJava
Posted by Alessio Soldano <as...@redhat.com>.
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 <as...@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
>
--
Alessio Soldano
Web Service Lead, JBoss
Re: Controlling generated source compilation in WSDLToJava
Posted by Daniel Kulp <dk...@apache.org>.
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 <as...@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