Enavigo

The assignment my students have to complete has functionality that involves outputing an XML Document into a file. So nice of the DOM folks to NOT have that functionality in the Document object, but good enough, we have the Transformer object which can do just that.

Using the Transformer object’s transform() method that allows you to send the result of a transformation into an output stream – a file.

The students were asked to save the XML to a file in the home folder of the person grading the assignment – a property accessible by using the Java method:
System.getProperty("user.home")
In Windows, the property is mapped to:
[DRIVE]:\Documents and Settings\[USER NAME]
“Documents and Settings” have spaces between the words ‘Documents’, ‘and’ and ‘Settings’. That, is, an, issue, if, you, are, using JBoss on Windows – why?

Let’s go back to the Transformer: we are supposed to be able to use this code…

File file = new File([PATH WITH SPACES]);
Result result = new StreamResult(file);
transformer.transform([source xml], result);


On JBoss something this innocuous will produce a FileNotFoundException, saying it cannot find the file at [DRIVE]:\Documents%20and%20Settings\[USER NAME] – the file location is escaped as if the file location was a URL. This is a problem and appaerently there is/was an open bug on the JBoss JIRA server. JBoss 4.0.1sp1 still does not have it resolved and the issue is apparently rooted in the FileURLConnection that handles files in JBoss. Sorta uncool, eh?

Solution:
Instead of going the file route directly, how about we use a stream instread:

PrintWriter outStream = new PrintWriter(new FileOutputStream([FILE_LOCATION]));
StreamResult fileResult = new StreamResult(outStream);
transformer.transform(source, fileResult);


Hope this helps!

I am a teaching fellow for a J2EE class at the Harvard Extension this semester and we are using the JBoss Application Server v. 4.0.1. Today, while examining homework assignment submissions one of my peers sends me an EAR file asking me to try and deploy it. All EAR files for the assignment are expected to have the same name.

JBoss is supposed to allow you – assuming the EAR file is correctly packaged – to simply copy the EAR file into its $JBOSS_HOME/server/default/deploy and have it install the application automatically. An application with the same name as an application already there is supposed to overwrite the application that was already there.

Sure of that, I go ahead and overwrite the existing application EAR file. JBoss’ console shows that the application deployed OK and was started. I hence try to access the application in its URL and lo and behold – I get the JSP welcome page of the application I just deleted! OK… I follow the procedure that was developed with pain and tears and stop JBoss, delete the application EAR file from the aforementioned deploy folder; then proceed to delete anything with the same name as the EAR file from the $JBOSS_HOME/server/default/tmp/deploy.

I started JBoss again, accessed the application URL and got, as I expected, a 404 error. Deployed the application again and whoa – the OLD application’s ghost was still present – I got the old application’s welcome JSP page. This is WEIRD.

An e-mail flurry ensues, we research feverishly, until co-TF Martin comes up with the answer (documentation shmocumentation…): There is also a $JBOSS_HOME/server/default/work/jboss.web/[SERVER_NAME]/ folder which contains a folder for each of the deployed applications. It appears that the accessed JSPs are converted into classes there. A quick deletion of that folder solves the problem completely and the new application finally rears its pretty head. THANKS MARTIN!