cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrea Smyth (JIRA)" <>
Subject [jira] Commented: (CXF-658) Tool dependecies on runtime components
Date Thu, 24 May 2007 08:11:16 GMT


Andrea Smyth commented on CXF-658:

This is not about the location of jms.xsd, but about the compile time dependencies of the
tools on the classes generated from jms.xsd, as for example in WSDLToServiceProcessor.setAddrElement.

If you defined interfaces like the following:
interface ToolsPlugin {
    String getOptionName();
    String getOptionHelp();
interface AddressGenerator extends ToolsPlugin {
    Object createAddress(String[] args);
the tool could look up all ToolPlugins on its path (by consulting META-INF/services), and
in a first step check if there is a "taker "for all of the arguments passes to the tool, otherwise
WSDLToServiceProcessor.setAddrElement then could do something like:

AddressGenerator gen = addressGenerators.get((String)env.get(ToolConstants.CFG_TRANSPORT));

That way the tool is extensible and if a new transport is implemented, it is possible to generate
addresses for this type of transport by simply putting a corresponding address generator on
the path; there will be no need to change the tools code itself.

See for how to write
a plugin for xjc.

> Tool dependecies on runtime components
> --------------------------------------
>                 Key: CXF-658
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Tooling
>    Affects Versions: 2.0-RC
>            Reporter: Andrea Smyth
>         Assigned To: maomaode
> In order to get schema validation working for all of our Spring XML extensions I wanted
to make some changes to jms.xsd.
> I was a bit surprised to find this schema not in the jms module itself but in cxf- tools-common
instead (and jms-context.xsd in cxf-common-schemas). 
> An attempt to move it into xf-rt-transports-jms revealed a dependency of cxf-tools-wsdlto
on this schema. This dependency is wrong and violates the principle of extensibility.
> If tools want to support generation of code/wsdl that involves details of a specific
binding or transport they should do so via an interface instead of hardcoding that dependency
into the generators.
> The concept of customising xjc with plugins is an example of how this can be done: the
generator/tool checks on its path for components that are able to generate address elements
for a particular address type "jms". If the jms module is on the path that is should implement
the bit that is needed by the tool,  fine, the tool embeds the result into whatever else it
generates.  Otherwise the tool fails with: "No processor found for adddress type "jms" or

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message