Develop Reference

Need to upgrade Java EE 1.4 application code to EE 7

I need to upgrade the source code for an existing Java EE 1.4 application to Java EE 7. What I need to do primarily? Any particular steps in order which I need to follow?

You are looking into a time difference of 10 years between 1.4 and 7, which in the IT is huge.
Replacing the old J2EE parts by Java EE code basically means rewrite the whole application - so it very much depends on what exactly needs to migrated and how much you can control this scenario.
From an own project where I had to deal with J2EE code I can recommend - if rewriting is not an option - to make the old application run on a new application server and only migrate small parts of it, if possible into a newly deployed application. This worked well, we still have J2EE code in the application and even add/fix small parts in the old code, but it runs together with Java EE code. One thing you have to take care about is the entity manager, because it leads you into trouble if you persist the same data via both ways.

Other than the obvious syntactical changes, I'd suggest looking at what libs you're using and seeing if those are now supported under 7.
When moving application code across versions, most of the time the jump is backwards compatible (I'd say in your case it won't be given such a massive jump) but one of the biggest factors will be if you're using legacy third party code, you'll need to find new supported versions of those products.
This includes say, if you're using a legacy application server and upgrading that. After all this then you can start to consider any syntactical changes that your IDE should help you with :)

I'd recommend WebSphere Migration Toolkit (an Eclipse plugin). Although it's primary usage is to look for a changes, when migrating from other platforms to WebSphere, it will scan your code, jsp pages, xml files and detect any Java, Java EE related issues also. So you will have rough idea what will need to be changed e.g. in relation to JDK changes.
See some info about that toolkit:
WebSphere Migration Toolkit
WebSphere Migration Toolkit download
Other WebSphere migration tools

Java EE 6 Application Server for Web Profile with JavaMail

I have a Java EE web application using features from the Java EE 6 web profile + the EJB Timer service and JavaMail. I'm currently using GlassFish 3.1.2 full profile during development, but I want to investigate the alternatives because:
There seems to be a bug with multipart forms in GlassFish 3.1.2 and GlassFish 3.1.1 had other problems hurting me which are fixed in 3.1.2. (catch 22...) That bug is fixed by the jar in the ticket.
There seems to be a lot more options for application servers supporting the "web profile" than the "full profile" and the former is supposed to be so much more lightweight.
I want to choose the best option for deployment
I am currently using the embedded application server feature of GlassFish for tests, so a similar facility for any alternative is desirable. At worst, I can live with stiking to GlassFish embedded for the automated tests.
Is it possible to "add" a JavaMail and EJB Timer Service implementation module to an applicaton server implementing only the web profile? Does it work well? If this is not possible, are there alternatives to using JavaMail and the EJB Timer Service?
Which application servers meeting my requirements can you recommend?
Finally, I considered using the "Asynchronous invocation" feature of EJBs which is not part of EJB lite. If I understood correctly, it is illegal to start threads manually when running in a Java EE container. In that case, how can asynchronous operations be started in the Java EE Web Profile?
I'm still relatively new to the whole Java EE ecosystem and terminology so please don't hesitate to ask me to clarify any parts of my question.
Supporting doc
Java EE 6 web profile vs Full profile
EJB 3.1 vs EJB lite
edit 1
According to the Apache TomEE doc, TomEE, TomEE+ and OpenEJB would fit the bill.
edit 2
Based on the AS 7.1 release notes, this thead and this issue JBoss AS 7.1.0 seems to implement all the features I need.

First of all, I have never used GlassFish so I cannot give you any information about that.
I'm not sure if your application is being build for a true production envrionment but jboss 7.1 does not yet have any official commercial support in case you run into trouble.
Jboss 5.1 optimized for JDK 6 has commercial support via red hat.
That being said, a jboss instance can be fully configured and is very flexible. That means that you can start with the 'web' profile and add/remove services you do not need. (Removing unused services is always advised for production environments.)
Here is a wiki that gives information about slimming a jboss profile in jboss 5. It indicates all steps needed to remove a service.
The slimming operation can also be reversed, so you can add anything you need to a certain profile.
So there are basicly two approaches:
Start with a profile like 'default' or 'all' and start removing services that are not needed for your application
Start with the 'minimal' or 'web' profile and start adding services you are missing for your application. You copy the services from a profile that has it. (I personally prefer this approach)
Adding and removing services can be a work of trial and error though. You need to search the internet for a correct guide for the service you are trying to add or remove. (Tip, always do your operations on a copy of the profile provided by the AS and document each step. That way you can start over if you did something that seems irreversible.)
I hope this is of any help.

tom's right that JBoss AS7 doesn't have commercial support yet. However, it is coming - AS7 is being productised as EAP 6 (annoyingly!), and is going into beta in a few days. The community version has been out for a few months now, and although it does have a lot of rough edges, it basically works pretty well.
AS7 has a much more modular architecture than previous versions. The idea is that you only load the modules you need, which means that although it's a full-profile implementation (as of 7.1), if you only use web profile features, you only pay the runtime cost of a web profile implementation. You still have the bits you don't need sitting on disk, but disk is cheap (7.1.0 is 125 MB all in - hardly huge).
I'm afraid i haven't used any other fully-grown app servers (not in the last decade, at least), and so can't comment on them. I believe Geronimo supports full-profile EE6, so if you don't need commercial support, that might be worth a look.
I have spent some time using Tomcat-based setups. Yes, you can add enough extras to Tomcat to create a sort of 'bionic Tomcat' that is basically an app server, but doing it yourself is work you really shouldn't be doing - pure waste. I haven't used TomEE. I'm not a big fan of Tomcat generally, i have to admit.

As you state, OpenEJB/TomEE definitely fit the bill. Here are some examples you might like based on the things you mention:
TimerService and #Schedule
TimerService and ScheduleExpression
#Asynchronous Methods
To configure your JavaMail resource in your test case, just do like so:
Properties p = new Properties();
p.setProperty("superbizMail", "new://Resource?type=javax.mail.Session");
p.setProperty("superbizMail.mail.smtp.host", "mail.superbiz.org");
p.setProperty("superbizMail.mail.smtp.port", "25");
p.setProperty("superbizMail.mail.transport.protocol", "smtp");
p.setProperty("superbizMail.mail.smtp.auth", "true");
p.setProperty("superbizMail.mail.smtp.user", "someuser");
p.setProperty("superbizMail.password", "mypassword");
EJBContainer.createEJBContainer(p);
Then inject the JavaMail Session into your EJB via:
#Resource
private Session superbizMail;
Behind the scenes the 'superbizMail.' part is shaved off all the properties and the resulting set of properties is passed into javax.mail.Session.getDefaultInstance(Properties props). The resulting Session is what is injected into the #Resource reference

Integration testing a legacy Java EE application with Arquillian

I've recently begun working with a large, legacy enterprise Java application. It's primarily built on Websphere Commerce 6. It contains a mix of EJB 1.x and 2.x along with quite a bit of code that hooks directly into the Commerce API.
I've introduced the first unit tests while attempting to break dependancies and carefully refactor small portions of the code. We've been exploring the idea of using an integration testing framework to make the process of creating tests less fragile and time consuming.
Arquillian has been suggested as a very good option for integration testing. However, it looks geared towards more "modern" applications; most of the examples make use of Java EE 5+ and Maven. We're using J2EE and Ant. We're also currently tied to Java 1.4, and while it may be possible for us to move to Java 5, we won't be upgrading to EJB 3.x any time soon. We're also likely to stick with Ant.
With these constraints in mind, is it possible to use Arquillian? Or do better alternatives exist for integration testing legacy enterprise Java applications?

Arquillian has been suggested as a very good option for integration testing. However, it looks geared towards more "modern" applications; most of the examples make use of Java EE 5+ and Maven. We're using J2EE and Ant. We're also currently tied to Java 1.4, and while it may be possible for us to move to Java 5, we won't be upgrading to EJB 3.x any time soon. We're also likely to stick with Ant.
With these constraints in mind, is it possible to use Arquillian?
Note: I'm an Arquillian contributor. I've tried to be unbiased in my answer.
This would really depend on how your tests are executed. If you are attempting to use Arquillian's support for in-container tests, then you're unlikely to find a solution. WebSphere Commerce 6 uses WebSphere 6.0 as the underlying container, which is not supported by Arquillian at the moment. If you can hypothetically use a version of WebSphere Commerce that uses WAS 7.0 or 8.0 as the foundation, then most of my answer can be ignored, since these containers are supported.
You can attempt to run tests from the client using the #RunAsClient annotation, instead of the container, and this is more likely to succeed. Note that, you'll need to perform the deployment in some manner without a #Deployment annotated method, because of the afore-mentioned absence of support for WAS 6 in Arquillian.
If you intend to use Ant instead of Maven, then the only requirement is that all dependencies be present in the classpath. Unfortunately, there is no uber JAR or distribution for Arquillian, so for now, you'll need to know all the dependencies upfront.
Note - Building in WebSphere 6.0 support for Arquillian may not be a trivial activity, as compared to other more recent containers:
Firstly, there have to be means for deploying the archive. I'm not sure if the mechanism used in WebSphere 7 and 8 container support can be ported over.
Supporting in-container tests in Arquillian for WAS 6.0 may require supporting the Servlet 2.4 protocol for running tests. Currently, Arquillian supports Servlet Spec 2.5 and 3.0 for packaging it's ServletTestRunner. This is of course, necessary if the JMX protocol and the accompanying JMXTestRunner cannot be used.
Or do better alternatives exist for integration testing legacy enterprise Java applications?
I would normally advise folks to use a mix of Cargo and JUnit for functional testing legacy apps, but even Cargo does not appear to support WebSphere 6.0.
You might find JUnitEE to be a better fit for your needs if you are willing to package the JUnitEE TestRunner in your archive; note that JUnitEE's last release was in 2004, and the mailing list is a bit inactive, so YMMV.

Jetty 8 + EJB 3.1 + JTA + CDI + JPA 2 stack?

Can anyone tell me if it is currently possible to "glue together" a partial Java EE 6 Web Profile over Jetty?
I've found a lot of articles about integrating standalone EJB 3 containers, JTA providers, etc with older Jetty versions, so I wounder if I could make it all work together.
I would like to assemble a Servlet 3.0 + CDI + EJB 3.1 + JTA (if needed, all I really want is declarative transaction management) + JPA 2 environment over Jetty 8 (or Tomcat 7 if no Jetty alternatives are available).
My questions are: Can it be done? Has anyone managed to do that? Any articles about getting OpenEJB, Atomikos, Weld, EclipseLink and Jetty (or any other similar stack) working together? Any magical "do it all" pom.xml files out there?
PS: Yeah, I know I could just use GlassFish (which I like very much). I'm just wondering about how hard would it be to get something similar working with a Servlet Container, and how the two environments would compare in terms of complexity, performance, size, deploying speed, hardware resource consumption, etc.

I'd describe this as still in the early stages, but here is what we have so far:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/assembly/openejb-jetty/
Note, Apache TomEE lives at a similar path, i.e. 'assembly/openejb-tomcat'. Plan is to call the Jetty version Apache JetSet and have it be fully embeddable. Most people with commit are currently working on getting Apache TomEE to be officially Java EE 6 Web Profile certified. I'd describe that work to be in the late stages. We've a great setup in Amazon EC2 to run the web profile TCK against TomEE using a hundred EC2 t1.micro spot instances. It's pretty sweet. The TCK agreement with Apache and Oracle does not allow us to share access publicly. However, any Apache committer can sign an NDA to get access.
Ok, so I mention all that about TomEE because the plan is once we're done with the Tomcat version, to do it all over again with Jetty (JetSet). Many of us committers, myself and Jonathan Gallimore for example, actually prefer Jetty by a large margin. But as the Tomcat integration code was much further along and had more users, we decided to just finish that one first. There is an incredible amount of work that isn't Tomcat specific that we will be able to leverage in the Jetty version; getting access to the TCK legally, the heaps of code to get it to run, the more heaps of code to get it automated, and numerous integration bits which are generic and not specific to Tomcat.
All that said, there's no reason others have to wait to work on a Jetty version just because most of us are still finishing the Tomcat version. Apache projects should be viewed as individuals working together, not companies like Oracle or Redhat or VMWare. That can be both good and bad. The good part is that if you or anyone else wants to hack on the Jetty version you can do that right now. You'll have to submit patches for awhile till you earn commit, but having someone else do the actual commit command is not that bad. If you start small and stay active and open, it's usually pretty easy to earn commit. The key to getting patches in quickly is a steady stream of small to moderately sized patches. Any step forward or sideways with no steps backward is a good patch in my opinion. As long as people can see where you're going it's good enough. Certainly more Agile than the one-big-patch approach and allows for all the really fun and collaborative magic to happen along the way.
Some threads which would be good places to say hello. Step 1 is just to say hello. No need to have code in hand to talk on the dev list or be taken seriously:
http://openejb.979440.n4.nabble.com/Jetty-Integration-td1457408.html
http://openejb.979440.n4.nabble.com/Jetty-Integration-td2318962.html

Tomcat has that stack implemented in a server called TomEE(formerly TomTom).
These are the components it uses.
Connector Apache Geronimo Connector
CDI Apache OpenWebBeans
EJB Apache OpenEJB
Javamail Apache Geronimo JavaMail
JPA Apache OpenJPA
JSF Apache MyFaces
JSP Apache Tomcat
JSTL Apache Tomcat
JTA Apache Geronimo Transaction
Servlet Apache Tomcat
As far as Jetty I'm not sure. OpenEJB is your only option for EJB outside of a JavaEE6 container(AFAIK) and I'm not sure Jetty is 100% tested with this. For CDI you can always use something like Seam.
In my opinion I believe the Spring framework would be your best option for the Jetty container(that's just my opinion though). In my experience after trying to get Tomcat working with Open EJB, Spring is a lot easier to set up.
You also have to remember Open EJB doesn't implement the entire EJB 3.1 stack at this point.
Also Open EJB is not tested on Tomcat 7 either. So you have to stay with Tomcat 6 if you go that route.

OpenEjb has not released a version with JPA2 support, although their development version supports JPA2 fine AFAIK.
I'm using embedded OpenEjb in Jetty6, because I could not get my app working in newer jetties yet. I think there is work under way to get an OpenEJB tightly integrated with Jetty like TomEE, but that may be some way off..

Geronimo is a complete J2EE stack which runs on top of Jetty.
There's a document on its setup on https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-jetty.html

Java EE App Server Hello World

I am fairly comfortable with standalone Java app development, but will soon be working on a project using a Java EE application server.
Does anyone know of a straightforward how-to tutorial to getting a hello-world type application working in an application server? I'm (perhaps naievly) assuming that the overall approach is similar between different frameworks, so I'm more interested in finding out the approach rather than getting bogged down in differences between the different frameworks.
If you are not aware of a good guide, then could you post bullet-point type steps to getting a hello-world running?, i.e.
Download XX
Write some code to do YY
Change file ZZ
Other steps...
Note: Just because I have a windows machine at home, I would prefer to run if this could be run on windows, but in the interest of a better answer, linux/mac based implementations are welcome.

I would choose JBoss AS or GlassFish for a start. However I'm not sure what you mean by Java EE "Hello World". If you just want to deploy some JSP you could use this tutorial (for JBoss):
http://www.centerkey.com/jboss/
If you want to get further and do the EJB stack and/or deploy an ear-file, you could read the very good JBoss documentation:
Installation Guide
Getting started
Configuration Guide
In general you could also just do the basic installation and change or try the pre-installed example applications.
I currently have JBoss installed (on windows). I develop with Eclipse and use the Java EE server integration to hot deploy or debug my code. After you get your first code running you realy should have a look at the ide integration since it makes development/deploy roundtrips so much faster.

The JavaEE (they dropped the 2) space is pretty big. A good tutorial to start is the one from Sun. For a simple hello world application, the web container only would suffice. A well known servlet jsp container is tomcat. See here for installation instructions. Try installing it with eclipse and create a web project. This will generate some files for you that you can look at and edit. Also starting and stopping the application server is simpler.

Another option is to get Oracle JDeveloper (free to download and use - it's a full featured IDE that includes some neat extras like the SQL workbench and BPEL designer).
As a learning tool, it is quite good, not only for the tutorials available from Oracle, but it includes a range of "cue-card" lessons in the tool itself to teach many common techniques.
cue card view http://tardate.heroku.com/images/jdev-cuecards.jpg

If you haven't gone near NetBeans in a while its catching up with Eclipse very fast and worth a look, especially when starting Java EE.
Version 6.x installs Tomcat and/or Glassfish for you and then provides wizards to create/deploy/redeploy applications.
The initial tutorial on Web Applications is here and a more complex example here.

As JeroenWyseur puts it, Java EE is a fairly big space. In addition to what he said, you should try to get more details of what exactly you'll be doing: servelts & co, EJB (entity, session, message beans?) and try to get familiar with that.
It should be clear for you that your code runs in a managed environment, which imposes a lot of constraints. in order to make sure you understand what happens you should get familiar with the concept of deployment. Then, if you do EJBs, transaction management is important too. If you don't understand exactly what happens when a bean or a servlet is deployed, how transactions are managed, how beans are invoked, you're going to have a hard time.
A book that helped me a lot back in the time is Mastering EJB, by Ed Roman.
Also, getting familiar with RMI will help you understand EJBs.