The migration wasn't so smooth - the customer used some proprietary code we had to change. And let me tell you - configuring TopLink to run on WAS is a real pain, especially when some TopLink code is accessed through EJBs and some through regular Java classes from the web tier.
But the real problem was WAS7 deployment. It took forever... We tried running it from RAD7.5 or from the admin console directly - it was painful. It took around 5 minutes, and every configuration action that required application restart took ages to complete.
Turns out the problem lies in the JavaEE5 spec. When you deploy an EAR it needs to look for annotated classes that are marked as EJB and servlets. So deploying a WAR file with a large number of classes and JAR files will be very slow.
There are deployment separation solutions (putting the classes in the app-inf/lib of the EAR instead of web-inf/lib of the WAR) but a quick fix, that fits when you don't use annotated servlets is to add the metadata-complete attribute to your web.xml file (in the web-app tag). It tells the deployer that all of your servlets and filters are configured inside the web.xml file.
See this link for the complete web_app_2_5 XSD description. http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd
Trying to port a large app (which uses Toplink Essentials) from Glassfish to Websphere 7 right now. please could you give us some clues on how you solved the particular "configuring TopLink to run on WAS is a real pain" issues?
ReplyDeleteRight now we have a problem with weaving.