The general idea is good. But not really getting the point/purpose of
having both before and after hooks.
On 08/17/2012 01:12 AM, Strong Liu wrote:
I'm thinking add the interface below, with it, modules like
envers can choose either before or after the metamodel get processed to hook into its own
extending mappings
public interface MetadataContributingIntegrator extends Integrator {
/**
* Allow the integrator to alter the {@link MetadataImplementor} BEFORE {@link
MetadataSources} get processed.
* <p/>
*
* At this stage, metamode ( like {@link
org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is not available yet.
* This is a good time to add the custom sources into {@MetadataSources} and get it
processed by Hibernate Metamodel.
*
* @param metadata The Metamodel which is going to be completed by processing
MetadataSources.
* @param source Meta data sources to be processed.
*/
public void beforeMetadataProcessing(MetadataImplementor metadata, MetadataSources
source);
/**
* Allow the itnegrator to alter the {@link MetadataImplementor} AFTER @{@link
MetadataSources} get processed.
* <p/>
*
* At this stage, metamode ( like {@link
org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is bindded.
* So, it depends on the integrator to manually create metamodel and add it to {@link
MetadataImplementor} or modifiy the
* existing one.
*
* @param metadata
* @param source
*/
public void afterMetadataProcessing(MetadataImplementor metadata, MetadataSources
source);
}
downside is, envers with old metamodel calls Configuration.buildMappings() again during
the integration phase, so, its created hbm xml can be processed (again) before SF create,
but with new metamodel, it is hard to do that I think ( or too time consuming )
and to create envers own metamodel ( hbm ) it needs to know the hibernate type of entity
property, which can be easily get from Entitybinding but hard / duplicated to resolve from
source by envers itself, so it seems we should choose "afterMetadataProcessing"
but envers' hbm creation involves lots of code and pretty complicated ( to me :)
it's better to reuse those code and choose "beforemetadataProcessing" and
let new metamodel to take care of that.
thoughts?
On Aug 2, 2012, at 12:17 AM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> On 31 Jan 2012, at 10:55 PM, Sanne Grinovero wrote:
>
>> Why is the "annotation indexing" discussion part of the metamodel?
> Why not? We are using Jandex in the new metamodel which is a annotation
index/repository
>
>> I initially understood that a replacement of commons-annotations was
>> being developed, which would be nice for Search too as Search does not
>> and should not depend on Hibernate ORM.
> as Strong already said, there is no replacement module for commons-annotations. There
is no
> need for it.
>
> And yes, Search should imo also switch to Jandex, however, it can initially just
create its own index.
> Of course it might be nice to be able to use a Jandex index passed to it via the
integrator spi. Different story though.
>
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev