Next question: does this work java-first via the JAX-WS API?
On Wed, Sep 15, 2010 at 10:34 PM, Daniel Kulp <[email protected]> wrote: > 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: > http://cxf.apache.org/docs/using-the-jmsconfigfeature.html > 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 > stuff). > > 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: > http://cxf.apache.org/docs/soap-over-jms-10-support.html > > 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? > > Dan > > > >> >> 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("org.apache.activemq.broker.BrokerService"); >> 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.in.read(); >> System.out.println("Server exiting"); >> System.exit(0); > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog >
