Re: svn commit: r782672 - in /incubator/click/trunk/click/examples/src/org/apache/click/examples/page/table: SearchTablePage.java TableStyles.java

[Bob Schellink <sa...@gmail.com>]

Malcolm Edgar wrote:
> Interesting - should services be considered as transient. In Spring
> services are generally singletons, if the transient variable reference
> becomes null its not going to be reset.


Hmm, I've noticed Serialization exceptions in the logs because the 
stateful Pages references non-serializable services. Thought transient 
should be an easy fix. But if Spring is not going to re-inject them we 
should revert back.

Re: svn commit: r782672 - in /incubator/click/trunk/click/examples/src/org/apache/click/examples/page/table: SearchTablePage.java TableStyles.java

[Bob Schellink <sa...@gmail.com>]

Malcolm Edgar wrote:
>>
>> Another option might be to change the way "injected Spring beans" work
>> (option 3 from the javadoc). Currently the beans are injected when a new
>> instance of Page is created. However we could change this so that injections
>> occurs in the "activatePageInstance" method, much like ApplicationContext is
>> re-injected.
> 
> I did this pattern in an earlier revision of the SpringClickServlet,
> maybe work putting this in.


Just to clarify, I suggest the "injected Spring beans" approach only 
for the stateful Page examples: table/TableStyles.java and 
table/SearchTablePage. For stateless Pages the annotation based 
approach works great.

bob

Re: svn commit: r782672 - in /incubator/click/trunk/click/examples/src/org/apache/click/examples/page/table: SearchTablePage.java TableStyles.java

[Malcolm Edgar <ma...@gmail.com>]

On Wed, Jun 10, 2009 at 6:07 AM, Bob Schellink<sa...@gmail.com> wrote:
> Malcolm Edgar wrote:
>>
>> I suppose the service should be made serializable, this should not be
>> any problem as it is stateless
>
>
> This is certainly one option but as far as best practice goes it could be
> problematic as Spring services tend to reference each other.
> I can imagine a situation where serialization can pull in lots of referenced
> Spring services, which could lead to problems.

I would become a problem if a service referenced an object graph, e.g.
an in memory cache etc.  So people would need to take care. I wonder
if Spring has an activate/passivate concept.

> Playing around with the various options it seems that stateful Pages might
> be better off using the ApplicationContext injection approach:
>
> public class StatefulPage extends Page implements ApplicationContextAware {
>
>  ...
>
>  public CustomerService getCustomerService() {
>    return (CustomerService) ctx.getBean("customerService");
>  }
>
>  public void setApplicationContext(ApplicationContext applicationContext)
> throws BeansException {
>        this.ctx = applicationContext;
>    }
> }
>
> The ApplicationContext is re-injected by Click, even for stateful pages,
> meaning the service can be looked up instead of injected.
>
> Another option might be to change the way "injected Spring beans" work
> (option 3 from the javadoc). Currently the beans are injected when a new
> instance of Page is created. However we could change this so that injections
> occurs in the "activatePageInstance" method, much like ApplicationContext is
> re-injected.

I did this pattern in an earlier revision of the SpringClickServlet,
maybe work putting this in.

> Anyway just throwing around some ideas.
>
> bob
>
>

Re: svn commit: r782672 - in /incubator/click/trunk/click/examples/src/org/apache/click/examples/page/table: SearchTablePage.java TableStyles.java

[Bob Schellink <sa...@gmail.com>]

Malcolm Edgar wrote:
> I suppose the service should be made serializable, this should not be
> any problem as it is stateless


This is certainly one option but as far as best practice goes it could 
be problematic as Spring services tend to reference each other.
I can imagine a situation where serialization can pull in lots of 
referenced Spring services, which could lead to problems.

Playing around with the various options it seems that stateful Pages 
might be better off using the ApplicationContext injection approach:

public class StatefulPage extends Page implements 
ApplicationContextAware {

   ...

   public CustomerService getCustomerService() {
     return (CustomerService) ctx.getBean("customerService");
   }

  public void setApplicationContext(ApplicationContext 
applicationContext) throws BeansException {
         this.ctx = applicationContext;
     }
}

The ApplicationContext is re-injected by Click, even for stateful 
pages, meaning the service can be looked up instead of injected.

Another option might be to change the way "injected Spring beans" work 
(option 3 from the javadoc). Currently the beans are injected when a 
new instance of Page is created. However we could change this so that 
injections occurs in the "activatePageInstance" method, much like 
ApplicationContext is re-injected.

Anyway just throwing around some ideas.

bob

Re: svn commit: r782672 - in /incubator/click/trunk/click/examples/src/org/apache/click/examples/page/table: SearchTablePage.java TableStyles.java

[Malcolm Edgar <ma...@gmail.com>]

I suppose the service should be made serializable, this should not be
any problem as it is stateless

On Tue, Jun 9, 2009 at 8:33 AM, Bob Schellink<sa...@gmail.com> wrote:
> Malcolm Edgar wrote:
>>
>> Interesting - should services be considered as transient. In Spring
>> services are generally singletons, if the transient variable reference
>> becomes null its not going to be reset.
>
>
> Hmm, I've noticed Serialization exceptions in the logs because the stateful
> Pages references non-serializable services. Thought transient should be an
> easy fix. But if Spring is not going to re-inject them we should revert
> back.
>