cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: CXF Extensions for Spring XML
Date Mon, 14 May 2007 18:55:32 GMT
Hola, comments inline....

On 5/14/07, Andrea Smyth <> wrote:
> Hi all,
> I was looking at some of our BeanDefinitionParsers and configuration
> schemas and noticed there are some problems:
> 1. Schema validation is currently disabled - and turning it on requires
> a number of changes to existing configuration files on the one hand but
> also to code (BeanDefinitionParsers).
> These are mainly due to the fact that stringified QNames are not legal
> bean ids as per
> - they
> are of type xsd:ID not xsd:string.
> The workaround for plain bean elements is simple, just use the name
> attribute instead. But that is not possible for elements in the
> namespace (conduit,
> destination etc)  or in the namespace
> (endpoint, server, client), as no name attribute is defined for these
> elements.

I was trying to get this reenabled a couple weeks ago and the major problem
was with the beans extending the wsdl:tExtensibilityElement. Spring really
didn't like that. We shouldn't have to extend the wsdl:tExtensibilityElement
now as we have a WSDL schema which allows elements anywhere. However, I went
down this route and ran into a problem with WSDL4J. It expects all the
extensibility elements to extend ExtensibilityElement. Anyone know a way
around this? Could we just make those elements extend ExtensibilityElement
in Java, but not extend wsdl:tExtensibilityElement in the code?

Finally, some elements (rmManager) are of a type that has no id
> attribute define at all, but on the other hand the resp. parsers assume
> that there is a non null id.

Yeah, we should definitely be creating an ID automatically in this case.

2. Some elements, e.g. endpoint, server, client in the
> namespace are of a type that extends
> beans:identifiedType, i.e. have an id attribute of type xsd:ID.
> Others, e.g. conduit, destination in the
> namespace do not
> extend beans:identifiedType but instead have an id attribute added
> manually as:  <xs:attribute name="id" type="xs:string"
> use="required"/>.  This type inconsistency is very confusing: in some
> case the ids can be stringified QNames, but in others they can't.

I didn't realize the id was an xsd:ID. We should definitely fix this!

3. The same set of attributes seem to be defined repeatedly for the
> different elements in the namespace - in
> fact its hard to see where the elements endpoint, server, and client
> actually differ. The schema should use an attribute group or inheritance
> to highlight what they have in common (this should be component
> specific, i.e. include "binding", "executor", "features" but exclude
> "abstract") More importantly, there is a lot of duplicate code in the
> BeanDefinitionParsers for these elements which should be removed.

+1 to collapsing some of this stuff. See my other email in the "Determining
the features..." thread for info on why there is both an endpoint & server.

4. Question: Do we really need both an "abstract" and an
> "createdFromAPI" attribute in the endpoint, server and client elements
> in the namespace? From what I have seen,
> they are used synonymously, and in that case I would much prefer the use
> of "abstract" as this is commonly understood by Spring users, but I may
> have overlooked something.

Yes, unfortunately we do. There are 2 distinct use cases:
 1. createdFromAPI="true" - here we need to automatically change the ID and
append ".jaxws-client" or ".jaxws-endpoint" to the ID. Otherwise the
<jaxws:client> and <jaxws:endpoint> would have the same ID. We can't use
abstract="true" because...
2. Parent/child relationships - in this case, abstract="true" simply means
we want to inherit from the parent bean at some point. We don't want to
change the ID in #1, because that would highly confusing for the user.
They'd end up writing something like this where the IDs didn't match:

<jaxws:endpoint id="myParentBean" .../>
<jaxws:endpoint id="foo" parent="myParentBean.jaxws-endpoint" .../>

5. To avoid the inconsistencies w.r.t the presence and type of an id
> attribute, we should make it a policy that all types extend
> beans:identifiedType. And all types use the same attribute group (a
> subset of the beans:beanAttributes group) including the "abstract" and
> "name" attributes at a minimum. This group should be defined in the
> common package along with the (CXF) AbstractBeanDefinitionParser, which
> should also handle the attributes in a common way for all types, e.g.
> use the value of the name attribute as an alternative to an id attribute.

6. I don't like the way the id of the bus bean is making its way all
> into the code now  - it's bad enough that it is repeated everywhere in
> the xml files (<property name="bus" ref="cxf"/>) but worse that numerous
> BeanDefinitionParsers make use of that bean name too - they could at
> least use a String constant.


7. Extensibility: To avoid having to change schema and bean definition
> parser in addition to the actual runtime component whenever I want to
> inject a new property into it, I would like custom elements to accept
> child elements and attributes from the beans namespace, and have them
> handled in the same way they are handled for beans elements, e.g. allow
> something like
> <wsrm:rmManager>
>    <wsrm:sourcePolicy .../>
>    <!-- new, and possibly only for development/test purposes -->
>    <beans:property name="store" ref="txStore"/>
> </wsrm:manager>
> <beans id="txStore"
> class=""/>
> I am not sure of this is feasible, but as it stands using custom xml is
> not very flexible at all

This is probably possible.

- never mind the amount of (repetitive!) code
> required for each extension which amounts to a lot more than was ever
> necessary in the property editors based approach. While I don't want to
> go back to these, I do believe that there are some problems in mixing
> the "custom xml for configuration" approach with "plain Spring xml for
> wiring".  E.g. parameterise NamespaceHandlers, BeanDefinitionParsers and
> spring.schemas, spring.handlers and simply have ONE properties or xml
> file per module based on which the schema locations, namespace handlers,
> parsers etc are registered dynamically.

 We can definitely fix the repetitive code problem. Thats mostly my fault.
However, I'm not sure if we can get rid of the spring.schemas/handlers and
NamespaceHandlers needed for each module. How exactly would you propose
getting rid of those?

8. Schema validation must be enabled as soon as possible, IMO before 2.0
> final as it will be very helpful for users writing their configuration
> files. At the very least existing Spring xml files should be fixed to
> pass an optional validation step.
> +1 if we can make it work. As I mentioned above, I ran into major issues
with WSDL4J in an attempt to make this work.

- Dan
Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message