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 > >
