Re: [T5.3] Contributing a Service Override using addInstance()

[Steve Eynon <st...@alienfactory.co.uk>]

> Perhaps we need complement the addInstance() methods with
> addProxy() methods on the Configuration interfaces?

Actually, this would be nice for a couple of times now I've been bit by
having

  config.addInstance("blah", OptionalImpl.class);

where OptionalImpl references a jar that's no longer deployed resulting
in an "Exception constructing service" when the contribution finally gets used.

The fix is simple enough, binding OptionalImpl as a service and injecting
it via @Local into the contribution method.

But changing the one line to:

  config.addProxy("blah", OptionalImpl.class);

would be much shorter and cleaner!

Steve.

On 28 February 2012 01:43, Howard Lewis Ship <hl...@gmail.com> wrote:
> FYI: http://tapestryjava.blogspot.com/2012/02/plastic-advanced-example.html
>
>
> On Mon, Feb 27, 2012 at 8:45 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> On Fri, Feb 24, 2012 at 9:14 AM, Blower, Andy
>> <An...@proquest.co.uk> wrote:
>>> Sorry, premature celebration. :-(
>>>
>>> It works until the proxy is serialized, which throws a NotSerializableException. In normal binding / override the proxy is a JustInTimeObjectCreator and using this proxy it seems to be a ReloadableObjectCreator, but nether of them are marked as Serializable so I'm not sure how it normally works. My understanding was that SSO's could hold references to services since these were simply referring to a proxy which essentially could be serialized and replicated across a cluster since it only sent a token.
>>
>> The code for this is hidden inside ModuleImpl.createProxyInstance()
>> which creates a proxy that implements Serializable, and the optional
>> writeReplace() method. See all ModuleImpl.createProxy().
>>
>> Basically, the proxy uses writeReplace() to write a ServiceProxyToken
>> into the output stream; when the stream is deserialized, the
>> ServiceProxyToken uses a static field to locate the Registry, and
>> replaces itself with the service.
>>
>> If there is a way to @Inject a @Local service to contribute to
>> ServiceOverrides, that will work better, as the local service will
>> have it own proxy & ServiceProxyToken.  Much like the second example
>> on http://tapestry.apache.org/ioc-cookbook-overriding-ioc-services.html
>>
>> But I'm not sure how this affects your original problem.
>>
>> You may find it is easier to use either method advice, or service
>> decoration, to augment the existing service in place, rather than
>> replace it entirely.
>>
>> In fact, this does point to the idea that Tapestry could use a new
>> type of module method for replacing built-in services with
>> replacements cleanly, rather than rely on ServiceOverrides.  Such a
>> module method (and related RegistrtyImpl support) would make the
>> replacement hide behind the original service's id and
>> ServiceProxyToken.
>>
>>
>>>
>>> How far out am I here?
>>>
>>>
>>> -----Original Message-----
>>> From: Blower, Andy [mailto:Andy.Blower@proquest.co.uk]
>>> Sent: 22 February 2012 17:35
>>> To: Tapestry users
>>> Subject: RE: [T5.3] Contributing a Service Override using addInstance()
>>>
>>> Yes that works! I had no idea you could do such a thing as I'd not see it anywhere in the documentation.
>>>
>>> I don't know if an addProxy() method is worth adding, our requirements seem quite unusual. If it would be useful to other Tapestry users then maybe.
>>>
>>> Thanks for the reply Howard.
>>>
>>> -----Original Message-----
>>> From: Howard Lewis Ship [mailto:hlship@gmail.com]
>>> Sent: 21 February 2012 19:51
>>> To: Tapestry users
>>> Subject: Re: [T5.3] Contributing a Service Override using addInstance()
>>>
>>> This might work:
>>>
>>>  @Contribute(ServiceOverride.class)
>>>
>>>  public static void
>>> setupApplicationServiceOverrides(MappedConfiguration<Class,Object>
>>> configuration, ObjectLocator locator)
>>>
>>>  {
>>>  SomeServiceType override = locator.proxy(SomeServiceType.class,
>>> SomeServiceTypeOverrideImpl.class);
>>>
>>>   configuration.add(SomeServiceType.class, override);
>>>
>>>  }
>>>
>>>
>>> This contributes a proxy for the override, rather than the override itself ... meaning that eventual construction of SomeServiceTypeOverrideImpl is deferred until needed, and that will be after the MasterObjectProvider and ServicesOverride are constructed.
>>>
>>> Give it a try and report back!
>>>
>>> Perhaps we need complement addInstance() methods with addProxy() methods on the Configuration/OrderedConfiguration/MappedConfiguration
>>> interfaces?
>>>
>>>
>>> On Tue, Feb 21, 2012 at 6:33 AM, Blower, Andy <An...@proquest.co.uk> wrote:
>>>> 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.eynon@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 <An...@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.Blower@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-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator of Apache Tapestry
>>>
>>> The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast!
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>>
>>> ---------------------------------------------------------------------
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org