Thanks Daniel,
this was pretty much the conclusion that we'd come to as well.
cheers,
j
On Mon, 2008-06-02 at 16:28 -0400, Daniel Kulp wrote:
> Apparently not supported... :-(
>
> I've been googling a bit and discovered that it's pretty much
> impossible to do this from custom namespace BeanDefintionParsers that
> process the full DOM element themselves. In our case, we feed the
> DOM element into JAXB to have it parse it into the JAXB bean that was
> generated from the schema with the jaxb code generator.
>
> The PropertyPlaceholderConfigurer thing only looks at the
> BeanDefinition arguments that are "String", "List", and "Map" types
> (and other BeanDefinitions). Thus, it cannot dig into JAXB things
> that we create to sub in values (and it wouldn't be able to since in
> the JAXB objects, the type could be something like an int that would
> hold the property).
>
> I have it semi-working by writing the DOM element to a string and
> using a factory to re-parse that string later in the factory method.
> Thus, Spring will see the big long string, sub in the vars, and then
> we'll re-parse into JAXB. Kind of sucks, but at least semi-works.
>
> The "better" solution would probably be to write a JAXB plugin or
> something that would process the DOM element and build up a spring
> BeanDefinition instead of an actual JAXB bean. That's probably quite
> complex though. We might be able to do it with an XJC plugin that
> would generate a special "SpringParser" thing for each bean. I
> definitely need to think about this some more.
>
> In anycase, if I can get the tests passing with my hack, I'll commit
> it, but I'm really not happy about the solution. It smells of crappy
> code.
>
> Dan
>
>
>
> On May 27, 2008, at 11:44 PM, Jason Dwyer wrote:
>
> > hi,
> >
> > we've been using the SOAP/JMS transport with cxf happily for a
> > couple of
> > months, and have come to a point where we're setting up deployment
> > topologies for production environments, and need to make the values
> > for
> > the jms destination/address configurable.
> >
> > however, it appears that due to the way cxf loads up beans
> > automagically, there is no way we are able to reference property
> > placeholders for the values we want to configure.
> >
> > eg:
> >
> > <beans>
> > ...
> > <bean id="propertyConfigurer"
> >
> > class
> > =
> > "org
> > .springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> > <property name="location">
> > <value>classpath:jms.properties</value>
> > </property>
> > </bean>
> > ...
> >
> > <jms:destination
> > name="{http://some.namespace.com}AccountServicePort.jms-
> > destination">
> > <jms:address destinationStyle="queue"
> > jndiConnectionFactoryName="ConnectionFactory"
> > jndiDestinationName="${acccount.queue.name}"
> > connectionUserName="${jms.username}"
> > connectionPassword="${jms.password}">
> > <jms:JMSNamingProperty
> > name="java.naming.factory.initial"
> > value="${connectionFactory.class}" />
> > <jms:JMSNamingProperty name="java.naming.provider.url"
> > value="${jms.host.url}" />
> > </jms:address>
> > </jms:destination>
> >
> > </beans>
> >
> > and in jms.properties, we set up the values as per standard
> > propertyPLaceholderConfigurer practice.
> >
> >
> > we've tried moving the jms:destinations into cxf.xml in the root of
> > the
> > classpath, and let cxf find it by itself, to no avail, as well as
> > putting all the definitions into our standard applicationContext.xml
> > which is loaded by the cxf servlet ( as well as programatically with a
> > ClassPathXmlApplicationContext ).
> >
> >
> > is there a viable workaround for this?
> >
> > thanks in advance,
> >
> > j.dwyer
>
> ---
> Daniel Kulp
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
>
>
>
>
