You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Jason Dwyer <Ja...@majitek.com> on 2008/05/28 05:44:14 UTC

Property Placeholder configuration for jms:destinations

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

Re: Property Placeholder configuration for jms:destinations

Posted by Jason Dwyer <Ja...@majitek.com>.

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
> dkulp@apache.org
> http://www.dankulp.com/blog
> 
> 
> 
>

Re: Property Placeholder configuration for jms:destinations

Posted by Daniel Kulp <dk...@apache.org>.

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
dkulp@apache.org
http://www.dankulp.com/blog