marc,

The problem is at very rare occasion on remove() of entity B loaded
previously by entity A :

java.lang.IllegalArgumentException: object is not an instance of declaring
class
       at java.lang.reflect.Field.get(Native Method)
       at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getPkFieldValue(JDBCCommand.java
:660)
       at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.setPrimaryKeyParameters(JDBCComm
and.java:364)
       at
org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.setParameters(JDBCLoad
EntityCommand.java:97)
       at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute(JDBCCommand.java:159
)
       at
org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntity
Command.java:82)
       at
org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.loadEntity(JAWSPersistence
Manager.java:150)
       at
org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager
.java:349)
       at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchron
izationInterceptor.java:193)
       at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterce
ptor.java:186)
       at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)
       at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:263)
       at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
       at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:19
0)
       at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
       at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:329)
       at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI
nvoker.java:480)
       at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericPr
oxy.java:335)
       at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityProxy.java:13
3)
       at $Proxy74.remove(Unknown Source)

"not an instance" because the classloader of the Class and the Object are
different even if they should be the same.
   protected Object getPkFieldValue(Object pk, PkFieldMetaData
pkFieldMetaData)
      throws IllegalAccessException
   {
      Field field = pkFieldMetaData.getPkField();
      System.out.println(pkFieldMetaData.getClass().getClassLoader());
      System.out.println(pk.getClass().getClassLoader());
      return field.get(pk);
   }
I think this is a correct analysis no ?

Different because the Object is get from EntityEnterpriseContext with a
ClassLoader linked to another EntityContainer that this one.  I have
verified that.  It has the classloader of the entity container A that has
"wake up" the entity B.
These 2 are in different ejb jar, so don't have the same parent class
loader.  Correct ?

So I think a problem occurs in the cache pool of Authorization when entity
User load entity Authorization

Only with Optimize false else the calls are completely different (from
JRPMContainerInvoker) and RMied or marshalled whatecver you call that ...

It is a very rare case because normally if A calls B, they will probably be
in the same ejb jar and the problem vanishes.

Est ce que je raconte jusqu'ici a du sens ou pas ?  Si oui je continue...

Merci.
Vincent.




> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de marc
> fleury
> Envoy� : samedi 12 mai 2001 19:15
> � : [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] TR: [JBoss-user] Obscure issue (bug?) with CMP
> using column mapping
>
>
> c'est quoi ton probleme exactement?
>
> marc
>
>
> |-----Original Message-----
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of
> |Vincent Harcq
> |Sent: Saturday, May 12, 2001 1:16 PM
> |To: Dev JBoss
> |Subject: [JBoss-dev] TR: [JBoss-user] Obscure issue (bug?) with CMP
> |using column mapping
> |
> |
> |Hi,
> |I give up.
> |I now understand (a bit) the interceptors, the cache, the proxy, ... (btw
> |wooooooow,quel pied!) but still can not fix this problem...
> |All what I can say is that it occurs only with Optimized true,
> |with 2 entity
> |beans being in 2 different ejb jars, when the first jar remove the
> |entity of
> |the second jar.
> |Because when calling remove() directly, the loadEntity is make and
> |cause the
> |problem because the entity enterprise context has been loaded by another
> |classloader, but why ? don't know.  They are switched correctly
> |depending of
> |the container in JRMPContainerInvoker so why ?
> |if I call a remote method before the remove(), this will loadEntity
> |correctly, then remove does not need to do it (isValid TRUE in
> |EntitySynchronizationInterceptor and so no problemo.
> |Why this difference in loadEntity ?  because remobe() comes from
> EJBObject
> |and not from the remote interface of the bean ?  dont know...
> |
> |Bullshit de putain de merde, there are other more interesting
> things to do
> |that fighting a bug that you'll never have...
> |
> |Disappointed and learning Vincent.
> |
> |
> |> The spec requires that the state of the bean is loaded before
> |> ejbRemove is called. The JBoss container is not doing this, in
> |> violation of the spec.
> |>
> |> Because commit option A is the default, the state of the bean will
> |> often already be loaded when ejbRemove is called, and the effects
> |> of this bug will not be visible.
> |>
> |> If the state is not already loaded, calling a "get" method will load
> |> the state, which will make it available in ejbRemove, assuming "A".
> |> (If you want to break your workaround, switch to commit "C".)
> |>
> |> Any volunteers to fix this?
> |>
> |> -Dan
> |>
> |> On 8 May 01, at 17:39, David Esposito wrote:
> |>
> |> > Vincent,
> |> >
> |> > You are my hero .. :) ... it works now ... it's always nice when the
> |> > workarounds are painless to integrate ... ;)
> |> >
> |> > Here's the snippet of code:
> |> >
> |> > joinRecords = repHome.findByRetailerID(params.memberCompanyID);}
> |> >
> |> > //Clear the table out for this company
> |> > while(joinRecords != null && joinRecords.hasMoreElements())
> |> > {
> |> >   RepresentativeJoin joinRec =
> |> > (RepresentativeJoin)joinRecords.nextElement();
> |> >
> |> >   log("Representative_ID = " + joinRec.getRepresentative());
> |> >
> |> >   log("Deleting rec...");
> |> >   joinRec.remove();
> |> >   log("Delete succeeded...");
> |> > }
> |> >
> |> > if the first log() line is missing, the thing bombs out on
> |> remove() like I
> |> > described below ... with one call to the remote interface,
> the remove()
> |> > works smoothly ...
> |> >
> |> > Is this issue documented sufficiently for you to add it to
> the list of,
> |> > ahem, "known issues" or do you need me to explore it further?
> |> >
> |> > Thank you very much ...
> |> >
> |> > -Dave
> |> >
> |> > > -----Original Message-----
> |> > > From: [EMAIL PROTECTED]
> |> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Vincent
> |> > > Harcq
> |> > > Sent: Tuesday, May 08, 2001 4:38 PM
> |> > > To: [EMAIL PROTECTED]
> |> > > Subject: RE: [JBoss-user] Obscure issue (bug?) with CMP
> using column
> |> > > mapping
> |> > >
> |> > >
> |> > > Hi,
> |> > > if you run remote= fBPK() then remote.remove(), can you try a
> |> > > remote.getanyfield() in between and let me know if it solve
> |> the problem or
> |> > > not.  I also saw something similar to that.
> |> > > Thanks.
> |> > > Vincent.
> |> > >
> |> > > > -----Message d'origine-----
> |> > > > De : [EMAIL PROTECTED]
> |> > > > [mailto:[EMAIL PROTECTED]]De la
> part de David
> |> > > > Esposito
> |> > > > Envoy� : mardi 8 mai 2001 17:33
> |> > > > � : [EMAIL PROTECTED]
> |> > > > Objet : [JBoss-user] Obscure issue (bug?) with CMP using
> |> column mapping
> |> > > >
> |> > > >
> |> > > > Hello all,
> |> > > >
> |> > > > I have a weird situation:
> |> > > > JBOSS 2.2.1
> |> > > > Sun JDK 1.3
> |> > > > PostGreSQL 7.1 (although I have the same problem with
> Oracle 8.1.7)
> |> > > >
> |> > > > I have a CMP bean that is used to manipulate join tables
> |> ... (you know,
> |> > > > tables with only 2 columns used for a many-many
> |> relationship) ... rather
> |> > > > than create a half dozen beans, I have created only one
> and use the
> |> > > > deployment descriptor to map it to the appropriate table. All
> |> > > of my tables
> |> > > > contain 2 integer fields which, when concatenated, form the
> |> PK for the
> |> > > > table. So my deployment descriptors look like the following:
> |> > > >
> |> > > > From ejb-jar.xml:
> |> > > >
> |> > > > <entity>
> |> > > >   <ejb-name>Supplier_Representative</ejb-name>
> |> > > >
> |> <home>mypackage.ejb.representativejoin.RepresentativeJoinHome</home>
> |> > > >
> |> <remote>mypackage.ejb.representativejoin.RepresentativeJoin</remote>
> |> > > >
> |> > > >
> <ejb-class>mypackage.ejb.representativejoin.RepresentativeJoinBean
> |> > > > </ejb-clas
> |> > > > s>
> |> > > >   <persistence-type>Container</persistence-type>
> |> > > >
> |> > > >
> <prim-key-class>mypackage.ejb.representativejoin.RepresentativeJoi
> |> > > > nPK</prim-
> |> > > > key-class>
> |> > > >   <reentrant>False</reentrant>
> |> > > >
> |> > > >
> <cmp-field><field-name>representative_id</field-name></cmp-field>
> |> > > >   <cmp-field><field-name>reference_id</field-name></cmp-field>
> |> > > >
> |> > > >   <resource-ref>
> |> > > >     <description>Data source</description>
> |> > > >     <res-ref-name>jdbc/MyDB</res-ref-name>
> |> > > >     <res-type>javax.sql.DataSource</res-type>
> |> > > >     <res-auth>Container</res-auth>
> |> > > >   </resource-ref>
> |> > > > </entity>
> |> > > >
> |> > > > From jaws.xml:
> |> > > >
> |> > > > <entity>
> |> > > >   <ejb-name>Supplier_Representative</ejb-name>
> |> > > >   <cmp-field>
> |> > > >     <field-name>representative_id</field-name>
> |> > > >     <column-name>representative_id</column-name>
> |> > > >   </cmp-field>
> |> > > >   <cmp-field>
> |> > > >     <field-name>reference_id</field-name>
> |> > > >     <column-name>supplier_id</column-name>
> |> > > >   </cmp-field>
> |> > > >   <finder>
> |> > > >     <name>findBySupplierID</name>
> |> > > >     <query>supplier_id = {0}</query>
> |> > > >     <order></order>
> |> > > >   </finder>
> |> > > > </entity>
> |> > > >
> |> > > > So you see that i use the <cmp-field> to map between the
> |> bean instance
> |> > > > variables and the DB columns (in this case, the reference_id
> |> > > variable maps
> |> > > > to the supplier_id field in the DB) ... my bean PK class
> |looks like:
> |> > > >
> |> > > > public class RepresentativeJoinPK implements Serializable
> |> > > > {
> |> > > >     public int representative_id;
> |> > > >     public int reference_id;
> |> > > >
> |> > > >     public RepresentativeJoinPK() {
> |> > > >         this(0,0);
> |> > > >     }
> |> > > >
> |> > > >     public RepresentativeJoinPK(int representative_id, int
> |> > > reference_id) {
> |> > > >         this.representative_id = representative_id;
> |> > > >         this.reference_id = reference_id;
> |> > > >     }
> |> > > >
> |> > > >      public int hashCode(){
> |> > > >              return 0;
> |> > > >      }
> |> > > >
> |> > > >      public boolean equals(Object o) {
> |> > > >         if(o != null && o.getClass().equals(getClass()))
> |> > > >             return
> ((((RepresentativeJoinPK)o).representative_id ==
> |> > > > this.representative_id) &&
> |> (((RepresentativeJoinPK)o).reference_id ==
> |> > > > this.reference_id));
> |> > > >         else
> |> > > >             return false;
> |> > > >     }
> |> > > >
> |> > > >      public String toString() {
> |> > > >         return Integer.toString(this.representative_id) + "," +
> |> > > > Integer.toString(this.reference_id);
> |> > > >     }
> |> > > > }
> |> > > >
> |> > > > Alright, so here's the problem ... If I create a few
> |> instances (a few
> |> > > > records), and use them actively, all is well ... For example, if
> |> > > > I create 4
> |> > > > records during one client interation ... then a second or two
> |> > > > later, try to
> |> > > > read the beans ... then a few seconds later, try to remove() the
> |> > > > beans, all
> |> > > > is well ...
> |> > > >
> |> > > > However, if I either:
> |> > > >
> |> > > > a) let the beans passivate (by letting enough time pass)
> |> > > > b) restart JBOSS
> |> > > >
> |> > > > I am still able to READ the beans from the DB (display the
> |> > > contents of the
> |> > > > field, read the PK using getPrimaryKey() on the remote interface)
> |> > > > but when i
> |> > > > try to do a remove() (i've tried using the home interface's
> |> > > remove(Handle
> |> > > > h), remove(PrimaryKey pk) and the remote interface's remove()
> |> > > methods()) i
> |> > > > get the following exception:
> |> > > >
> |> > > >  TRANSACTION ROLLBACK EXCEPTION:Load failed; nested exception is:
> |> > > >         java.lang.IllegalArgumentException: object is not
> |> an instance of
> |> > > > declaring class; nested exception is:
> |> > > >         java.rmi.ServerException: Load failed; nested
> exception is:
> |> > > >         java.lang.IllegalArgumentException: object is not
> |> an instance of
> |> > > > declaring class
> |> > > >  java.rmi.ServerException: Load failed; nested exception is:
> |> > > >        java.lang.IllegalArgumentException: object is not an
> |> instance of
> |> > > > declaring class
> |> > > >  java.lang.IllegalArgumentException: object is not an instance of
> |> > > > declaring
> |> > > > class
> |> > > >        at java.lang.reflect.Field.get(Native Method)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getPkFieldValue(JDBCCo
> |> > > > mmand.java
> |> > > > :658)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.setPrimaryKeyParameter
> |> > > > s(JDBCComm
> |> > > > and.java:364)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.setParameter
> |> > > > s(JDBCLoad
> |> > > > EntityCommand.java:97)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute(JDBCComman
> |> > > > d.java:159
> |> > > > )
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.execute(JDBC
> |> > > > LoadEntity
> |> > > > Command.java:82)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.loadEntity(JAWSP
> |> > > > ersistence
> |> > > > Manager.java:150)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersiste
> |> > > > nceManager
> |> > > > .java:341)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(Enti
> |> > > > tySynchron
> |> > > > izationInterceptor.java:192)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInsta
> |> > > > nceInterce
> |> > > > ptor.java:186)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT
> |> > > > .java:133)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter
> |> > > > ceptorCMT.
> |> > > > java:263)
> |> > > >        at
> |> > > >
> |> org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercept
> |> > > > or.java:19
> |> > > > 0)
> |> > > >        at
> |> > > >
> |org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
> |> > > >        at
> |> org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:323)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMP
> |> > > > ContainerI
> |> > > > nvoker.java:482)
> |> > > >        at
> |> > > >
> org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityPro
> |> > > > xy.java:14
> |> > > > 6)
> |> > > >        at $Proxy23.remove(Unknown Source)
> |> > > >        at
> |> > > >
> mypackage.servlets.RepAuthorizationServlet.serviceRequest(RepAutho
> |> > > > rizationSe
> |> > > > rvlet.java:141)
> |> > > >
> |> > > > I saw somethign about this issue (regarding passivating
> |> beans) on some
> |> > > > threads back on the mailing list back in November 2000, but it
> |> > > sounded as
> |> > > > though this problem had been fixed ... The really weird part is
> |> > > > that as long
> |> > > > as the operations are read-only, I don't have a problem ... it's
> |> > > > only when i
> |> > > > try to remove() the bean that I get this exception ... my
> |> > > finders all work
> |> > > > fine ...
> |> > > >
> |> > > > So, to summarize:
> |> > > >      Things work perfectly all the time EXCEPT when trying to
> |> > > > use the remove()
> |> > > > method on passivated beans (or beans freshly loaded from
> |the DB) ...
> |> > > >
> |> > > > So, if you've managed to read to the end of this message, I
> |> > > > applaud you ...
> |> > > > I think it's nearly impossible that I left anything out
> |> with the above
> |> > > > ramblings ...  :)
> |> > > >
> |> > > > Thanks in advance...
> |> > > >
> |> > > > -Dave
> |
> |
> |_________________________________________________________
> |Do You Yahoo!?
> |Get your free @yahoo.com address at http://mail.yahoo.com
> |
> |
> |_______________________________________________
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to