In my last post I suspected the Woodstox lib to be the reason that Tapestry 5.1 does not work on Google App Engine (GAE).
So, I tried to eliminate the Woodstox lib and just use Stax – and it turned out to be really easy. The only problem was that the standard Stax parser does not handle DTDs in a nice way – you have to parse them yourself.
Changes to Tapestry:
- use XMLInputFactory instead of XMLInputFactory2 in TemplateParserImpl
- remove inputFactory.configureForSpeed(); in TemplateParserImpl
- use XMLStreamReader instead of XMLStreamReader2 in StaxTemplateParser
- change the dtd() method StaxTemplateParser to (this could be nicer):
private void dtd() throws XMLStreamException
String dtd = reader.getText();
String dtdElements = dtd.split(" ");
if(dtdElements.length > 3)
String rootName = dtdElements;
String publicId = null;
String systemId = null;
publicId = dtdElements;
if(dtdElements.length > 4)
systemId = dtdElements;
systemId = dtdElements;
tokenAccumulator.add(new DTDToken(rootName, publicId, systemId, getLocation()));
I have eliminated Woodstox – Tapestry runs now on plain Stax (included in JRE). But it still does not work on GAE – seems that the whole Stax package is locked and cannot be used. Maybe I give it another try. Hmmm.
I just got an Goole AppEngine account. The first thing I had to try was if Tapestry 5 works – and yes it does.
Then I tried a simple Tapestry 5.1 application (actually the same app with the newer library version and it does not work. What I got was this:
java.lang.RuntimeException: Exception constructing service 'TemplateParser':
Error invoking constructor org.apache.tapestry5.internal.services.TemplateParserImpl(Map, boolean) (at TemplateParserImpl.java:50)
via org.apache.tapestry5.internal.services.InternalModule.bind(ServiceBinder) (at InternalModule.java:65) (for service 'TemplateParser'):
Could not initialize class com.google.apphosting.runtime.security.shared.stub.javax.xml.stream.XMLInputFactory
It seems that the Woodstox StAX2 lib is the problem.
This time: Why the Internet Explorer supports only 251 (with extension) character filenames?
Recently our test guy of the QA department of our company was testing our newest web application. We have a simple HTML form file upload included in this app. The test case said that we check for file names with a maximum of 255 characters. The app is used with IE6 (yes it’s still out there), so we still have to test it there.
We got a ticket with: “Cannot upload file with more than 222 chars” from our QA. We checked the problem and found out that this seems to be a problem only in IE (6 and 7) not in Firefox. Funny. We also found out that NTFS supports only path length of 255 (not filename length). That means file can only have 255 chars in the root of the filesystem.
With this in mind we tested again – this time with files in the root of the file system – there they could be 255 chars. Again the problem was in IE – Firefox could upload files with 255 char filenames. We checked the Web for this without really finding anything.
Then I found out that the only problem in IE is the file picker – in the filename field you can enter 255 chars. You cannot select a file with more than 251 chars in the file system root.
Then our QA guy found the root of the problem: Microsoft Office does not support filename over a certain length (depends on version). You cannot open or save files with MsOffice 2000 with a filename longer than 251 chars (see also Microsoft Office Applications File Name Length Limitation). There is the reason.
Now you can ask yourself: “Does IE use the Office file picker or did the IE guys restrict filenames because of office? We’ll never know.
After my old blog hoster has given up his hosting server, I was offline for nearly a year. Now, I have set up a new one on wordpress.com and imported the old stuff from my old blog (big plus for WordPress). Hope my blogging rhytm is a bit more steady.
Most of the people are terrorized on flights. I’m not, especially after reading this article (at least I try not to ;)).