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: [EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
