We Keep Coding

Wildfly domain mode additional validations problems

I am currently working on migrating my company's production environment from JBoss 5 to Wildfly 10 and Java 6 to Java 8, I have heard that the domain operation mode may present some additional validations problems between exchanging messages between DC And HCs, Can anyone with more experience explore this matter and tell if domain mode can be disadvantageous and bring problems in the production environment?
I know that depends on the application and the infrastructure available, I will mention some features used by the application, EJB, JMS, Infinispan to hibernate entity caches, APIs with JAX-RS, I am also creating load balancing based on Metric (heap) with apache to direct the request between servers.
The Environment is composed of several clusters, some larger with about 15 wildfly servers and other smaller ones with 2 servers.
Thanks

We just migrated few of our production environments from JBoss 4.2 to WildFly 9 including all third party jar updates + jdk6 to jdk 8.
WildFly comes with almost latest modules of every library, it means you have to also update your code accordingly or you have to exclude those modules in wildfly.
You are referring documentation of WildFly 8. I would recommend if you are planning to upgrade to WildFly 10 then refer https://docs.jboss.org/author/display/WFLY10/Operating+modes. There might not be any difference in documentation but its better to refer documentation of same version.
To setup and configure cluster we referred https://docs.jboss.org/author/display/WFLY9/WildFly+9+Cluster+Howto
and
https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
Transactions behavior has also changed in WildFly.
Applications are working fine and it's much easier to maintain in WildFly as compared to JBoss.
There is a tool called WindUp which will also provide you an estimate of changes for migration.

Hibernate without Java EE 6

I have Websphere 7 server, and it don't support JPA 2.0. So I can't run on WAS 7 JPA 2.0 applications.
But I'm wondering how Spring users run Hibernate on Tomcat or Jetty? This servlet-containers also (as WAS 7) doesn't support Java EE 6.
So it's mean that I can run Hibernate on WAS 7 with the same results as on the Tomcat or Jetty?.
If yes, what are benefits of using app-servers for JPA? Why all developers don't use servlet-containers instead app-servers?
Also I heard about "container-managed" stuff, that allows some additional features and functionality. So it's mean that many developers (who uses Spring on Jetty and Tomcat) don't get benefits of using container-managed features of app-servers?
P.S. I know about available Feature Pack patch for WAS 7 for JPA 2.0 support, but question not about it.

You can bring in a lot of functionality by including the appropriate jars in your WEB-INF/lib folder, but then the servlet container cannot help you in any way with the functionality, and it will most likely not be well integrated with the functionalty actually provided by the container. A typical example is bringing your own JSF 2.0 libraries.
The real advantages of using implementations in the container, is that the container can then help with clustering across multiple hosts, providing JDBC connection pools, etc.
So, you need to be more careful when including e.g. Hibernate yourself, and do all the configuration inside your own deployment, but it can be done.

You could just as well ask an exactly opposite question: "why use bare servlet containers with JPA 2 since it is included in all the Java EE 6 servers?".
Basically it boils down to either:
having a light-weight container and then a heavy application (the Spring way),
having a light-weight application and then a heavy container (the Java EE 6 way).
After years of evolution, the models of building the applications with Spring and Java EE 6 have converged to the point where sometimes you cannot really tell just by looking at a class, whether it's a Spring or a CDI bean. So the real difference is mostly in configuration.

Application servers offer a set of services "out of the box", so they are easier to use if the offered services are the ones you need. You just package and deploy your application and the thing works. Furthermore, most of the technologies are instantiated by the application server, so you avoid a lot of classloader issues.
The problem with application servers is that sometimes (quite often, actually), you need to pick and choose particular versions of particular frameworks, services, etc that are incompatible with those which the application server offers. In those cases, you usually need to fiddle with the application server, and in some cases, what you would like to do might not even be possible with your application server.
For example, Weblogic 10.x is a Java EE 5 application server and so it will offer by default JSF 1.2 and JPA 1. If you want to use something newer, you need to manually deploy some additional libraries (JSF 2.0), or patch the server (JPA 2.0).
Another example: with Glassfish 3.1 I have not been able to use Tomcat EL intead of Glassfish EL. Tomcat EL supports varargs method call while Glassfish EL does not.
That rigidness of Java EE application servers makes a lot of people prefer developing for a standalone servlet container such as Tomcat or Jetty, where you have nothing out of the box but the Servlet and JSP APIs, but you can manually put everything inside. You can also package it with your application, which is more comfortable when you are developing, but can give you problems if you deploy more than one application per container (waste of resources, classloading issues, classloader leaks, ...)
UPDATE:
There are some differences in using JPA in a SE environment (such as Tomcat) when compared to using JPA inside a Java EE container. Basically:
You have to manually manage EntityManagerFactory and EntityManager instances.
Tomcat does not do injection so #PersistenceContext annotation and similar ones do not work.
Note that some containers (such as Spring) can be configured to hide these details, so you can work exactly as if you were inside a Java EE container.
Read the JPA spec for details on running in SE environments instead of EE environments.
Regarding another libraries, in general you will find some minor differences. For example, JAX-WS requires registering a servlet and a listener for your webapp, but anything else should be identical. Usually you can search the documentation for instructions on how to run the thing inside a standalone servlet container.

There is a JPA 2.0 feature pack for WAS 7.0, which may help you.

Is it worth upgrading to JBoss 7.1 from JBoss 5.1

Currently our production environment runs JBoss 5.1 and we have been debating whether or not its worth migrating to JBoss 7.1. If it was a simple server upgrade, then it wouldn't be a problem. But, unfortunately, we would have to change configurations and that would take some effort. Also, our server runs in a cluster and I read that JBoss 7.1 has more cluster support.
So is it worth it or not?
Thanks

We're currently in the same situation.
There seem to a a lot of things on the positive side:
We'll have to migrate off 5.1 at one point. We need full profile and there are not that many OSS alternatives (GlassFish and maybe Geronimo). That point alone will probably sell the migration since PCI-DSS forbids us to use EoL'd software.
The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files but one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard appreciate this if you've never configured a JBoss.
The EJB remoting no longer uses a thread per socket.
Removing a subsystem you don't need is so much easier.
The class loding model looks sane and you get a lot of control through jboss-deployment-structure.xml
The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
While we're not too excited about Java EE 6 replacing some of our SLSBs with #Singleton beans and some of our SARs with timer EJBs certainly looks interesting.
Faster start up and less memory usage (at least for an empty server or small deployments). We haven't yet tested a large deployment.
The deployments folder is empty by default
Things that we still need to look into:
We're a bit worried about Infinispan performance. We currently use the TreeCache API of JBoss Cache. While there is an adapter for Infinispan that provides the same API some theoretical tests show worse write performance. This only applies to the tree API of Infinispan.
ExternalContext is no longer supported, we currently use it to populate a JNDI tree from a .bindings file
JMX console is gone, if you have anything that builds on this it needs to be adapted, Edit there is actually a port of JMX-Console available AS7-2227
We don't run in a cluster so I can't comment on that.
What will probably be the biggest effort for us is migrating all the shell scripts (installation, integration tests, …) that interact in one way or another with JBoss.
Update
We have migrated and it was definitely worth it. Some updates to the points above:
Even large deployments are fast with minimal amounts of tuning.
The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
7.1 has so many bugs it was unusable for us, so we are on 7.2 / EAP 6.1 and plan to go to 7.3 / EAP 6.2. Still has its fair share of bugs but we can work around them. We're especially looking forward to role-based access control for the management interface which will allows us to run our scripts with minimal privileges.
There will not be a supported version of GlassFish 4 which puts a big question mark on it for production use.
EJB remoting security is a lot less flexible. We had to put in some workarounds since previously we were mixing authenticated and unauthenticated EJB calls — this is no longer possible.
The JEE 6 BOM POM from JBoss is a mixed bag. In theory it is nice because it manages the versions of all you JEE dependencies. In practice the coordinates are horrible with the version in the artifactId which is going to be annoying when we migrate to JEE 7. Also it isn't very helpful when you want to include an implementation of a JEE API for tests.
Infinispan tree API performance was not an issue.
We replaced the JMX-Console scripts with DMR scripts.
Update 2
There is a deadlock when using EJB remoting over SSL. This deadlock is present even in EAP 6.2. We're now at the point when we have quite a patch set of features backported from WildFly to AS 7.

Is everything working on JBoss 5.1.0 for you? Is your performance something you can live with?
I'm currently in the middle of upgrading from JBoss 5.1.0GA to JBoss 7.1.1 and it has not been easy at all. You're basically upgrading to a new application server. You will need to budget a lot of dollars for this effort I'm guessing.
Having said that JBoss 7.1.1 is VERY fast compared to 5.1.0 (start up times at least). I think in the next 6 months (or so) most of the "hard" migration and transition issues will be fleshed out in the jboss forums or through bug fixes. At that point you and your team can reevaluate if you want to do the migration.
Good luck!

If you are using SSL, one advantage to upgrading is that JBoss 7.1.1 runs on jdk 1.7, which has support for TLS 1.1 & 1.2, while jdk 1.6 only supports up to TLS 1.0. JBoss 5 will not run on java 1.7 so you are susceptible to a BEAST attack.

Regardless, I'd wait a bit.
AS 5 is a EE5 server, AS 7.1 is a EE6 server (and EE6 spec came out in 2009). So that's alot of work for an excellent new runtime environment, but it won't give you any hot architectural possibilities.
The WildFly 8.0.0.CR1 is already due and that's EE7 server bringing you a bunch of new interesting developing possibilitites, like WebSockets and JAX-RS 2.0 (http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof). New admin features like Single Instance Patching. And it's not sure that AS7-to-WildFly8 will be a super-easy migration since som major new stuff is introduced, like Undertow instead of JBossWeb/Tomcat.
If you gotta go, you gotta go - and if U wind down the dead 7.x path, don't forget to get your hands on the much improved 7.2.0.Final tag (several hundred issues better that 7.1.1). But if you think you can start developing/migrating now using Beta/CR releases and wait some months for a nice production-stable WildFly 8.x.x release, you might be able to sit tight longer before next major update.
br,
Jens

Benefits (and tips) of an upgrade from JBoss 4.2.x to JBoss 5.x, 6.x, 7.x and WildFly 8.x?

Please assume that I do not need to worry about development time and costs: I am interested in general technical benefits (improved performance? improved APIs?) and new features.
I am currently working on products using 4.2.x, and we consider a major shift for versions that are a long time ahead and need to converge.
I had a brief look at the release notes of each version and some articles about each release for 5.x, 6.x, 7.x and 8.x. But I would be glad to have first-hand feedback from people who have made the switch.
I noticed there are some important changes surrounding messaging (switching from JBoss MQ to JBoss Messenging), and that for JBoss 7.x it seems to change a fair bit its configuration layer. Then there's a lot more going on when switching to JBoss/WildFly 8.x.
Please recommend good articles pointing at pitfalls if you can. I found a few for migrations to JBoss 5.x, but not that many for 6.x or even 7.x, and someone else is evaluating 8.x for us now. Feel free to recommend alternatives as well if you think they are relevant, though I'd prefer to focus only on JBoss.
For information, we use a mix of JPF- and OSGi-enabled (using Eclipse Equinox) plugin-based systems, with clients developed in Swing (some deployed via WebStart).
Update: Though this question brought some great answers already, I think it deserves an update for WildFly (and actually, our internal projects delayed making the switch from 4.2.x to 7.x as originally planned to wait for WildFly). New thoughts and answers are welcome.

I've upgraded from JBoss 4 to 5 and from experience the following are the most important to note:
JBoss 5 (and 6 and 7) are not as forgiving as JBoss 4 with XML files. You must make sure that all your deployment descriptor XML files are valid. You may be using DTDs in some files - I recommend upgrading these to use XML schema instead.
Some libraries may cause incompatibilities. This can be particularly true if you access web services and/or do XML parsing
If you precompile your JSPs in JBoss 4, you probably won't be able to in JBoss 6/7.
JBoss 4 and 5 use different message queue implementations. If you have any message queues or topics defined you will need to redefine them.
JBoss TreeCache is no longer used. If you use this for caching purposes, you will need to change to use the new JBoss cache instead.
JBoss 5 security is different. If your remote clients require secured access to JBoss, you will need to configure them differently.
Some useful resources are:
https://dzone.com/articles/migrating-jboss-4-jboss-5
http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga
Officially JBoss 6 is only certified for the Java EE Web Profile, so if you use "legacy" features such as EJB 2.x, they will potentially not be supported in the future. Depending on the lifecycle of your application, this may or may not be a problem. JBoss 6 currently supports EJB2.1 fully, but it is not certified against this.
I have also found that JBoss 5 handles memory a lot better that JBoss 4. With JBoss 4 I see a lot more PermGen errors than I do with JBoss 5.

I can only speak from production experience with JBoss 5.1.0 and some investigation of version 6.
JBoss 5 is Java EE 5 and JBoss 6 and 7 are Java EE 6. The disparity in API features is best documented in those specs. JBoss 6 is likely to have a very short shelf-life; it is only certified for the Java EE 6 web profile and bugfixes are being targeted at version 7 (in its 3rd beta at time of writing).
I think you'd get better answers on the JBoss community forum.

We upgraded from JBoss AS 5 to JBoss AS 7 and are eying towards WildFly AS 8.1. Right now we can't migrate to 8 because there is no MQ Series JMS 2 RAR.
Some of the differences:
The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files. Instead everything is one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard to appreciate this if you've never configured a JBoss 5.x.
The class loading model looks sane and you get a lot of control through jboss-deployment-structure.xml
The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
The EJB client maven dependency mess is gone, instead you now get a BOM POM.
You get a BOM POM for the server APIs.
Faster start up and less memory usage. We deploy 80 EJBs and the MQ Series RAR in 6 seconds without much tuning. Our live dataset is somewhere above 200 MB.
The deployments folder is empty by default
The (lack of) quality of XNIO is scary. In 7.x it's only used for EJB remoting and we hit several show stopper bugs (deadlocks, double free, socket handle leaks, …). In 8.x it is used for servlets as well instead of Tomcat. There are still a lot of very basic servlet bugs being fixed in undertow.
Changes that we had to do our application:
change JNDI names to EE 6 standardized names
migrate from JBoss Cache to Infinispan (part of our code has been migrated to the flat API, some parts still use the tree API)
security is slightly less flexible (you can no longer fix authenticated and unauthenticated calls)
some horrible code that relied on details of remote JNDI
the configuration of the EJB client is different
all of you scripts for installing, deploying, starting, stopping, …
ExternalContext is gone, we had to replace it with a different approach
we replaced MBeans in SARs with #StartUp EJBs
some ugly hacks for Cocoon
The AS 7.x series has a lot of bugs with fixes only available in the EAP series. If you want go to with 7.x instead of 8.x we strongly recommend you buy EAP 6.

Here is an interesting thread on JBoss AS 7 compromises and future, also mentioning issues with AS 5 and AS 6:
http://community.jboss.org/message/613171

Just wanted to bring this to anyone's attention who might be facing PermGen bloat issue after upgrading to the latest. The JBoss-6 Microcontainer tries to scan for Jboss specific annotations by loading the classes from all the JARs in the class-path on startup. This causes the PermGen bloating as it starts to load all the unwanted classes. To reduce the amount of scanning, the Microcontainer provides another descriptor hook, by means of jboss-scanning.xml.
Add this 'jboss-scanning.xml' to the WEB-INF inside WARs and ass 'jboss-scanning.xml' to the META-INF inside EARs.
<scanning xmlns="urn:jboss:scanning:1.0">
<!-- Purpose: Disable scanning for annotations in contained deployment. -->
</scanning>

Real world comparisons of Glassfish and JBoss 5?

Does anyone have experiences with both in the real world? How do they compare in terms of performance (memory usage, speed, etc)? Stability?
Does JBoss Seam work well on Glassfish?

A number of things from my own experience:
GlassFish has much better administration console
(JBoss has three consoles, each of them far from being ideal).
Hot deployment is more reliable on GlassFish
JMS works better on GlassFish - this applies to GF vs. JBoss 4.X.
As far as I see the JMS implementation was drastically modified in
JBoss 5.X, so maybe this claim is no longer true
WebServices are working better on GlassFish,
I had a number of issues with more advanced configuration on JBoss
GlassFish has more super-high-end entrprise add-ons, like HA-Database, that stores
user session on a cluster in Database, not in memory, so the full failover is
possible, whatever disaster would happen
JBoss is more much popular, there are a lot of administrators, developers, who know it,
so it is easier to find someone, who can develop on JBoss, there are also more
resources in the net. Sometimes this is more important, then technical superiority of
one solution over another.
GlassFish is friendlier for developers. Redeployment of the web application on GF 3
lasts more or less one second - in oreder to achieve this kind of speed
of redeployment for JBoss I need JRebel. In addition, if someone is using NetBeans,
there is a number of smart wizards, that are very helpful.
The future of GlassFish is not certain because of the acquisition of SUN by Oracle.
Right now Oracle claims it will support it, but who knows how this support will
look like and how long will it last. Even though GlassFish is open source, hardly
anyone is ready to develop application server for his/her own needs...
From my point of view GF is easier to administer, is a better solution from purely technological point of view, but it is far less popular and has uncertain future.
I am not connected in any way with RedHat/JBoss or SUN/GlassFish, my company (erudis.pl) is supporting and developing for both servers.

(disclaimer: I work at Sun and I am in the GF team)
I agree that Seam works fine on GlassFish; see https://blogs.oracle.com/theaquarium/tags/seam
GFv3 is quite different than JBoss 5; in particular:
GFv3 is based on OSGi while JBoss 5's kernel is based on JMX.
GFv3 supports JavaEE 6; JBoss 5 supports Java EE 5.
GFv3 is designed to be very modular; services start on demand, there is an update center repository, etc. GFv3 is significantly smaller than JBoss 5 and will start much faster. JBoss 5.1 GA is listed as 130MB; GFv3Preview is 50MB. GFv3 starts in a couple of seconds; JBoss in tens (you should try the startup for your own platform).
There are other differences, some inherited from GlassFish v2 like the graphical admin console, or the admin CLI.
A more direct comparison for JBoss 5 would be the GlassFish v2 releases, which are based on Java EE 5. The latest release in that family is GFv2.1, with a GFv2.1.1 release scheduled in October (see https://blogs.oracle.com/theaquarium/entry/schedule_for_glassfish_v2_1).
Sun also provides patch releases of GlassFish (akin to RedHat's support for JBoss); see https://blogs.oracle.com/glassfishforbusiness and sun.com/glassfish.

It's strictly what you're used to. I found configuring and using JBoss to be about as pleasing as trying to shave with a jagged spoon while riding a unicycle with no seat. Glassfish however, just seems to work.

My choice is Glassfish: it is faster to start-up, to deploy web applications.
the Admin console is very accurate, moreover it is both graphical and command-line.
Now it is fully-supported by Oracle, its future is not uncertain any more.
It is based upon OSGi: it is really modular.
You can install Spring-osgi applications easly.
You can freely choice between Eclipse Link , Apache Open JPA and Hibernate without pain.
It is greatly integrated in NetBeans (and, of course, Eclipse).
On the other hand, Jboss is more widespread and thus it is easy to find job on it (IMHO because it is an old App Server; glassfish is relatively new).

I started developing a Seam application on JBoss and after a few months tried to get it working on Glassfish. I found the Glassfish enviroment very counterintuitive. I had to fix some strange errors on GF and I could not find any information on the web so after a few days I gave up and went back to JBoss. So personally I would not recommend Glassfish.

I will have to go with Glassfish on this. Deploying a diverse range of application built on different webservices, we had major compatibility issues, resulting in customizing the class loading & still faced many issues. Glassfish I never faced any such issues.