RE: [JBoss-user] Re:[JBoss-user]ClassCircularityError-QueuedPessimisticEJBLock$TxLock
That makes sense. Thanks. In any case, we've found a way to workaround this issue which works for our purposes. Basically, we've moved everything from jboss/server/default/lib to jboss/lib and moved all the jars from all the sars to jboss/lib. I realize that this basically defeats hot-deploy of any of the sars, but it works for us since we're running a (very) stripped-down deployment of JBoss. (This is our first release in which we are moving from straight Tomcat to JBoss+Tomcat and are in the process of gradually migrating to J2EE technologies). Currently each jar in jboss/lib much be explicitly called out via the property jboss.boot.library.list. If I were to make the changes to ServerLoader such that it defaults to the whole directory, is this a patch which you would consider absorbing? If not, no big deal, we have a launcher app which we can use to bootstrap the whole thing. Thanks, Rob -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user- [EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Thursday, September 25, 2003 9:14 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Re:[JBoss-user]ClassCircularityError- QueuedPessimisticEJBLock$TxLock Version 2 still suffers from deadlock problems because is does not reliquish the class loader lock. The only hack to workaround the vm issue would be to retry loading after seeing a CCE. Robert Cauble wrote: Thanks - I really appreciate the help. Also, is this problem something which you have worked around for 3.2.2? (I'm still seeing it in 3.2.1.). Or is this something which can't be solved until Sun fixes their stuff? I noticed that there is a UnifiedClassLoader2 which looks like it solved the original deadlock problem by locking the UnifiedLoaderRepository from the loadClass method. It also looks like it didn't have the ClassCircularityError issue that UnifiedClassLoader3 has (since it never relinquishes the ClassLoader lock via a call to wait). What was wrong with this approach such that you switched to UnifiedClassLoader3? Thanks, Rob --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Re:[JBoss-user]ClassCircularityError-QueuedPessimisticEJBLock$TxLock
Thanks - I really appreciate the help. Also, is this problem something which you have worked around for 3.2.2? (I'm still seeing it in 3.2.1.). Or is this something which can't be solved until Sun fixes their stuff? I noticed that there is a UnifiedClassLoader2 which looks like it solved the original deadlock problem by locking the UnifiedLoaderRepository from the loadClass method. It also looks like it didn't have the ClassCircularityError issue that UnifiedClassLoader3 has (since it never relinquishes the ClassLoader lock via a call to wait). What was wrong with this approach such that you switched to UnifiedClassLoader3? Thanks, Rob -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user- [EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Wednesday, September 24, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Re:[JBoss-user]ClassCircularityError- QueuedPessimisticEJBLock$TxLock On Wed, 2003-09-24 at 19:54, Robert Cauble wrote: Multiple classloaders is more restrictive when it comes to the security model. Classes in the same package cannot access package private methods if the classes are in different classloaders. Got it. Thanks. You can also get errors when instances of the same class name but different class objects are passed between classloaders. Can you give me an example? Is this something which the JVM can't handle? Or do mean that it's easy for the programmer to make a mistake if they were to do something like instantiate an object of a class Foo loaded from class loader A and then cast it to a class Foo loaded from class loader B? Correct ClassCastException or the more subtle LinkageError, IncompatibleClassChangeError Regards, Adrian Thanks, Rob --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] RE: [JBoss-user] Re:[JBoss-user]ClassCircularityError-QueuedPessimisticEJBLock$TxLock
Scott is the best person to answer those questions. But if you can reproduce it why don't you try it with 3.2.2RC4? Also enable TRACE for org.jboss.mx.loading and post the log snippet where it goes wrong. I do know UCL2 didn't work under certain threading situations. The idea behind UCL3 is to pass class loading tasks to the thread that owns the classloader to avoid the issue. Sun agree the way they check ClassCircularity is wrong, but haven't fixed it :-( Regards, Adrian On Thu, 2003-09-25 at 14:44, Robert Cauble wrote: Thanks - I really appreciate the help. Also, is this problem something which you have worked around for 3.2.2? (I'm still seeing it in 3.2.1.). Or is this something which can't be solved until Sun fixes their stuff? I noticed that there is a UnifiedClassLoader2 which looks like it solved the original deadlock problem by locking the UnifiedLoaderRepository from the loadClass method. It also looks like it didn't have the ClassCircularityError issue that UnifiedClassLoader3 has (since it never relinquishes the ClassLoader lock via a call to wait). What was wrong with this approach such that you switched to UnifiedClassLoader3? Thanks, Rob -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user- [EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Wednesday, September 24, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Re:[JBoss-user]ClassCircularityError- QueuedPessimisticEJBLock$TxLock On Wed, 2003-09-24 at 19:54, Robert Cauble wrote: Multiple classloaders is more restrictive when it comes to the security model. Classes in the same package cannot access package private methods if the classes are in different classloaders. Got it. Thanks. You can also get errors when instances of the same class name but different class objects are passed between classloaders. Can you give me an example? Is this something which the JVM can't handle? Or do mean that it's easy for the programmer to make a mistake if they were to do something like instantiate an object of a class Foo loaded from class loader A and then cast it to a class Foo loaded from class loader B? Correct ClassCastException or the more subtle LinkageError, IncompatibleClassChangeError Regards, Adrian Thanks, Rob --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Re:[JBoss-user]ClassCircularityError-QueuedPessimisticEJBLock$TxLock
Version 2 still suffers from deadlock problems because is does not reliquish the class loader lock. The only hack to workaround the vm issue would be to retry loading after seeing a CCE. Robert Cauble wrote: Thanks - I really appreciate the help. Also, is this problem something which you have worked around for 3.2.2? (I'm still seeing it in 3.2.1.). Or is this something which can't be solved until Sun fixes their stuff? I noticed that there is a UnifiedClassLoader2 which looks like it solved the original deadlock problem by locking the UnifiedLoaderRepository from the loadClass method. It also looks like it didn't have the ClassCircularityError issue that UnifiedClassLoader3 has (since it never relinquishes the ClassLoader lock via a call to wait). What was wrong with this approach such that you switched to UnifiedClassLoader3? Thanks, Rob --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] ClassCircularityError-QueuedPessimisticEJBLock$TxLock
Can someone please point me towards some documentation which describes the advantage of the UnifiedClassLoader model over the tree-based class loading model? We purchased the JBoss documentation and all it says in the administrators guide is that JBoss 3.x employs a new class loading architechture that facilitates sharing of classes across deployment units. It also mentions that prior to this architecture, MBeans were not hot-deployable. Is this basically saying that it allows you to hot-deploy a component without having to re-deploy those components which depend on it and its classes? Any help here would be appreciated. Thanks, Rob
RE: [JBoss-user] Re: [JBoss-user] ClassCircularityError-QueuedPessimisticEJBLock$TxLock
Thanks for your quick response. That helps a lot.
I have a couple more questions though...
In the parent-delegation model, as long as the class of the shared
object is present in a parent class loader of the two classes which are
sharing the object, there should be no need to marshall the object,
right? Is it just that it's too unwieldy to factor out the shared
classes and place them in a parent class loader?
Also, what is the difference in functionality between a)having several
UnifiedClassLoaders which are part of the same UnifiedLoaderRepository
and b)having a single instance of a classloader which is a subclass of
URLClassLoader which allows url's to be added dynamically, hence
supporting hot-deploy? In my previous email I was thinking that the
advantage was you could redeploy a class without having to redeploy the
classes which depend on it, but as you said any classes hard-referencing
it would need to be redeployed anyway.
Thanks,
Rob
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-user-
[EMAIL PROTECTED] On Behalf Of Adrian Brock
Sent: Wednesday, September 24, 2003 9:35 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-user] Re: [JBoss-user] ClassCircularityError-
QueuedPessimisticEJBLock$TxLock
On Wed, 2003-09-24 at 14:49, Robert Cauble wrote:
Can someone please point me towards some documentation which
describes
the advantage of the UnifiedClassLoader model over the tree-based
class loading model? We purchased the JBoss documentation and all it
says in the administrators guide is that JBoss 3.x employs a new
class loading architechture that facilitates sharing of classes
across
deployment units. It also mentions that prior to this architecture,
MBeans were not hot-deployable.
The main benefit of the UnifiedClassLoader is it removes the
need to do any marshalling when crossing application boundaries.
A little care in packaging means there is no marshalling between
the front plane (WEB/Remote Interface/etc.) and the back plane
(JCA, db, jms, etc)
Hotdeployment of mbeans is possible because it uses the same
classloader scheme, not because it uses the UnifiedClassLoader per se.
As a side note:
Eclipse uses a similar scheme and have made no attempt to workaround
this Sun JVM bug (unlike us), but then they don't support redeployment
and you must explicity share classes.
The JMX spec also uses a similar scheme. As of JMX1.2 they have
hacked the spec to avoid the bug rather than fix the JVM.
Try the following test to see the overhead of marshalling,
every parameter and return value must be marshalled (a String is
very simple object to marshall):
import java.rmi.MarshalledObject;
public class Marshalling
{
static final int iterations = 10;
public static void main(String[] args)
throws Exception
{
System.out.println(Non-marshalled);
Payload payload = new NonMarshalledPayload();
test(payload);
System.out.println(Marshalled);
payload = new MarshalledPayload();
test(payload);
}
public static void test(Payload payload)
throws Exception
{
String value = new String(Value);
long begin = System.currentTimeMillis();
for (int i = 0; i iterations; ++i)
{
payload.setValue(value);
payload.getValue();
}
System.out.println(Time per iteration (nano secs): +
((100
* (System.currentTimeMillis() - begin)) / iterations));
}
public interface Payload
{
Object getValue() throws Exception;
void setValue(Object value) throws Exception;
}
public static class NonMarshalledPayload
implements Payload
{
Object value;
public Object getValue()
{
return value;
}
public void setValue(Object value)
{
this.value = value;
}
}
public static class MarshalledPayload
implements Payload
{
MarshalledObject value;
public Object getValue()
throws Exception
{
return value.get();
}
public void setValue(Object value)
throws Exception
{
this.value = new MarshalledObject(value);
}
}
}
Is this basically saying that it allows you to hot-deploy a
component
without having to re-deploy those components which depend on it and
its classes?
It depends how tightly linked they are. The UnifiedClassLoader
actually makes component redeployment harder. Every component
hard-referencing the shared class must also be redeployed.
Regards,
Adrian
Any help here would be appreciated.
Thanks,
Rob
--
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
---
This sf.net email is sponsored
RE: [JBoss-user] Re: [JBoss-user] ClassCircularityError-QueuedPessimisticEJBLock$TxLock
On Wed, 2003-09-24 at 16:21, Robert Cauble wrote:
Thanks for your quick response. That helps a lot.
I have a couple more questions though...
In the parent-delegation model, as long as the class of the shared
object is present in a parent class loader of the two classes which are
sharing the object, there should be no need to marshall the object,
right? Is it just that it's too unwieldy to factor out the shared
classes and place them in a parent class loader?
Hot deployment works by throwing about the classloader and creating
a new one.
In the parent/child model, throwing away the parent makes
all the children invalid.
Also siblings cannot see each other (this requires marshalling).
Also, what is the difference in functionality between a)having several
UnifiedClassLoaders which are part of the same UnifiedLoaderRepository
and b)having a single instance of a classloader which is a subclass of
URLClassLoader which allows url's to be added dynamically, hence
supporting hot-deploy? In my previous email I was thinking that the
advantage was you could redeploy a class without having to redeploy the
classes which depend on it, but as you said any classes hard-referencing
it would need to be redeployed anyway.
Multiple classloaders is more restrictive when it comes to
the security model. Classes in the same package cannot access
package private methods if the classes are in different classloaders.
You can also get errors when instances of the same class name
but different class objects are passed between classloaders.
Regards,
Adrian
Thanks,
Rob
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-user-
[EMAIL PROTECTED] On Behalf Of Adrian Brock
Sent: Wednesday, September 24, 2003 9:35 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-user] Re: [JBoss-user] ClassCircularityError-
QueuedPessimisticEJBLock$TxLock
On Wed, 2003-09-24 at 14:49, Robert Cauble wrote:
Can someone please point me towards some documentation which
describes
the advantage of the UnifiedClassLoader model over the tree-based
class loading model? We purchased the JBoss documentation and all it
says in the administrators guide is that JBoss 3.x employs a new
class loading architechture that facilitates sharing of classes
across
deployment units. It also mentions that prior to this architecture,
MBeans were not hot-deployable.
The main benefit of the UnifiedClassLoader is it removes the
need to do any marshalling when crossing application boundaries.
A little care in packaging means there is no marshalling between
the front plane (WEB/Remote Interface/etc.) and the back plane
(JCA, db, jms, etc)
Hotdeployment of mbeans is possible because it uses the same
classloader scheme, not because it uses the UnifiedClassLoader per se.
As a side note:
Eclipse uses a similar scheme and have made no attempt to workaround
this Sun JVM bug (unlike us), but then they don't support redeployment
and you must explicity share classes.
The JMX spec also uses a similar scheme. As of JMX1.2 they have
hacked the spec to avoid the bug rather than fix the JVM.
Try the following test to see the overhead of marshalling,
every parameter and return value must be marshalled (a String is
very simple object to marshall):
import java.rmi.MarshalledObject;
public class Marshalling
{
static final int iterations = 10;
public static void main(String[] args)
throws Exception
{
System.out.println(Non-marshalled);
Payload payload = new NonMarshalledPayload();
test(payload);
System.out.println(Marshalled);
payload = new MarshalledPayload();
test(payload);
}
public static void test(Payload payload)
throws Exception
{
String value = new String(Value);
long begin = System.currentTimeMillis();
for (int i = 0; i iterations; ++i)
{
payload.setValue(value);
payload.getValue();
}
System.out.println(Time per iteration (nano secs): +
((100
* (System.currentTimeMillis() - begin)) / iterations));
}
public interface Payload
{
Object getValue() throws Exception;
void setValue(Object value) throws Exception;
}
public static class NonMarshalledPayload
implements Payload
{
Object value;
public Object getValue()
{
return value;
}
public void setValue(Object value)
{
this.value = value;
}
}
public static class MarshalledPayload
implements Payload
{
MarshalledObject value;
public Object getValue()
throws Exception
{
return value.get();
}
public void setValue(Object value)
throws Exception
RE: [JBoss-user] Re: [JBoss-user]ClassCircularityError-QueuedPessimisticEJBLock$TxLock
On Wed, 2003-09-24 at 19:54, Robert Cauble wrote: Multiple classloaders is more restrictive when it comes to the security model. Classes in the same package cannot access package private methods if the classes are in different classloaders. Got it. Thanks. You can also get errors when instances of the same class name but different class objects are passed between classloaders. Can you give me an example? Is this something which the JVM can't handle? Or do mean that it's easy for the programmer to make a mistake if they were to do something like instantiate an object of a class Foo loaded from class loader A and then cast it to a class Foo loaded from class loader B? Correct ClassCastException or the more subtle LinkageError, IncompatibleClassChangeError Regards, Adrian Thanks, Rob --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] ClassCircularityError-QueuedPessimisticEJBLock$TxLock
See bug#4699981, ClassCircularityError thrown without reason during class loading http://developer.java.sun.com/developer/bugParade/bugs/4699981.html -- Scott Stark Chief Technology Officer JBoss Group, LLC Toshiya Kobayashi wrote: Hi all, I did a stress test on my application. then I got the following stacktrace. org.jboss.tm.JBossTransactionRolledbackException: Unexpected Error java.lang.ClassCircularityError: org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock$TxLock at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.getTxLock(QueuedPessimis ticEJBLock.java:129) at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.waitForTx(QueuedPessimis ticEJBLock.java:291) at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.doSchedule(QueuedPessimi sticEJBLock.java:209) at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.schedule(QueuedPessimist icEJBLock.java:157) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.jav a:85) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterce ptor.java:53) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor .java:84) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:243) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:11 7) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinde rInterceptor.java:122) at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:483) at org.jboss.ejb.Container.invoke(Container.java:674) at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFacto ry.java:353) at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38) at $Proxy60.getStatus(Unknown Source) at jp.co.sunmoretec.pronto.bbs.ejb.BunshoListControl.getSortBunshoList(BunshoLi stControl.java:207) at jp.co.sunmoretec.pronto.bbs.ejb.BunshoListControl.getKeijibanList(BunshoList Control.java:100) at jp.co.sunmoretec.pronto.bbs.ejb.BbsControlBean.keijibanList(BbsControlBean.j ava:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Stateles sSessionContainer.java:629) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(Cach edConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSe ssionInstanceInterceptor.java:72) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor .java:84) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:243) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:11 7) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinde rInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionConta iner.java:322) at org.jboss.ejb.Container.invoke(Container.java:674) at sun.reflect.GeneratedMethodAccessor68.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:83) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46 ) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInter ceptor.java:100) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85) at $Proxy45.keijibanList(Unknown Source) at jp.co.sunmoretec.pronto.bbs.servlet.CallBbsControl.callKeijibanList(CallBbsC ontrol.java:144) - conditions of my application/environment JBoss 3.2.1(with Tomcat 4.1.24) Test Clients send requests to a Servlet. And the Servlet calls a SessionFacade(transaction-Required). the EntityBean of interest [BunshoEntity] uses CMR, but the type of the field [status] is String.
