We are migrating from JBoss EAP5 to EAP 6.3. There is a file in EAP "ejb2-timer-service.xml" where one can choose to persist timer in local DB or not. What would be the equivalent in EAP 6? Thanks!
From JBoss 7 is no longer supported persist EJB timers in database.
Timers are only persisted in the file system standalone/data/timer-service-data
Ability to use alternate persistent stores for EJB timers
Related
I'm migrating old applications from JBoss EAP 6.4 to JBoss EAP 7.3 and I have a strange behaviour. I setup the remote connector on EAP 7.3 and both 2.1 and 3.x EJB applications are deployed, but if I try connect from an old client, having a very old jboss client jar (1.0.25.Final-redhat-1) I have some errors.
The 3.x applications work without problem and in JBoss EAP 7.3 I can see this log when a call arrives
INFO [org.wildfly.naming] (default task-1) Wildfly Naming version 1.0.11.Final-redhat-00001
For the 2.1 EJB application (that works without problem on the old JBoss EAP 6.4) I see this different log on the server console
INFO [org.jboss.ejb.client] (default task-2) JBoss EJB Client version 4.0.27.Final-redhat-00001
and from the client side I receive this error
INFO: Cannot create a scoped EJB client context for JNDI naming context org.jboss.ejb.client.naming.ejb.EjbNamingContext#abb9e4 since the current EJB client context selector can't handle scoped contexts
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy1.create(Unknown Source)
at com.test.ejbmigration.EjbRemoteClient.main(EjbRemoteClient.java:117)
Caused by: java.lang.ClassNotFoundException: org.jboss.ejb.client.EJBIdentifier
I found an old issue related to this problem that is quite similar
https://issues.redhat.com/browse/EJBCLIENT-51
but anyway I think it isn't the same situation. Using a new client with new library there is no problem, but in my scenario I have the possibility to have an EJB 2.x application in EAP 7.3 and old client calling it in the same way.
I would like to understand if the migration of old EJB 2.x applications to EAP 7.3 and remote call from old clients can be a problem or if there is some particular settings that can be done on the server to accept also the call from old client.
I would have added this to another thread, but I am unable to comment on other's posts. And what I read did not answer my question. I just installed EAP 7.2.0.GA. In the console log, it says:
JBoss EAP 7.2.0.GA (WildFly Core 6.0.11.Final-redhat-00001)
However, others think it is around version 13. And when I look at the releases of wildfly ( http://wildfly.org/downloads/ ) a version 6 is so old it does not even show up and would have been prior to 2014...
So, how can it be 6.0.11.Final?
WildFly core is just a component in WildFly application server.
As such is also used in JBoss EAP which is a downstream product based on WildFly AS.
WildFly core is standalone project which provides most of core capabilities (management, cli, administration, subsystem infrastructure...) of the application server without any Java EE support, that is added to it by WildFly project.
you can see the sources for both at
https://github.com/wildfly/wildfly-core/
https://github.com/wildfly/wildfly/
as for your confusion.
WildFly core 6.0.x is used in EAP 7.1 as well as in WildFly 14
which you an see also in the sources https://github.com/wildfly/wildfly/blob/14.0.0.Final/pom.xml#L375
micro version is not always exactly the same, as in the process of building downstream product of EAP, extra patches can be added.
WildFly Core is a component in JBoss Enterprise Application Platform 7 (EAP 7). So, this log means:
JBoss EAP 7.2 - JBoss EAP in version 7.2
GA - General availability
WildFly Core 6.0.11.Final - component WildFly Core in version 6.0.11.Final.
See also:
JBoss Enterprise Application Platform Component Details
Software release life cycle
I'm about to start working on a project to be deployed later this year and would like to use JDK8. We use JBoss EAP for production but the latest JBoss EAP, 6.2 (based on JBoss AS 7.3) does not yet support it.
From a compatibility perspective, is it ok to start deploying in Wildfly8 now (which supports JDK8) with the expectation that later this year the corresponding EAP will come out?
It all depends on your application to be fair.
WildFly 8 support EE7 and EAP6 EE6, so it is up to you to decide what level of Java EE you need/want.
In future WildFly will be base for EAP7, which version of WildFly will depend on what is available at the time when "productivization" will begin.
As for Java 8 support goes, EAP 6.3 runs on Java 8, currently it is at Beta release which you can grab from http://jbossas.jboss.org/downloads/ with GA release coming soon.
I am currently in the phase of migrating my Clustered Application from Jboss eap 5.1 to Jboss eap 6.1 (Jboss AS 7.1). The jboss eap 6.1 uses HornetQ as its JMS system as compared to Jboss eap 5.1 which used JBoss MQ as JMS system. My application has the requirement of using global and local JMS topics(distributed and non-distributed topics). On jboss eap 5.1, there is a configuration file in the messaging folder called 'xxx-destination-service.xml' which provided a boolean attribute called 'Clustered' defined for each of the JMS topics. This xml file and the attribute is no longer supported in jboss eap 6.1. Can anyone provide me pointers on how this can be done in jboss eap 6.1.
I am Clustering my application in Domain Mode on Jboss eap 6.1 . So please tell what configuration chnages need to be done in my domain.xml or any other xml file.
TIA for your help.
Ajit
I would like to use a custom version of the HSQL DB in an application that I am deploying in JBoss. However, JBoss already contains an HSQLDB.jar. The JBoss jar is being resolved by my application instead of the custom jar in my ear.
How can I use a different version of HSQL in my web application from the one that JBoss uses internally?
Can I remove the HSQLDB.jar included with JBoss without negatively impacting the Application Server?
The custom version it's just a newer version? If it's that the case than you can simply replace the jar in the Jboss lib folder. Jboss uses HSQLDB as far as I know for queue persistence.