I noticed. I read the source and this return bind(class,class) is what I
missed: "So thanks you two". Maybe updating the documentation... well let
it be :).
Sadly I need AOP for that too, so having an undecorated service is not good
enough. Currently I just stick with
Reflection.invoke(ServiceProxy.getImplementation(service), "myMethod").
Works in both non-production and production mode is the best work around I
found.
It resides in its own private method so readers just see it as
resetDatabase(). So I am quite happy with it.
I love dealing with legacy code. Maybe I have a chance and drop all this
and provide a warper service to the service of tapestry I can not control.
So I can
extend the former interface and add an extended version of the interface
(why noone mentioned extending the service interface?
this would be a real good OOP solution :-) ).
So in the end I pitty us for not being able to decorate implementation
classes, its quite easy to implement using asm and alike(extending original
class).
Anyhow. Life goes on.
Thanks alot for your input (both of you). Solved my problem.
Cheers,
Martin (Kersten),
Germany
2013/10/16 Lance Java <lance.j...@googlemail.com>
> If you really really really want to do this thing that we are both
> suggesting is a bad idea, you can do one of the following in AppModule
>
> public static MyServiceImpl buildMyServiceImpl(…) {
> return new MyServiceImpl(…);
> }
>
> OR
>
> public static void bind(ServiceBinder binder) {
> binder.bind(MyServiceImpl.class, MyServiceImpl.class);
> }
>
> And then you can:
>
> @Inject
> private MyServiceImpl myService;
>
