Howdy all - I'm a newbie to Hibernate, and just finished my first two installation tests comparing xml config to programmatic config (and comparing annotations to xml mappings).

It took some hacking to get the programmatic config to work, because the examples I copied to do the xml configuration didn't preface the configuration properties with "hibernate.". The xml test worked like a charm nevertheless.

Then, when I gave programmatic configuration a try, I translated the XML statements directly to Java AnnotationConfiguration.setProperty statements. I got all kinds of weird runtime errors on getCurrentSession, beginTransaction, saveObject, and commit. I traced these back to particular config parameters that weren't doing their job.

Some of the config parameters need to be prefaced with "hibernate." and some of them don't. It looks like a bug that the programmatic config and the XML config react differently to the same property names. It also seems like there is an opportunity to increase reuse here - possibly there are functionally duplicate code paths between the programmatic config and the file-based config causing the divergence. Or perhaps this is a difference between Configuration (which I used to do the xml-based configuration) and AnnotationConfiguration (which I used to do the programmatic configuration).

I was going to write up a Jira issue on this, but read on the site that you guys require us to write a post to this forum and get permission before filing a bug? That seems bizarre, but here it is. Oh noble foxes guarding your own henhouse, is it OK to file a bug?

Versions: Hibernate core 3.2 cr2
Hibernate annotations 3.2 cr1
(Note I had to back-rev to cr2 for core because cr3 wasn’t working with the annotations package.)

Xml cfg file text (used with Configuration):


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory name="HoldEmHoleCardDbSessionFactory">
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="connection.password">secret</property>
<property name="connection.url">jdbc:mysql://localhost/test</property>
<property name="connection.username">reallysecret</property>
<property name="dialect">org.hibernate.dialect.MySQLDialect</property>

<!-- Enable Hibernate's automatic session context management -->
<property name="current_session_context_class">thread</property>

<!-- Disable the second-level cache -->
<property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>

<!-- Echo all executed SQL to stdout -->
<property name="show_sql">true</property>

<!-- Drop and re-create the database schema on startup -->
<property name="hbm2ddl.auto">create</property>

<mapping resource="PersistentObjectWithCfg.hbm.xml"/>
</session-factory>
</hibernate-configuration>

Programmatic config that worked (using AnnotationConfiguration):

// set the properties to log onto the mySQL test database
config.setProperty(
"hibernate.connection.driver_class", "com.mysql.jdbc.Driver" );
config.setProperty(
"hibernate.connection.password", "secret" );
config.setProperty(
"hibernate.connection.url", "jdbc:mysql://localhost/test" );
config.setProperty(
"hibernate.connection.username", "reallysecret" );
config.setProperty(
"hibernate.dialect", "org.hibernate.dialect.MySQLDialect" );


// Enable Hibernate's automatic session context management -->
config.setProperty(
"hibernate.current_session_context_class",
"org.hibernate.context.ThreadLocalSessionContext" );

// Disable the second-level cache -->
config.setProperty(
"cache.provider_class", "org.hibernate.cache.NoCacheProvider" );

// Echo all executed SQL to stdout -->
config.setProperty( "show_sql", "true" );

// Drop and re-create the database schema on startup -->
config.setProperty( "hibernate.hbm2ddl.auto", "create" );

config.addAnnotatedClass( PersistentObjectWithAnno.class );

No - all of them (if done programmatically) needs the "hibernate." prefix.
If something seemed to work without it was most likely because it was some default.



I consider it a feature of the cfg.xml.

You could argue they should be equal but one could also argue otherwise because of:

1) the reason it is done in the cfg.xml is to make it easier to type/change. same reason we prefer attributes over elements in our xml's. With programmatic access that is not such a big issue.

2) that is how it always worked (backwards compatibility is important and it's extremely easy for you to fix; just put "hibernate." in front ;) thus some might utilize that you can store other properties than "hibernate." prefixed ones.




What reuse are you referring to here ? They all use the same configuration method today so what is there else to be reused ?

btw. you keep mentioning "path" which for me normally refer to file or url paths where as you only mention names



:) if you knew how many bogus bug reports we get then you would not find it bizarre. Plus we don't say you should ask for permission; we simply say you should discuss the issue on the forum *before* you put it in jira since *alot* of the "bugs" comes from misunderstanding or simply not knowing how a feature is/should work.

To your particular issue then I would not call it a bug that the Configuration does not autoprefix the properties.

Max - thanks for the quick response - comments inline below



Aiee - that's worse than what I thought - it demonstrates that not only is the configuration failing silently (which I'll elaborate below) but that in the case of a property where I get the name wrong but try to assign it the default value, the failure will come to light months or years from now when I change the value away from the default, and it will be hard to troubleshoot - making me suspect there's something wrong with the new property value not the property name.



Yes I argue they should be equal. My expectation is that I should be able to translate whatever I did directly from an XML configuration file into a programmatic configuration. That's exactly what I did, and the code blew up all over. The fact that I have to know there is a distinction means Hibernate is harder to learn.

Aside from that, the distinction is debatable - if allowing users to shortcut the names in XML configurations is a benefit, why isn't it just as much a benefit in programmatic configuration?

Finally, though as you say it is easy to fix - it is a royal pain to troubleshoot. The configuration routine fails to set the expected parameter without warning or error, so you don't know you set the parameter wrong. Later in the program, at some point later, some routine will fail, and you have to relate it back to the "missing" configuration parameter and guess what's wrong. I spent some time yelling at the computer "It's right there! Why don't you see it?!!" before I stumbled on the trick of adding "hibernate." to the beginning of the name.

Note also that the names without the "hibernate." at the beginning came from your "getting started" example in your documentation. Also note there's nothing in the documentation that explains you have to have fully qualified parameter names in programmatic configuration but are allowed to shortcut them in XML configuration. We users have to guess by digging through examples.

You can fix this without breaking backward compatability simply by making the programmatic configuration as permissive as the XML configuration. That way nothing new will fail. Is there really anyone who is taking advantage of the difference between configuration processing to create parameters not prefaced by "hibernate."? That means this can only be done programmatically and not through XML? It's also not documented anywhere.



What I mean is to parse the parameter names the same in both places. You must have some code in the parser for XML configuration that handles the parameter names missing "hibernate.". Reuse this same code to parse the programmatic configuration parameter names.



Sorry - I meant property name. Since they are qualified with dots, they seem like "paths" to me. I'll be more careful with my lingo from now on ;)



Hey - consider it the second-sincerest form of flattery that your wonderful work has brought a flood of unreasonable demands from hordes of us clueless idiots. ;)

But - though I was semi-kidding about the foxes guarding the henhouse, I'm also semi-serious. If there is a lot of misunderstanding about a feature, then that indicates that the feature could be made more intuitive and easier to use. This seems so obviously a bug to me I wouldn't hesitate for a minute filing a Jira. It's definitely not a high-priority bug, but it is a usability problem, and the documentation could be better whether you fix it or not.

How about this - if I offered to fix the problem, and made the programmatic config act the same as the XML config, would you accept it as a fix? That way I'm not burdening you with the work. Or is preserving the current undocumented behavior more important?

- John

provide a patch and let see if it passes through the foxes "backwards-compability-filter" for 3.2.

But no promises since this is ancient behavior.

Max - I don't have a true patch yet, but the fix is very small and contained. In Configuration.java, all I did was move the 2-line "if" statement from "addProperties" into "setProperty," and change "addProperties" so the new setProperty is called. Now the same feature that was added to "addProperties" will work for programmatic configuration using "setProperty."

It doesn't look like there are any JUnit tests that include "setProperty" in the source checkout. (...or the Eclipse search functions are doing me wrong...)

Since the only change is to have "setProperty" add an extra property with "Hibernate." pre-pended, and "setProperty" is only called once in the Hibernate distribution, I doubt this will fail back-compat tests. (unless you have tests that are not included in the source checkout, and that do something like count the number of properties after a call to "setProperty").

It is a pervasive change, however, because it changes "addProperties" even in a small way, so I wouldn't try to argue to change it now, 'till after GA. If you want me to open a bug or send a real patch, or change the fix in any way, let me know. I could conceive of several variations, but think this is the best one. Obviously, our priorities may vary.

Here is the text of the proposed fix, starting at line 1290 of Configuration.java:

hmmm....i actually think this will break e.g. entity-manager since it has non-hibernate rooted properties from ejb3 property settings.

Is entity-manager in the Hibernate-Ext branch? That would be why I didn't see it.

It probably won't break it, but it will add an extra property that is hibernate-rooted for each property that is non-rooted. If that is unacceptable, the next fallback would be to keep "setProperty" at it's original implementation, but add a new method "setHibernateProperty" that performs the same logic as "addProperties" like this:



Adding a line to the javadoc for each method about how the property names are treated would complete the picture, so no one will be uncertain or confused about what's going on in the background.

This way there's no chance of a back-compat problem because the original implementations remain the same (unless I introduced a bona-fide implementation bug).

and then it would be api bloat for somethign that is very trivial to do your self.....

Max you're missing the point. It is only trivial to fix *once you figure out what's wrong*. As I mentioned before, it took me about an hour to troubleshoot the problem before I figured out the *trivial* fix.

Let me put it to you this way - you said:

I think you are adding to this very problem when you make Hibernate more difficult to understand and then argue down everyone who is trying to help you improve it.

You guys introduced a usability problem into Hibernate when you made xml configuration behave differently than programmatic configuration. Whatever your reason for that, you are violating a very reasonable user expectation that the similar interfaces should exhibit similar behavior.

So, now that the two interfaces (setProperty and configure/addProperties) have different behaviors, you say we shouldn't make them the same because some people (entity-manager) are taking advantage of the difference. How did they find out the difference? They have to somehow know about a private implementation because the interface gives no clue. When I respond with OK - then make the difference explicit in the interface so that people other than Hibernate committers can figure out what's going on, you say it's api bloat.

To me, these things hardly qualify as "problems" compared to the frustration I had in figuring out programmatic configuration. Fixing setProperty to act like configure/addProperties will not break back-compat, and it will only have an unexpected, though harmless side-effect in a few rare cases. Adding a setHibernateProperty interface is adding one simple setter method with no other consequence. It even reuses all 3 of its lines of code from implementation that was already in Hibernate. I would hardly call that api bloat. Refusing to change anything means you are going to frustrate more users with this usability problem.

Just because I am the first person to raise a stink about this, I am not the only person who ever ran into it. I am sure there are plenty others who had the same experience, but simply gave up and went back to xml configuration, or figured it out and privately cussed at you, but won't take the trouble to help you fix it. I think it is in the spirit of an open-source community for us users to help refine packages like Hibernate as we come across problems.

I do understand and also (like you) have a right to an opinion about the api, right ? :)

you are welcome to put your request for .setHibernateProperty in jira because i do hear what you are saying - i'm just not super keen on it.

the minimal change/improvement is also to describe in javadoc what the method actually do.

In any case, put it in jira and we'll see what happens.

Sure Max, makes sense, and I respect your opinion, even if we disagree.

Thanks for the discussion.

I'll put in a jira next time I have a few minutes.

- John