No it's not foolproof. And I don't think it will ever be, as we're
basically trying to deal with the semantics of a method. This was briefly
discussed some time ago.
As for the situation that was raised, I think it is fair, and useful, to
the user (bean developer) to know that doing what they're doing (creating a
new identity on each constructor) will cause their implementations to
behave oddly (or possibly not at all, by the sound of Rickard's description).
So I think the check should stay but the error message could be changed.
Don't complain about missing equals() or hashcode(), complain about this
code not being able to work when deployed in jBoss.
Does anyone see problems with this, are there situations where this kind of
warning would be wrong?
-- Juha
At 10:28 30.10.2000 -0500, you wrote:
> Yeah, but this isn't foolproof either. A superclass could have
>redeclared it without changeing the functionality, or changing it to
>specifically not work the way we want. I don't think it does a lot of
>good to check for existence of the methods without trying to determine
>whether they do the right thing.
> So I guess it comes down to whether we want to raise a red flag in
>situations like the one that kicked this off. And it sounds like maybe we
>do (the verdict seems to be that the approach taken in that case is
>troublesome) - but we should probably have a section in the manual on
>common verifier errors and how to resolve them.
>
>Aaron
>
>On Mon, 30 Oct 2000, Dan OConnor wrote:
>> Hi Aaron,
>>
>> I think we should simply ensure that equals and hashCode are
>> implemented in a class derived from Object. I don't think we should
>> try to test the functionality of these methods if they exist, as this
>> second test has ample room for mistakes and little upside.
>>
>> The code to do this could involve calling "getDeclaredMethod" on
>> each class object in the inheritance tree until you reached Object
>> (or found an appropriate method). You would travel up the
>> inheritance heirarchy by using getSuperclass.
>>
>> Just a thought...
>>
>> Dan
>>
>>
>>
>> On 30 Oct 00, at 9:06, Aaron Mulder wrote:
>>
>> > Yes, I see. We test whether two objects created with the default
>> > constructor are equal, since usually all the variables are initialized to
>> > default values in the deafult constructor. However, in your object, the
>> > default constructor actually grabs an ID from the database, so two
objects
>> > created by the default constructor are *not* equal, and our test fails
>> > even though the object is legit.
>> > So, there are a couple points:
>> >
>> > - Your object is fine; you can ignore the message
>> > - Our test is flawed, because we assume things about the default
>> > constructor
>> > - However, we haven't thought of a better test - unless perhaps we were
>> > to create an object, and then serialize and deserialize it to get another
>> > object, and then compare the two. Perhaps that's the way to go. Anyone
>> > have thoughts on this?
>> >
>> > Aaron
>> >
>> > On Mon, 30 Oct 2000, Tim Squires wrote:
>> > > Hey Chaps,
>> > >
>> > > I have the following errors appearing on deployment of an entity EJB
with a
>> > > single primary key, the value of the primary key being populated
from an
>> > > Oracle sequence:
>> > >
>> > > [Verifier]
>> > > Class : area_type
>> > > Section: 9.2.9
>> > > Warning: The primary key class must override equals().
>> > >
>> > > [Verifier]
>> > > Class : area_type
>> > > Section: 9.2.9
>> > > Warning: The primary key class must override hashCode().
>> > >
>> > > Using prod-3 on NT with JDK1.3.
>> > >
>> > > The primary key code is:
>> > >
>> > > package com.mywds.beans;
>> > >
>> > > import javax.naming.*;
>> > > import java.sql.*;
>> > > import javax.sql.*;
>> > > import com.mywds.util.*;
>> > >
>> > > public class area_typePK implements java.io.Serializable
>> > > {
>> > > public Integer id;
>> > >
>> > > //Assuming that this bean will be implemented on an Oracle database
>> > > //it uses the area_typePK_seq to retrieve the next primary key
integer.
>> > > public area_typePK()
>> > > {
>> > > //Connect to the database
>> > > Connection conn = null;
>> > > try
>> > > {
>> > > Context ctx = new InitialContext();
>> > > DataSource ds = (DataSource)ctx.lookup("jdbc/OraclePool");
>> > > conn = ds.getConnection();
>> > >
>> > > //Find the next free integer from the area_typePK_seq sequence
>> > > Statement stmt = conn.createStatement();
>> > > ResultSet query = stmt.executeQuery( "select
area_typePK_seq.nextval
>> > > pk from dual" );
>> > >
>> > > if ( query.next() )
>> > > this.id = new Integer( query.getInt( "pk" ));
>> > > //else
>> > > //throw new Exception( "area_typePK: No area_type primary
key
>> > > returned from area_typePK_seq." );
>> > >
>> > > query.close();
>> > > query = null;
>> > > stmt = null;
>> > >
>> > > }
>> > > catch(NamingException ne)
>> > > {
>> > > //throw new Exception( "area_typePK: Hello Tim: Unable to
connect to
>> > > JNDI server to retrieve context: "+ne.toString() );
>> > > }
>> > > catch(SQLException se)
>> > > {
>> > > //throw new Exception( "area_typePK: Problem executing SQL:
>> > > "+se.toString() );
>> > > }
>> > > finally
>> > > {
>> > > if(conn != null)
>> > > try
>> > > {
>> > > conn.close();
>> > > conn = null;
>> > > }
>> > > catch(SQLException e)
>> > > {
>> > > //throw new Exception( "area_typePK: Unable to close current
>> > > connection: "+e.toString() );
>> > > }
>> > > }
>> > >
>> > > }
>> > >
>> > > public area_typePK( int id )
>> > > {
>> > > this.id = new Integer( id );
>> > > }
>> > >
>> > > public area_typePK( Integer id )
>> > > {
>> > > this.id = id;
>> > > }
>> > >
>> > >
>> > > public int hashCode()
>> > > {
>> > > Integer hc = new Integer( id.toString() );
>> > > return hc.intValue();
>> > > }
>> > >
>> > > public boolean equals( Object obj )
>> > > {
>> > > if ( obj == null || !(obj instanceof area_typePK))
>> > > return false;
>> > > else if (((area_typePK)obj).id == id )
>> > > return true;
>> > > else
>> > > return false;
>> > > }
>> > >
>> > > public String toString()
>> > > {
>> > > return id.toString();
>> > > }
>> > >
>> > > }
>> > >
>> > >
>> > > If I change equals to always return true and the hashCode to always
return 1,
>> > > jBoss does not throw the above error.
>> > >
>> > > Any help, hints or examples would be great.
>> > >
>> > > Thanks for your time,
>> > > Tim.
>> > >
>> > > ---------------------
>> > > It's not what you know, it's who you tell.
>> > >
>> > > -----------------------
>> > > "Free text messages!!! Another 100% free service brought to you by
the award winning Totalise"
>>
>> > > Visit http://sms.totalise.net"
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > --------------------------------------------------------------
>> > > To subscribe: [EMAIL PROTECTED]
>> > > To unsubscribe: [EMAIL PROTECTED]
>> > > Problems?: [EMAIL PROTECTED]
>> > >
>> >
>> >
>> >
>> > --
>> > --------------------------------------------------------------
>> > To subscribe: [EMAIL PROTECTED]
>> > To unsubscribe: [EMAIL PROTECTED]
>> > Problems?: [EMAIL PROTECTED]
>> >
>>
>>
>>
>>
>> --
>> --------------------------------------------------------------
>> To subscribe: [EMAIL PROTECTED]
>> To unsubscribe: [EMAIL PROTECTED]
>> Problems?: [EMAIL PROTECTED]
>>
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Problems?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
