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 <[EMAIL PROTECTED]> 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.
>
>
