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? 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
