cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: CXF Spring Configuration and PropertyPlaceholderConfigurer
Date Mon, 15 Sep 2008 15:36:33 GMT
On Sunday 14 September 2008 3:49:40 pm Christian Schneider wrote:
> thanks for the hint. I will try this. I think the feature of replacing
> properties is extremely important for the cxf users. Can we trun off the
> validation by default?

Actually, I think spring has it on by default as well.   As Benson mentioned, 
the validation is a good thing as it would flag "errors" like 
or other silly things of extra chars that don't belong there.   Without the 
validation, errors resulting from such things would "really suck" to try and 

> Another idea would be to do the validation after the properties have
> been replaced.

This is next to impossible to do the way Spring handles the replacement stuff.   
If you follow what spring does:

1) Parse XML into a dom.  If validation is on, the XML parser handles the 

2) Walk the DOM calling any namespace handlers to build up "Bean Definitions"  
for all the beans.   At this point, the xml is now gone.

3) Call the bean definition post processors.  The property replacement thing 
walks the Bean definitions to find strings that have ${prop} syntax and 
replaces the strings.

4) Then the beans are created from the bean definitions.

There isn't any XML left at the time of the property replacement.    Nothing 
to validate at that point.

> I have got another question about the xml configuration. Is it possible
> to tell spring that an element is a reference to to a bean? I would like
> to add the functionality of referencing the
> ConnectionFactory to the address element. So people can define their
> factory locally or use springĀ“s jndi logic to look it up. Of course I
> could simply add a string type element and search for the Factory by
> hand but I would prefer to let spring do this work.

Well, kind of yes, kind of no.   I would take a look at the JAX-WS 
EndpointDefinitionParser.   The jaxws:endpoint element has a "implementor" 
attribute, which if it starts with # is considered a reference to another 
bean.   In that case, the parser calls:
(or bean.addPropertyReference("property", val.substring(1)); for a property)
Spring does the lookups and all that for you.


> Greetings
> Christian
> Daniel Kulp schrieb:
> > Christian,
> >
> > I don't think it has anything to do with the
> > AbstractBeanDefinitionParser.  It has to do with the schema validation
> > that we turn on by default and camel doesn't.    The schema validation
> > occurs at XML parse time when spring is constructing the DOM.   This is
> > long before any of the spring bean processing.
> >
> > The issue is types that aren't strings really don't validate with
> > properties. For example, a <element name="timeout" type="int"/> won't
> > validate if it appears as:
> > <timeout>${cnfigured.timeout}</timeout>
> > in the xml file as that's not an int.
> >
> > If you turn off the schema validation, it will probably work for you.
> > Obviously, you have to make sure the xml is then valid yourself.  I think
> > it would be -Dorg.apache.cxf.spring.validation.mode=VALIDATION_NONE
> >
> >
> >
> > Dan

Daniel Kulp

View raw message