You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by James Mao <ja...@iona.com> on 2006/12/20 10:31:51 UTC
[Tools] About wsdl extensions
Hi,
I'm trying to reuse the wsdl extension mechanism used in
rt/core/WSDLManagerImpl for tools,
But i found that it has the dependency problem, to resolve the
dependency problem,
one solution is to move the extensions.xml and schemas to metacode module.
For example, to support XMLBinding, we could move the xml-binding.xsd,
xml-binding.xjb and extensions.xml to metacode.
Later when we support new binding or new transport, we could put xsd and
extensions file into metacode
I don't know if there is any better solution?
Thanks,
James.
Re: [Tools] About wsdl extensions
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi James,
On 12/20/06, James Mao <ja...@iona.com> wrote:
>
> Hi Dan,
>
> From What I can see now, what we really need is just the extension
> schema and the extensions.xml (also the generated code from the schema
> for wsdl11 extensibility elements), nothing else.
> tools2 depends on whole soap & xml and jms transport will work, but i
> don't think it's a better solution.
>
> Previously tools has it's own serializer/deserializer which registered
> into the ExtensionRegistry, the idea basically is reuse the registration
> we already have in WSDLManagerImpl.
>
> The problems of tools2 depends on soap, xml, jms are:
> * if we have another binding or transport, we have to modify the tools
> dependency
Not true. The tools should reuse the discovery mechanism inside CXF, so if
there is a new binding added tools should be able to pick it up as well.
* if we want to package just tools, we have to package whole bindings
> and transports from which we only use schema and extensions.xml
So what? It seems fitting to me that we have to depend on cxf-jms to get JMS
support with our WSDL, so I don't see a problem here.
The problems of moving schemas and extensions.xml into top level meta
> module is:
> * separate the wsdl extensions of bindings and transport into a
> different module, if there is new binding or transport the schema has to
> defined in the meta module.
-1
Another solution i have is the schema and extension still stay in
> bindings and transports module, but we split the module into two
> submodule.
> One is core sub module another is meta module which only include the
> wsdl11 extension schema (later wsdl20 extension schema) and
> extensions.xml.
> Take the xml module as example, we split the xml binding module into
> xml-core submodule and xml-meta submodule, and move the schema and
> extensions.xml into xml-meta submodule
The benefit of this approach is that all the binding/transport specific
> stuff still stay in there own module, and the tools can depends on
> binding-meta submodule not the whole binding module.
> The problem of this approach is that we introduce more modules, means
> there are more jars introduced.
-1 - too much complexity.
So there are actually three solutions, they both have pros and cons. i
> myself prefer the last one.
I much prefer just relying on the soap/xml/http/jms modules at runtime
during generation.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [Tools] About wsdl extensions
Posted by James Mao <ja...@iona.com>.
Hi Dan,
From What I can see now, what we really need is just the extension
schema and the extensions.xml (also the generated code from the schema
for wsdl11 extensibility elements), nothing else.
tools2 depends on whole soap & xml and jms transport will work, but i
don't think it's a better solution.
Previously tools has it's own serializer/deserializer which registered
into the ExtensionRegistry, the idea basically is reuse the registration
we already have in WSDLManagerImpl.
The problems of tools2 depends on soap, xml, jms are:
* if we have another binding or transport, we have to modify the tools
dependency
* if we want to package just tools, we have to package whole bindings
and transports from which we only use schema and extensions.xml
The problems of moving schemas and extensions.xml into top level meta
module is:
* separate the wsdl extensions of bindings and transport into a
different module, if there is new binding or transport the schema has to
defined in the meta module.
Another solution i have is the schema and extension still stay in
bindings and transports module, but we split the module into two submodule.
One is core sub module another is meta module which only include the
wsdl11 extension schema (later wsdl20 extension schema) and
extensions.xml.
Take the xml module as example, we split the xml binding module into
xml-core submodule and xml-meta submodule, and move the schema and
extensions.xml into xml-meta submodule
The benefit of this approach is that all the binding/transport specific
stuff still stay in there own module, and the tools can depends on
binding-meta submodule not the whole binding module.
The problem of this approach is that we introduce more modules, means
there are more jars introduced.
So there are actually three solutions, they both have pros and cons. i
myself prefer the last one.
Cheers,
James.
> Hi James,
>
> I'm not sure I understand. tools2 will have to depend on the soap & xml
> modules. Why is this an issue?
>
> Regards,
>
> - Dan
>
> On 12/20/06, James Mao <ja...@iona.com> wrote:
>>
>> and also need to mention is that the xml-binding.xsd is wsdl11 specific,
>> i don't know how we handle the wsld11 extensibility and wsdl20
>> extensibility? any plan?
>>
>> Another solution I have is to move the xsd and extensions.xml to tools2
>> temporarily.
>> > Hi,
>> >
>> > I'm trying to reuse the wsdl extension mechanism used in
>> > rt/core/WSDLManagerImpl for tools,
>> > But i found that it has the dependency problem, to resolve the
>> > dependency problem,
>> >
>> > one solution is to move the extensions.xml and schemas to metacode
>> > module.
>> > For example, to support XMLBinding, we could move the xml-binding.xsd,
>> > xml-binding.xjb and extensions.xml to metacode.
>> >
>> > Later when we support new binding or new transport, we could put xsd
>> > and extensions file into metacode
>> >
>> > I don't know if there is any better solution?
>> >
>> > Thanks,
>> > James.
>> >
>> >
>>
>>
>
>
Re: [Tools] About wsdl extensions
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi James,
I'm not sure I understand. tools2 will have to depend on the soap & xml
modules. Why is this an issue?
Regards,
- Dan
On 12/20/06, James Mao <ja...@iona.com> wrote:
>
> and also need to mention is that the xml-binding.xsd is wsdl11 specific,
> i don't know how we handle the wsld11 extensibility and wsdl20
> extensibility? any plan?
>
> Another solution I have is to move the xsd and extensions.xml to tools2
> temporarily.
> > Hi,
> >
> > I'm trying to reuse the wsdl extension mechanism used in
> > rt/core/WSDLManagerImpl for tools,
> > But i found that it has the dependency problem, to resolve the
> > dependency problem,
> >
> > one solution is to move the extensions.xml and schemas to metacode
> > module.
> > For example, to support XMLBinding, we could move the xml-binding.xsd,
> > xml-binding.xjb and extensions.xml to metacode.
> >
> > Later when we support new binding or new transport, we could put xsd
> > and extensions file into metacode
> >
> > I don't know if there is any better solution?
> >
> > Thanks,
> > James.
> >
> >
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [Tools] About wsdl extensions
Posted by James Mao <ja...@iona.com>.
and also need to mention is that the xml-binding.xsd is wsdl11 specific,
i don't know how we handle the wsld11 extensibility and wsdl20
extensibility? any plan?
Another solution I have is to move the xsd and extensions.xml to tools2
temporarily.
> Hi,
>
> I'm trying to reuse the wsdl extension mechanism used in
> rt/core/WSDLManagerImpl for tools,
> But i found that it has the dependency problem, to resolve the
> dependency problem,
>
> one solution is to move the extensions.xml and schemas to metacode
> module.
> For example, to support XMLBinding, we could move the xml-binding.xsd,
> xml-binding.xjb and extensions.xml to metacode.
>
> Later when we support new binding or new transport, we could put xsd
> and extensions file into metacode
>
> I don't know if there is any better solution?
>
> Thanks,
> James.
>
>