On Thu, 10 Jan 2013 18:39:26 -0200, Cezary Biernacki
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 T
On Thu, 10 Jan 2013 17:30:03 -0200, bhorvat
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 does
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 wo
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
On Thu, 10 Jan 2013 17:24:38 -0200, bhorvat
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 unsubscrib
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
, 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.
>
> --
On Thu, 10 Jan 2013 16:37:14 -0200, bhorvat
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 paramete
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
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 wrote:
> Is there any reason not to use static final someth
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
11 matches
Mail list logo
