For posterity and the benefit of searchers... I've ended up working around this by writing a very lightweight facade that implements the JAX-WS Provider interface and provides a no-argument constructor for CXF to call. This creates an Injector which is used to bring up the 'real' web service implementation, with dependencies supplied via constructor injection. Then any web service calls to the facade's invoke() method are just passed straight through to the real object which it keeps a reference to.
This means that the facade isn't really testable in isolation, but it doesn't do much so it doesn't really need to be. And the real web service provider can be tested with mocked-out dependencies without using Guice. If anyone has a better solution I'd be happy to hear it, but this seems to work pretty well. Andrew. 2009/2/6 Andrew Clegg <[email protected]>: > PS I'm still using Guice 1.0 but I'm happy to upgrade if nearly-2.0 > makes this easier... > > 2009/2/6 Andrew Clegg <[email protected]>: >> Hi folks, I'm looking for a bit of advice here... >> >> I'm building a JAX-WS Provider web service using the CXF toolkit. The >> Provider class is created by CXF (actually via Spring but I don't use >> Spring myself) via a no-arg constructor on starting the application. >> NB When I say Provider in this message, I mean a JAX-WS Provider >> (http://java.sun.com/javase/6/docs/api/javax/xml/ws/Provider.html) not >> a Guice Provider. >> >> Now, the Provider has various dependencies (handlers for different >> SOAP operations) which I want Guice to inject as they in turn contain >> lots of other injectable dependencies. I can't control the creation of >> the Provider myself, so I was thinking of creating the Injector in the >> Provider's constructor with a module binding the handlers in, and >> doing an injectMembers( this ) to inject them into fields of the >> Provider. >> >> This works, but it makes testing the Provider with mock handlers more >> complicated, as my unit tests want to override these injections. >> >> I could make the injected fields non-final and write setter methods >> for them, so the unit tests can override the default implementations >> with the mocks. However this has two drawbacks: >> >> 1. It'd slow my tests down, as the real objects that aren't being >> tested still get constructed. >> >> 2. If there's an error in constructing one of these objects then a >> test will fail, even though the test isn't testing these objects. >> >> Another option is to delay the injection to the first time the >> invoke() method of the provider is called, using something like this: >> >> if( ! injectionHasBeenDone ) { >> Injector i = Guice.createInjector( new ProductionModule() ); >> i.injectMembers( this ); >> } >> >> but that seems a bit ugly somehow, and it'd mean the first user of the >> web service gets a bit of a delay. >> >> What's the best practice for doing this kind of thing? I can't help >> feeling like I'm missing some obvious bit of Guice that would help >> here. >> >> Thanks! >> >> Andrew. >> >> -- >> :: http://biotext.org.uk/ :: >> > > > > -- > :: http://biotext.org.uk/ :: > -- :: http://biotext.org.uk/ :: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
