The information presented here comes from an effort to upgrade a Java enterprise application to the most current versions of all of its parts; primarily to get onto Java 6. Its starting system specifications were the following:
- JBoss 4.2.2
- Java 1.5.0_27
- SEAM 2.1.0
- RichFaces 3.3.1
- JSF 1.2
- EJB 3.0
- Remote EJB’s
For reasons that will be explained in detail, it was not possible to upgrade each of the system parts to their various current versions. The end result was the following:
- JBoss 5.1.0
- Java 1.6.0_27
- SEAM 2.2.2
- RichFaces 3.3.3
- JSF 1.2
- EJB 3.0
- Remote EJB’s
Due to the size and scope of the enterprise application itself in combination with the incompatibilities between system components, the entire effort ended up taking me a long time. The following is a log of this endeavor with all of the errors I encountered and how they were resolved. The intention of this writing is for both a historical purpose, and to help others avoid the pitfalls of performing such an upgrade on a sufficiently large enterprise application.
Why didn’t it just work out of the box with Java 6?
JBoss 4.2.2 Web Services do not work with Java 1.6. It results in a runtime error with SOAP. This means in order to run with Java 6 we have to upgrade JBoss.
java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
What about JBoss 7.0?
The configuration is so different that it in no way resembles any previous version, and it does not support Remote EJB’s.
Remote EJB invocations isn't currently available in AS 7.0. That will be implemented by AS 7.1.
(http://community.jboss.org/message/616635)
So, how about JBoss 6.1.0?
JBoss 6 supports Java 6, SEAM, RichFaces, JSF, EJB 3.0, and remote EJB’s. The question is now what versions of these will work?
What about RichFaces 4?
Yes, it works but with JBoss 6.1.0 and JSF 2.0.
RichFaces supports the following JSF implementations and frameworks:
- MyFaces 2 and higher
- Seam 3 and higher
- Mojara 2 and higher
So looks like you have to upgrade to SEAM 3
Thus far we have JBoss 6.1.0, RichFaces 4.0.0, and JSF 2.0. SEAM 3 has apparently changed everything, and is not backward compatible with a SEAM 2 configuration. I was never able to even get “Hello World” working with SEAM 3, which is to be expected since it is “not done” (http://seamframework.org/157223.lace).
While according to compatibility it is supposed to work with JBoss 6 (http://seamframework.org/Seam3/Compatibility), I again haven’t been able to get even the most simple example working.
Back to SEAM 2
Since SEAM 3 does not work we have no choice but to go back to SEAM 2. RichFaces requires JSF 2.0 and in its specification says it only works with SEAM 3. While I question how one could know that RichFaces 4 only works with SEAM 3 when no one to my knowledge has a working example on JBoss 6, the goal is to upgrade to Java 6. There is also some unspecified hack to get SEAM 2 working with JSF 2, but any type of hack would probably make upgrading harder in the future. Okay, back to to RichFaces 3.
Back to RichFaces 3, how about 3.3.3?
Sorry no, not on JBoss 6: http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html_single/#SupportedServers
JBoss 6 isn’t even listed as a supported server, and in my experience I haven’t been able to find anyone able to get RichFaces 3 working under JSF 1.2 or 2.0 on JBoss 6. I haven’t been able to get a “Hello World” working either.
Wait, where are we now?
- We can’t use SEAM 3 because it doesn’t work (or at least the community can’t get it to work) on JBoss 6
- We can’t use RichFaces 4 because it requires JSF 2 and SEAM 2 requires JSF 1.2
- RichFaces 3 isn’t supported (and won’t run apparently) on JBoss 6
- Finally, was can’t use JBoss 6 because SEAM 2 doesn’t support it (http://seamframework.org/Seam2/GettingStarted), and of course RichFaces 3 doesn’t work with it either
JBoss 5.1.0, Hello World
On paper RichFaces 3 and SEAM 2 work on JBoss 5, and JBoss 5 can run on Java 6. Take into account though the same is true for RichFaces 4, JSF 2, SEAM 3, and Remote EJB’s on JBoss 6. While an example exists for RichFaces 3 + SEAM 2 on JBoss, it of course doesn’t work out of the box on JBoss 5.
As a starting point I used Eclipse 3.7 (Indigo), JBoss Tools 3.3.3 (http://www.jboss.org/tools/download/installation/update_3_3), and Seam 2.2.2 (http://seamframework.org/Seam2/Downloads). JBoss Tools has a “Create Seam Web Project wizard,” so it should work right out of the box, right?
First, you have to rename jboss-seam-2.2.2.jar to jboss-seam.jar in the seam-2.2.2/lib installation. This is because if you don’t the SEAM wizard won’t allow you to select where you put SEAM because it looks for the JAR of this name.
Second, RichFaces component will not work out of the box. If you try to use something like a calendar or a TabPanel you will get this message:
Resources framework is not initialised, check web.xml for Filter configuration
Not too hard; add this to the web.xml:
<filter>
<display-name>Ajax4jsf Filter</display-name>
<filter-name>ajax4jsf</filter-name>
<filter-class>org.ajax4jsf.Filter</filter-class>
</filter>
<filter-mapping>
<filter-name>ajax4jsf</filter-name>
<url-pattern>*.seam</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>
Third, there are all sorts of problems with .xhtml files:
- layout/template.xhtml - Delete anything referencing authentication
- layout/menu.xhtml - Delete the content of the toolBarGroup
Fourth, you have to delete the xerces and xml-apis jars out of the lib directory. These are in JBoss now.
EARs containing Beans and WARs with shared libraries in the root of the EAR
A detail of the project I am converting is that it contains several WAR files, in which the library dependencies reside in the root level of the EAR, instead of the WEB-INF/lib directories of the WARs.
There are a couple of interesting side-effects of this type of structure on JBoss 5:
- The app no longer runs in Eclipse, because the libraries don’t actually reside in the root directory of the deployment
- Having these dependencies in the root of the EAR interferes with the admin-console deployment. There are several ways of dealing with this, but the easiest is just to remove it from deploy. (https://issues.jboss.org/browse/JBAS-7032)
In terms of getting this configuration to work in Eclipse, you only would have to automatically copy the JAR files to the root of the deployment. The deployment assembly settings right? No. When they work, they only copy a few files. The files they choose to copy whether you use a filterset or add each one manually are seemingly random.
How about a custom builder within Eclipse to copy the files? The JBoss server in eclipse deploys to a dynamic location within .metadata\.plugins\org.jboss.ide.eclipse.as.core within your workspace, so you would need to access it through an environment variable if you were trying to create custom builder. Is there an environment variable like ${jboss_config}? There would have to be but good look figuring it out.
In order to have JBoss in a predictable place, you can modify the server settings by double-clicking on the JBoss Server in the service view, selecting the Deployment tab, and making it deploy to a custom location (http://community.jboss.org/message/564310).
Since you don’t want your Eclipse version of your EAR messing with your manually deployed one, it is best to create a second server/YOUR_PROJECT deployment directory which is a copy of the default minus deploy/admin-console. You also have to make sure to modify the JBoss runtime configuration to NOT use the default configuration, and to use the one you just created.
For example under JBoss Runtime Configuration -> Open Launch Configuration::
--configuration=eclipse -b localhost -Djboss.server.base.url=file:/C:/Java/jboss-5.1.0.GA/server/
The story of our app...
Jars over, application.xml changed, JBoss properties-service.xml changed to use environment.properties, build changed to use Java 6 and the JBoss 5 libraries, Eclipse project modified to compile using all the new libraries, and all of the other modifications made according to “Hello World”. It should deploy just fine right?
Error #1: Error installing to PostClassLoader
[org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to PostClassLoader: name=vfsfile:/C:/Java/jboss-5.1.0.GA/server/myapp/deploy/MyApp.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/C:/Java/jboss-5.1.0.GA/server/myapp/deploy/MyApp.ear/account-application.jar/
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
…
Caused by: java.lang.NullPointerException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.jboss.metadata.process.processor.ejb.jboss.SetDefaultLocalBusinessInterfaceProcessor.process(SetDefaultLocalBusinessInterfaceProcessor.java:114)
at org.jboss.metadata.process.chain.ejb.jboss.JBossMetaDataProcessorChain.process(JBossMetaDataProcessorChain.java:115)
at org.jboss.ejb3.deployers.Ejb3MetadataProcessingDeployer.deploy(Ejb3MetadataProcessingDeployer.java:115)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
Possibilities:
- A problem with the version declared in the ejb-jar.xml: https://issues.jboss.org/browse/EJBTHREE-1976. Nope, version is 3.0 in the HelloWorld as well
- The jboss.xml could be referencing a bean that is a pojo (https://issues.jboss.org/browse/JBMETA-195). While commenting out the beans got the deployment farther, it didn’t get rid of this error. This indicates this is a problem with something else.
- EJB’s with zero parameters: https://issues.jboss.org/browse/JBMETA-207. This seems pretty likely since the version of JBoss listed is 5.1.0
This stack trace is pretty useless, and the only matches for any part of it on the internet are to those two JIRA issues. Resorting to just a “how to go from JBoss 4 to 5” search:
- Persitence.xml and ejb-jar.xml must validate, remove xalan.jar, xercesImpl.jar, serializer.jar, xml-apis.jar from the application. (http://community.jboss.org/wiki/MigrationFromJBoss4)
- There are numerous guides relating to this; too many to list
Nothing works, now what?
An issue with all these guides though is that they are for applications most likely smaller than the one we are upgrading. Sticking will all the advice still doesn’t have an effect on this startup error. The next resort is to break our application, which currently sits as one big Java project that can only be run by ant build and deploy, into its component pieces and get them working one at a time. Starting with the EJB that contains all the Java code that is causing this error.
Our project’s directory structure is the following:
- Application
- src (EJB)
- ear
- WebEar
- Application WAR #1
- Application WAR #2
- Application WAR #3
- Application WAR #4
- lib
I have experimented with running this configuration out of Eclipse, and while it is possible the configuration is extremely complicated. I however also like to avoid developer setup documents which are 10 pages long, so sometimes the path of least resistance is the best way to go.
The advantage of being able to run out of Eclipse is that you don’t have to Ant build, deploy it, and startup JBoss every time you want to see a change. A different project structure also lets things be broken apart and tested more easily, because they don’t rely on you having to modify an already complicated Ant build.
The idea is that like “Hello World,” a project that we can get running easily in Eclipse should be in this project directory structure:
- Application EAR (Enterprise Application Project)
- lib
- Application Bean (EJB Project with no client)
- Application WAR #1 (Dynamic Web Project)
- Application WAR #2 (Dynamic Web Project)
- Application WAR #3 (Dynamic Web Project)
- Application WAR #4 (Dynamic Web Project)
The reliance on the Eclipse project wizards results in projects that run in Eclipse out-of-the-box.
Checklist
- EAR deploys with Bean
- EAR deploys with Bean and application.xml contains all of the needed libraries
- EAR deploys with Bean, libraries, and data sources
- Error: EAR deploys with Bean, libraries, data sources, and messaging config
Error #2: Queue[/queue/myapp/bulkMessageQueue
ERROR [ExceptionUtil] Queue[/queue/myapp/bulkMessageQueue, name=myapp/bulkMessageQueue] startService
javax.naming.NameNotFoundException: myapp not bound
The issue is that JMS configuration has changed between 4 and 5: http://javabeanz.wordpress.com/2009/06/05/configuring-jms-in-jboss-5/
For myapp-jms-service.xml:
JBoss 4:
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=myapp/bulkMessageQueue">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
JBoss 5:
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=myapp/bulkMessageQueue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">
jboss.messaging:service=ServerPeer
</depends>
<depends>jboss.mq:service=DestinationManager</depends>
<attribute name="JNDIName">queue/myapp/bulkMessageQueue</attribute>
</mbean>
Back to the checklist:
- EAR deploys with Bean, libraries, data sources, messaging config, and mail config
… and the Seam interceptors in the ejb-jar.xml - ERROR: … add all the source code for the bean
Back to ERROR #1: Error installing to PostClassLoader
org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to PostClassLoader: name=vfsfile:/C:/Java/jboss-5.1.0.GA/server/myapp/deploy/MyApp.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
We now know that this error has something to to with one or more of the following:
- Java source - Can’t really remove this
- jboss.xml - Removing this gets rid of the error
- ehcache.xml
- persistence-container.xml
- The WSDL files
Ding, ding, ding! Something is wrong with the jboss.xml
jboss.xml looks like this:
<jboss>
<enterprise-beans>
<!-- Actions -->
<session>
<ejb-name>BasketActionImpl</ejb-name>
<jndi-name></jndi-name>
<clustered>false</clustered>
</session>
<session>
<ejb-name>ContractPricingActionImpl</ejb-name>
<clustered>false</clustered>
</session>
...
The presence of one or more of those beans is what is causing the error. A cursory look has also revealed that several of the beans here don’t exist. I eventually found out that the reason for the failures was related to ejb-name classes that don’t exist. After removing classes (one at a time) jboss was able to launch with this configuration. Note though that removing the clustering settings causes error #12.
ERROR #3: Can't find a persistence unit
org.jboss.deployers.spi.DeploymentException: Error deploying MyEJB.jar: Exception while processing container metadata for EJB: DBServiceImpl in unit: MyEJB.jar
…
Caused by: java.lang.IllegalArgumentException: Can't find a persistence unit named 'MyPu' in AbstractVFSDeploymentContext@31521104{vfsfile:/C:/Java/jboss-5.1.0.GA/server/eclipse/deploy/MyApp.ear/MyEJBjar/}
There is obviously a problem with the persistence-container.xml, as it is the one that defines the datasource which cannot be found. According to the thread at http://community.jboss.org/thread/146523, there are a couple different ways to deal with persistence.xml. Note that is is always referred to as “persistence.xml”. If you change the name of the this XML file to persistence.xml, it works. This is an indication that JBoss 5 wants your persistence unit to be defined in persistence.xml by default.
Back to the checklist:
- ...and WAR #1 with a relatively empty configuration
- ERROR: ...and WAR #1 with RichFaces and SEAM in the configuration from Hello World
Error #4: NoClassDefFoundError: org/jboss/resteasy/specimpl/UriInfoImpl
java.lang.ClassNotFoundException: javax.ws.rs.ext.Provider
java.lang.NoClassDefFoundError: org/jboss/resteasy/specimpl/UriInfoImpl
This is because of the inclusion of jboss-seam-resteasy-2.2.2.jar, which does not include the REST Easy dependencies. This can just be removed from the application.xml.
Error #5: Server cycles between deploying and undeploying
2011-10-17 12:14:03,137 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) deploy, ctxPath=/account
2011-10-17 12:14:03,199 INFO [org.apache.catalina.startup.ContextConfig] (HDScanner) WARNING: Security role name NONE used in an <auth-constraint> without being defined in a <security-role>
2011-10-17 12:14:03,215 INFO [javax.enterprise.resource.webcontainer.jsf.config] (HDScanner) Initializing Mojarra (1.2_12-b01-FCS) for context '/account'
2011-10-17 12:14:05,324 INFO [javax.servlet.ServletContextListener] (HDScanner) Welcome to Seam 2.2.2.Final
2011-10-17 12:14:09,434 WARN [org.jboss.seam.security.permission.PersistentPermissionResolver] (HDScanner) no permission store available - please install a PermissionStore with the name 'org.jboss.seam.security.jpaPermissionStore' if persistent permissions are required.
2011-10-17 12:14:09,621 INFO [org.quartz.simpl.SimpleThreadPool] (HDScanner) Job execution threads will use class loader of thread: HDScanner
2011-10-17 12:14:09,637 INFO [org.quartz.core.QuartzScheduler] (HDScanner) Quartz Scheduler v.1.5.2 created.
2011-10-17 12:14:09,637 INFO [org.quartz.simpl.RAMJobStore] (HDScanner) RAMJobStore initialized.
2011-10-17 12:14:09,637 INFO [org.quartz.impl.StdSchedulerFactory] (HDScanner) Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
2011-10-17 12:14:09,637 INFO [org.quartz.impl.StdSchedulerFactory] (HDScanner) Quartz scheduler version: 1.5.2
2011-10-17 12:14:09,637 INFO [org.quartz.core.QuartzScheduler] (HDScanner) Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
2011-10-17 12:14:09,902 WARN [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapperMBean
2011-10-17 12:14:20,871 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) undeploy, ctxPath=/account
I encountered this issue earlier and just blamed it on Eclipse, but closer attention to the logs reveals there is a missing class. This JAR can be downloaded here: http://www.java2s.com/Code/Jar/JKL/Downloadpojocachejar.htm
Followed by:
2011-10-17 13:15:05,809 WARN [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/jmx/LifeCycle
Apparently life has moved on past JBoss Cache, http://community.jboss.org/wiki/JBossCache, but you can get jbosscache here: http://www.java2s.com/Code/Jar/JKL/Downloadjbosscachejar.htm
Followed by:
2011-10-17 13:23:37,277 WARN [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/CacheManager
The JAR can be downloaded here: http://www.java2s.com/Code/Jar/JKL/Downloadjbosscachecorejar.htm
Followed By:
2011-10-17 14:14:10,356 WARN [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jgroups/blocks/MethodCall
jgroups.jar, which can be obtained in the JBoss Cache release.
Followed by:
2011-10-17 13:34:08,809 WARN [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) Failed to setup clustering, clustering disabled. ClusteringNotSupportedException: Could not access CacheManager for JBossWeb clustering
At this point I am baffled, as there are not any other obvious signs of why JBoss decided it doesn’t like this context and undeploys it. The message “Could not access CacheManager for JBossWeb clustering” on Google only points to the source code from where it came, so I am either way off or this is not related.
Upon further research, these messages have nothing to do with the undeploy. There is a majorly annoying bug in all of JBoss 5: http://stackoverflow.com/questions/1451614/jboss-deploy-undeploy-loop-caused-by-hdscanner-in-a-exploded-ear
You pretty much can’t have anything but .xml files in your WAR WEB-INF directory. Removing a .jpg from here resolved this issue.
Error #6: SEAM Actions don’t resolve
2011-10-17 15:08:59,774 WARN [org.jboss.ejb3.interceptors.aop.InterceptorsFactory] (http-localhost%2F127.0.0.1-8080-1) EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
2011-10-17 15:08:59,805 WARN [org.jboss.ejb3.interceptors.aop.InterceptorsFactory] (http-localhost%2F127.0.0.1-8080-1) EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
2011-10-17 15:09:13,555 WARN [org.jboss.seam.security.jaas.SeamLoginModule] (http-localhost%2F127.0.0.1-8080-2) Error invoking login method
javax.el.PropertyNotFoundException: Target Unreachable, identifier 'loginAction' resolved to null
Apparently there is a problem with the SEAM security configuration, which is what controls login. This is to be expected since security changed in SEAM 2.2.2: http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Seam_Reference_Guide/Migration20.Changes.html
There is also of course different XSD’s now available, which require that you change all the -2.1.xsd’s to 2.2.xsd’s.
The following post indicates that the problem may be that the class inside the JAR within the EAR is not being picked up by SEAM, because there is no seam.properties files in the JAR: http://stackoverflow.com/questions/3978976/can-the-seam-authenticator-reside-in-the-ear-file-lib-folder
This was the problem. If you have beans in a JAR that JAR must define an empty seam.properties file in order for it to be scanned for beans.
Error #7: javax.naming.NameAlreadyBoundException: classPathEntries
Apparently there is an issue with the hibernate-core jar existing in both the ears in the deployment, this was resolved by deleting deleting the second ear. Eventually the second EAR was made to not include this JAR.
Also had the same problem with javassist
Error #8: Unit Tests no longer run out of Eclipse
The problem is running unit tests with a classpath that is too long in Eclipse.
You have to edit the classpath of the target to not include external dependencies
Error #9: Some pages are 404 not found
This was a really annoying problem that plagued me for a long time. Buttons that used to correctly direct to htm pages were no longer working. Upon closer inspection the link that works is going to pageC.htm while the one that doesn’t is going to pageB.xhtml. Something is not rewriting xhtml to htm in the page rendering.
The problem the entire time has been these pages were named “xtml” instead of “xhtml” and I didn’t see it. Apparently the previous version of SEAM, JBoss, Java, or something else handled xtml even though it is not a part of the configuration.
Error #10: java.lang.InstantiationException: org.apache.log4j.Logger
javax.ejb.EJBException: java.lang.RuntimeException: org.jboss.serial.exception.SerializationException: Could not create instance of org.apache.log4j.Logger - org.apache.log4j.Logger
...
caused by: java.lang.InstantiationException: org.apache.log4j.Logger
Google only provided two solutions: make the logger static or declare it as @Transient
Doing both of these didn’t get rid of the error.
There was a warning about a @Destory method in a class that was using a log4j logger, so I changed it to be seam injected. This too didn’t work, even when marked with @Transient.
As it turns out the way to fix this is simple, only use static transient Loggers. In my application this means I had to do this 890 times. A result of this problem is also a memory leak, because the beans can’t be destroyed.
Error #11: EJB Timer throws a null pointer exception
2011-10-28 09:19:54,584 ERROR [org.jboss.ejb.txtimer.TimerImpl] (EJB-Timer-1319811479419[target=jboss.j2ee:ear=Irio.ear,jar=jboss-seam-2.2.2.jar,name=TimerServiceDispatcher,service=EJB3]) Error invoking ejbTimeout
javax.ejb.EJBException: java.lang.RuntimeException: java.lang.NullPointerException
It doesn’t prevent startup and corrects itself, but slows the start up process down. There doesn’t appear to be anyway to get rid of getting this exception at least once on start up.
However, it should be noted that if you start getting these errors several times during startup it is an indication that JBoss will fail to startup eventually. The only way to prevent this is to delete the tmp, work, and data directories every time you restart a JBoss instance.
Error #12: Caused by: java.lang.NoClassDefFoundError: org/jgroups/Channel
The solution is to add the jgroups jars to lib/endorsed for whatever server you are running.
Reference: http://community.jboss.org/message/440606
But then you get a stack:
2011-11-03 09:57:33,359 ERROR [org.jboss.ejb3.cache.simple.SimpleStatefulCache.SMSOptionsActionImpl] (SFSB Passivation Thread - jboss.j2ee:ear=Irio.ear,jar=IrioAccountApplication.jar,name=SMSOptionsActionImpl,service=EJB3) problem passivation thread
javax.ejb.EJBException: Could not passivate; failed to save state
Reference: http://seamframework.org/Documentation/HandlingPrePassivateCleanupInSFSBs
Reading this article lead me to take a look at clustering again, which has to do with Error #1. As is turned out setting the troublesome class to clustered = false in the jboss.xml seems to have resolved this issue.
I again had to come back to this, and found that further down in the stacktrace there is a message about a missing class.
Long story short, I had to add the following jars to lib/endorsed:
- mail.jar
- log4j.jar
- commons-logging.jar
- jbosscache.jar
- jgroups-all.jar
- pojocache.jar
- jbosscache-core.jar
The error following the passivation error, was java.lang.NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapper
When I looked in the logs prior to all of this and during startup, I found that there was a warning message stating the clustering was disabled because orjava.lang.NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapper. So I figured if I got rid of this startup error that it would get rid of the passivation error. The problem though is that they only way to get this error is to do something involving the bean, and then wait several hours.
Error #13: Database connection hangs forever (using MS SQL)
The reason for this has to do with a problem between Java 1.6.0_29 and the MS SQL JDBC driver. The only solution is to use Java 1.6.0_27, which is why that is the version of Java listed in the new spec even though it is not the most recent version of Java 6.
Error #14: JBOSS_HOME and JAVA_HOME environment variables do to propagate into scheduled tasks
http://community.installshield.com/showthread.php?t=147931 indicates that the only way Scheduled Tasks can pick up changes to environment variables is to reboot the machine. However, in my case I was not able to reboot the machine so I had to find a workaround.
To do it without having to reboot:
- Login as the non-running user
- Disable all Scheduled Tasks
- Change the environment variable
- Start the Task Manager and select to show all processes from all users
- In the Task Manager, kill all tasks being run by the Scheduled Task running user (taskeng.exe)
- Log Off
- Log on as the non-running user
- Enable all Scheduled Tasks
ERROR #15: java.lang.OutOfMemoryError: unable to create new native thread
This issue has to do with the following things:
- The amount of memory allocated with Xmx. This is in your conf if using the service wrapper.
- The amount of memory allocated with Xms. This is in your conf if using the service wrapper.
- The maximum number of AJP threads allowed in jbossweb.sar/server.xml
The key is finding the balance between these values, which is dependent on Java version, what your application is doing, and how much memory is available on your machine.
Reference: http://blog.egilh.com/2006/06/2811aspx.html
Error #16: Failed to parse source: {http://java.sun.com/xml/ns/javaee}virtual-host
org.jboss.xb.binding.JBossXBException: Failed to parse source: {http://java.sun.com/xml/ns/javaee}virtual-host cannot appear in this position. Expected content of {http://java.sun.com/xml/ns/javaee}web is unordered_sequence: {http://java.sun.com/xml/ns/javaee}context-root? {http://java.sun.com/xml/ns/javaee}web-uri?
The following is no longer valid, as virtual-host isn’t allowed here.
<module>
<web>
<web-uri>foo.war</web-uri>
<context-root>/foo</context-root>
<virtual-host>myhost</virtual-host>
</web>
</module>
Remove it because it should be defined in jboss-web.xml anyways.
Error #17: javax.ejb.EJBNoSuchObjectException: Could not find Stateful bean: 41z4l26-wb41k6-ev4j007b-1-ev4jirql-bw
I have been seeing this error in the logs quite often and in the previous version of JBoss, being 4.2.2. It didn’t appear to be critical so I jut let it be like the hundreds of other errors. I however stumbled across and article explaining the cause for this: http://community.jboss.org/wiki/JbossTimeoutSettingForSeam
To summarize, you get this problem with stateful session bean timeouts do not match the session timeout. This is great considering that the default session timeout (web.xml) is 30 minutes while the default stateful session bean timeout is 5 minutes (ejb3-intercepters-aop.xml).
Warning #1: EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
This is something that can be ignored entirely, and the developers even recommend that you do. Every time you access a bean you will get this warning, so it floods the log.
