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 <ha...@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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
