openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Wellmann <Harald.Wellm...@multi-m.de>
Subject Re: Confusing warning about openjpa.jdbc.SynchronizeMappings
Date Tue, 07 Sep 2010 18:44:06 GMT

Hi Kevin,

I can't offer a fix (yet), but I think I've pinpointed the problem. Here is
a little test case:

import static org.junit.Assert.assertEquals;
import org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl;
import org.junit.Test;

public class ConfigurationTest {

    @Test
    public void cloneTest() {
        JDBCConfigurationImpl config = new JDBCConfigurationImpl();
        JDBCConfigurationImpl newConfig = (JDBCConfigurationImpl)
config.clone();
        assertEquals(config, newConfig);
    }
}

The warning message about the configuration property
openjpa.jdbc.SynchronizeMappings is logged during config.clone().

clone() is implemented by invoking first toProperties(true) and then
fromProperties() on the resulting properties map.

fromProperties() removes all known properties from the map and then issues
warnings for all remaining ones - at least that seems to be the intention.

The problem is that SynchronizeMappings has no default value, or rather a
default value of null. Thus, the map generated by toProperties(true)
contains the key openjpa.jdbc.SynchronizeMappings with a value of null.

fromProperties() in fact only removes the known properties with a non-null
value,  so the key openjpa.jdbc.SynchronizeMappings remains in the map and
causes the warning.

The warning would not appear if clone() invoked toProperties(false), but I'm
not sure if this has any side effects.

Moreover, in my test case, the assertion 

   assertEquals(config, newConfig);

fails - now the Javadoc of Object.clone() states that x.clone().equals(x) is
not an absolute requirement (without giving any good reasons), but in this
case I would definitely expect the clone of a configuration to be equal to
the original.

The assertion failure is caused by LockTimeout:0[int] != LockTimeout:0[int],
so it appears that for x of class IntValue the invariant 

x.clone().equals(x)

does not hold either (why?).

Incidentally, the comment of ConfigurationImpl.toProperties() is outdated.
It references a non-existing parameter getAll and a non-existing method
getAllProperties().

Hopefully, this is enough input for someone familiar with the implementation
details to come up with a fix...

Best regards,

Harald






-- 
View this message in context: http://openjpa.208410.n2.nabble.com/Confusing-warning-about-openjpa-jdbc-SynchronizeMappings-tp5495438p5507719.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Mime
View raw message