Title	JSPWiki with container authentication not compatible with IBM JDK
Date	25-Feb-2006 00:56:32 EET
Version	2.3
Submitter	89.55.177.112
Bug criticality	FatalBug
Browser version
Bug status	ClosedBug
PageProvider used
Servlet Container	Tomcat 5.5
Operating System	Win32, AIX
URL
Java version	IBM jdk-1.4.1

With container authentication JSPWiki does not start up with an IBM JDK, so it does not run on IBM's AIX or z/OS (they only have IBM JDKs).

24.02.2006 23:27:20 org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter WikiServletFilter
java.lang.NoClassDefFoundError: sun/security/util/PropertyExpander$ExpandException
	at com.ecyrd.jspwiki.auth.AuthenticationManager.initialize(AuthenticationManager.java:131)
	at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:540)

This is because AuthenticationManager uses internal sun classes which are not part of the official Java API and are not part of the IBM JDK.

If you want to reproduce this, you need either an IBM JDK for Linux or AIX. An IBM JDK for Windows you can only get as part of a DB2 for Windows. I did not try, but it should be included in DB2 Universal Database Express Edition, too. It is also included in a Websphere Application server. And as far as I know WAS only runs with an IBM JDK, so JSPWiki will not run with WAS with container authentication.

---

The root cause of this issue is probably line 283 of the com.ecyrd.jspwiki.auth.PolicyLoader class, which reads:

        if (!(Policy.getPolicy() instanceof PolicyFile)) 
        {
            throw new SecurityException(
            "Policy implementation must be of type sun.security.provider.PolicyFile.");
        } 

PolicyFile, and the related PropertyExpander, are indeed Sun classes. The reason we're doing the check for PolicyFile is to make sure that we can parse the jspwiki security policy, but it is probably unnecessary because most JVMs parse the default policy file format just fine.

Do you have access to the source code and a running IBM JDK? Could you try commenting out this code block and seeing if it makes a difference? It should. If it does, we will remove the check for PolicyFile.

In the meantime, here is a temporary workaround. Extract the jspwiki.policy file in the WAR file (in WEB-INF) to a directory of your choosing. Then, set the following JVM property before starting WAS or your preferred servlet container under the IBM JRE:

-Djava.security.policy=/path-to/jspwiki.policy

That will cause PolicyLoader to skip the check, and it won't try to parse the policy file (and load the Sun classes) as a result. -- Andrew Jaquith

--Andrew Jaquith, 25-Feb-2006

---

The Exception in the logs is not the SecurityException from the snippet you gave but rather the NoClassDefFoundError from the logs.

And I always run catalina.bat with

set CATALINA_OPTS="-Djava.security.manager -Djava.security.policy=D:\java\apache-tomcat-5.5.15\webapps\JSPWiki\WEB-INF\jspwiki.policy"

No, the problem is, when the VM first loads PolicyLoader.class it tries to resolve the import sun.security.util.PropertyExpander;

--Jürgen Weber, 25-Feb-2006

---

I dug in a bit further. Seems IBM split the rt.jar into a core.jar and some more. There is even a security.jar that contains some sun.* classes, but not the PropertyExpander. So, PolicyLoader.setJaasConfiguration() will not run with an IBM JDK.

--Jürgen Weber, 25-Feb-2006

---

Yes, the import issue makes perfect sense. Could you try removing the import and the instanceof PolicyFile code block to see if that would allow JSPWiki to run under the IBM JDK? If that works, I'll remove them from the CVS version also. -- Andrew Jaquith, 25-Feb-2006

---

Taking a closer look at things, I think we're going to have to remove the PropertyExpander stuff entirely, as well as the instanceof PolicyFile block... and there might be one more Sun class, ConfigFile that needs to come out... but *probably* not, since it seems to be the default implementation on all JDKs. Well, if you've still got the ability to do a quick snip-and-recompile I'd appreciate it if you'd give it a try with the IBM JDK. Otherwise I'll do it, but it's going to take me a while to get my Linux environment set up (I develop on OS X). --Andrew Jaquith, 26-Feb-2006

---

With JWhich I tried the three sun.* and com.sun.* classes you import, surprisingly the PolicyFile class is included in the IBM JDK (but not in GNU Classpath). When I commented out the missing imports in PolicyLoader.java, there were several other errors more and I didn't bother running the code, cause it surely wouldn't run.

E:\temp>E:\jdk-1.4.1-IBM\bin\java.exe -classpath . JWhich sun.security.provider.PolicyFile

Class 'sun.security.provider.PolicyFile' found in
'file:/E:/jdk-1.4.1-IBM/jre/lib/security.jar!/sun/security/provider/PolicyFile.class'

Classpath:
.

E:\temp>E:\jdk-1.4.1-IBM\bin\java.exe -classpath . JWhich sun.security.util.PropertyExpander

Class 'sun.security.util.PropertyExpander' not found.

Classpath:
.

E:\temp>E:\jdk-1.4.1-IBM\bin\java.exe -classpath . JWhich com.sun.security.auth.login.ConfigFile

Class 'com.sun.security.auth.login.ConfigFile' not found.

Classpath:
.

--Jürgen, 01-Mar-2006

---

In 2.3.91, I've removed all of the dependencies on Sun-specific Policy/Configuration classes. This should fix the issue. Could you try out the latest build and see if that helps you? Thanks.

--Andrew Jaquith, 30-Mar-2006

---

Congrats, now it's working. I checked with the IBM JDK under Windows. I have container-managed security against OpenLdap. (And I have removed the signing of jspwiki.jar, it still works).

--Jürgen Weber, 02-Apr-2006

---

Outstanding! I am marking this bug closed.

--Andrew Jaquith, 03-Apr-2006