RE: T.5.2.x Possible page pooling removal impact query
Thanks Josh. I think some of the fields I was concerned about ex. private final Pattern validatorPattern = Pattern.compile(VALIDATOR_PATTERN); would just be final, and not static - probably wasn't giving solid enough examples, but I have enough to go on now, and have identified a small number of areas I'm going to update. Worth highlighting anyway I think, as the kind of errors that can creep in a hard to pin down (at least for me!). Thanks. Regards, Jim. -Original Message- From: Josh Canfield [mailto:joshcanfi...@gmail.com] Sent: 22 January 2011 14:27 To: Tapestry users Subject: Re: T.5.2.x Possible page pooling removal impact query As far as I can remember, the removal of the page pool only affects *non*-static fields. Static variables wouldn't be affected only because they already needed to be thread safe. On Jan 21, 2011 6:48 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Anyone care to have a quick glance at the attachment for coding red flags they could highlight, or even just advise on whether it is a question of tracking down third party source to check if there are thread safety issues in any of their called methods? Thanks a million. As far as I can remember, the removal of the page pool only affects *non*-static fields. Anyway, as a general rule, you should never initialize a non-static field in its declaration (unless the value is immutable). Your code only has static fields, so using or not the page pool won't make any difference at all. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: T.5.2.x Possible page pooling removal impact query
Thanks for the feedback Donny. The code excerpts are a few taken from
various support classes (not page classes, though they are used throughout
the app including within page classes) with static members / methods grouped
under various contexts (date / number / string utils etc.) The logger is
slf4j (with log4j). The Money / Scalar classes are wrappers for BigDecimal,
to allow money / arithmetic ops with predictable precision. I found a few
instances of Matcher that I think I will bundle into a service. Thanks for
your help.
Regards,
Jim.
-Original Message-
From: Donny Nadolny [mailto:donny.nado...@gmail.com]
Sent: 21 January 2011 22:23
To: Tapestry users
Subject: Re: T.5.2.x Possible page pooling removal impact query
I glanced over it, it looks okay. A few notes:
You didn't give the package name for Logger, Money, or Scalar, so I can't
comment on them, although Log4j's Logger is thread safe, and I would guess
most loggers are.
Pattern is thread safe, but note that Matcher is not.
Yes, it is just a matter of looking through any objects that you initialize
in the Page class, outside of a method. An alternative is to create any
variables you need in setupRender() rather than when you declare them in the
class, only moving them out if they cause poor performance (and checking
that they're thread safe beforehand). My coding style normally is not to
have many objects like that in the page class, instead having them in
services.
Attachment text for the archives:
In the release notes for T.5.2.0
(http://tapestry.apache.org/release-notes-52.html#ReleaseNotes5.2-Tap5.2.0)
there is a section on references to non thread-safe objects and the impact
upon them of the removal of Page Pooling, using:
private final DateFormat format =
DateFormat.getDateInstance(DateFormat.MEDIUM, locale);
... as a problem example. I have a few examples below of some code I am
using and am concerned about introducing subtle bugs that are difficult to
track down.
private final static Logger log =
LoggerFactory.getLogger(VitasBasePage.class);
public static final Money MAX_VALUE = new Money(.99);
public static final Currency DEFAULT_CURRENCY = Currency.getInstance(EUR);
public static final boolean USE_PRODUCTION_PORTS =
!(false.equals(System.getProperty(PRODUCTION_PORTS_PARAM)));
private static final int ROUNDING_MODE = BigDecimal.ROUND_HALF_EVEN;
public static final Scalar HALF = new Scalar(0.5);
static final String VALIDATOR_PATTERN=(?!)\\s*,\\s*(?!([0-9]*\\}));
private final Pattern validatorPattern = Pattern.compile(VALIDATOR_PATTERN);
public static final String DATE_FORMAT_NOW = -MM-dd HH:mm:ss;
public static final int MILLISECS_PER_DAY = 8640;
public static String now() {
Calendar cal = Calendar.getInstance();
SimpleDateFormat sdf = new SimpleDateFormat(DATE_FORMAT_NOW);
return sdf.format(cal.getTime());
}
public static String now(String dateFormat) {
Calendar cal = Calendar.getInstance();
SimpleDateFormat sdf = new SimpleDateFormat(dateFormat);
return sdf.format(cal.getTime());
}
On Fri, Jan 21, 2011 at 5:07 PM, Jim O'Callaghan
jc1000...@yahoo.co.ukwrote:
The spam filter has blocked this email up to the 4th attempt so I've put
most of it into the attached text file.
The query relates to thread safety, specifically the example in the
T.5.2.0
release notes
(http://tapestry.apache.org/release-notes-52.html#ReleaseNotes5.2-Tap5.2.0
)
Anyone care to have a quick glance at the attachment for coding red flags
they could highlight, or even just advise on whether it is a question of
tracking down third party source to check if there are thread safety
issues
in any of their called methods? Thanks a million.
Regards,
Jim.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
RE: T.5.2.x Possible page pooling removal impact query
Thanks for the feedback Thiago. Regards, Jim. -Original Message- From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] Sent: 22 January 2011 02:47 To: Tapestry users Subject: Re: T.5.2.x Possible page pooling removal impact query Anyone care to have a quick glance at the attachment for coding red flags they could highlight, or even just advise on whether it is a question of tracking down third party source to check if there are thread safety issues in any of their called methods? Thanks a million. As far as I can remember, the removal of the page pool only affects *non*-static fields. Anyway, as a general rule, you should never initialize a non-static field in its declaration (unless the value is immutable). Your code only has static fields, so using or not the page pool won't make any difference at all. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informa��o Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T.5.2.x Possible page pooling removal impact query
As far as I can remember, the removal of the page pool only affects *non*-static fields. Static variables wouldn't be affected only because they already needed to be thread safe. On Jan 21, 2011 6:48 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Anyone care to have a quick glance at the attachment for coding red flags they could highlight, or even just advise on whether it is a question of tracking down third party source to check if there are thread safety issues in any of their called methods? Thanks a million. As far as I can remember, the removal of the page pool only affects *non*-static fields. Anyway, as a general rule, you should never initialize a non-static field in its declaration (unless the value is immutable). Your code only has static fields, so using or not the page pool won't make any difference at all. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T.5.2.x Possible page pooling removal impact query
I glanced over it, it looks okay. A few notes:
You didn't give the package name for Logger, Money, or Scalar, so I can't
comment on them, although Log4j's Logger is thread safe, and I would guess
most loggers are.
Pattern is thread safe, but note that Matcher is not.
Yes, it is just a matter of looking through any objects that you initialize
in the Page class, outside of a method. An alternative is to create any
variables you need in setupRender() rather than when you declare them in the
class, only moving them out if they cause poor performance (and checking
that they're thread safe beforehand). My coding style normally is not to
have many objects like that in the page class, instead having them in
services.
Attachment text for the archives:
In the release notes for T.5.2.0
(http://tapestry.apache.org/release-notes-52.html#ReleaseNotes5.2-Tap5.2.0)
there is a section on references to non thread-safe objects and the impact
upon them of the removal of Page Pooling, using:
private final DateFormat format =
DateFormat.getDateInstance(DateFormat.MEDIUM, locale);
... as a problem example. I have a few examples below of some code I am
using and am concerned about introducing subtle bugs that are difficult to
track down.
private final static Logger log =
LoggerFactory.getLogger(VitasBasePage.class);
public static final Money MAX_VALUE = new Money(.99);
public static final Currency DEFAULT_CURRENCY = Currency.getInstance(EUR);
public static final boolean USE_PRODUCTION_PORTS =
!(false.equals(System.getProperty(PRODUCTION_PORTS_PARAM)));
private static final int ROUNDING_MODE = BigDecimal.ROUND_HALF_EVEN;
public static final Scalar HALF = new Scalar(0.5);
static final String VALIDATOR_PATTERN=(?!)\\s*,\\s*(?!([0-9]*\\}));
private final Pattern validatorPattern = Pattern.compile(VALIDATOR_PATTERN);
public static final String DATE_FORMAT_NOW = -MM-dd HH:mm:ss;
public static final int MILLISECS_PER_DAY = 8640;
public static String now() {
Calendar cal = Calendar.getInstance();
SimpleDateFormat sdf = new SimpleDateFormat(DATE_FORMAT_NOW);
return sdf.format(cal.getTime());
}
public static String now(String dateFormat) {
Calendar cal = Calendar.getInstance();
SimpleDateFormat sdf = new SimpleDateFormat(dateFormat);
return sdf.format(cal.getTime());
}
On Fri, Jan 21, 2011 at 5:07 PM, Jim O'Callaghan jc1000...@yahoo.co.ukwrote:
The spam filter has blocked this email up to the 4th attempt so I've put
most of it into the attached text file.
The query relates to thread safety, specifically the example in the T.5.2.0
release notes
(http://tapestry.apache.org/release-notes-52.html#ReleaseNotes5.2-Tap5.2.0
)
Anyone care to have a quick glance at the attachment for coding red flags
they could highlight, or even just advise on whether it is a question of
tracking down third party source to check if there are thread safety issues
in any of their called methods? Thanks a million.
Regards,
Jim.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T.5.2.x Possible page pooling removal impact query
Anyone care to have a quick glance at the attachment for coding red flags they could highlight, or even just advise on whether it is a question of tracking down third party source to check if there are thread safety issues in any of their called methods? Thanks a million. As far as I can remember, the removal of the page pool only affects *non*-static fields. Anyway, as a general rule, you should never initialize a non-static field in its declaration (unless the value is immutable). Your code only has static fields, so using or not the page pool won't make any difference at all. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
