We Keep Coding

Why is TomEE Java EE6 certified but TomEE+ not?

Like the title says. I don't have much knowledge regarding the inner workings of Java EE6 certification. However, it seems that TomEE+ is just just a superset of TomEE, so shouldn't TomEE+ also be Java EE6 certified?
We just decided to build up Tomcat (vs not use a lot of the features in Glassfish) for our in-house developed admin apps, and am really intrigued by TomEE+ as it has almost everything we want.
FYI, we were originally just looking at Tomcat7, and installing Jersey and Hibernate.

Long story short, the entire set of TCK tests that apply to the functionality included must pass the TCK in order to be labeled "certified".
TomEE+ passes the same tests that TomEE passes (more actually), but by virtue that it includes more things and not all of them pass their respective tests, TomEE+ is not certified.
We actually only had one distribution, just plain "TomEE", but for certification requirements it became two, TomEE (the now stripped down version) and TomEE+ (the original).
TomEE+ actually passes the JAX-RS TCK, we run those tests everyday. In order to have a certified binary that includes JAX-RS we would have to either create a third TomEE distro that's Web Profile + JAX-RS, or just add JAX-RS to the plain TomEE binary. We're adding JAX-RS to the Web Profile in JavaEE 7 at the JCP level, so adding JAX-RS to plain TomEE is just a matter of time.
At the moment we're just trying to get the 1.0.0 out the door -- actually took a break from that to come check out stackoverflow :) Neck deep in scanning code and needed a bit of a breather :) The coming 1.0.0 is already about 20% faster on deploy than the released beta-2, but after this round of hacking it should be much more. I dare not say how much till it's finished, but it's looking really great so far.
Anyway, give TomEE+ a try. If for some reason you feel there are still more benefits to putting all the parts together yourself, definitely let us know and we'll figure something out. Our whole deal is making it so you don't have to do that yourself anymore. So if what is up there doesn't quite fit you, we'll make something that does.

The name of the openejb war has changed to tomee, and it looks like the download page hasn't been updated for the dropin-war section.
These sites will link to an appropriate mirror, or for any download link, substitute the text "openejb-tomcat" for just "tomee" and they should work.
http://www.apache.org/dyn/closer.cgi/openejb/4.0.0-beta-2/tomee-plus-webapp-4.0.0-beta-2.war
http://www.apache.org/dyn/closer.cgi/openejb/4.0.0-beta-2/tomee-webapp-4.0.0-beta-2.war
I'll let the TomEE guys know...

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>

Way to keep minimal application-server dependency?

What is the best (easiest, most seamless) way to build a Java app while relying as little as possible on the actual application-server used in deployment?
For example, say I want to deploy on Apache Geronimo, and later want to use GlassFish, how difficult would the transition be? What is the best way to abstract the use of each app server?
Excuse my ignorance, I'm relatively new to Java development. I want to start a new project, but am unsure on whether to use separate APIs for the functionality I need or develop on top of a chosen app-server from the start.
Thanks for your help,
Ivan

Without getting into too much details, even though you can write bare-bones Java EE code, the configuration around it is not very simple. Each application server has its own set of configuration files and naming conventions (for example, the format for specifying the location of the AS is different in IBM WAS and in JBOSS). Though these are not very important for application development, once you get to the deployment phase, these will become important.
As far as the libraries and your code is concerned as long as you stick to EJB standards you will be able to run your application on majority of the application servers (I know of WAS and JBoss - the code that I wrote didn't have to change for these servers; the configuration though, well that was a different beast !).

Follow Java EE specification as much as possible, while follow server specification least as possible.
If we try to find out what are in common among there Java EE application servers(JBoss, WAS...), answer is Java EE specification which server vendors must follow. If you have 2 solutions on a Java EE problem, you could check which solution comply with Java EE specification better rather than server specification.

From my experience with Jboss and Sun AS, you should just forget about AS-independency.
In sql, for example, you can do quite a lot without employing vendor-specific features. Well, it's not like that in Java EE. For Jboss and SAS even 'hello world' applications will require different configuration. And more application grows, more vendor-specific features you have to use.
In particular, if you look at official Sun Java EE tutorial, you'll find that it employs SAS-specific configuration files (sun-web.xml, sun-ejb-jar.xml, etc) from the very beginning.
But all above applies only if you use full range of Java EE features (like EJB, JMS, mbeans). I've found that if you just have servlets/jsps packaged in one war-archive, such application can still be very portable.

If you have the resources then consider developing and testing for several application servers instead of just your initial target one. This will allow you to - from the start - pinpoint things that need to be configurable and code accordingly.
Personally I would consider Glassfish 3.0.1 in such a situation as it is the reference implementation, so things should at least work there without any special efforts.

Java SOAP Server that can be deployed in Tomcat, JBoss, Geronimo, etc. etc. etc

I'm hoping to create a Java SOAP server which I can deploy in Tomcat, or in JBoss, or in Geronimo, or in XYZ, etc. etc. etc.
Bottom line, it should have the least dependencies possible. I'm trying to avoid libraries outside of what's included in a standard java distro because of licensing/packaging/reusability issues.
Can any provide a link to where I should start looking, or some example code?

Java 1.6 introduced the possibility to create standard SOAP webservices with the standard JDK.
There are many examples on the web, for example http://weblogs.java.net/blog/2006/12/12/webservices-jdk-6
IDEs like NetBeans also call the necessary tools (apt) automatically which makes it very easy to get started.
However I did not research how well this will work across all available containers.

Apache Axis2 (http://ws.apache.org/axis2/) should provide what you're looking for, or JAX-WS (https://jax-ws.dev.java.net/) if you want more lightweight.

Wow.
http://www.w3.org/TR/soap/
There's the standard. You will be spending a lot of time on this project. You'll need to also check out the HTTP and XML specs to build those components.
Ignoring XFire and Axis2 is an very very expensive choice...

I recently used Metro 1.4 for this (an open source glassfish component) which implements the standard approach for web services.
Drop in the jars in a Java 5 web container, annotate your class and method with standard #tags, and let Metro do the rest.
I have been very pleased with performance in a Jetty container.

If you use Spring web service module you don't need Axis or XFire. I think it's a good way to go if you're already using Spring.

Are there (experimental) JSR-262 JMX-WS enabled Java tools or applications?

I am very interested in the Web Services Connector for Java Management Extensions (JMX) Agents and the reference implementation ws-jmx-connector. JSR 262 will provide a new opportunity for cross-platform/cross-language enterprise integration projects, given the option to communicate with JMX Agents using non-Java clients. (I have been able to use the reference implementation with a Delphi client with little effort).
Are there any (open source) Java tools or products which are JSR 262 'enabled' and expose MBeans over JMX WS - so that the JSR 262 reference implementation can be used, without the need to modify their source code?

I am quite interested in it as well but I haven't had time to work with it. However, as it is just another protocol implementation you should be able to use it with the standard tools (like jconsole). Just make sure it is in the classpath and specify a valid service url, probably something like "service:jmx:ws://localhost:8080/test", when connecting.
If you look here http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html there is an example on how to extend the classpath when starting jconsole. I've used that technique for a few other protocols and it usually just works.
In order to give you a good example I downloaded the the JSR-262-ri.jar, ran the installation and added the jar-files in the lib directory to my classpath but all I got was:
SEVERE: The JAX-WS 2.1 RI is not Sun's unbundled RI.
JAX-WS jars must be located in your classpath when running on JDK 5 and JDK 6 update release 4 (or higher).
If running on a previous JDK 6 (JDK 6 to JDK 6 update 3 included) you need to use the endorsed directory .
NB: The JAX-WS 2.1 release bundled in JDK 6 cannot be used to run this Connector. The unbundled release of JAX-WS 2.1 is required.
This wrong release is loaded from : the bootclasspath.
so I guess I had some conflict that I really cannot motivate myself to spend time on right now... If anyone knows, feel free to comment. I would love to get it working on my server side to play around.
I hope this is at least a better answer than having the question unanswered.
Edit: Or did you mean open source java tools that uses it to expose MBeans so that you can use them from delphi (or whatever)? In that case I will gladly open source a simple tool if I can just get rid of that error above :-)