On Thursday 23 September 2010 4:40:11 pm Christian Schneider wrote: > CXF uses the prefix to determine which transport implementation to > use. So jms:// triggers > that the jms transport is handling this endpoint. So I think this is > more than only a requirement of jax ws.
Right. If you aren't using the factories and explicitely setting a transport ID, them jms:// would be needed to trigger a discovery of the transport. If you set the transport ID on the factory, it shouldn't be needed. > As we now already have three ways of configuring jms we of course should > think about retiring at least one in the long run. Longer term, I think we should eliminate the custom JMS extensor things and just go with the spec for JMS in wsdl. Thus, it would be: In Spring - use the spring things In WSDL and code first - use the SpecJMS things Not something short term though as I know a bunch of folks are using the old things. Dan > > Regards > > Christian > > Am 23.09.2010 16:12, schrieb Daniel Kulp: > > On Monday 20 September 2010 8:22:07 pm Benson Margulies wrote: > >> I'm not sure what, if anything, to do with pubsub. It's all using the > >> wsdl config, right? Is there anything wrong? > > > > There's nothing WRONG. It's a perfectly fine example. It's just > > showing how to use the older WSDL config and not the newer SOAP/JMS spec > > stuff. I'm actually OK with that. I definitely don't see us dropping > > support for those wsdl extensor things. > > > >> Why the bogus endpoint > >> address in the Endpoint call in the server? > > > > I think JAX-WS requires some sort of address to the endpoint.publish call > > so we historically just stick in "jms://" in there to make JAX-WS happy. > > :-) If you try something like enpoint.publish(null), you have to cast > > the null to resolve the overloaded publish. Nothing major. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
