Re: [JBoss-user] The Weblogic to JBoss/Jetty experience.

[Rickard <ri...@xp...>]

Bill Burke wrote:
> 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?

The jboss.xml one is only necessary if you have several JAR's. Otherwise
it works with just ejb-jar.xml. Using several JAR's in an EAR should
work too (IIRC).

> - 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

Because they don't use pooling. Simply set the pool size to 0 in
standard-jboss.xml for the same behaviour. If you need pooling, then the
WL 5.1 behaviour is gonna kill your performance.

> - 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.

PK values should not be updated, true.

> - 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.

True, that should be documented better.

> 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.

The Jasper engine is flawed in many ways, true. This is one of them. (It
sucks performance-wise too).

> - 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

True, this is a common problem. I remember that we had a discussion
about whether to include CLASSPATH or not. I personally preferred not to
use it because it's error-prone, but it was decided to keep it (can't
remember why right now).

> 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.

Well, it's nice to have it end good, but it's sad that you had such a
bumpy road. Hopefully some of the sillier items on the list will improve
as we go along.

regards,
  Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: ri...@xp...