cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Either my new JMS sample is confused or I am ...
Date Thu, 16 Sep 2010 02:34:50 GMT
On Wednesday 15 September 2010 2:33:47 pm Benson Margulies wrote:
> This is from the java_first_jms sample that I cleaned up. Why is the URL in
> the server factory trivial? Why doesn't it need to state the host and the
> port? Is 61616 some sort of a default?

This is part of what Willem and I were debating about earlier today.   

A bit of history of the JMS transport:

In the OLD OLD JMS transport (2.0.x and early 2.1.x), the ONLY way to 
configure JMS stuff was via custom JMS extensions in the WSDL which interated 
with JNDI.   Thus, it only worked for wsdl first use cases.  The jms_pubsub  
and jms_queue demos are configured this way. 

At some point in there, we added SOME ability to configure things via spring 
config.  It's the same wsdl extensors, but configurable in spring config.  
That allowed some Java-first cases to work as the custom config could be 
specified in a spring cxf.xml config file.   That is how your 'new' sample is 
configured.   See src/main/resources/cxf.xml.  That's where the 61616 is 
configured into the cxf stuff.

During 2.1.x timeframe, Christian re-wrote the JMS transport to allow use of 
the "normal" Spring JMS/Template stuff.  We don't have a sample for that, but 
the docs are at:
This made it much more intuitive for a Spring user to configure the JMS stuff 
and wire in the Spring JMS things (for things like the Spring transactions and 

In ALL of the above cases, the configuration for the broker URL and queue 
names and such are all part of the configuration elements.   The "jms://" URL 
was pretty much irrelevant.  It's ONLY purpose was to trigger the use of the 
JMS transport if you don't manually configure in a transport ID onto the 
service factory.   

With 2.3, we've implemented the SOAP over JMS specification.  Part of that 
specification actually provides for a URL format for the jms:// URL.   With 
that spec, we can now completely do JMS without any of the above configuration 
and wsdl extensors and such.  It also allows pure Java first use case of SOAP 
over JMS without any config.  The jms-spec-demo shows use of the spec stuff, 
but it's still a wsdl first thing.  See the docs at:

It would be GOOD to update the java_first_jms sample to use the new soap/jms 
spec URL instead of the config.   Not required, but for 2.3, it would probably 
be the way we should promote the java-first case for JMS.

Does that answer your question?


> Also, how would this look using the JAX-WS Endpoint class?
>  boolean amqBroker = args.length > 0 && "-activemqbroker".equals(args[0]);
>         if (amqBroker) {
>             /*
>              * The following make it easier to run this against something
> other than ActiveMQ. You will have
>              * to get a JMS broker onto the right port of localhost.
>              */
>             Class<?> brokerClass = ServerJMS.class.getClassLoader()
>                 .loadClass("");
>             if (brokerClass == null) {
>                 System.err.println("ActiveMQ is not in the classpath,
> cannot launch broker.");
>                 return;
>             }
>             Object broker = brokerClass.newInstance();
>             Method addConnectorMethod =
> brokerClass.getMethod("addConnector", String.class);
>             addConnectorMethod.invoke(broker, "tcp://localhost:61616");
>             Method startMethod = brokerClass.getMethod("start");
>             startMethod.invoke(broker);
>         }
>         Object implementor = new HelloWorldImpl();
>         JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
>         svrFactory.setServiceClass(HelloWorld.class);
>         svrFactory.setAddress("jms://");
>         svrFactory.setServiceBean(implementor);
>         svrFactory.create();
>         System.out.println("Server ready... Press any key to exit");
>         System.out.println("Server exiting");
>         System.exit(0);

Daniel Kulp

View raw message