[hibernate-dev] HHH-5375 - Move AnnotationConfiguration-added methods to Configuration and deprecate AnnotationConfiguration

[Steve Ebersole]

http://opensource.atlassian.com/projects/hibernate/browse/HHH-5375

In attempting this I ran into the difference between Configuration and
AnnotationConfiguration of processing mapping files (hbm.xml).
Configuration tries to process these immediately, whereas
AnnotationConfiguration delays that attempt.  So merging these 2 would
require changing the behavior in Configuration to delay attempts to
process/bind hbm.xml files to match what is done in
AnnotationConfiguration.

What's the ramification?

Well previously Configuration would allow a developer to do, as an
example, stuff like:
Configuation cfg = ...;
cfg.setProperty( "hibernate.default_schema", "ABC" );
cfg.addResource( "SomeEntity.hbm.xml" );
cfg.setProperty( "hibernate.default_schema", "XYZ" );
cfg.addResource( "AnotherEntity.hbm.xml" );

When "SomeEntity.hbm.xml" gets processed, the default schema in effect
is "ABC"; when "AnotherEntity.hbm.xml" gets processed, it is "XYZ".  Now
this has never been explicitly supported, but it is a side effect of the
lack of a "lifecycle" to how configurations are built (this will be
addresses in 4.x).

Now I am pretty sure we have consistently said that the above is not
supported and that user should not expect the "added" metadata to be
available until after buildMappings() has been called.  In fact, what
those calls should look like would be:
Configuation cfg = ...;
cfg.setProperty( "hibernate.default_schema", "ABC" );
cfg.addResource( "SomeEntity.hbm.xml" );
cfg.buildMappings();
cfg.setProperty( "hibernate.default_schema", "XYZ" );
cfg.addResource( "AnotherEntity.hbm.xml" );
cfg.buildMappings();

which has the same effect today as the code above, and will continue to
have the same effect moving forward even if we have Configuation delay
the processing/binding.

So I'd like to get input on whether we make this change today (for 3.6)
and merge Configuration+AnnotationConfiguation into a single class[1],
or if we push this back until 4.x when we begin the rest of the
configuration changes.


[1] Really the intent is move methods/fields from AnnotationConfiguation
up to Configuation and deprecate AnnotationConfiguation.  That way
existing code can, for s short time, continue to use
AnnotationConfiguration without change.


-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org