cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: [Tools] About wsdl extensions
Date Thu, 21 Dec 2006 03:56:09 GMT
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 <james.mao@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.
>> >
>> >
>>
>>
>
>


Mime
View raw message