Thanks for the reply Steve. The two classes I mention are Tapestry IoC classes, not my own.
What you describe is how most of our overrides are implemented but this one is conditional - we only need to override this service in a specific environment and that's what causes the issue. If I define it like that if the override is not applied then the IoC has two implementations bound (if you don't bind it you can't have it injected into the override method) and will throw errors whenever the service is injected without a specific ID. There are 100's of places where we have plain injections and is not practical to change them. -----Original Message----- From: Steve Eynon [mailto:steve.ey...@alienfactory.co.uk] Sent: 21 February 2012 10:36 To: Tapestry users Subject: Re: [T5.3] Contributing a Service Override using addInstance() Hi, I'm not really sure what's going on as the two classes you mention, ValidatingMappedConfigurationWrapper & AbstractConfigurationImpl, don't appear in your code snippet. If you define your overriding service as an Interface (say in the bind() method) then T5 will create a proxy for it. public static void bind(ServiceBinder binder) { binder.bind(ToOverrideInterface.class, ToOverrideImpl.class).withId("anything so we don't conflict with the existing ID"); } then you can inject that in the service override like this: public static void contributeServiceOverride(MappedConfiguration config, @Local ToOverrideInterface override) { config.add(ToOverrideInterface.class, override); } The @Local is important, otherwise T5 doesn't know which serivce to inject (yours or the one you're trying to override). Steve. On 20 February 2012 20:54, Blower, Andy <andy.blo...@proquest.co.uk> wrote: > I managed to get this to work by tracking down all dependencies and finding > that one was being used in the services' constructor. Once I moved the > initialisation code into a lazy init method I stopped getting the exceptions. > > Unfortunately, I still have an issue because when using addInstance() > Tapestry is not using a proxy for the overriding service implementation, > instead I'm getting a concrete reference instead which I thought never > happened with Tapestry IoC. This causes problems when used in objects that > are serialized to the session because it tries to serialize the service > implementation rather than just the service proxy. > > My override looks like this: > > @Contribute(ServiceOverride.class) > public static void > setupApplicationServiceOverrides(MappedConfiguration<Class<?>, Object> > configuration) > { > configuration.addInstance(ProductConfig.class, > DynamicMultiProductConfig.class); > } > > Basically the contributionType in ValidatingMappedConfigurationWrapper > (AbstractConfigurationImpl) is Object which isn't an interface so a proxy > isn't created. How can I change the signature of my module service override > method so that contributionType is an interface and I get a service proxy > like every other service? > > Can anyone help me? > > > -----Original Message----- > From: Blower, Andy [mailto:andy.blo...@proquest.co.uk] > Sent: 15 February 2012 14:51 > To: users@tapestry.apache.org > Subject: [T5.3] Contributing a Service Override using addInstance() > > I've read the section below about contributing a service override. This > method is exactly what I need to resolve an issue I'm having getting a > conditional override implemented, but it doesn't appear to work if the > service implementations' constructor has any other T5 service dependencies in > the signature. (T5 complains that ServiceOverride depends on itself. > > Is this true, because that doesn't seem to be what's implied below by "handle > dependency resolution", and makes addInstance of limited usefulness. I'm > hoping I'm just missing something here. > > > > From http://tapestry.apache.org/ioc-cookbook-overriding-ioc-services.html : > > "In this case, it is very easy to supply your own alternate implementation of > a service. > AppModule.java (partial) > > @Contribute(ServiceOverride.class) > > public static void > setupApplicationServiceOverrides(MappedConfiguration<Class,Object> > configuration) > > { > > configuration.addInstance(SomeServiceType.class, > SomeServiceTypeOverrideImpl.class); > > } > > The name of the method is not important, as long as the > @Contribute<http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Contribute.html> > annotation is present on the method. > > In this example, we are using addInstance() which will instantiate the > indicated class and handle dependency resolution. (Be careful with this, > because in some cases, resolving dependencies of the override class can > require checking against the ServiceOverrides service, and you'll get a > runtime exception about ServiceOverrides requiring itself!)" > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org