You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Zonsheine, David" <Da...@Orbitz.com> on 2011/12/21 14:09:56 UTC
Table display disappears when moving to Tomcat 6.0.29
Hi,
I want to share a table display issue we spent a few days on fixing when moving our tomcat webapp from tomcat 6.0.16 to 6.0.32.
It took us a while to understand that an 'offers' page does not work correctly (does not display a table) not because of a data problem (We have moved to a new api with the offers (coreg) host, and to OJF7.14) but because of a ui issue.
That was after we concluding that the page stops working with the other change but with tomcat Tomcat 6.0.32.
Drilling down we find that the Tomcat versions from which the problem starts we have found that the problem arises specifically on Tomcat 6.0.29.
In parallel investigating this we saw the problem relates to the way table are built on the page.
This is a dynamic build of tables (table ids, for each loop using the ids, javascript manipulation using the ids). And furthermore, the parameter there were used to build the dynamic ids was an *Enum*.
The enum that was used was built like this:
{code}
public enum OfferType {
LEISURE,
BUSINESS;
public static OfferType fromString(String str) {
if (StringUtils.isNotEmpty(str)) {
if (str.equals(LEISURE.toString())) {
return LEISURE;
}
else if (str.equals(BUSINESS.toString())) {
return BUSINESS;
}
}
return null;
}
public String toString() {
switch (this) {
case LEISURE:
return "Leisure";
case BUSINESS:
return "Business";
default:
return "";
}
}
}
{code}
As we use the enum for string in the page the toString() method were called. The method output was different from the OfferType.name output. This mismatch caused an inconsistency between the dynamically created tables and reading the table ids. A mismatch between to CamelCase output of toString() and the upperCase output of OfferType.name.
h3. So why this happened when moving to Tomcat 6.0.32?
This is [why|https://issues.apache.org/bugzilla/show_bug.cgi?id=50105].
You can see was fixed in [Tomcat v.6.0.29|http://tomcat.apache.org/tomcat-6.0-doc/changelog.html]
h3. In short
Tomcat fix to match the EL specification (to use Enum.name instead of toString()) switched on the mismatch problem. Until the fix only the toString method was used. After the change the Enum.name was used for the EL expression and toString for other usage of the Enum.
h3. Simple fix.
In our case it was enough to take out the toString method and get rid of the CamelCase string.
{code}
public enum OfferType {
LEISURE,
BUSINESS;
// we override just for get rid of the potential exceptions of valueOf.
// Nothing to do with the problem described.
public static OfferType fromString(String str) {
try {
return valueOf(str);
}
catch(final Exception exception) {
return null;
}
}
}
{code}
Re: Table display disappears when moving to Tomcat 6.0.29
Posted by Pid <pi...@pidster.com>.
On 21/12/2011 13:09, Zonsheine, David wrote:
> Hi,
>
> I want to share a table display issue we spent a few days on fixing when moving our tomcat webapp from tomcat 6.0.16 to 6.0.32.
>
> It took us a while to understand that an 'offers' page does not work correctly (does not display a table) not because of a data problem (We have moved to a new api with the offers (coreg) host, and to OJF7.14) but because of a ui issue.
>
> That was after we concluding that the page stops working with the other change but with tomcat Tomcat 6.0.32.
>
> Drilling down we find that the Tomcat versions from which the problem starts we have found that the problem arises specifically on Tomcat 6.0.29.
>
> In parallel investigating this we saw the problem relates to the way table are built on the page.
>
> This is a dynamic build of tables (table ids, for each loop using the ids, javascript manipulation using the ids). And furthermore, the parameter there were used to build the dynamic ids was an *Enum*.
>
> The enum that was used was built like this:
>
> {code}
> public enum OfferType {
> LEISURE,
> BUSINESS;
>
> public static OfferType fromString(String str) {
>
> if (StringUtils.isNotEmpty(str)) {
> if (str.equals(LEISURE.toString())) {
> return LEISURE;
> }
> else if (str.equals(BUSINESS.toString())) {
> return BUSINESS;
> }
> }
>
> return null;
> }
>
> public String toString() {
> switch (this) {
> case LEISURE:
> return "Leisure";
> case BUSINESS:
> return "Business";
> default:
> return "";
> }
> }
> }
> {code}
Err, 'case' statements in there... !?
A couple of small notes:
Avoiding the thrown exception just means you increase the risk of an NPE
at some point later - IMHO if it's not the correct enum type, trap the
exception & handle it properly.
Were I to attempt what you /were/ attempting, I would write the enum as
follows:
public enum OfferType {
LEISURE("Leisure"),
BUSINESS("Business")
; // <--- this semicolon is required, don't forget it
private String prettyName;
private OfferType(String prettyName) {
this.prettyName = prettyName;
}
@Override
public String toString() {
return prettyName;
}
}
p
> As we use the enum for string in the page the toString() method were called. The method output was different from the OfferType.name output. This mismatch caused an inconsistency between the dynamically created tables and reading the table ids. A mismatch between to CamelCase output of toString() and the upperCase output of OfferType.name.
>
> h3. So why this happened when moving to Tomcat 6.0.32?
>
> This is [why|https://issues.apache.org/bugzilla/show_bug.cgi?id=50105].
>
> You can see was fixed in [Tomcat v.6.0.29|http://tomcat.apache.org/tomcat-6.0-doc/changelog.html]
>
> h3. In short
> Tomcat fix to match the EL specification (to use Enum.name instead of toString()) switched on the mismatch problem. Until the fix only the toString method was used. After the change the Enum.name was used for the EL expression and toString for other usage of the Enum.
>
> h3. Simple fix.
>
> In our case it was enough to take out the toString method and get rid of the CamelCase string.
>
> {code}
> public enum OfferType {
> LEISURE,
> BUSINESS;
>
> // we override just for get rid of the potential exceptions of valueOf.
> // Nothing to do with the problem described.
> public static OfferType fromString(String str) {
> try {
> return valueOf(str);
> }
> catch(final Exception exception) {
> return null;
> }
> }
> }
> {code}
--
[key:62590808]