Saturday, September 23, 2006

Zuzu Angel

0 comments
Assistam ao filme acima. Excelente produção nacional, contando uma parte da história do Brasil que muitos não conhecem. Muito boas interpretações.

Problems counting characters with JavaScript and Firefox?

1 comments
Basically Firefox, when counting a textarea string length, counts each breakline as one characters, but expands it to CRLF when submitting. If you have a database limit and relies on JavaScript to keep your textarea under this limit, a simple JavaScript function will not work. Surprising, but it will work perfectly in Internet Explorer, although commonly the inverse is true when we find JavaScript problems.

To solve that problem, I created a modified version that seems to be working so far:

function textCounter(field,cntfield,maxlimit) {
var extra = 0;
if (navigator.appName=="Netscape" &&
parseInt(navigator.appVersion)>=5) {
var index = field.value.indexOf('\n');
while(index != -1) {
extra += 1;
index = field.value.indexOf('\n',index+1);
}
}
if (field.value.length + extra > maxlimit)
field.value = field.value.substring(0, maxlimit-extra);
else
cntfield.value = maxlimit - field.value.length - extra;
}


In case of Firefox (and Netscape, for that matter), it counts the breaklines, adding or subtracting this amount when checking the number of characters.

If you find some problem here or know a better version available on the internet, please let me know. I searched, but couldn't find a version that overcomes this Firefox behavior.

Thursday, September 14, 2006

JSVC and APR do not work together for HTTPS connector

0 comments
That is an old bug that I did not have time to provider further information yet.

Anyway, I don't need jsvc any longer, since Apache is proxying to Tomcat, but it is an interesting thing to debug and help improving Tomcat.

Tuesday, September 05, 2006

Apache httpd proxying to Tomcat (with Acegi redirection)

0 comments
I ran into some problems when testing a Apache HTTPD server proxying, through AJP protocol, to Tomcat where the main application used Spring and Acegi. Acegi performs an excellent work of redirecting from HTTP to HTTPS (and vice-versa) when a given URL requires secure or insecure channel. However, it was not redirecting properly when Apache was proxying all the requests.

Initially I thought it was a problem with proxying, but after checking the log, I realized that Acegi was not redirecting to the correct places but only to the context root (e.g /context/). After checking its source code (if a simple Google search does not return what we expect, it is the second fastest way), I noticed that my portMapper object was not being used by the redirection classes (such as RetryWithHttpsEntryPoint). That would not be problem if I were not using non-standard ports (standard ones are 80->443 and 8080->8443).

So, in order to fix this problem, you may do the following:

1 - Change your ports to standard ones (even if only for testing purposes).

2 - Instantiate a portMapper object and define http->https ports (try to have 1-1 relationship, avoiding 80->443, 81->443, in order to avoid problems when Acegi redirects https to http).

3 - Inject this portMapper object in objects that perform redirection, such as: RetryWithHttpsEntryPoint, RetryWithHttpEntryPoint and AuthenticationProcessingFilterEntryPoint (I can't remember any other classes at this moment).

This last step may be somewhat tricky, since you must instantiate RetryWithHttpsEntryPoint, for example, inject portMapper in it. And you must inject your instantiated object into SecureChannelProcessor. The same goes for InsecureChannelProcessor and RetryWithHttpEntryPoint.

In my case, it was much simpler to move to standard ports :-) But at least I found out a way of solving it if I couldn't change the ports.

Log NullPointerException when starting Tomcat

5 comments
if you find the following stacktrace when starting Tomcat with commons-logging-1.1.jar and log4j:


java.lang.NullPointerException
at org.apache.log4j.Category.isEnabledFor(Category.java:757)
at org.apache.commons.logging.impl.Log4JLogger.isTraceEnabled(Log4JLogge
r.java:327)


It seems to be related to a bug in commons-logging related to the implementation of support for trace-level logging. Replace it with and older version (such as 1.0.4). At least for me it worked pretty well. It seems that commons-logging passes a wrong parameter to log4j.

I commented it in Tomcat bug 39090 (actually the same stacktrace is refered in 39631, but it was set as duplicated).