"Jonathan K. Weedon" wrote:
>
> Evan,
>
> Actually, in my example, I did not say that the PK type was "int".
Point taken. This was a business method.
> It could either be "int" or "Integer".
>
> Of course, that side steps the issue. There has been a long-standing
> ambiguity in the EJB spec as to whether primitive types were valid
> PKs. We assumed yes, others assumed no.
>
> Although the wording in the spec is still not clear, Linda and Vlada
> have provided us a statement that primitives are not allowed. The
> argument for this is rather odd, in that otherwise the signatures
> of various methods would have to change. Clearly this arguments is
> a little light, in that there are lots of other APIs in Java that
> permit calling methods that handle primitives, and which use Object
> wrappers as a substitute. For example:
>
> Object java.lang.reflect.Method invoke(Object, Object[])
>
> But at the end of the day, the spec authors have chosen to disallow
> primitives as PKs, and we will comply.
Actually I hope the spec will relax this one day. We have requested
as much.
> -jkw
>
> Evan Ireland wrote:
> >
> > Jonathan,
> >
> > Your example could be improved by not using 'int' as a primary key type.
> > This is not legal in EJB. The primary key has to be a class. This caused
> > us a major nuisance in fact, as we had people porting code from BAS to
> > EAServer that wouldn't deploy as we did not accept invalid primary key
> > types. We have since added deployment support for these invalid types as
> > we didn't want to be one of the few vendors not supporting it.
> >
> > "Jonathan K. Weedon" wrote:
> > >
> > > Cedric Beust wrote:
> > > >
> > > > > From: Jonathan Weedon [mailto:[EMAIL PROTECTED]]
> > > >
> > > > > I fully agree that:
> > > > >
> > > > > 1) "it doesn't need the state of the bean", and
> > > > > 2) "this method should be a home method".
> > > > >
> > > > > However, you still need to verify the existence of the record in the
> > > > > database, and therefore ejbLoad cannot be a noop. It does not matter
> > > > > whether you use commit option B or C, you need to go to the database,
> > > > > in order to know whether to throw a NoSuchObjectException, as per the
> > > > > EJB 2.0 (and 1.1) specification.
> > > >
> > > > Actually, no.
> > > >
> > > > NoSuchObjectException should only be thrown if the call to the business
> > > > method cannot be completed. In that particular case, the call will succeed
> > > > because the business method doesn't need to load any state in order to
> > > > complete.
> > > >
> > > > However, a call to a getter or a setter will result in NoSuchObjectException
> > > > being thrown, which is the expected behavior.
> > >
> > > Cedric,
> > >
> > > Going through the EJB 2.0 spec, I have to agree that there is no direct
> > > statement which your implementation violates. However, it very much
> > > violates the spirit of the spec. Let me motivate the example a little
> > > more.
> > >
> > > Consider that I have a Customer Entity. The PK of the Customer Entity
> > > happens to be the Customer's id number. However, I don't really want
> > > to hard-code that fact into my EJB interface, so I declare the PK type
> > > to be opaque: that is, java.lang.Object.
> > >
> > > Now, consider I have a business method on my Customer interface, which
> > > is used to get the customer id:
> > >
> > > public int getCustId() throws RemoteException;
> > >
> > > When I implement this method, I might do it as follows:
> > >
> > > public int getCustId() {
> > > Object pk = entityContext.getPrimaryKey();
> > > return ((Integer) pk).intValue();
> > > }
> > >
> > > That is, I use the fact that I know the PK is the customer id, and use
> > > it to get the int value.
> > >
> > > So, here we have a perfectly valid business method that never calls a
> > > getter or setter method. Furthermore, it does not really make sense
> > > to put this business method on the home interface, as it really is a
> > > proper instance-level business method.
> > >
> > > In my opinion, the spirit of the EJB spec should not allow the first
> > > line of getCustId() to ever execute. That is, a NoSuchObjectException
> > > ought to have been thrown by ejbLoad before the business method is
> > > ever invoked, in the case where the customer does not exist in the
> > > database. But you are saying that not only can this business method
> > > be executed, but I am guessing that the whole transaction can be
> > > committed, even though that particular customer no longer exists
> > > in the universe.
> > >
> > > That's broken. I can't show you how it violates the EJB spec (the
> > > spec does not go to that level of detail). But hopefully you can
> > > see, from a common sense perspective, that it is broken.
> > >
> > > [Actually, I believe the behavior is based on a much earlier version
> > > of the EJB 2.0 specification. Early versions (ca. April 2000) of the
> > > spec did allow for this behavior explicitly in the case of optimistic
> > > concurrency, where the existence check was deferred to the end of the
> > > transaction. But in the current proposed final EJB 2.0 spec, this
> > > behavior does not seem legitimate.]
> > >
> > > -jkw
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
