JasperException: Unable to compile class for JSP
Applies to:
JBoss
Description:
Occurs while starting JBoss and trying to access the jmx-console
Cause:
a. Invalid JAVA_HOME value.
b. Incompability with servlet/JSP api.
Applies to:
JBoss
Description:
Occurs while starting JBoss and trying to access the jmx-console
Cause:
a. Invalid JAVA_HOME value.
b. Incompability with servlet/JSP api.
Applies to:
JBoss
Description:
Occurs when redeploying an application several times
Cause:
There is a BUG related to class unloading http://jira.jboss.com/jira/browse/JBAS-1319.
The web container (Tomcat) was still holding references to the ClassLoaders (required condition to unload the class).
Sun’s Java virtual machine creates a so called Permanent Generation in their memory heap where they store reflective data about the current runtime. In practice this usually means instances of java.lang.Class and java.lang.reflect. classes. These classes are only unloaded if all the references to the classLoaders are gone plus there is no more instances of the class. This will happen during Full GC operations.
Applies to:
JBoss
Description:
Occurs while using Jboss
Cause:
This exception is caused by one of two things.
a. A common issue is that you reached the max number of user processes for the account that you’re running JBoss on. You can see the limit by using “ulimit -u”.
b. Another common issue is that the default stack size on recent vms with the -server option is probably too large.
Applies to:
JBoss
Description:
You have A.ear and B.ear, and B.ear relies upon an EJB that is packaged in A.ear. You update some code inside A.ear and redeploy it, and when you go to test the updated code using a method contained in B.ear, you get a ClassCastException.
Cause:
First off, this is not a bug with the JBoss classloader, this is normal expected behavior. What is happenning is when A.ear is redeployed any references that B.ear may have to classes contained inside A.ear are no longer valid.
Applies to:
JBoss
Description:
Occurs when EJB passivates
Cause:
This happened due to an EJB instance being passivated to a file (.ser) and then later that file being removed by a clean up service. When the EJB instance was then called on to be activated, it’s serialized form on file was not there.
Applies to:
JBoss, Velocity
Description:
Occurs while using Velocity in JBoss
Cause:
Velocity deploys their servlet as a singleton.
Applies to:
JBoss
Description:
There is little difference between the two:
a. NoClassDefFoundError represents an unfound import
b. ClassNotFoundException represents dynamic classloading
Cause:
a.You forgot to add the class
b. You forgot to add a class that this class depends upon
c. You compiled the class for the wrong version
d. The class is not visible from where it is being loaded
e. You are deploying on Windows (NTFS)
f. Some other error
g. Not using the correct api
Applies to:
JBoss
Description:
Standalone client. You want to lookup a UserTransaction from JNDI according to the AS guide . You do it by specifying the properties for the InitialContext programmatically, like so:
UserTransaction tx = null;
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
“org.jnp.interfaces.NamingContextFactory”);
props.setProperty(Context.PROVIDER_URL, “jnp://localhost:1099″);
props.setProperty(Context.URL_PKG_PREFIXES, “org.jboss.naming:org.jnp.interfaces”);
InitialContext ctx = new InitialContext(props);
tx = (UserTransaction) ctx.lookup(“UserTransaction”);
tx.begin();
But the lookup does not work, instead you get a java.lang.RuntimeException: UT factory lookup failed
Cause:
The properties are not forwarded to the lookup within UserTransactionSessionFactory.
Applies to:
JBoss
Description:
You see:
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resourcefile: java.naming.factory.initial
Cause:
jndi.properties file is missing in classpath
Applies to:
JBoss
Description:
Occurs when when accessing JBoss from a remote client. When attempting to use JMS or RMI remotely, you might run across an exception that looks like this:
javax.naming.CommunicationException [Root exception is java.rmi.ConnectException: Connection refused to host: 127.0.0.1
Cause:
This is the result of a problem in the JBoss server side configuration. You’re successfully talking to the correct server, but it does not know its own hostname or IP address.