Restcomm - JBoss 5 Compatibility - jboss

There is a project we've been working on and we use JBoss 5 in it. Recently we wanted to use Restcomm in our project as well but JBoss versions seemed to be a problem. We work with JBoss 5 but from what I understand Restcomm started with JBoss 7 and moved on from there. My question is, is there a way to use Restcomm with JBoss 5, because upgrading from JBoss 5 means a lof of work fork us?

Related

Is it fine to use WildFly 10 instead of JBOSS EAP 7? If so, is WildFly 10 stable?

I want to use JBOSS EAP 7 but it has subscription charges so I changed my mind to use WildFly 10. Also, I want to know if all the functionalities of WildFly 10 works well just like JBOSS EAP 7. Anyone can give me some ideas?
Please check Is JBoss EAP 7 has a functionality that Wildfly doesn't have? and links https://www.redhat.com/en/technologies/jboss-middleware/application-platform, https://developers.redhat.com/products/eap/download/ .

JBoss AS vs WildFly 8

Can anyone please give me the main difference between JBoss AS 7 and WildFly 8?
I'm going to start a very important project and I have to choose between JBoss AS 7 and WildFly 8 (for this project I'm going to use GWT, JPA/Hibernate and jBPM 6).
WildFly 8 is the next iteration of the JBoss application server after JBoss AS 7 / EAP 6.
Basically:
JBoss AS 7.x = JEE6
JBoss EAP 6.x = JEE6
WildFly 8.x = JEE7
Red Hat typically backports security fixes from newer versions into older versions, Red Hat also typically releases "feature packs" that allow you to access newer features/specs.
So if it is a very important project and you do not need JEE7 specs, you may want to use JBoss EAP which is the productized version of JBoss AS 7.
Otherwise you may want to use WildFly if you need the more cutting edge specs and features.
Related
See JBoss AS / WildFly versions history for more details.
WildFly is the new name of JBoss AS so that the company JBoss and the application server JBoss cannot induce confusion anymore.
Think of WildFly 8 as JBoss AS 8, just with a different name.
JBoss 7 is an implementation of JavaEE 6.
WildFly 8 is an implementation of JavaEE 7.
The JBoss application server is the "commercialized" version of the community Wildfly application server. Red Hat offers support contracts for JBoss and has a long term maintenance schedule for JBoss.
The versions are also different. JBoss EAP 6 corresponds to Wildfly 7.

Is it ok to deploy today with Wildfly8 waiting for the next JBoss EAP to be released?

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.

What community version of Jboss is recommended for jdk 1.7 and why

I need to migrate from Jboss 5.1.0 GA to any other that supports jdk 1.7.
I'm currently using jboss 5.1 with seam 2, jdk 1.6 and sqlserver 2008 r2.
What community version of Jboss is recommended for jdk 1.7 and why?
Thanks in advance!
You can actually get JBoss AS 5.1.0 GA to run on JDK 7, see JBAS-6981. All of the following options will work with JDK 7:
JBoss AS 5.1.0 (plus the fix for JBAS-6981)
JBoss AS 6.1.0
JBoss AS 7.1.1
JBoss EAP 6.2
WildFly AS 8 CR 1
The right solution depends on your situation:
The simplest solution with the least risk is to stay with JBoss AS 5.1.0 and fix JBAS-6981 yourself. We did that and ran with it for over a year and it worked fine. Note however that JBoss AS 5.1.0 is end of life, eg. there aren't any security patches available.
If you don't want to fix JBAS-6981 yourself you can go with JBoss AS 6.1.0. This should be quite a simple migration because it builds on the same architecture and has the same disk layout. Note however that it is Java EE 6 which means among other things standardized JNDI names. Depending on your application this can have quite a bit impact — or none at all. Note however that JBoss AS 6.1.0 is end of life, eg. there aren't any security patches available.
The next "stable" community version is JBoss AS 7.1.1 with brings a whole new architecture. Depending on your application that can be quite a large migration — or a really simple one. However I would recommend against JBoss AS 7.1.1 as it's buggy as hell. Note there won't be any future releases for JBoss AS 7.1.1 as well.
JBoss EAP 6.2 builds on JBoss AS 7.1.1 (AS 7.3 actually) and contains many bug fixes (and some features). You either need to build it from source or get a license from Red Hat. There will be patches for EAP 6.2.
The current in development community version is WildFly AS 8 CR1. As you can see from the version name there isn't a stable release yet. And it contains a whole new servlet engine, which makes a whole lot of people nervous. I would only use it if you have really good integration tests.
I don't know what the situation regarding Seam is for any of them.
Note that sooner or later you'll have to migrate to a newer version of JBoss AS anyway. To judge how hard the migration will be you first need to know what dependencies on JBoss AS you have in your code.

Migrating fron jboss 4 to jboss 5.1.1 eap

please let me know what are the changes i have to do if i want to deploy the application which was running in jboss 4 and built with ejb 2.0
I am trying to deploy the same ear which was running in jboss 4 and built with ejb 2.0
but i am getting deployment exceptions.
There's a fairly big list, but thankfully it's been documented by some kind people that have done it before. Here's the JBoss community documentation on likely migration issues:
Migration from JBoss 4 to 5