Very good input, Harald. Thanks for your efforts. I'll post this
information to the existing JIRA and we'll see if we can somebody to take a
look. It would be great to get this one off the books.
Kevin
On Tue, Sep 7, 2010 at 1:44 PM, Harald Wellmann
<harald.wellm...@multi-m.de>wrote:
>
> 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.
>
