Develop Reference

Connect Java Mission Control to Wildfly 16

I try to connect Java Mission Control (JMC) with Wildfly 16. Application server lays on Docker.
I successfully connected to wildfly via jconsole, to manage it I followed steps described here.
Unfortunately, I have no luck to connect via JMC. The URL which I use looks like this:
service:jmx:remoting-jmx://192.168.99.100:9990
I tried to set Xbootclasspath to jboss-cli-client.jar as it was described here, but I just get Unable to connect error.
I set the same jars, which are used for jconsole, but still I got Unable to connect.
I gave a try to adding flags on container site, as it was shown here, but with these flags, even wildfly haven't started.
Then, I found here the idea to hardcode some jboss classes to enable connection via remoting-jmx. I changed version of jars, according to these provided by wildfly16 and put it to jmc.ini like this.
-Xbootclasspath/a:"C:/Program Files/Java/jdk-10.0.2/lib/missioncontrol/dropins/jboss-cli-client.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting-jmx/main/remoting-jmx-3.0.1.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting/main/jboss-remoting-5.0.8.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logging/main/jboss-logging-3.3.2.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/main/xnio-api-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/nio/main/xnio-nio-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/main/jboss-marshalling-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/river/main/jboss-marshalling-river-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/cli/main/wildfly-cli-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/staxmapper/main/staxmapper-1.3.0.Final;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/protocol/main/wildfly-protocol-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/dmr/main/jboss-dmr-1.5.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/controller-client/main/wildfly-controller-client-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/threads/main/jboss-threads-2.3.3.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.7.Final.jar"
After that, finally, I have another error, which is
Could not initialize class org.jboss.remotingjmx.RemotingConnector
I added dependencies of remoting-jmx-3.0.1.Final to Xbootclasspath, but I got still the same error.
My question is, have you got any idea, how to make this connection works ? Maybe someone have done it in different way ?
Any advices how can i debug this problem, will be priceless? Because I'm lack of ideas how to solve it.

In %WILDFLY_HOME%\bin\standalone.conf.bat
put:
set "JAVA_OPTS=%JAVA_OPTS% -XX:+FlightRecorder"
In jmc.ini below -vmargs put
-Xbootclasspath/a:C:\%wildfly_home%\bin\client\jboss-cli-client.jar
(%wildfly_home% is different of course, or just copy jboss-cli-client.jar to another directory and correct the path)
3. Run JMC, then Create New Connection - in Connection Properties pane push the button "Custom JMX service URL", put:
service:jmx:http-remoting-jmx://localhost:9990
In the credentials fields just put user and password, they should be created for Realm Management (e.g. using %wildfly_home%\bin\add-user.bat)
Hope this helps someone.

Solution doesn't work on java 11 for me. Mission control fails on connect to wildfly with error:
Caused by: java.lang.NoClassDefFoundError: org/ietf/jgss/GSSManager
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
at java.base/java.lang.Class.getConstructor0(Class.java:3342)
at java.base/java.lang.Class.getConstructor(Class.java:2151)
at java.base/java.security.Provider.newInstanceUtil(Provider.java:152)
at java.base/java.security.Provider$Service.newInstance(Provider.java:1824)
at org.wildfly.security.WildFlyElytronBaseProvider$ProviderService.newInstance(WildFlyElytronBaseProvider.java:218)
at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:94)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:76)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64)
at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1545)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:430)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:419)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:244)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Besides, jmc that was embedded to jdk 8 isn't able to start flight recording for java 11 process.
So after investigation i found out that this class is loaded with bootstrap classloader. According to https://openjdk.java.net/jeps/261
jdk.security.jgss module isn't defined to bootstrap classloader. But classes in jboss-cli-client.jar(it originates from wildfly-elytron project) need jgss classes in runtime.
So i found out dirty workaround for this problem: bootstrap needed classes from jre 8 in jmc.ini. Full option for linux is:
-vmargs -Xbootclasspath/a:<path_to_wildfly>/jboss-cli-client.jar:<path_to_jdk8>/jre/lib/rt.jar
And for windows:
-vmargs -Xbootclasspath/a:<path_to_wildfly>\jboss-cli-client.jar;<path_to_jdk8>\jre\lib\rt.jar
after this jmc(run on 11 jdk) succesfully connects to wildfly(run on 11 jdk) and can start and analyze flight recordings.

RMI Registry Issue: rmiregistry may cause unintended exceptions when binding with codebase using the "file:" URL scheme

Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)

I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.

Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html

It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734

If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!

If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.

I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).

Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.

I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &

Weird problem using sun.security.pkcs11.SunPKCS11: The specified procedure could not be found?

I'm developing this application to be used speceifically with Firefox (it's for internal use). Basically, we're using the sun.security stuff to read Firefox's KeyStore and sign data with the certs we get.
I've tested this on several machines and the results are varying, I can't seem to pinpoint the reason.
I've tested it on the latest ubuntu release, Firefox 3.6.13, using Java version 1.6.0_22, it works there. I also have a Windows XP laptop with the same Firefox version using Java version 1.6.0_17, where it works as well.
There are 2 other Windows XP laptops that it will not work on, giving the same error. They're running the same version of Firefox and using java version 1.6.0_17.
The error is:
java.security.ProviderException: Could not initialize NSS
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:183)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:86)
at SignedMessage.SigningApplet.initializeCrypto(SigningApplet.java:327)
at SignedMessage.SigningApplet.init(SigningApplet.java:84)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: The specified procedure could not be found.
at sun.security.pkcs11.Secmod.nssLoadLibrary(Native Method)
at sun.security.pkcs11.Secmod.initialize(Secmod.java:186)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:179)
... 5 more
Exception: java.security.ProviderException: Could not initialize NSS
From what I can tell it can't find the native nssLoadLibrary routine? The configuration file is pointing it to the Firefox install directory (where it can grab the nss3.dll or libnss3.so file). It does this across all pc's and all the paths in the configuration seem to be valid.
A sample config file, for what it's worth:
name=NSS
nssDbMode=readOnly
nssModule=keystore
nssSecmodDirectory="C:\\Documents and Settings\\user\\Application Data\\Mozilla\\firefox\\Profiles/8bzd2qqm.default"
nssLibraryDirectory=C:\Program Files\Mozilla Firefox
I was hoping someone would have a clue, or maybe some tips on getting further with debugging. I'm at a loss here.

I'm likely much too late for this to be of use to you, but I was having similar problems, and adding dist\WINXXX_DBG.OBJ\lib to my PATH resolved this issue.

Quick answer: Use the x86 jdk not the x64 jdk with NSS and JSS
Quick test against a NSS certificate database:
keytool -list -v -storetype pkcs11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg NSS_CONFIG_FIPS
where NSS_CONFIG_FIPS is the path to a config file pointing to an NSS database. This command will fail with a stack trace that matches the questioners error if it is a JDK issue and succeed if the JDK is configured properly (and if the config file is correct)
Note that my stack trace included the message:
Caused by: java.io.IOException: %1 is not a valid Win32 application.
I ran dumpbin /headers on the NSS dlls and found that the Mozilla built binaries are all 32 bit. I installed the x86 jdk and repointed JAVA_HOME. Everything began working.
To Vivek's point, NSS and the accompanying executables are very sensitive to the presence of the libraries. Be sure all of the .dll, .lib, and .chk files are present on the path. In particular, modutil.exe will fail certain commands without the chk files and the error messages are not helpful. Your NSS lib folder will need to include the NSS and NSPR lib folders, the jss4.dll and jss4.lib files, and the jss4.jar.
Also note that if you build NSS yourself, the libaries will not be signed with an approved code signing cert which will cause problems with JCA.

Error accessing a Web Service with SSL

I have a program that is supposed to send a file to a web service, which requires an SSL connection. I run the program as follows:
SET JAVA_HOME=C:\Program Files\Java\jre1.6.0_07
SET com.ibm.SSL.ConfigURL=ssl.client.props
"%JAVA_HOME%\bin\java" -cp ".;Test.jar" ca.mypackage.Main
This was works fine, but when I change the first line to
SET JAVA_HOME=C:\Program Files\IBM\SDP\runtimes\base_v7\java\jre
I get the following error:
com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:119)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:140)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:86)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:593)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:552)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:537)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:434)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:247)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:132)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:242)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:222)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:115)
at $Proxy26.fileSubmit(Unknown Source)
at com.testing.TestingSoapProxy.fileSubmit(TestingSoapProxy.java:81)
at ca.mypackage.Main.main(Main.java:63)
Caused by: java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:7)
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:1)
at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:110)
at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:14)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:902)
at com.ibm.net.ssl.www2.protocol.https.b.getOutputStream(b.java:86)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:107)
... 14 more
Caused by: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.SSLJsseUtil.b(SSLJsseUtil.java:20)
at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:36)
at javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:16)
at javax.net.ssl.HttpsURLConnection.<init>(HttpsURLConnection.java:36)
at com.ibm.net.ssl.www2.protocol.https.b.<init>(b.java:1)
at com.ibm.net.ssl.www2.protocol.https.Handler.openConnection(Handler.java:11)
at java.net.URL.openConnection(URL.java:995)
at com.sun.xml.internal.ws.api.EndpointAddress.openConnection(EndpointAddress.java:206)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.createHttpConnection(HttpClientTransport.java:277)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:103)
... 14 more
So it seems that this problem would be related to the JRE I'm using, but what doesn't seem to make sense is that the non-IBM JRE works fine, but the IBM JRE does not. Any ideas, or suggestions?

Try adding these two lines somewhere in your setup code:
Security.setProperty("ssl.SocketFactory.provider", "com.ibm.jsse2.SSLSocketFactoryImpl");
Security.setProperty("ssl.ServerSocketFactory.provider", "com.ibm.jsse2.SSLServerSocketFactoryImpl");

Java only allows one SSL connection factory class for a JVM. If you are using a JDK thats shipped with WebSphere Application Server v6x/7x/8x or any other WebSphere server tools in Rational Application Developer, then those require IBM ( com.ibm.websphere.ssl.protocol.SSLSocketFactory ) specific class from WebSphere Application Server runtime.
because the java security file has the JSSE socket factories set like below
# Default JSSE socket factories
#ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
#ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl
# WebSphere socket factories (in cryptosf.jar)
ssl.SocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLSocketFactory
ssl.ServerSocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLServerSocketFactory
So, If you uncomment the Default JSSE Socket factories and comment out the WebSphere ones then WAS is going to puke.
Better work around would be to have com.ibm.ws.security.crypto.jar file in your class path. This jar file has a dependency on com.ibm.ffdc.jar file so you need that in your class path well. Both these jarfiles are available under <WebSphere_Install_Dirctory>/plugins/

If your non IBM jre is sun, then it already comes with SSL classes implementation packaged along with it.
It seems the IBM jre is not containing SSL implementation classes at all.

One more "solution" which seems to be working for me. Create your own security properties file, my.java.security with contents like:
ssl.SocketFactory.provider=
ssl.ServerSocketFactory.provider=
When calling Java (or in my case maven), add the command line option:
-Djava.security.properties=C:\myfiles\my.java.security
Cribbed from the IBM Liberty documentation: http://www-01.ibm.com/support/knowledgecenter/was_beta_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_trouble.html?lang=en

one may set these properties at WAS_HOME/*/java/jre/lib/security/java.security file by uncomenting the following JSSE props.
Default JSSE socket factories
ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl

Found this topic while searching for the same error message but found a different solution.
To test a https REST service using the Apache Wink client:
ClientConfig config = new ClientConfig();
config.setBypassHostnameVerification(true);
RestClient client = new RestClient(config);
And set the Factory's empty:
Security.setProperty("ssl.SocketFactory.provider", "");
Security.setProperty("ssl.ServerSocketFactory.provider", "");
My runtime is a standalone Camel test using IBM JRE 1.7 from IBM WebSphere v8.5.5.

I had a similar issue when my Batch application was trying to fetch data from Restful web service using Apache wink. I was using MyEclipse as my dev environment. And was using the jre provided by IBM webSphere 8.5. When I changed to Sun 1.6 jre, the issue got resolved.

JSP exception - class not found (tomcat)

I'm setting up an existing application on a new Tomcat 5.5 server connecting to a Postgres database (running on Debian Lenny). When I access it I get a series of stack traces with the following root cause:
java.lang.ClassNotFoundException: java.sql.SQLClientInfoException
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1363)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1209)
java.lang.Class.forName(libgcj.so.90)
java.lang.Class.initializeClass(libgcj.so.90)
java.lang.Class.initializeClass(libgcj.so.90)
org.postgresql.Driver.makeConnection(Driver.java:382)
org.postgresql.Driver.connect(Driver.java:260)
java.sql.DriverManager.getConnection(libgcj.so.90)
jof.DBConnection.getConnection(DBConnection.java:81)
jof.BeanInterfaceBase.db(BeanInterfaceBase.java:263)
jof.BeanInterfaceBase.getStatement(BeanInterfaceBase.java:613)
jof.HelpInterface.findByNaturalId(HelpInterface.java:81)
jof.HelpInterface.findByNaturalId(HelpInterface.java:128)
org.apache.jsp.index_jsp.getHelp(index_jsp.java:162)
org.apache.jsp.index_jsp._jspService(index_jsp.java:369)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:331)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
java.lang.reflect.Method.invoke(libgcj.so.90)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244)
java.security.AccessController.doPrivileged(libgcj.so.90)
javax.security.auth.Subject.doAsPrivileged(libgcj.so.90)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
What's missing?

java.lang.ClassNotFoundException: java.sql.SQLClientInfoException
What's missing?
To be precise: the mentioned class is missing in the runtime classpath. It must be in the runtime classpath as a standalone class file (*.class) or packaged in a JAR file (*.jar). Alternatively you can also add its actual path to the runtime classpath.
By default the webapp's Webapp/WEB-INF/lib and Webapp/WEB-INF/classes folders are covered by the runtime classpath, as is appserver's Appserver/lib folder and the Java's JRE/lib.
Any 3rd party webapp-specific JAR files ought to be placed in Webapp/WEB-INF/lib. Any webapp-specific classes (servlets, etc..) ought to be placed in Webapp/WEB-INF/classes. Any appserver-specific (or webapp-common) JAR files ought to be placed in Appserver/lib. The Java's JRE/lib folder must be left untouched.
Hope this helps.
Edit: the actual problem is worse: this is indeed a Java 6 only class. Tomcat is apparently running on a Java 5. Review your JAVA_HOME environment variable. It must at least point to root installation folder of Java 6 JRE.

This is a guess, but I see that java.sql.SQLClientInfoException is a class that was introduced in Java6. What version of Java is being used to launch your Tomcat server? Maybe you are developing under Java6 but then deploying to a Tomcat running Java5?