You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by bhorvat <ho...@gmail.com> on 2013/01/10 00:34:58 UTC
Reason not to use static final
Is there any reason not to use static final something in the page classes?
I want to introduce some const field that is only needed in the page class
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Reason-not-to-use-static-final-tp5719227.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Reason not to use static final
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 10 Jan 2013 18:39:26 -0200, Cezary Biernacki <ce...@gmail.com>
wrote:
> However they are not really created and discarded for every request,
> just access private variables is changed in bytecode,
> and content is stored outside class instances.
> It is something that typical Java code does not do.
But, in Tapestry code, the fields, from our code perspective, still works
the same way as if they weren't changed at bytecode leve.
> Another complication rises from mutable objects stored in a user session
> (e.g. @Persist or @SessionState), as they might be accessed
> simultaneously.
This is actually a general problem in Java webapps based directly or
indirectly in the Servlet API (or maybe even all or at least most webapps
in any language).
> Personally, I would avoid any synchronization code in page/component
> classes. It would mean that all static fields could hold only immutable
> data.
> If some mutable state would need to be shared between threads,
> I would delegate synchronization handling either to services
> or to mutable objects themselves.
Agreed. :)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Reason not to use static final
Posted by Cezary Biernacki <ce...@gmail.com>.
I don't think that you can blindly apply to general Java logic to code in
page and component classes.
They are rewritten by Tapestry, and normal rules don't fully apply.
On surface page and components behave
as they would be created and discarded for every request,
so you normally don't need to worry about synchronizing access
to private variables (but still there are some special cases).
However they are not really created and discarded for every request,
just access private variables is changed in bytecode,
and content is stored outside class instances.
It is something that typical Java code does not do.
Another complication rises from mutable objects stored in a user session
(e.g. @Persist or @SessionState), as they might be accessed simultaneously.
Personally, I would avoid any synchronization code in page/component
classes.
It would mean that all static fields could hold only immutable data.
If some mutable state would need to be shared between threads,
I would delegate synchronization handling either to services
or to mutable objects themselves.
Best regards,
Cezary
On Thu, Jan 10, 2013 at 8:07 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 10 Jan 2013 16:37:14 -0200, bhorvat <ho...@gmail.com>
> wrote:
>
> Interesting.
>>
>> And what would be best approach for the multiple threads accessing the
>> same
>> even handler?
>>
>>
>> Synchronized key word, synchronized block, using Lock or Barrier or
>> something else?
>>
>
> If your event handler method uses only parameters, its own variables and
> non-static fields, you don't need any kind of synchronization. Otherwise,
> this question becomes off-topic, being a general Java question and not
> something related to Tapestry.
>
> --
> Thiago H. de Paula Figueiredo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Reason not to use static final
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 10 Jan 2013 16:37:14 -0200, bhorvat <ho...@gmail.com>
wrote:
> Interesting.
>
> And what would be best approach for the multiple threads accessing the
> same
> even handler?
>
>
> Synchronized key word, synchronized block, using Lock or Barrier or
> something else?
If your event handler method uses only parameters, its own variables and
non-static fields, you don't need any kind of synchronization. Otherwise,
this question becomes off-topic, being a general Java question and not
something related to Tapestry.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Reason not to use static final
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 10 Jan 2013 17:30:03 -0200, bhorvat <ho...@gmail.com>
wrote:
> Awesome then. I think that before (maybe still, but I think it has moved
> from that) tapestry was using some sort of page pool, so that was my
> concern.
Tapestry isn't using a page pool since 5.2. In addition, page pool or not,
this doesn't make a difference, as Tapestry always shielded your code from
synchronization problems related to pages and their non-static fields.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Reason not to use static final
Posted by bhorvat <ho...@gmail.com>.
Awesome then. I think that before (maybe still, but I think it has moved from
that) tapestry was using some sort of page pool, so that was my concern.
cheers
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Reason-not-to-use-static-final-tp5719227p5719243.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Reason not to use static final
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 10 Jan 2013 17:24:38 -0200, bhorvat <ho...@gmail.com>
wrote:
> It is more of a general question, what approach should be there
> considering tapestry?
The same as not using Tapestry. ;)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Reason not to use static final
Posted by bhorvat <ho...@gmail.com>.
It is not related to that.
It is more of a general question, what approach should be there considering
tapestry?
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Reason-not-to-use-static-final-tp5719227p5719241.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Reason not to use static final
Posted by Howard Lewis Ship <hl...@gmail.com>.
Don't put shared mutable state into a static field.
On Thu, Jan 10, 2013 at 6:37 PM, bhorvat <ho...@gmail.com> wrote:
> Interesting.
>
> And what would be best approach for the multiple threads accessing the same
> even handler?
>
>
> Synchronized key word, synchronized block, using Lock or Barrier or
> something else?
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Reason-not-to-use-static-final-tp5719227p5719237.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: Reason not to use static final
Posted by bhorvat <ho...@gmail.com>.
Interesting.
And what would be best approach for the multiple threads accessing the same
even handler?
Synchronized key word, synchronized block, using Lock or Barrier or
something else?
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Reason-not-to-use-static-final-tp5719227p5719237.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Reason not to use static final
Posted by Howard Lewis Ship <hl...@gmail.com>.
Tapestry ignores static fields when performing instrumentation. I often use
static final fields. If you make them public, you can access them from the
template as if they were a property.
On Wed, Jan 9, 2013 at 11:34 PM, bhorvat <ho...@gmail.com> wrote:
> Is there any reason not to use static final something in the page classes?
>
> I want to introduce some const field that is only needed in the page class
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Reason-not-to-use-static-final-tp5719227.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com