I've seen some posts here about supporting WebLogic deployment
descriptors, so I thought I should share some of our experiences of
porting a year old Weblogic 5.1 application to JBoss/Jetty. We started
off using JBoss 2.0Final and have recently moved to various snapshots of
JBoss 2.1 as bugs are fixed. We're using Jetty 3.0.3 as well. One
thing to note is that this was our first project using EJB, so we were a
little cloudy on the EJB spec and the correct way to write beans.
JBoss:
- We found that we needed to declare <ejb-ref>s for referenced beans in
our jboss.xml and ejb-jar.xml files for JBoss to work with our Jars. We
did not need to do this with Weblogic. Maybe this isn't a problem in
JBoss 2.1?
- For EntityBeans, we did not know that the EJB spec states that each
persistent data member of your bean class needs to be initialized in the
ejbCreate methods. We were depending on the initial values being set in
the declaration of the member variable . (i.e. class fooBean { int
m_SomeVariable = 25; }). This is not a problem with Weblogic 5.1
- This problem almost caused us to ditch JBoss and buy Weblogic,
although it was an RTFM error. We're using JAWS and CMP and the default
for <tuned-updates> is false. When tuned-updates is false, every field
in the bean is updated in the database including the primary keys! When
you update a primary key you must obtain a write-lock on the index for
the table. This was causing deadlock in our application because we were
having one thread that was inserting into a table causing a lock on the
index and another thread that was trying to update a primary key that
was trying to get a lock on the index. The moral of the story is ALWAYS
HAVE <tuned-updates> set to TRUE! IMHO, tuned-updates should be removed
as a configuration parameter, or at least, primary keys should not be
updated if they have not changed if tuned-updates is set to false.
Otherwise, you're going to have dumbasses like me thinking JBoss is a
piece of shit, when it is plain user error.
- Another deadlock problem we had was that the default <trans-attribute>
for Weblogic is "Supports" for stateless beans, and for JBoss it is
"Required". Since some of our Stateless Beans where using entity beans
and we were assuming "Supports", we were getting deadlock everywhere.
It is not clearly stated in the JBoss documentation that the default
trans-attribute is Supports.
Jetty:
- With the Weblogic 5.1 JSP engine you can do <jsp:include>s and then do
a <jsp:forward> or a redirect. With Jetty and probably Tomcat, since
they both use the apache Jasper engine, <jsp:include> causes a flush of
the output buffer and commits the request. Thus you can't do a
<jsp:forward> or a redirect.
- For the <jsp:setProperty> tag, the property attribute name's first
character must be lowercase for Jetty. Weblogic takes either lower or
uppercase.
i.e.
<jsp:setProperty name="TheObject" property="FooBar" param="foobar"/> ERROR!
<jsp:setProperty name="TheObject" property="fooBar" param="foobar"/>
CORRECT
- errorPage will not work if you have already have had a <jsp:include>
since the buffer get's flushed.
- To get the Jetty/Jboss integrated VM to work you must load your
application's non-ejb-jars and classes through the ClassPathExtensions
in jboss.conf. Don't have your application's jars/classes in the System
classpath
- You must have xml.jar in your CLASSPATH.
BTW, this story has a happy ending. We have successfully ported or
application from Weblogic 5.1 to JBoss/Jetty and are happy so far with
the move.
(Jamie, do you have anything to add?)
Best regards,
Bill
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
