John O'Hanley

Greenhorn
+ Follow
since Oct 13, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by John O'Hanley

There's a commecial tool called formula4j that was built for this purpose.

One disadvantage of eval and scripting tools is that they are open to injection attacks.
11 years ago
There's a tool called formula4j that will do the job. (It's a commercial tool.)
11 years ago
There is an alternative to replaceAll that avoids regular expressions:

The String.replace(CharSequence, CharSequence) method

See as well :
javapractices.com
16 years ago
No, no luck so far. If I find an answer, I will post it...
16 years ago
Custom error pages can be configured in web.xml.

When I use a Filter that wraps the response, the usual mechanism for serving custom error pages goes haywire. Why?

GOOD:
No filter:
custom error pages served OK.

GOOD:
Filter added, but does no wrapping of the response:
custom error pages served OK.

GOOD:
Filter added, wraps response, and
*filter code itself* throws an error :
custom error pages served OK.

BAD:
Filter added, wraps response, and
code *other than filter code* throws an error :
custom error pages NOT served.
Instead, a generic server error page is served.

WRONG ANSWER:
"Configure a dispatcher element for ERROR."
No, doesn't fix. Doesn't even apply, since such config
refers to when to *apply* a filter, not how errors
themselves are handled.

(Using Servlet2.4, Tomcat 5.5)

How do I ensure that my custom error pages are always
served, regardless of what filters are active?

- Perplexed.
16 years ago
Found the problem.

String(byte[]) will apparently *eliminate* null items in the array. The servlet container was using the raw byte[], and leaves nulls in, in some form or other. The nulls are translated into empty spaces somewhere along the way.

See the javadoc for String(byte[]), which says :
"The behavior of this constructor when the given bytes are not valid in the default charset is unspecified"

The fix was push the nulls to the end of the array, and to trim them off at the end.

The corrected code reads as :
18 years ago
Better formatting here :

18 years ago
Making a Servlet filter for trimming the leading space char's on each line. The implementation is acting in a way I cannot explain. The correct trimming appears to be done according to the log statements on the server, but the source in the browser shows the whitespace as still remaining! How can this be? Very puzzling behaviour...

public byte[] replaceContent(byte [] aBytes) {
fLogger.fine("Modified Output Stream : replaceContent().");

//eliminate initial spaces and tabs
byte[] result = new byte[aBytes.length];
for( int idx = 0 ; idx < aBytes.length; ++ idx ){
byte character = aBytes[idx];
if ( ! fCanEliminateSpacesAndTabs ) {

result[idx] = character;
// if ( character != '5' ) { //drop '5's as expected!
// result[idx] = character;
// }

if (character == '\r' || character == '\n') {
fCanEliminateSpacesAndTabs = true;
}
}
else {
if ( character == ' ' || character == '\t' ) {
//result[idx] = 'x'; //replaces spaces with x's as expected
//result[idx] = '\t'; //works as expected - replaces spaces with tabs
//result[idx] = '\u0000'; //logs OK, browser source not OK
//result[idx] = 0; //logs OK, browser source not OK
//when I 'do nothing' here to *drop* the whitespace, log shows OK, browser not OK - whitespaces reappears!!!
}
else {
result[idx] = character;
if ( character != '\r' && character != '\n' ) {
fCanEliminateSpacesAndTabs = false;
}
}
}
}
//This shows the desired result in the log, but served text still
//has initial spaces. why?
fLogger.fine("Result: " + new String(result)); //shows desired result!!
return result;
}
18 years ago
Here is an example of both static and dynamic replacement of text:
http://www.javapractices.com/Topic80.cjp
Here is inof about parsing in Java in general:
http://www.javapractices.com/Topic87.cjp
20 years ago
Here is some more <a href="http://www.javapractices.com/Topic83.cjp">example code</a> for this
task. It follows the style of the book "Java Platform Performance", by Wilson and Kesselman.
20 years ago
The answer:
JSPs always create a session, if one does not exist.
This default behavior is turned off using the page directive, as in
<%@ page session="false" %>
See:
http://www.javapractices.com/Topic191.cjp
20 years ago
JSP
Yes.
As shown in this log extract, the value is "ISO-8859-1", which is the default character encoding.
SESSION Object Name: javax.servlet.jsp.jstl.fmt.request.charset Value: "ISO-8859-1"
As well, I am using the Jakarta Taglibs implementation.
20 years ago
JSP
Well, according to my last quote of the JSTL spec, your comment is glaringly and incontrovertibly false.
20 years ago
JSP
FYI:
From the JSTL spec, section 8.4:
"After an action has called ServletResponse.setLocale(), and sessions are
enabled, it must determine the character encoding associated with the response locale (by calling ServletResponse.getCharacterEncoding()) and store it in the scoped variable javax.servlet.jsp.jstl.fmt.request.charset in session scope."
20 years ago
JSP