Mailing-List: contact cxf-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Message-ID: <2962505.1180334115958.JavaMail.jira@brutus>
Date: Sun, 27 May 2007 23:35:15 -0700 (PDT)
From: "maomaode (JIRA)" <jira@apache.org>
To: cxf-issues@incubator.apache.org
Subject: [jira] Commented: (CXF-658) Tool dependecies on runtime components
In-Reply-To: <10322077.1179419716624.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499483 ] 

maomaode commented on CXF-658:
------------------------------

Excellent comment! Andrea,

I'm going to look into this approach.

And the ToolPlugin as metioned in your comment, will go into the API module,
And the jms.xsd will go into the rt/transport/jms module, and also in the jms module will have an sub-class of AddressGenerator, 
And we need a AddressGeneratorFactory to look up the specific addressGenerator based on the tools' argument 'ToolConstants.CFG_TRANSPORT'

correct?

And another thing i want to mention is that it's not just about address, we will need the bindings as well (WSDL2XML for example).

Do you have another name for the ToolPlugin, since we already have a ToolPlugin for frontends/databindings in tools?
Since it's about the Wsdl extensions, how about WSDLExtensibilityPlugin?


> 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
>            Assignee: 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.