Wednesday, July 26, 2006

Slide 2.1 working with Security on WebSphere

slide 2.1 security websphere
Slide 2.1 does not work "out-of-the-box" with WebSphere 6. It seems most slide-users have worked around it by turning off security. Clearly, this is not an option for a production system - so we need to get it working.
This is a elaboration on my post #12099 to the slide-user list. Thanks to the post on the list from Lynn Richards #10690. A committer is welcome to add any content from here to the Slide-Wiki on WebSphere Setup. It certainly needs more detail. You will need:
  • slide-server-2.1 source code - in order to make corrections and re-build.

  • IBM HTTP Server (IHS) and the Web Server Plugin

Slide Source Changes - UTF-8

There are a two places (that I could find) in the code where the content type is set to "text/xml; charset=\"UTF-8\"". The WebSphere servlet container can't handle the quotes around the encoding. This needs to be changed to "text/xml; charset=UTF-8". This works for Tomcat too, so perhaps it should be committed in the server source?
  1. jakarta-slide-server-src-2.1\src\webdav\server\org\apache\slide\webdav\method\
    < public static final String TEXT_XML_UTF_8 = "text/xml; charset=\"UTF-8\"";
    > public static final String TEXT_XML_UTF_8 = "text/xml; charset=UTF-8";
  2. jakarta-slide-server-src-2.1\src\webdav\server\org\apache\slide\webdav\util\
    <         res.setContentType("text/html; charset=\"UTF-8\"");
    >         res.setContentType("text/html; charset=UTF-8");

Slide Configuration

"/" Path "Forbidden"

The issue where all paths appear to be "/" no matter what path is accessed on Slide is due to the following code in jakarta-slide-server-src-2.1-\src\webdav\server\org\apache\slide\webdav\util\ and a difference in implementation between WebSphere and Tomcat
    String result = null;
  if (config.isDefaultServlet()) {
      result = req.getServletPath();
  } else {
      result = req.getPathInfo();
req.getServletPath() seems to always be "/" in WebSphere when the WebDAV servlet is mapped to "/". The solution is to force slide to use the getPathInfo() method by turning off the Default Servlet flag in the web.xml:

The EAR file might be corrupt? web.xml validation

When you install a war file on WebSphere the web.xml is parsed and validated against the spec. Any discrepancies with the spec will give you the un-helpful error that the "EAR file might be corrupt". Add the detail below to you opening node in the web.xml and make sure it is valid according to the schema (using an editor such as XML Spy) before including it in the war file:
You'll find that all the <description> nodes are in the wrong place within the <init-param> nodes - they should be the first child rather than the last.
More importantly is the security-constraint section. To get authentication, you must define the constraint for all the possible http (WebDAV) methods. The problem is according to the web.xml spec, the only valid http-method values are: HEAD, GET, POST, PUT, DELETE, OPTIONS and TRACE. To have the other WebDAV methods secure as well, leave the specific http-method constraints out. This node is optional and if you don't specify any, all Http methods will be secure and this will include the WebDAV extensions too.
 <!-- Uncomment this to get authentication -->
      <web-resource-name>DAV resource</web-resource-name>
      <!-- comment out the explicit http-method list                     
   'valid' Http Methods
         Http Extensions

WebSphere Configuration

Global Security

How to configure WebSphere with a Custom or LDAP realm is beyond the scope of this post (maybe later) but with Security turned on, you will need to either Turn off "Java 2 Security" or define a policy file for the slide web-app.
With Java 2 security on, slide will get AccessControlException(s) when it tries to check for the existence of things like its properties file (from the "java.home" location? See - it will catch the exception if the load fails but not if the file.exists() check is forbidden).

WebServer Integration

It appears that when the WebSphere AppServer handles HTTP requests it assumes the same default as the IBM WebServer, namely - content is only to be expected and read for POST and PUT requests. This page on IBM's support site is old but seems to apply for v6 as well: Software
Group Ref #1145705
To get the WebDAV extensions to HTTP working you need to configure the IBM WebServer with the AppServer using IBM's WebServer Plugin. It's in the Plugin where you're then able to allow content in all HTTP/WebDAV requests. Ie "true" for
Specifies whether or not users can include content in POST, PUT, GET, and HEAD requests when a Content-Length or Transfer-encoding header is contained in the request header. You can specify one of the following values for this attribute:

  • true if content is to be expected and read for all requests
  • false if content only is only to be expected and read for POST and PUT requests.
false is the default.
If you have version 6, with the WebServer and AppServer on the same machine and the Server setup to propagate changes to the plugin-cfg.xml file, you can set this flag in the Admin Console:
  • Web servers > webserver1 > Plug-in properties > Request and response
    Check the box for - Accept content for all requests
I found integrating the AppServer with the WebServer via plugin not a simple process. You should do this before installing slide and use the /snoop servlet to check if things are working via the WebServer.

Aside: If you try a URL like: http://localhost/snoop/hello/world/ok you will see the difference between the ServletPath and PathInfo in WebSphere and why we need to force slide to use the later.
You could actually use a WebServer other than IBM's. The difference will be that you may need to manually configure the Plugin in the AppServer and WebServer and then when the Admin console updates the plugin-cfg.xml file you may need to copy this to the place where the WebServer expects.

Installing Slide

After you install/deploy the slide.war (I gave it the enterprise application name of "slide") you need to edit the Class Loading properties.
Class loader mode = Parent Last
WAR class loader policy = Application
This avoids the problem of WebSphere v6 including an older version of JDOM (1.0Beta7) in its lib folder as well as property file loading issues. Check that slide has been correctly associated with the WebServer Plugin:
  • Enterprise Applications > slide > Map modules to servers
    You should see something like:
It's important to see both the server and the webserver "module" in this list.
After starting the slide application it should be accessible via the WebServer (port 80 by default). All access will have to be via the WebServer and this should hopefully work without error and will be secure.

Tuesday, July 18, 2006

AccessControlException access denied WebSphere

Keywords: access denied websphere

After enabling global security in WebSphere, all access to file system resources from the web app gives "AccessControlException" messages. The application can't load it's properties file(s).

I actually found this solution pretty quickly with a google search. Need to turn off "Java 2 Security" in the Global Security settings or define a policy that allows your application access to the resources it needs.

To disable "Java 2 Security"
  1. Open the administrative console and go to Security-->Gloabal Security
  2. Uncheck "Enforce Java 2 Security"
  3. Save the changes and restart WebSphere
To define a policy

Monday, July 17, 2006

Can't deploy WAR on WebSphere 6 - AppDeploymentException

websphere war deploy install "The EAR file might be corrupt or incomplete" DeploymentDescriptorLoadException

Trying to deploy ("install") a war file (for the Jakarta Slide WebDAV Server) in WebSphere after it appeared to work fine on Tomcat & JBoss gets the following two messages in the WebSphere Administration Console:

  1. The EAR file might be corrupt or incomplete.

  2. AppDeploymentException: [null] IWAE0022E Exception occurred loading deployment descriptor for module "[warfilename].war" in EAR file "[WebSphereHome]\profiles\[ProfileName]\wstemp\[TempFolder]\upload\[warfilename]_war.ear"

The first message (and the .ear part of the second) is very confusing and from a quick google it seems that many developers are thrown off and attempt to put their war file in an ear ... it's not necessary.

The clue was the cause exception "DeploymentDescriptorLoadException" in the second message. It's a long story how I got to this, but the issue was my deployment descriptor - WEB-INF\web.xml. WebSphere validates this against the schema for the web.xml and is not flexible. Add this detail to you opening <web-app> node in your web.xml and make sure it is valid according to the schema (using an editor such as XML Spy):
<web-app version="2.4" 

In my situation slide contained a security-constraint which in turn referenced http-method names that aren't valid according to the web.xml spec (limited to HEAD, GET, POST, PUT, DELETE, OPTIONS, TRACE). But WebDAV extends the HTTP spec ... not sure what to do about that. Commenting out the entire security-constraint section or the offending http-method references fixes the issue for the mean time.

Next issue is how to configure some basic users and roles in WebSphere. The documentation seems very thorough on overviews and definitions, but light-on when it comes to how-tos.

Tuesday, July 11, 2006

Cannot load into server: The specified procedure could not be found

apache mod_jk "The specified procedure could not be found" tomcat

I've download the Apache HTTP server and according to the site "2.2.2 is the best available version". The downloaded mod_jk from the where it claimed that the download was for Apache 2.0, and works with Apache 2.0.55 and later ... there was no 2.2.x download so I assumed (wrongly) that this would work with Apache 2.2.x as it is "later".

Added the LoadModule line in the httpd.conf file as instructed in
and got the following error:
Cannot load [full path]/ into server: The specified procedure could not be found

You can't use a Apache 2.0.x module with Apache 2.2.x apparently - it must be built pointing at that specific version of Apache (if you're clever enough to build your own modules with the source code then this is no problem - you could get the source for JK 1.2.15 and build it pointing at your install Apache 2.2.x).

If you rely on the binaries built by Apache, use the HTTP server 2.0.x

Wednesday, July 05, 2006

xalan parameter must be a "valid Java Object"

xalan IllegalArgumentException "The value of param" "must be a valid Java Object"

On an application server (JBoss) where you can't control the version of xalan that is getting loaded with your web application, you get the following error in the preparation phase of a XML transform:
java.lang.IllegalArgumentException: The value of param [param-name] must be a valid Java Object
at org.apache.xalan.transformer.TransformerImpl.setParameter(

The issue here is that the object being set in the javax.xml.transform.Transformer.setParameter(String name, Object) is a null. In xalan 2.5.0 this doesn't seem to be an issue, but in xalan 2.7.0 it is!

Stop the null being put set as a parameter and the issue is solved.

The last few posts have been around this issue of the web application not being able to control its classpath in JBoss. I've tried the ClassLoadingConfiguration advice in the JBoss Wiki with no success. The endorsed directory contains the different xalan library (as visible in the "sun.boot.class.path" system property) and despite specifying some sort of isolation, the endorsed directory still applies. As the issue was ultimately with a newer version of xalan and it's probably be bad to be putting nulls in anyway I haven't tried to force this class/library loading issue.

Monday, July 03, 2006

Invalid or corrupt jarfile

"Invalid or corrupt jarfile" java -jar manifest file

Packaging up a class with a main method into a jar-file using ant gives the following error when you try to run it with the java -jar [jarfile] command: "Invalid or corrupt jarfile".

Using the ant task to create the manifest file on-the-fly gives you and entry like:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.2
Created-By: 1.4.2_07-b05 (Sun Microsystems Inc.)
Main-Class: com.example.MyMainClass

Creating the manifest file myself, with the bare essentials fixes the issue:
Manifest-Version: 1.0
Main-Class: com.example.MyMainClass

With more investigation I'm sure I could have got the dynamic meta-file creation working with Ant as I know other people do - there must be some peculiarity in the combination of my ant version (1.6.2), java version (1.4.2_07) and perhaps the current phase of the moon.

Parsing of the Meta-inf file has been an issue that has come-up, been fixed and then come-up again for sun. See: Bug Id: 4991229. If you can work out if this bug exists in the your (or my) version of the Java SE you have more patience that me.