CXF Extensions for Spring XML

[Andrea Smyth <an...@iona.com>]

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 
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd - 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 
http://cxf.apache.org/transports/http/configuration namespace (conduit, 
destination etc)  or in the http://cxf.apache.org/jaxws namespace 
(endpoint, server, client), as no name attribute is defined for these 
elements.
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 
http://cxf.apache.org/jaxws 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 
http://cxf.apache.org/transports/http/configuration 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 http://cxf.apache.org/jaxws 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 http://cxf.apache.org/jaxws 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:rmManager>
   <wsrm:sourcePolicy .../>
   <!-- new, and possibly only for development/test purposes -->
   <beans:property name="store" ref="txStore"/>
</wsrm:manager>
<beans id="txStore" 
class="org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore"/>

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.


Andrea.

Re: CXF Extensions for Spring XML

[Andrea Smyth <an...@iona.com>]

Looks like we are  agreeing on all of the points  :) - I'll see what I 
can fit in over the next couple of days.
On the point of extending wsdl:tExtensibilityElement. some ideas below ...

Dan Diephouse wrote:

> Hola, comments inline....
>
> On 5/14/07, Andrea Smyth <an...@iona.com> 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
>> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd - 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
>> http://cxf.apache.org/transports/http/configuration namespace (conduit,
>> destination etc)  or in the http://cxf.apache.org/jaxws 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?

Beans for which we define a schema and provide a bean definition parse 
should never have to extend wsdl:tExtensibilityElement - only types that 
are used as attributes/child elements of such beans should. Also, for 
those beans we would NOT use JAXB to generate a class from which the 
implementation inherits: we don't want attributes such as "abstract", 
"id", "name" make their way into component code.
Many components already have their getters/setters for configurable 
properties coded manually instead of inheriting them from a JAXB 
generated class. And since we don't generate custom getters/setters any 
more there is not much advantage of inheriting from a generated bean.

Andrea.

Re: CXF Extensions for Spring XML

[Dan Diephouse <da...@envoisolutions.com>]

Hola, comments inline....

On 5/14/07, Andrea Smyth <an...@iona.com> 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
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd - 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
> http://cxf.apache.org/transports/http/configuration namespace (conduit,
> destination etc)  or in the http://cxf.apache.org/jaxws 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
> http://cxf.apache.org/jaxws 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
> http://cxf.apache.org/transports/http/configuration 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 http://cxf.apache.org/jaxws 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 http://cxf.apache.org/jaxws 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.
>
>
+1!!!

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.


+1

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="org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore"/>
>
> 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
http://envoisolutions.com | http://netzooid.com/blog