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 <[EMAIL PROTECTED]> 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.
