[
https://issues.apache.org/jira/browse/CXF-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498540
]
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 fail.
WSDLToServiceProcessor.setAddrElement then could do something like:
AddressGenerator gen =
addressGenerators.get((String)env.get(ToolConstants.CFG_TRANSPORT));
port.addExtensibilityElement(gen.createAddress(....);
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 http://weblogs.java.net/blog/kohsuke/archive/2005/06/writing_a_plugi.html
for how to write a plugin for xjc.
> Tool dependecies on runtime components
> --------------------------------------
>
> Key: CXF-658
> URL: https://issues.apache.org/jira/browse/CXF-658
> 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
> similar.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
