JBossDeveloper

Correct in majority of the cases, especially in public networks, but in my case, I already trust the authenticity of the other end.

I understand you may "trust" the other server, but that doesn't prevent you from being exploited.  If you're OK with exposing your data to a simple man-in-the-middle attack why do you care that it's even encrypted?  Maybe I'm an idealist, but encryption without proper authentication seems like a complete waste of time - especially when the resolution to the problem is a simple upgrade.  In the end it's your data of course, so you can do whatever you want with it.

Is there really no way to configure this XARecovery environment with SSL?

I'm not sure how else to explain it at this point.  SSL authentication in HornetQ 2.3.0.CR1 is broken.  If you want properly secure SSL then you need to upgrade (either HornetQ itself or the application server as a whole).  It's as simple as that.

The latest public release of Jboss AS 7.x is 7.2.Final, I am not using EAP (it's not the topic of the discussion but I am not interested in switching to the EAP version).

When I said "GA release of AS7" I was referring to releases that are generally available for download on the website.  I'm certainly aware that you could download the Git tag of 7.2 and build it yourself, but again, I wouldn't consider that a GA release since it isn't generally available. 

As discussed in the community during 7.2 release time, 7.2 was called EAP 6.1 (and used as base for EAP) but despite that version name, 7.2 was the actual latest AS7 stable release. (as mentioned in the git commit  that states "version 7.2.0.Final")

As you note, the 7.2.0.Final tag was used as a base for EAP 6.1, but EAP 6.1 had several important changes such as using HornetQ 2.3.1.Final instead of 2.3.0.CR1.  In any event, you can download EAP 6.1 for free from the same place where you can get GA releases of AS7.  It's not clear to me why you wouldn't simply choose to use that (or a newer) version.

I won't get into all this again, but it's worth noting that the 7.2.0.Final tag was always for internal purposes related to the development of EAP 6.x.  It was never meant to get a GA release (which is why it never was).  The commit message for the 7.2.0.Final tag says, "Prepare 7.2.0.Final for pre-releases."

Version 7.2 also fixes many bugs that I experienced with 7.1.1, that's why I don't understand the introduction of many CR and Beta packages in 7.2.0.Final (why call it final?)

I realize that the 7.2.0.Final tag has a lot of bug fixes over 7.1.1.Final, but that doesn't necessarily mean it's suitable for a GA release.  Is this ideal?  No.  Is it slightly confusing?  Yes.  A lot of factors went into the decision and in my opinion it was the right one.