Keyfactor
Update from ejbca-ce 6.15 to 7.4/7.9: Java-error "could not deserialize" in wildfly's server.log
Hello @ll,
we followed the instruction from https://doc.primekey.com/ejbca790/ejbca-installation/application-servers/wildfly-24 and ending up in the java error: could not deserialize. Trace: 2022-09-06 10:50:51,926 INFO [org.ejbca.core.ejb.authorization.AuthorizationSystemSessionBean] (ServerService Thread Pool -- 117) Roles or CAs exist, not intializing Super Administrator Role 2022-09-06 10:50:56,574 WARN [io.undertow.servlet] (ServerService Thread Pool -- 98) UT015020: Path /* is secured for some HTTP methods, however it is not secured for [HEAD, POST, GET] 2022-09-06 10:50:56,577 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: '/ejbca/ra' for server 'default-server' 2022-09-06 10:50:58,321 ERROR [org.jboss.as.ejb3.invocation] (ServerService Thread Pool -- 117) WFLYEJB0034: EJB Invocation failed on component EndEntityProfileSessionBean for method public abstract void org.ejbca.core.ejb.ra.raadmin.EndEntityProfileSessionLocal.initializeAndUpgradeProfiles(): javax.ejb.EJBException: javax.persistence.PersistenceException: org.hibernate.type.SerializationException: could not deserialize at [email protected]//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:266) at [email protected]//org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:388) at [email protected]//org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:158) at [email protected]//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at [email protected]//org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at [email protected]//org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72) at [email protected]//org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at [email protected]//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at
Lines later in wildfly's server.log we get also the error message: ClassNotFoundException: org.jboss.invocation.MarshalledValue
Complete line for "ClassNotFoundException":
2022-09-07 08:34:52,439 ERROR [org.ejbca.core.ejb.upgrade.UpgradeSessionBean] (ServerService Thread Pool -- 109) Error thrown during upgrade: : javax.ejb.EJBException: java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.invocation.MarshalledValue from [Module "deployment.ejbca.ear" from Service Module Loader]
In wildfly's standalone.xml we could find the line:
and the file:
/opt/kvtg/wildfly-24.0.1.Final/modules/system/layers/base/org/jboss/as/clustering/infinispan
but we could not find:
We used following system and software versions: OS: Centos 7 Wildfly: 24 (we tried v20 and v15 as well) ant: 1.9.4 ejbca: 7.9 (7.4 also) java: java-1.8.0-openjdk-1.8.0.342.b07-1.el79 (java 11 has the same behavior).
At the moment we have not any success and any help is apreciated.
Kind regards, Michael
Hi,
This is a known issue that I am told is fixed in the upcoming release. It's a problem with some value in the End Entity Profiles.
Hello Tomas,
starting wildfly 24 with ejbca-7.10.0.2 shows same error message and trace:
2022-10-25 09:40:38,987 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service 2022-10-25 09:40:39,134 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing. 2022-10-25 09:40:39,145 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 4 (per class), which is derived from the number of CPUs on this host. 2022-10-25 09:40:39,319 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] 2022-10-25 09:40:39,621 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0012: Started server default-server. ...skipping... 2022-10-25 09:43:10,812 ERROR [org.jboss.as.ejb3.invocation] (ServerService Thread Pool -- 104) WFLYEJB0034: Jakarta Enterprise Beans Invocation failed on component EndEntityProfileSessionBean for method public abstract void org.ejbca.core.ejb.ra.raadmin.EndEntityProfileSessionLocal.initializeAndUpgradeProfiles(): javax.ejb.EJBException: javax.persistence.PersistenceException: org.hibernate.type.SerializationException: could not deserialize at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:268) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:390) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:160) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
kind regards
Michael
I see that I missinterpreted the error, it's not the issue that I thought.
Do you have "db.keepjbossserialization=true" in conf/cesecore.properties by any chance?
The first error message is still: 1291:2022-11-03 10:10:02,300 ERROR [org.jboss.as.ejb3.invocation] (ServerService Thread Pool -- 109) WFLYEJB0034: Jakarta Enterprise Beans Invocation failed on component EndEntityProfileSessionBean for method public abstract void org.ejbca.core.ejb.ra.raadmin.EndEntityProfileSessionLocal.initializeAndUpgradeProfiles(): javax.ejb.EJBException: javax.persistence.PersistenceException: org.hibernate.type.SerializationException: could not deserialize
That didn't answer my question about "db.keepjbossserialization=true" did it?
The title of this issue is confusing. It says upgrade of EJBCA, but I think this issue was triggered by an upgrade of WildFly was it not? What version of WildFly were you running before, when things were working?
ejbca version 6.15 was working with wildfly 15,20 and 24. Upgrading ejbca to 7.4 and 7.9 was not working with wildfly 20 and 24. Upgrading to ejbca 7.10 was not working with wildlfy 24.
Tomas. I had assumed that the wildfly's standalone.xml needs to be adapted to ejbca 7.4/9/10. Could you please provide such an configuration file? Then I would try to adapt to our needs.
Sorry. This option is set now. Before this option was not set.
It's recommended to keep it as false. So don't enable it please :-).
Could you post the full stacktrace, perhaps a file attachment of server.log?
- stop wildfly
- remove server.log
- start wildfly
- get error, attach server.log here
How old is this installation originally from? org.jboss.invocation.MarshalledValue in GlobalConfigurationData sounds like an EJBCA 4 type. Reading GlobalConfiguration looks to behave the same in both EJBCA 6.15 and 7.x, I can't see any difference in code. MarshalledValue is a type that was removed from JBoss/WildFly a long time I believe.
We maintain this installation since 2014 but originally it was even itroduced earlier.
Are you sure the new installation points to the upgraded database from 6.15? And not to an older EJBCA 4 database?
What you should have done is to upgrade, incl post-upgrade on EJBCA 5 then. There are different ways to progress I guess. Find a version of WildFly that has MarshalledValue class in it and make sure GlobalConfiguration is upgraded there (load-edit-save).
Another option, maybe, is to delete GlobalConfiguration and it should be re-created when you start up (I'm unsure, it's a maybe).
A third is to make another (new) installation, and database-copy GlobalConfigurationData from the new system and overwrite what's in the old.
I'm a bit surprised, this should have been taken care of in the upgrade step to 6.3.2.6: https://doc.primekey.com/ejbca/ejbca-installation/upgrading-ejbca
But it's likely salvagable using one of the way outlined.
GlobalConfiguration holds the data that you can see in the Admin UI->System Configuration. Check your old system what is there first, likely most default settings.