You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Rao, Sameer V" <SR...@amfam.com> on 2009/03/24 16:33:04 UTC
wsdl2java<-->XJC "Options" being passed to SchemaCompiler does not seem to have effect
I was looking at the JAXBDataBinding class
(cxf-tools-wsdlto-databinding-jaxb) and was not sure of the following-
1. We are building Options used by SchemaCompiler and calling its
parseArgument(). However, values passed through that argument list don't
seem to take any effect? Example the following-
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/resources/MyService.wsdl</wsdl>
<extraargs>
<extraarg>-xjc -verbose, -p
org.myapps.entities</extraarg>
</extraargs>
</wsdlOption>
</wsdlOptions>
Looking at the code in JAXBDataBinding, the call to
opts.parseArguments(args) should pass the above values to XJC and they
should have the intended effect. But I don't see it having.
2. In JAXBDataBinding we pass the schemas to XJC by the call-
addSchemas(opts, schemaCompiler, schemaLists); i.e. pass the schema
list. Would we gain any benefit by passing the WSDL itself? I read the
XJC accepts a WSDL with a -WSDL option?
Re: wsdl2java<-->XJC "Options" being passed to SchemaCompiler does
not seem to have effect
Posted by Benson Margulies <bi...@gmail.com>.
Further complexity is the binding files. Binding files have schemaLocation
attributes. JAXB does not resolve those. We can pre-resolve those, in fact,
my not-yet-checked in attempt does so.
My view of the big picture is this. We currently, precariously, arrange
consistent behavior from wsdl4j reading WSDL and JAXB. If you unleash jaxb
on the full wsdl, who knows what will happen?
On Thu, Mar 26, 2009 at 3:42 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Tue March 24 2009 11:33:04 am Rao, Sameer V wrote:
> > I was looking at the JAXBDataBinding class
> > (cxf-tools-wsdlto-databinding-jaxb) and was not sure of the following-
> >
> > 1. We are building Options used by SchemaCompiler and calling its
> > parseArgument(). However, values passed through that argument list don't
> > seem to take any effect? Example the following-
> >
> > <wsdlOptions>
> > <wsdlOption>
> >
> > <wsdl>${basedir}/src/main/resources/MyService.wsdl</wsdl>
> > <extraargs>
> >
> > <extraarg>-xjc -verbose, -p
> > org.myapps.entities</extraarg>
> > </extraargs>
> > </wsdlOption>
> > </wsdlOptions>
> >
> > Looking at the code in JAXBDataBinding, the call to
> > opts.parseArguments(args) should pass the above values to XJC and they
> > should have the intended effect. But I don't see it having.
>
> I THINK it should be:
>
> <extraarg>-xjc-verbose,-p,org.myapps.entities</extraarg>
>
> Basically, with what you have, I think the -verbose and -p flags and stuff
> are
> being passed into our stuff, not just xjc.
>
> > 2. In JAXBDataBinding we pass the schemas to XJC by the call-
> > addSchemas(opts, schemaCompiler, schemaLists); i.e. pass the schema
> > list. Would we gain any benefit by passing the WSDL itself? I read the
> > XJC accepts a WSDL with a -WSDL option?
>
> This is something Benson has been looking into a bit. There are pluses
> and
> minuses to both ways.
>
> Basically, by the time we get here, we have already resolved the WSDL and
> all
> it's imports and such so that we could start building up the JAX-WS parts
> of
> the model. Thus, the wsdl and schemas have already been downloaded and
> parsed. If we pass the wsdl (either as a URL or a stream or even a DOM),
> JAXB will call back out to resolvers to re-resolve everything. Thus,
> we'll
> need to write resolvers and such to call back through our stuff to get
> things.
> JAXB also then expects those to be streams which it would re-XML parse.
> Basically, it would take longer as everything gets downloaded and parsed
> twice. Once for JAX-WS processing, once for JAXB.
>
> HOWEVER, passing the steams and stuff in WOULD allow line numbers in the
> JAXB
> errors. That's a good thing. Also, we wouldn't need to hold onto the
> DOMs
> so once JAXB processing is done, they could be discarded.
>
> So, pluses and minuses. What we have works "OK". We're just trying
> investigate to see if anything else could be done to make it better.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: wsdl2java<-->XJC "Options" being passed to SchemaCompiler does not seem to have effect
Posted by Daniel Kulp <dk...@apache.org>.
On Tue March 24 2009 11:33:04 am Rao, Sameer V wrote:
> I was looking at the JAXBDataBinding class
> (cxf-tools-wsdlto-databinding-jaxb) and was not sure of the following-
>
> 1. We are building Options used by SchemaCompiler and calling its
> parseArgument(). However, values passed through that argument list don't
> seem to take any effect? Example the following-
>
> <wsdlOptions>
> <wsdlOption>
>
> <wsdl>${basedir}/src/main/resources/MyService.wsdl</wsdl>
> <extraargs>
>
> <extraarg>-xjc -verbose, -p
> org.myapps.entities</extraarg>
> </extraargs>
> </wsdlOption>
> </wsdlOptions>
>
> Looking at the code in JAXBDataBinding, the call to
> opts.parseArguments(args) should pass the above values to XJC and they
> should have the intended effect. But I don't see it having.
I THINK it should be:
<extraarg>-xjc-verbose,-p,org.myapps.entities</extraarg>
Basically, with what you have, I think the -verbose and -p flags and stuff are
being passed into our stuff, not just xjc.
> 2. In JAXBDataBinding we pass the schemas to XJC by the call-
> addSchemas(opts, schemaCompiler, schemaLists); i.e. pass the schema
> list. Would we gain any benefit by passing the WSDL itself? I read the
> XJC accepts a WSDL with a -WSDL option?
This is something Benson has been looking into a bit. There are pluses and
minuses to both ways.
Basically, by the time we get here, we have already resolved the WSDL and all
it's imports and such so that we could start building up the JAX-WS parts of
the model. Thus, the wsdl and schemas have already been downloaded and
parsed. If we pass the wsdl (either as a URL or a stream or even a DOM),
JAXB will call back out to resolvers to re-resolve everything. Thus, we'll
need to write resolvers and such to call back through our stuff to get things.
JAXB also then expects those to be streams which it would re-XML parse.
Basically, it would take longer as everything gets downloaded and parsed
twice. Once for JAX-WS processing, once for JAXB.
HOWEVER, passing the steams and stuff in WOULD allow line numbers in the JAXB
errors. That's a good thing. Also, we wouldn't need to hold onto the DOMs
so once JAXB processing is done, they could be discarded.
So, pluses and minuses. What we have works "OK". We're just trying
investigate to see if anything else could be done to make it better.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog