No comment... . :)
2013/10/28 Chris Mylonas
> Sorry to bring up an old thread, I'm just reading it now - to my
> entertainment and learning :)
>
> I've created a JIRA - https://issues.apache.org/jira/browse/TAP5-2210
>
> For the purpose of suggesting an "Alternatives" section for the tapestry
>
Sorry to bring up an old thread, I'm just reading it now - to my
entertainment and learning :)
I've created a JIRA - https://issues.apache.org/jira/browse/TAP5-2210
For the purpose of suggesting an "Alternatives" section for the tapestry
features that would be commonly used and how to initiate NO
Using serviceBinder.bind(Service, ServiceImpl).preventReloading() solves
the issue. Now I can use impl =
(ServiceImpl)ServiceProxyUtil.getImplementation(registry.getService(Service.class)).
So I dont need to invoke methods using reflection and I have AOP and
Decoration for the rest of the service m
I checked the sources. After setting production mode to test my proxy util
for this it does not change reload behaviour. It seams to be only switched
off in case a service is bound with preventReload or a global property to
prevent reloading is set or the service is not an interface.
So in the end
Dont see this to work with AOP on the LegacyInterface or do I overlook
something.
Better might be the use of a legacy service and provide an extended service
using refelction to access the legacy service implementation (subclass).
Would also make it clear and nice.
2013/10/16 Lance Java
> Here
Here's a workaround
public interface LegacyService {
void method1();
}
public class LegacyServiceImpl implements LegacyService {
public void method1() { ... }
public void method2() { ... }
}
public interface ExtendedService {
void m
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(ServiceProx
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(MyServ
>
> Also it makes everything feel stiff and decoupled in a not useful way.
>
> Stiff is the opposite of decoupled. And interfaces are quite useful, but
I'm not really in the mood of explaining why. OOP and IoC already do that
for me.
Nope. Completely wrong :). Stiff means not changeable in terms
Also, see @PostInjection:
/**
* Annotation for methods that should be invoked after injection. This
occurs last: after constructor injection and
* after field injection. It should be placed on a public
method. Any return value from the method is
* ignored. The order of invocation for class
On Tue, 15 Oct 2013 19:06:17 -0300, Martin Kersten
wrote:
AFAIK, just set the tapestry.production-mode symbol to true and service
reloading is turned off.<
Wasn't this also turning of the template realoading and Page/Component
replacement? Which I would like to have enabled.
See my other
On Tue, 15 Oct 2013 19:18:51 -0300, Martin Kersten
wrote:
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 tapestri
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
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 t
>AFAIK, just set the tapestry.production-mode symbol to true and service
reloading is turned off.<
Wasn't this also turning of the template realoading and Page/Component
replacement? Which I would like to have enabled.
Ok I use Screenshots and a Firefox Selenium Driver with a trigger so the
testca
On Tue, 15 Oct 2013 18:34:09 -0300, Lance Java
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.
Reloadable services are a development only feature that are aimed at
improving developer productivity by reducing down time.
As Thiago has said, casting to the concrete type is not good OO practice.
If you need to access methods on the concrete class it's probably a sign
that you need to add metho
On Tue, 15 Oct 2013 13:01:51 -0300, Martin Kersten
wrote:
I struggle a bit with the class loader supporting service implemenation
reloading.
AFAIK, just set the tapestry.production-mode symbol to true and service
reloading is turned off.
I dont need this and I would love to be able to c
I struggle a bit with the class loader supporting service implemenation
reloading. I dont need this and I would love to be able to cast my Service
instances to the impl class which is quite a good way.
Sometimes I think I want to go with a meta service object storing all the
services that are per
19 matches
Mail list logo
