Even if do not own the interface, you can still create a new interface extending the original one. Than in your code you can inject your new interface to ger access to your extra methods. I am not at the computer now, so I do not have any examples, but I used such approach to "add" some methods to Tapestry's interfaces.
Yours, Cezary On 15 Oct 2013 23:19, "Martin Kersten" <martin.kersten...@gmail.com> wrote: > I do not own the interface. Currently I just use reflection to get the > concrete service instance from the proxy and use reflection to call my > method. > > And If I remember my diggin into the code session of tapestry's IOC > correctly, binding a concrete (implementation) class is just binding the > class to all its (super)interfaces. The only way of getting something > concrete out of tapestries registry is using the autobuild, > > So if I miss a opportunity here to make my life easy again you are welcome > to tell me about it. This interface only is really disturbing and in case > of AOP features it even breaks the interface idea. You have to annotate the > interface to describe an implementation detail. Wow that is really good OOP > to the max (sarcasm intended). > > I just wonder myself why we dont have concrete services that are returned > for interfaces they implement and just use something like @Before and > @After or @Init or a simple LazyInitialization interface they implement > for lazy initialization support (first access). Would be way better then > this interface heavy IOC. But being around with tapestry since 3.x I know > its mostly about history and Java capabilities of proxy generation. Do not > like the idea. > > What is about creating a service using a builder method? This should at > least selectively avoids the reload classloader thing, right? > > > PS: If you can show me a snippet where I can inject a concrete service > implementation I would be instantly silenced. But yet again this would make > AOP and stuff useless (unless something has changed in that direction) > since Tapestry can only advice interfaces not concrete classes. > > > > 2013/10/15 Thiago H de Paula Figueiredo <thiag...@gmail.com> > > > On Tue, 15 Oct 2013 18:34:09 -0300, Lance Java < > lance.j...@googlemail.com> > > wrote: > > > > I don't recommend this at all, in fact I think it is a terrible idea.... > >> but if you really want to stop tapestry from creating reloadable > proxies, > >> you can declare your services by concrete class instead of by interface > >> in your AppModule. > >> > > > > In addition, any service declared based on an interface will be proxied, > > so casting it to the implementation class won't work. As Lance said, if > you > > need to use service implementation methods that aren't in the service > > interface, you're probably needing to add them to the service interface > or > > rethinking your architecture. > > > > > > -- > > Thiago H. de Paula Figueiredo > > Tapestry, Java and Hibernate consultant and developer > > http://machina.com.br > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org< > users-unsubscr...@tapestry.apache.org> > > > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >
