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
