Harkness, David wrote:
bob combs wrote:
WORKING!
WOOT!
Had to add a null constructor into UUID to get the create()
to work due
to CMP wanting to do a class.newInstance(), then populate data on the
primary key.
Yes, and I believe that's also the reason that the PK's fields (in th
bob combs wrote:
> WORKING!
WOOT!
> Had to add a null constructor into UUID to get the create()
> to work due
> to CMP wanting to do a class.newInstance(), then populate data on the
> primary key.
Yes, and I believe that's also the reason that the PK's fields (in the
class) need to be public --
bob combs wrote:
> putting the @ejb.pk-field entry back on the getId() method generates a
> correct getPrimaryKey()
Cool, then you're almost there, right? Or are you all the way there? I
still think it's odd that it creates a PK each time you call
getPrimaryKey(), but that's not so nefarious I sup
bob combs wrote:
> Problem lies in what's being generated in the getPrimaryKey()
> in the VO:
>
>public com.messagegate.foundation.id.UUID getPrimaryKey() {
> com.messagegate.foundation.id.UUID pk = new
> com.messagegate.foundation.id.UUID();
> return pk;
>}
WTF?! That's truly b
WORKING!
Had to add a null constructor into UUID to get the create() to work due
to CMP wanting to do a class.newInstance(), then populate data on the
primary key. Now I just have to make the VO inherit from somewhere or
merge methods in so I can get a get/set UUID. Some form of inheritance
wo
More fun:
putting the @ejb.pk-field entry back on the getId() method generates a
correct getPrimaryKey()
Harkness, David wrote:
bob combs wrote:
org.jboss.deployment.DeploymentException: Field id in prim-key-class
must be the same type
Ah yes, note to self: reply *after* coffee. By u
Almost!
Problem lies in what's being generated in the getPrimaryKey() in the VO:
public com.messagegate.foundation.id.UUID getPrimaryKey() {
com.messagegate.foundation.id.UUID pk = new
com.messagegate.foundation.id.UUID();
return pk;
}
should be:
public com.messagegate.foundation.id
More follow-up.
Seems that the name of the field is kind of issue. If I change the field
name in the bean to "idd" (as in getIdd/setIdd with a matching
pk-field=idd entry) the bean will deploy. However, any SQL that gets
issued (either a table create or if I create the table by hand, a query)
bob combs wrote:
> org.jboss.deployment.DeploymentException: Field id in prim-key-class
> must be the same type
Ah yes, note to self: reply *after* coffee. By using a custom PK class,
you still need to map the individual fields (one in your case) using the
types in the PK class. So you need
pu
Follow up:
org.jboss.deployment.DeploymentException: Field id in prim-key-class
must be the same type
Here's specifically what I have now:
--
package com.messagegate.mms.message.ejb;
import javax.ejb.EntityBean;
import com.messagegate.foundation.id.IdentifierFactory;
import com.messagega
Thanks David, but I've been that route too (you're seeing some scatterd
remnants of various experiments).
I get a deployment message that "field id must be of same type". Same
type as what would be nice to know. I'll make everything match up both
ways though and give it another go.
Harkness, Da
bob combs wrote:
> I'm having quite a time attempting to use a CMP bean with a custom PK
> class w/ support in the value object. I'm sure I'm missing something
> fairly simple.
>
> [...]
>
> In the Bean xdoclet
>
> /**
> * @ejb.bean name="Message"
> * pk-field="id"
^^
> **/
I'm having quite a time attempting to use a CMP bean with a custom PK
class w/ support in the value object. I'm sure I'm missing something
fairly simple.
Anyway, I've got a UUID class that looks something like:
public class UUID implements Serializable {
public String id; // docs suggest th
13 matches
Mail list logo
