You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Martin Kersten <ma...@gmail.com> on 2013/10/15 18:01:51 UTC
Switching off Reloading of Service Implemenation?
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 thread directly and bound the concrete services
towards this meta service object lifecycle.
Having all services being as narrow focused as possible towards the
perThread scope makes it already look like a bunch of special services
fascating a big service at all (also it is not implemented this way).
Never the less is this reloading of serivce implementations build in or an
option I can switch off somehow. I did not dig into the code right now
since I have no computer at hand (well one with Eclipse on it).
Cheers,
Martin (Kersten),
Germany
Re: Switching off Reloading of Service Implemenation?
Posted by Martin Kersten <ma...@gmail.com>.
No comment... . :)
2013/10/28 Chris Mylonas <ch...@opencsta.org>
> 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 NOT using them -
> e.g. this service implementation preventReloading()
>
> I'm sure there are a few "alternatives" that would save some mailing list
> time and dev-ing.
>
> Cheers
> Chris
>
>
>
> On Wed, Oct 16, 2013 at 10:46 PM, Martin Kersten <
> martin.kersten.mk@gmail.com> wrote:
>
> > 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 methods as long as I use the proxy
> > to access the methods.
> >
> > Mission successful.
> >
> >
> > 2013/10/16 Martin Kersten <ma...@gmail.com>
> >
> > > 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 in production mode the reloading is enabled(?).
> > >
> > >
> > > 2013/10/16 Martin Kersten <ma...@gmail.com>
> > >
> > >> 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 <la...@googlemail.com>
> > >>
> > >>> Here's a workaround
> > >>>
> > >>> public interface LegacyService {
> > >>> void method1();
> > >>> }
> > >>>
> > >>> public class LegacyServiceImpl implements LegacyService {
> > >>> public void method1() { ... }
> > >>> public void method2() { ... }
> > >>> }
> > >>>
> > >>> public interface ExtendedService {
> > >>> void method2();
> > >>> }
> > >>>
> > >>> public interface Hack {
> > >>> public LegacyService getLegacyService();
> > >>> public ExtendedService getExtendedService();
> > >>> }
> > >>>
> > >>> AppModule
> > >>> ---------
> > >>> public Hack buildHack(@Autobuild LegacyServiceImpl impl) {
> > >>> return new Hack() {
> > >>> public LegacyService
> > getLegacyService() {
> > >>> return impl; }
> > >>>
> > >>> public ExtendedService
> > >>> getExtendedService()
> > >>> {
> > >>> return new
> > >>> ExtendedService()
> > >>> {
> public
> > >>> void
> > >>> method2()
> > >>> {
> > >>> return impl.method2();
> > >>> }
> > >>> };
> > >>> };
> > >>> };
> > >>> }
> > >>>
> > >>> public LegacyService buildLegacyService(Hack hack) {
> > >>> return hack.getLegacyService();
> > >>> }
> > >>>
> > >>> public ExtendedService buildExtendedService(Hack hack) {
> > >>> return hack.getExtendedService();
> > >>> }
> > >>>
> > >>>
> > >>>
> > >>> Component
> > >>> ---------
> > >>> @Inject
> > >>> private LegacyService legacyService;
> > >>>
> > >>> @Inject
> > >>> private ExtendedService extendedService;
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Switching off Reloading of Service Implemenation?
Posted by Chris Mylonas <ch...@opencsta.org>.
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 NOT using them -
e.g. this service implementation preventReloading()
I'm sure there are a few "alternatives" that would save some mailing list
time and dev-ing.
Cheers
Chris
On Wed, Oct 16, 2013 at 10:46 PM, Martin Kersten <
martin.kersten.mk@gmail.com> wrote:
> 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 methods as long as I use the proxy
> to access the methods.
>
> Mission successful.
>
>
> 2013/10/16 Martin Kersten <ma...@gmail.com>
>
> > 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 in production mode the reloading is enabled(?).
> >
> >
> > 2013/10/16 Martin Kersten <ma...@gmail.com>
> >
> >> 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 <la...@googlemail.com>
> >>
> >>> Here's a workaround
> >>>
> >>> public interface LegacyService {
> >>> void method1();
> >>> }
> >>>
> >>> public class LegacyServiceImpl implements LegacyService {
> >>> public void method1() { ... }
> >>> public void method2() { ... }
> >>> }
> >>>
> >>> public interface ExtendedService {
> >>> void method2();
> >>> }
> >>>
> >>> public interface Hack {
> >>> public LegacyService getLegacyService();
> >>> public ExtendedService getExtendedService();
> >>> }
> >>>
> >>> AppModule
> >>> ---------
> >>> public Hack buildHack(@Autobuild LegacyServiceImpl impl) {
> >>> return new Hack() {
> >>> public LegacyService
> getLegacyService() {
> >>> return impl; }
> >>>
> >>> public ExtendedService
> >>> getExtendedService()
> >>> {
> >>> return new
> >>> ExtendedService()
> >>> { public
> >>> void
> >>> method2()
> >>> {
> >>> return impl.method2();
> >>> }
> >>> };
> >>> };
> >>> };
> >>> }
> >>>
> >>> public LegacyService buildLegacyService(Hack hack) {
> >>> return hack.getLegacyService();
> >>> }
> >>>
> >>> public ExtendedService buildExtendedService(Hack hack) {
> >>> return hack.getExtendedService();
> >>> }
> >>>
> >>>
> >>>
> >>> Component
> >>> ---------
> >>> @Inject
> >>> private LegacyService legacyService;
> >>>
> >>> @Inject
> >>> private ExtendedService extendedService;
> >>>
> >>
> >>
> >
>
Re: Switching off Reloading of Service Implemenation?
Posted by Martin Kersten <ma...@gmail.com>.
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 methods as long as I use the proxy
to access the methods.
Mission successful.
2013/10/16 Martin Kersten <ma...@gmail.com>
> 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 in production mode the reloading is enabled(?).
>
>
> 2013/10/16 Martin Kersten <ma...@gmail.com>
>
>> 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 <la...@googlemail.com>
>>
>>> Here's a workaround
>>>
>>> public interface LegacyService {
>>> void method1();
>>> }
>>>
>>> public class LegacyServiceImpl implements LegacyService {
>>> public void method1() { ... }
>>> public void method2() { ... }
>>> }
>>>
>>> public interface ExtendedService {
>>> void method2();
>>> }
>>>
>>> public interface Hack {
>>> public LegacyService getLegacyService();
>>> public ExtendedService getExtendedService();
>>> }
>>>
>>> AppModule
>>> ---------
>>> public Hack buildHack(@Autobuild LegacyServiceImpl impl) {
>>> return new Hack() {
>>> public LegacyService getLegacyService() {
>>> return impl; }
>>>
>>> public ExtendedService
>>> getExtendedService()
>>> {
>>> return new
>>> ExtendedService()
>>> { public
>>> void
>>> method2()
>>> {
>>> return impl.method2();
>>> }
>>> };
>>> };
>>> };
>>> }
>>>
>>> public LegacyService buildLegacyService(Hack hack) {
>>> return hack.getLegacyService();
>>> }
>>>
>>> public ExtendedService buildExtendedService(Hack hack) {
>>> return hack.getExtendedService();
>>> }
>>>
>>>
>>>
>>> Component
>>> ---------
>>> @Inject
>>> private LegacyService legacyService;
>>>
>>> @Inject
>>> private ExtendedService extendedService;
>>>
>>
>>
>
Re: Switching off Reloading of Service Implemenation?
Posted by Martin Kersten <ma...@gmail.com>.
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 in production mode the reloading is enabled(?).
2013/10/16 Martin Kersten <ma...@gmail.com>
> 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 <la...@googlemail.com>
>
>> Here's a workaround
>>
>> public interface LegacyService {
>> void method1();
>> }
>>
>> public class LegacyServiceImpl implements LegacyService {
>> public void method1() { ... }
>> public void method2() { ... }
>> }
>>
>> public interface ExtendedService {
>> void method2();
>> }
>>
>> public interface Hack {
>> public LegacyService getLegacyService();
>> public ExtendedService getExtendedService();
>> }
>>
>> AppModule
>> ---------
>> public Hack buildHack(@Autobuild LegacyServiceImpl impl) {
>> return new Hack() {
>> public LegacyService getLegacyService() {
>> return impl; }
>>
>> public ExtendedService
>> getExtendedService()
>> {
>> return new
>> ExtendedService()
>> { public
>> void
>> method2()
>> {
>> return impl.method2();
>> }
>> };
>> };
>> };
>> }
>>
>> public LegacyService buildLegacyService(Hack hack) {
>> return hack.getLegacyService();
>> }
>>
>> public ExtendedService buildExtendedService(Hack hack) {
>> return hack.getExtendedService();
>> }
>>
>>
>>
>> Component
>> ---------
>> @Inject
>> private LegacyService legacyService;
>>
>> @Inject
>> private ExtendedService extendedService;
>>
>
>
Re: Switching off Reloading of Service Implemenation?
Posted by Martin Kersten <ma...@gmail.com>.
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 <la...@googlemail.com>
> Here's a workaround
>
> public interface LegacyService {
> void method1();
> }
>
> public class LegacyServiceImpl implements LegacyService {
> public void method1() { ... }
> public void method2() { ... }
> }
>
> public interface ExtendedService {
> void method2();
> }
>
> public interface Hack {
> public LegacyService getLegacyService();
> public ExtendedService getExtendedService();
> }
>
> AppModule
> ---------
> public Hack buildHack(@Autobuild LegacyServiceImpl impl) {
> return new Hack() {
> public LegacyService getLegacyService() {
> return impl; }
>
> public ExtendedService getExtendedService()
> {
> return new
> ExtendedService()
> { public void
> method2()
> {
> return impl.method2();
> }
> };
> };
> };
> }
>
> public LegacyService buildLegacyService(Hack hack) {
> return hack.getLegacyService();
> }
>
> public ExtendedService buildExtendedService(Hack hack) {
> return hack.getExtendedService();
> }
>
>
>
> Component
> ---------
> @Inject
> private LegacyService legacyService;
>
> @Inject
> private ExtendedService extendedService;
>
Re: Switching off Reloading of Service Implemenation?
Posted by Lance Java <la...@googlemail.com>.
Here's a workaround
public interface LegacyService {
void method1();
}
public class LegacyServiceImpl implements LegacyService {
public void method1() { ... }
public void method2() { ... }
}
public interface ExtendedService {
void method2();
}
public interface Hack {
public LegacyService getLegacyService();
public ExtendedService getExtendedService();
}
AppModule
---------
public Hack buildHack(@Autobuild LegacyServiceImpl impl) {
return new Hack() {
public LegacyService getLegacyService() {
return impl; }
public ExtendedService getExtendedService()
{
return new
ExtendedService()
{ public void
method2()
{
return impl.method2();
}
};
};
};
}
public LegacyService buildLegacyService(Hack hack) {
return hack.getLegacyService();
}
public ExtendedService buildExtendedService(Hack hack) {
return hack.getExtendedService();
}
Component
---------
@Inject
private LegacyService legacyService;
@Inject
private ExtendedService extendedService;
Re: Switching off Reloading of Service Implemenation?
Posted by Martin Kersten <ma...@gmail.com>.
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 <la...@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;
>
Re: Switching off Reloading of Service Implemenation?
Posted by Lance Java <la...@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;
Re: Switching off Reloading of Service Implemenation?
Posted by Martin Kersten <ma...@gmail.com>.
>
> 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 of thinking
and feel. Its like this once famous code smell attitude.
Are you using test first? Sometimes you sound like a waterfall programmer
(design, implement, verify).
>
> Today I am totally against using interfaces for services as long as you
> control the code and also are the end user of your code. It is simplier
> and clearer.
>
> Now try to write an unit test.
What would be the problem? I always extend the implementation class or mock
methods away. With all these final methods and classes being used when this
abstract stuff was famous 15-10 years ago, it can now considered not that
usefull anymore. Never program defensive unless it can be used to prevent
hard to spot bugs introduced by accidental miss usages.
But lets stop arguing :) It is not an OOP practice to program abstract to
express an implementation detail. And if you start write small methods the
abstractness you might favor in having in interfaces is not as good as the
abstractness that well placed and often encountered method names brings
into the picture.
----
Here is the code and documentation piece why I thought it was not possible
to use concrete service implemenations.
public <T> ServiceBindingOptions bind(Class<T> serviceClass)
{
if (serviceClass.isInterface())
{
try
{
String expectedImplName = serviceClass.getName() + "Impl";
ClassLoader classLoader = proxyFactory.getClassLoader();
Class<T> implementationClass = (Class<T>)
classLoader.loadClass(expectedImplName);
if (!implementationClass.isInterface() &&
serviceClass.isAssignableFrom(implementationClass))
{
return bind(
serviceClass, implementationClass);
}
throw new
RuntimeException(IOCMessages.noServiceMatchesType(serviceClass));
} catch (ClassNotFoundException ex)
{
throw new RuntimeException(String.format("Could not find
default implementation class %sImpl. Please provide this class, or bind the
service interface to a specific implementation class.",
serviceClass.getName()));
}
}
return bind(serviceClass, serviceClass);
}
See the last line wins. Thought it only works with interfaces and throws a
runtime exception if no implementation is found. The user guide also states:
"Following the convention over configuration principle, the autobuilding of
services can be even less verbose. If a service interface is passed as a
single argument to the bind() method, Tapestry will try to find an
implementation in the same package whose name matches the name of the
service interface followed by the suffix *Impl*."
So I just overlooked the intention of the method after all. But yet again
its about style and cognitive attitude. I for myself find the method above
harder to read as it should and also the implementation does not reflect
once intention about this method, here is a better way to represent the
intention:
public <T> ServiceBindingOptions bind(Class<T> serviceType) {
if (serviceType.isInterface())
bindInterface(serviceType, findImplementation(serviceType));
else
bindConcrete(serviceType);
}
See easy to understand. Thats the problem when you are used to write short
methods (the best advise I ever got, thanks mr beck :)). The problem also
is that class is used ambitious since Java has interfaces to be thought
about as classes. Java should have better be off using the type ->(Class |
Interface) speaking.
Also remember that every if requires an else or you do something wrong in
first place. If is splitting the program flow and therefore partitionate
the problem space of the method and therefore should particionate the
solution space as well. Therefore write a method. I often see lots of ifs
in tapestry making the source code leaving me with a feel of reading
something written by a slight autistic person (those who do something but
think beyond what they do, so making it harder for a focused reader to
understand).
Well but enought talk. OOP is good and if you read fowler, beck, evans and
martin of the last decade (old, I am) you will see that their style differs
in the way they think. Check out the 10year old discussion of state vs.
behavioural testing around fowler and his mates at thought works. He was
wrong in 'rejecting' behavioural testing as a good way to test. And yet
again those discussion emerge everywhere anytime. So lets stop here.
I write small methods, coupled in the how and decoupled in the what realm.
That's what I do. And from now on, I try to write not about it anymore.
Enough said and we already came to the conclusion that we disagree on that.
2013/10/16 Thiago H de Paula Figueiredo <th...@gmail.com>
> 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 <strong>public
> method</strong>. Any return value from the method is
> * ignored. The order of invocation for classes with multiple marked
> methods (including methods inherited from
> * super-classes) is not, at this time, defined.
> * <p/>
> * Tapestry also honors the {@link javax.annotation.**PostConstruct}
> annotation, and treats it identically to
> * PostInjection. This is both more flexible than PostConstruct (in that
> methods may have parameters, and multiple methods
> * may be annotated) but also falls short (Tapestry will only seek out
> public methods).
> */
> @Target(ElementType.METHOD)
> @Retention(RetentionPolicy.**RUNTIME)
> @Documented
> @UseWith(AnnotationUseContext.**SERVICE)
> public @interface PostInjection
>
> {
> }
>
> --
> 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<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Switching off Reloading of Service Implemenation?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
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 <strong>public
method</strong>. Any return value from the method is
* ignored. The order of invocation for classes with multiple marked
methods (including methods inherited from
* super-classes) is not, at this time, defined.
* <p/>
* Tapestry also honors the {@link javax.annotation.PostConstruct}
annotation, and treats it identically to
* PostInjection. This is both more flexible than PostConstruct (in that
methods may have parameters, and multiple methods
* may be annotated) but also falls short (Tapestry will only seek out
public methods).
*/
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@UseWith(AnnotationUseContext.SERVICE)
public @interface PostInjection
{
}
--
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
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switching off Reloading of Service Implemenation?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 15 Oct 2013 19:06:17 -0300, Martin Kersten
<ma...@gmail.com> 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 e-mail for the solution.
> This way I rather use no reload capability at all. But sometimes it
> happens.
You could just not change the service implementation while performing your
tests.
> How can I inject a concrete implementations?
The same way you inject interface-based services. You just need to declare
the service without specifying a service interface.
binder.bind(YourConcreteService.class);
> Please do not lecture me on OOP :-)
I love lecturing! I can't help it! :P
> I did my share with doing this
> Interface first programming style in 2001 (i guess) - programming only
> with public interfaces and public static factories for several weeks to
> get into and adopt this style. So if I do not want to use interfaces at
> all it has a good reason and is fully in line with OOP and IOC you can
> trust me.
No, I don't trust you for this one, reasons below.
> Today I am totally against using interfaces for services as long as you
> control the code and also are the end user of your code. It is simplier
> and clearer.
Now try to write an unit test.
> No additional interface to document, maintain and to describe
Wrong. If you need to document the interface well, you don't need to
document the implementation, except for specific implementation details.
That's what the Tapestry sources do, by the way.
> something you already see in the interface.
I have no idea what you're talking about. "No additional interface to
document what you already see in the interface?". I'm not following you.
> 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.
> So Yes it is good to have services around but it is depressing having an
> IOC that forces you to use service interfaces instead of concrete
> instances, makes no sense and feels overly complex ...
What IoC you're talking about? Tapestry-IoC it isn't, as it doesn't force
you the write service interfaces. Never did.
> PS: you mentioned this its against OOP thing quite some times. Stop doing
> so. OOP is something different then a style. Its a way to decompose and
> model reality (well a section of it). Thats all. Nothing about style.
> There is some measure of good and not so good OOP but this is well...
> style.
Maybe I've not chosen the appropriate word, but I stand by what I said.
--
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
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switching off Reloading of Service Implemenation?
Posted by Martin Kersten <ma...@gmail.com>.
>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
testcase opens a firefox window that is visible to me and
then waits until I am done with inspecting the result. It also is able to
take a screenshot and compare it to an expected image of the
page or at least presenting me the image. I use a JFrame image viewer that
updates every time the image changes. Makes it
simple to just run the test and look at the pages outcome when doing this
style adjustments.
This way I rather use no reload capability at all. But sometimes it happens.
> Of course, you can still inject services (including service
implementations) by id, so you can get the implementations themselves when
the needs arises.<
How can I inject a concrete implementations?
>>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.<<
> That's quite against the idea of IoC and OOP in general, which is about
*not* using specific implementations of a given service as far as possible.<
Please do not lecture me on OOP :-) I did my share with doing this
Interface first programming style in 2001 (i guess) - programming only with
public interfaces and public static factories for several weeks to get into
and adopt this style. So if I do not want to use interfaces at all it has a
good reason and is fully in line with OOP and IOC you can trust me.
Today I am totally against using interfaces for services as long as you
control the code and also are the end user of your code. It is simplier and
clearer. No additional interface to document, maintain and to describe
something you already see in the interface. Also it makes everything feel
stiff and decoupled in a not useful way.
So Yes it is good to have services around but it is depressing having an
IOC that forces you to use service interfaces instead of concrete
instances, makes no sense and feels overly complex ... So that has nothing
to do with IOC and OOP, its just about to ease the implementation of the
IOC (now in doupt) and also might have historic reason. So this lesson is
not about OOP, IOC or whatever. This is about having a service for
implementation that is serving concrete implemenation needs. So nothing to
design (in terms of architecture) or to abstract here. Just plain old
dependency inversion within the implementation realm.
PS: you mentioned this its against OOP thing quite some times. Stop doing
so. OOP is something different then a style. Its a way to decompose and
model reality (well a section of it). Thats all. Nothing about style. There
is some measure of good and not so good OOP but this is well... style. And
yet again there are those principles, which are good to know and all. The
rest is cognitive properties like experience, complexity and all this more
or less fishy defined stuff. So yes OOP ok but nope not against it, I can
ensure you :).
2013/10/15 Thiago H de Paula Figueiredo <th...@gmail.com>
> On Tue, 15 Oct 2013 13:01:51 -0300, Martin Kersten <
> martin.kersten.mk@gmail.com> 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 cast my Service instances
>> to the impl class which is quite a good way.
>>
>
> That's quite against the idea of IoC and OOP in general, which is about
> *not* using specific implementations of a given service as far as possible.
> Of course, you can still inject services (including service
> implementations) by id, so you can get the implementations themselves when
> the needs arises.
>
> --
> 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<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Switching off Reloading of Service Implemenation?
Posted by Cezary Biernacki <ce...@gmail.com>.
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" <ma...@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 <th...@gmail.com>
>
> > On Tue, 15 Oct 2013 18:34:09 -0300, Lance Java <
> lance.java@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-unsubscribe@tapestry.apache.org>
> >
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
Re: Switching off Reloading of Service Implemenation?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 15 Oct 2013 19:18:51 -0300, Martin Kersten
<ma...@gmail.com> 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 tapestries registry is using the autobuild,
Nope, that's not correct at all.
public interface Service {
public String method(String string);
}
public class ServiceImpl implements Service {
public String method(String string) {
return null;
}
}
public class TestModule {
public static void bind(ServiceBinder binder) {
binder.bind(ServiceImpl.class);
}
}
RegistryBuilder builder = new RegistryBuilder();
builder.add(TestModule.class);
final Registry build = builder.build();
final ServiceImpl service = build.getService(ServiceImpl.class);
System.out.println(service.getClass().getName());
The lines above print "method_advice.ServiceImpl" (all classes here are in
the method_advice package).
That was tested in Tapestry-IoC 5.3.6 and 5.4-alpha-22, so you've been
complaining without reason (except for the
annotations-in-service-interface-methods, but that will be fixed soon).
> You have to annotate the interface to describe an implementation detail.
> Wow that is really good OOP to the max (sarcasm intended).
This is a known limitation which bugs me a awful lot (just check the
mailing list archives) and it's in my plans to fix it myself:
https://issues.apache.org/jira/browse/TAP5-2029
> Would be way better then this interface heavy IOC.
OOP good practices are interface-heavy, so is IoC.
> What is about creating a service using a builder method? This should at
> least selectively avoids the reload classloader thing, right?
Service class reloading is disabled by setting the
tapestry.production-mode symbol, something I've said before in this same
thread, to false or calling binder.bind(***).preventReloading().
Case closed. :D
--
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
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switching off Reloading of Service Implemenation?
Posted by Martin Kersten <ma...@gmail.com>.
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 <th...@gmail.com>
> On Tue, 15 Oct 2013 18:34:09 -0300, Lance Java <la...@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<us...@tapestry.apache.org>
>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Switching off Reloading of Service Implemenation?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 15 Oct 2013 18:34:09 -0300, Lance Java <la...@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
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switching off Reloading of Service Implemenation?
Posted by Lance Java <la...@googlemail.com>.
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 methods to the interface since the interface describes
your public API.
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.
On 15 October 2013 17:47, Thiago H de Paula Figueiredo
<th...@gmail.com>wrote:
> On Tue, 15 Oct 2013 13:01:51 -0300, Martin Kersten <
> martin.kersten.mk@gmail.com> 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 cast my Service instances
>> to the impl class which is quite a good way.
>>
>
> That's quite against the idea of IoC and OOP in general, which is about
> *not* using specific implementations of a given service as far as possible.
> Of course, you can still inject services (including service
> implementations) by id, so you can get the implementations themselves when
> the needs arises.
>
> --
> 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<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Switching off Reloading of Service Implemenation?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 15 Oct 2013 13:01:51 -0300, Martin Kersten
<ma...@gmail.com> 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 cast my Service
> instances to the impl class which is quite a good way.
That's quite against the idea of IoC and OOP in general, which is about
*not* using specific implementations of a given service as far as
possible. Of course, you can still inject services (including service
implementations) by id, so you can get the implementations themselves when
the needs arises.
--
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
For additional commands, e-mail: users-help@tapestry.apache.org