This post is not about a tiny application. Whilst still interested in building small, simple and single purpose application and modules one must also make a living.
Right now, one of my assignments is to evaluate the possibility of migrating a large near-legacy J2EE application from Weblogic 8.1 to JBoss 6.
The business case behind this is simple. The weblogic license is more expensive, we are not using any power-features of weblogic and the licensing is unsuitable for the new virtual environments. And yes, we must upgrade in any case. Here are my notes of what has to be done to make it run in JBoss. Since I know beforehand that security might be an issue, and we are not using security, if you have it, you may stop reading.
Many of the issues I had is because the weblogic seems less strict, and only small corrections was required.
JSP tags and TLDs
For some reason, once upon a time, there was an urge to copy TLDs (like the struts ones) and place them in the war/WEB-INF folder. They would then be referenced from the web.xml and incorrectly by path from the JSPs. I have seen this many times and it's probably not a special case. This has to be cleaned up. Removed the TLDs that are in some jar-file somewhere. Removed the references in web.xml and fix the declarations in your JSPs. The uri parameter must match the uri declared in the tld-file.
A small note on custom tags. If you have tag parameters in your jsps which are not in the TLD, JBoss (catalina) will throw an exception. Weblogic will silently ignore it.
EJBs and naming
Weblogic and JBoss does create JNDI names for EJBs differently. They are placed in different namespaces and you need to change which ContextFactory is used. Most importantly you should declare names for you EJBs in the jboss.xml file, otherwise it can be hard to figure out and pick up in your code.
ear Packaging
JBoss gets really cranky if you happing to package classes multiple times in your ear-archive. This easily happens when you have ejb-jars in the ear and also includes the ejb-client jars for dependent ejbs and wars. In maven, this is an easy fix by using the "provided" scope for client dependencies and possibly also using the skinnyWars option for maven-ear-plugin. With ant, you'll have figure it out manually of course and with an older version of maven-ear-plugin you have to put in packagingExcludes in you war-plugins.
Persistence
This part is maybe the most complicated one. This is due to two main reasons. Weblogics implementation of EJBQL is more powerful and you'll have to build up the jboss.xml and jbosscmp-jdbc.xml files, corresponding to weblogic.xml and weblogic-cmp-jdbc.xml, respectlively.
EJBQL
The weblogic implementation of EJBQL supports aggregate functions like MAX and SUM. This is not supported in EJB 2.0 but in 2.1. Thus it should not be a problem in JBoss 6. However, JBoss does not support aggregated functions in nested query and a query like this
Some on these can be rewritten. They can be split into two and programmatically merged or they can be reimplemented with JPA. I haven't determined the best solution yet.
A small note on EJBQL is, like with JSPs, Weblogic is much more tolerant to small grammatical errors. You might need to put in the whitespaces and missing closing parenthesis here and there.
Persistence mappings
For the jboss files mentioned above you can find xslt templates online to convert them. They might not help you with everything thou. I haven't seen one that handles the relational mappings between entities yet and you will need to read up on this in the JBoss documentation.
ID Sequences (auto-increment kind of)
This is quite simple once you've figured it out, however it took me a while. Just add this to each entity in jbosscmp-jdbc.xml
Datasources
We are blessed with Oracle databases. You have to add the jdbc client jar to the default/server/lib directory and then you can setup the data source in the admin console. It seems buggy however and you might need to edit the xml-file on disk which is created. Pay attention that even if you set the JNDI name to MyDataSource the JNDI name becomes java:MyDataSource.
Right now, one of my assignments is to evaluate the possibility of migrating a large near-legacy J2EE application from Weblogic 8.1 to JBoss 6.
The business case behind this is simple. The weblogic license is more expensive, we are not using any power-features of weblogic and the licensing is unsuitable for the new virtual environments. And yes, we must upgrade in any case. Here are my notes of what has to be done to make it run in JBoss. Since I know beforehand that security might be an issue, and we are not using security, if you have it, you may stop reading.
Many of the issues I had is because the weblogic seems less strict, and only small corrections was required.
JSP tags and TLDs
For some reason, once upon a time, there was an urge to copy TLDs (like the struts ones) and place them in the war/WEB-INF folder. They would then be referenced from the web.xml and incorrectly by path from the JSPs. I have seen this many times and it's probably not a special case. This has to be cleaned up. Removed the TLDs that are in some jar-file somewhere. Removed the references in web.xml and fix the declarations in your JSPs. The uri parameter must match the uri declared in the tld-file.
A small note on custom tags. If you have tag parameters in your jsps which are not in the TLD, JBoss (catalina) will throw an exception. Weblogic will silently ignore it.
EJBs and naming
Weblogic and JBoss does create JNDI names for EJBs differently. They are placed in different namespaces and you need to change which ContextFactory is used. Most importantly you should declare names for you EJBs in the jboss.xml file, otherwise it can be hard to figure out and pick up in your code.
ear Packaging
JBoss gets really cranky if you happing to package classes multiple times in your ear-archive. This easily happens when you have ejb-jars in the ear and also includes the ejb-client jars for dependent ejbs and wars. In maven, this is an easy fix by using the "provided" scope for client dependencies and possibly also using the skinnyWars option for maven-ear-plugin. With ant, you'll have figure it out manually of course and with an older version of maven-ear-plugin you have to put in packagingExcludes in you war-plugins.
Persistence
This part is maybe the most complicated one. This is due to two main reasons. Weblogics implementation of EJBQL is more powerful and you'll have to build up the jboss.xml and jbosscmp-jdbc.xml files, corresponding to weblogic.xml and weblogic-cmp-jdbc.xml, respectlively.
EJBQL
The weblogic implementation of EJBQL supports aggregate functions like MAX and SUM. This is not supported in EJB 2.0 but in 2.1. Thus it should not be a problem in JBoss 6. However, JBoss does not support aggregated functions in nested query and a query like this
SELECT OBJECT(logg1) FROM LOGG logg1 WHERE logg1.systemId = ?1 AND
logg1.created = (SELECT MAX(logg2.created)
FROM LOGG logg2
WHERE logg2.systemId = logg1.systemId)
Some on these can be rewritten. They can be split into two and programmatically merged or they can be reimplemented with JPA. I haven't determined the best solution yet.
A small note on EJBQL is, like with JSPs, Weblogic is much more tolerant to small grammatical errors. You might need to put in the whitespaces and missing closing parenthesis here and there.
Persistence mappings
For the jboss files mentioned above you can find xslt templates online to convert them. They might not help you with everything thou. I haven't seen one that handles the relational mappings between entities yet and you will need to read up on this in the JBoss documentation.
ID Sequences (auto-increment kind of)
This is quite simple once you've figured it out, however it took me a while. Just add this to each entity in jbosscmp-jdbc.xml
<entity-command name="oracle-sequence">
<attribute name="sequence">THE_TABLE_IN_QUESTION_SEQ</attribute>
</entity-command>
Datasources
We are blessed with Oracle databases. You have to add the jdbc client jar to the default/server/lib directory and then you can setup the data source in the admin console. It seems buggy however and you might need to edit the xml-file on disk which is created. Pay attention that even if you set the JNDI name to MyDataSource the JNDI name becomes java:MyDataSource.
