By the way, here's what was really surprising about this. When I first hit the NPE, I thought, "OK, I need to set some transport IDs. Let's see what the standard version of the class has."
So, I turned off my class and set a breakpoint at the spot that looked at the transport ids. It was never called. I apologize for not capturing the details, but, in general, when the code is setting up lazily as a result of a call to get a server for a service, the rest of the (un)initialization status causes the logic to assume that there will be no transport ids, and it makes some assumptions, instead. By creating and advertising a factory on the bus before entering that code, I'm obviating all of that. Now, ignorantly, I would suggest that I should be able to arrange the same convenient treatment for my subclass as the standard class gets. Or, alternatively, your concept might be: "As soon as you (ahem) open the jar and start customizing things, we recommend spring wiring, and look at the supplied files to see how it's done." > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 14, 2007 1:57 PM > To: [email protected] > Subject: Re: customizing the HTTP transport factory > > Hi Benson, > > You're very close to getting it to work :-) If you look at the > cxf-extension-http-jetty.xml file you'll see that we associate several > transport IDs with that transport: > > <bean class=" > org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory" > lazy-init="true"> > <property name="bus" ref="cxf"/> > <property name="transportIds"> > <list> > <value>http://schemas.xmlsoap.org/soap/http</value> > <value>http://schemas.xmlsoap.org/wsdl/http/</value> > <value>http://schemas.xmlsoap.org/wsdl/soap/http</value> > <value>http://www.w3.org/2003/05/soap/bindings/HTTP/ > </value> > <value>http://cxf.apache.org/transports/http/configuration > </value> > <value>http://cxf.apache.org/bindings/xformat</value> > </list> > </property> > </bean> > > In code form, this is equivalent to: > > Set<String> tids = new HashSet<String>(); > tids.add("http://schemas.xmlsoap.org/soap/http";); > ... etc for all transport ids > > httpTransport.setTransportIds(tids); > > for (String tid : tids) { > dfm.registerDestinationFactory(tid, httpTransport); > } > > We should really write some docs on the transport layer, but hopefully > this > will get you going in the meantime. > > Thanks, > - Dan > > > On 7/13/07, Benson Margulies <[EMAIL PROTECTED]> wrote: > > > > I set out to replace JettyHTTPTransportFactory with a slightly modified > > version. So, I wrote the code below. > > > > The effect is an NPE when my factory object is asked for its > > transportIds, of which it has none. When I don't try to set this up, the > > default transport factory does not get asked for its transport ids, > > apparently because other things that aren't initialized protect it from > > being asked. > > > > I think I see what the transport Id has to be for SOAP, so I can just > > set it, but is this idea supposed to work without that? > > > > > > > > Bus bus = BusFactory.getDefaultBus(); > > DestinationFactoryManager dfm = > > bus.getExtension(DestinationFactoryManager.class); > > JettyHTTPTransportFactoryForStaticContent transportFactory = new > > JettyHTTPTransportFactoryForStaticContent(); > > transportFactory.setBus(bus); > > > > dfm.registerDestinationFactory("http://cxf.apache.org/transports/http/co > > nfiguration", transportFactory); > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog
