Committed on:
Portal 6.2.x GIT ID: 6ca59d4527d9dac47e357b546332d88dc96237c8.

Next, with all the classpath problems resolved, we are still unable to startup Jetty without errors:

WARN:oejuc.AbstractLifeCycle:FAILED org.eclipse.jetty.security.ConstraintSecurityHandler@2973cb2c: java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@6ceac619 in org.eclipse.jetty.security.ConstraintSecurityHandler@2973cb2c
java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@6ceac619 in org.eclipse.jetty.security.ConstraintSecurityHandler@2973cb2c

We have already configured the jetty-testrealm.xml to be used in start.ini, but for some reason this wasn't working. In order to work around the issue, it looks like we need to actually set the value against the loginService against the securityHandler.

http://stackoverflow.com/questions/9111759/http-error-503-accessing-jenkins-reason-service-unavailable

Since the jetty-testrealm.xml wasn't helping with the startup, it was removed. Since we were using the Test Realm in our default configuration rather than JAAS, it made the most sense to bring the old Test Realm configuration into the Liferay context rather than try to get things working with JAAS.

While starting Jetty with the --list-options command line switch works, we still have the same exception when invoking run.sh even though invoking java -jar start.jar normally allows for a startup to actually begin.

Through a process of elimination, the "jetty.version" environment variable is what prevents the startup from occurring. Therefore, we needed to rename the environment variable in order to allow for a proper startup to occur.

On startup, Jetty throws the following exception:

java.lang.ClassNotFoundException: org.eclipse.jetty.xml.XmlConfiguration
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:424)
at org.eclipse.jetty.start.Main.start(Main.java:602)
at org.eclipse.jetty.start.Main.main(Main.java:82)
ClassNotFound: org.eclipse.jetty.xml.XmlConfiguration

This is due to some problems that occur when Jetty is constructing its classpath. The root of the problem is revealed when you try to start Jetty with the --list-options command line switch.

27: 1.1 | ${jetty.home}/lib/ext/liferay/activation.jar
28: private-2011/04/13-23:33:42 | ${jetty.home}/lib/ext/liferay/hsql.jar
java.lang.NullPointerException
at org.eclipse.jetty.start.JarVersion.getMainManifestImplVersion(JarVersion.java:70)
at org.eclipse.jetty.start.JarVersion.getVersion(JarVersion.java:136)
at org.eclipse.jetty.start.Main.getVersion(Main.java:854)
at org.eclipse.jetty.start.Main.showAllOptionsWithVersions(Main.java:801)
at org.eclipse.jetty.start.Main.start(Main.java:531)
at org.eclipse.jetty.start.Main.main(Main.java:82)

By checking the source code, the Manifest that is being passed to JarVersion.getMainManifestImplVersion() is null. As this is retrieved from a JarFile object, checking the Javadocs for JarFile reveals that the Manifest object will be null if the manifest is missing.

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/jar/JarFile.html#getManifest()

So basically, Jetty's code does not handle this edge case and in order to resolve the initial startup error, we need to find the JAR that is missing a MANIFEST.MF file and add that file to it. It turns out that the file that's missing the MANIFEST.MF is jta.jar and so to resolve the initial startup error, we add a MANIFEST.MF to that JAR to resolve the issue.

Hi Brian,

Guess it's solved for 6.1.1 GA2 too, isn't it? (it's committed to 6.1.x branch)