cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <>
Subject CXF Extensions for Spring XML
Date Mon, 14 May 2007 09:06:44 GMT
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 
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.

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.

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.

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.

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:sourcePolicy .../>
   <!-- new, and possibly only for development/test purposes -->
   <beans:property name="store" ref="txStore"/>
<beans id="txStore" 

I am not sure of this is feasible, but as it stands using custom xml is 
not very flexible at all - 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.

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.


View raw message