Develop Reference

Where to add the jdbc driver on Netbeans/Glassfish in Windows?

I have an enterprise app created in Netbeans 6.8 which comes packaged with a Glassfish V3 server. I've been receiving the following exception from the server log when I try to deploy and run the EAR project:
SEVERE: jdbc.exc_cnfe_ds
java.lang.ClassNotFoundException: com.mysql.jdbc.Driver
From googling, the common solution to this is to copy the jar file (mysql-connector-java-5.1.6-bin.jar) containing that class to
$glassfish-v3-install-root/glassfish/domains/domain1/lib.
and in fact that's where it resides on the Unix server. However, I'm testing this on windows and the "domains/domain1" directories don't exist in the default glassfish install. I added them manually and added the jar, but it made no difference. I also added the jar as a variable to the windows classpath, but that also had no effect.
I then tried adding the jar file $glassfish-v3-install-root/glassfish/lib, and that produced a different error:
SEVERE: RAR5111 : Error casting to javax.sql.Datasource
java.lang.ClassCastException: com.mysql.jdbc.Driver cannot be cast to javax.sql.DataSource
I'm using the same jar file as exists for the server. I'm guessing the jar is misplaced? I don't want to put it in the project because that's not how it's deployed in production. Any help appreciated.

Putting the jar file in $glassfish-v3-install-root/glassfish/lib turned out to be correct.
The
"SEVERE: RAR5111 : Error casting to javax.sql.Datasource java.lang.ClassCastException: com.mysql.jdbc.Driver cannot be cast to javax.sql.DataSource"
error was, I believe, caused by an incorrect setting for the jdbc pooling on the glassfish server. But going to the admin console, available from the Netbeans "server" tab, going to the "JDBC", "Connection Pools", select "java.sql.driver" as the resource type and "com.mysql.jdbc.driver" as the driver classname will get rid of the casting issue.
Click the "Ping" button near the top to make sure you're connecting.

Removing Jar from War

When I am deploying my war file in Jboss 5.1 , I am getting:
ERROR [STDERR] log4j:ERROR A "org.jboss.logging.appender.FileAppender" object is not assignable to a "org.apache.log4j.Appender" variable.
ERROR [STDERR] log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
ERROR [STDERR] log4j:ERROR [BaseClassLoader#18c1f7d{vfszip:/C:/jboss-5.1.0.GA/server/default/deploy/OnlineUsage.war/}] whereas object of type
ERROR [STDERR] log4j:ERROR "org.jboss.logging.appender.FileAppender" was loaded by [org.jboss.bootstrap.NoAnnotationURLClassLoader#291aff].
ERROR [STDERR] log4j:ERROR Could not instantiate appender named "FILE".
Even with the above error , I can hit the ?wsdl URL correctly.
Next I tried simply by deleting the log4j jar file from war and deployed successfully without any error. Got ?wsdl correctly too.
My question is whether this will create problem in production or real time(Real time error or binding error).
In the past I got an error Failed to create SAX Parser. If it is not an issue to remove the jar from war, can I remove XercesImpl jar also? Since Jboss has its own jar files, I can avoid Class cast-exceptions.

In order to avoid class casting exception, I would highly recommend not packaging any JBoss or JDK provided jars in your WEB-INF/lib folder. If you have to for some reason, the utilize class loading isolation with jboss-classloading.xml file.
This principle holds true for other Java EE containers (Websphere, Weblogic, GlassFish, etc) as well. You never want to package JDK and container provided libraries in your own artifact.
You can make use JBoss Tattletale which is a great open source tool to find out what dependencies to not package in WAR/EAR.

Class Cast Exception When Same Jar is Included in WEB-INF/lib and CLASSPATH

I have a .jar file added to the CLASSPATH of the JBoss 5 startup (run.bat/run.sh) file. This is a dependency jar which is referred to from the servlet based application. If I use this setup, the servlet loads fine and works as expected. However, I noted that if I have the same jar in the servlet's WEB-INF/lib directory, I get a class cast exception as follows:
ERROR [STDERR] ERROR: com.idoox.wasp.ProtocolRepositoryImpl - Exception in protocolHandler soap, protocolHandler com.server.saaj.soap.SOAP11ProtocolHandler, class space root.wasp-impl.SOAP :
ERROR [STDERR] EXCEPTION:
ERROR [STDERR] com.systinet.saaj.soap.SOAP11ProtocolHandler cannot be cast to org.idoox.wasp.ProtocolHandler
ERROR [STDERR] java.lang.ClassCastException: com.server.saaj.soap.SOAP11ProtocolHandler cannot be cast to org.idoox.wasp.ProtocolHandler
This is not an issue since I won't have the jar in both places, but I'm just wondering why it is happening this way. Is this a class loading issue?
Thank You.

The jar file you are mentioning would be already available with JBoss. Whe you place it in the WEB-INF/lib; JBoss has already loaded the class from the jar available with JBoss and there is conflict with the class in the web-inf folder. Classes loaded by different classloaders are treated as different even if the classes are same. When you give in run.bat there is only one jar file loaded. JBoss loads this and there is no conflicting jars.

How do I correct a Java LinkageError exception?

I am developing an application for WebSphere 6.1 which uses a Java servlet. Within my servlet, I have defined a serial vesion ID of 1L. Upon deploying and running my application, I am receiving a LinkageError of the following type (from the server log):
[5/9/11 15:14:26:868 EDT] 0000001c WebApp
E [Servlet Error]-[ManageRecordsConsumerServlet]: java.lang.Exception:
java.lang.LinkageError: LinkageError while defining class:
<redacted>.docindexupdate.batch.servlet.ManageRecordsConsumerServlet
Could not be defined due to: (<redacted>/docindexupdate/batch/servlet
/ManageRecordsConsumerServlet) class name must be a string at offset=2074
This is often caused by having a class defined at multiple
locations within the classloader hierarchy. Other potential causes
include compiling against an older or newer version of the class
that has an incompatible method signature.
I'm not sure what the issue is. I was seeing this previously before defining a serial version uid and figured that by defining that and being consistent, future updates to the class file would run successfully. There are no errors during compilation or deployment to the server. Is it possible that an older version of the servlet is cached somewhere on the WebSphere instance (I am only deploying on my dev machine at the moment)?
The
class name must be a string at offset=2074
line is also confusing.

I am suspecting you have a jar that is being loaded in two different classloaders. By that I mean, your websphere server on startup loads that jar or has an endorsed directory with that jar. Also your EAR you are deploying has that jar in its lib. The two can conflict at runtime
What I would suggest is to find out which jar ManageRecordsConsumerServlet belongs to and either remove it from your EAR lib or your Websphere endorsed lib (best would be your EAR lib).

It may be versioning, but I don't thing so.
When two classes loaded by different classloader, a ClassNotFoundException is normally thrown.
When a class is passed over a wire/loaded from disk cache, VersionMismatchException is normally thrown.
When a class with different method signatures is used, NoSuchMethodError or alike is thrown.
I think this case is a corrupted class file. Could be corrupted in cache or in the JAR.

Strange jboss console error

I'm creating additional module to already multi-module maven project. And for this one I want everything to be like in other modules(meaning dependencies) just to test hello world, then I'll go do some more complex stuff. And it does print hello world as it should when deployed onto jboss server, but I get some strange error on console, had anyone had similar experience? and how can I fix it? Here it is :
15:48:35,789 ERROR [STDERR] log4j:ERROR A "org.jboss.logging.appender.FileAppender" object is not assignable to a "org.apache.log4j.Appender" variable.
15:48:35,789 ERROR [STDERR] log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
15:48:35,790 ERROR [STDERR] log4j:ERROR [BaseClassLoader#9a8d9b{vfszip:/C:/jboss-5.1.0.GA/server/default/deploy/new-module-0.0.1-SNAPSHOT.war/}] whereas object of type
15:48:35,790 ERROR [STDERR] log4j:ERROR "org.jboss.logging.appender.FileAppender" was loaded by [org.jboss.bootstrap.NoAnnotationURLClassLoader#506411].
15:48:35,790 ERROR [STDERR] log4j:ERROR Could not instantiate appender named "FILE".
Here is the part of Appender xml
http://pastebin.com/X7Dgdrki

First check your <server>/conf/jboss-log4j.xml for the configuration of the appender named FILE (and post it here if you can - that may give us more clues).
Further investigation reveals that org.jboss.logging.appender.FileAppender actually implements the interface org.apache.log4j.Appender. So this is apparently a classloader conflict. The same class definition (in this case org.apache.log4j.Appender), when loaded by two different classloaders, counts as two distinct classes for the JVM.
Is log4j.jar included in your war, or in your server/lib directory? If so, you could try removing it and see whether it resolves the issue.
Update: Actually the easiest possible solution is to simply change the type of the appender to org.apache.log4j.FileAppender in jboss-log4j.xml.
Regarding log4j.jar, what I mean is that if it is present in your war, it (and a copy of org.apache.log4j.Appender) gets loaded by the war classloader (BaseClassLoader#9a8d9b in your error message). And this causes the classloader conflict. So if you do not deploy log4j.jar with your war, the error may go away. This is related to Maven only in that the dependency is configured in your pom. For this little experiment, you can simply remove the log4j.jar from your war by hand; if this solves the issue, configure the log4j dependency in your pom as "provided", e.g.:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
<scope>provided</scope>
</dependency>
If log4j.jar is not in your war, it might still be in the server/default/lib directory - please check that and if it is there, try to remove it.

We recently came across this problem. We tried the suggestions above and they did not work. So we handled the problem by replacing all log4j imports with a abstract logging interface (we chose org.apache.commons.logging for this) and removing the log4j from the depdenancies. Then what happens is the actual underlying logging implementation supports whatever JBoss has set. And if we want to move back to Tomcat (without JBoss) we can just add the log4j jar or whatever logger implementation back into the war.