On Aug 22, 2012, at 8:11 AM, Steve Ebersole <st...@hibernate.org> wrote:
> Also, I think how you were expecting beforeMetadataProcessing to happen can't
> really happen, but I suspect it is the more direct way to port envers.
>
> I *think* what you were thinking is to have envers pass along its extra
> EntitySource/EntityHierarchy stuff. You cannot just simply "add the custom
> sources into {@MetadataSources} and get it processed by Hibernate Metamodel"
> if you mean adding EntitySource/EntityHierarchy. That is actually not the
> role of MetadataSources. MetadataSources is a collection of sources for find
> metadata information; its the collection of mapping files, annotated classes,
> annotated packages, etc. org.hibernate.metamodel.spi.MetadataSourceProcessor
> implementations (there is one for HBM and one for Annotations) are
> responsible for taking the MetadataSources and building EntityHierarchy
> instances and passing those off to binder.
>
> So I need to understand exactly what y'all want here in terms of Envers since
> that is our primary use case for this. Are you wanting to "contribute"
> additional EntityHierarchy structures? IIRC, old envers code used to build
> in-memory DOM structures (or am I way off base in my memroy there?); if that
> is the target, maybe contributing JaxbRoots to MetadataSources is the way to
> go.
Envers still builds in-memory DOM, and this is why I want a
"beforeMetadataProcessing" ( the name is under discussion ) so we can call
org.hibernate.metamodel.MetadataSources#addDocument
but the problem here is, I'm not sure if envers could (easier) build a DOM
without knowing metadata info ( like hibernate type of user provided mapping
entity property )
>
> Also, I wonder if we ought to rename MetadataSources to remove the ambiguity,
> maybe MetadataOrigins or MetadataSourcesOrigins?
>
> On 08/21/2012 08:16 AM, Steve Ebersole wrote:
>> Yes, thats what you said in the javadocs ;)
>>
>> What I mean is that we have a use case for one of those. But not the
>> other. So why develop something that we do not have a use case for?
>>
>> On Mon 20 Aug 2012 11:23:14 PM CDT, Strong Liu wrote:
>>> reuse the IntegratorService / ServiceLoader ?
>>>
>>> On Aug 21, 2012, at 2:14 AM, Steve Ebersole <st...@hibernate.org
>>> <mailto:st...@hibernate.org>> wrote:
>>>
>>>> Also, I have been thinking that there really ought to be different
>>>> types of "integrators". Not sure what we gain by forcing
>>>> MetadataContributingIntegrator, ServiceContributingIntegrator,
>>>> TypeContributingIntegrator, etc to extend Integrator
>>>>
>>>>
>>>> On Sat 18 Aug 2012 05:50:29 PM CDT, Steve Ebersole wrote:
>>>>> The general idea is good. But not really getting the point/purpose of
>>>>> having both before and after hooks.
>>>
>>> BEFORE:
>>>
>>> modules can choose extend the MetadataSources with its own hbm/ann and
>>> get Metadata (Binder) process it
>>>
>>> this is pretty like what envers does today, or what i'm hoping it
>>> could do, so we could reuse lots of envers code
>>>
>>> AFTER:
>>>
>>> modify existing EntityBindings etc or create its own EntityBindings
>>> based on the existing ones
>>>
>>>
>>>
>>>
>>>>>
>>>>> 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
>>>>>> <mailto: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 <mailto:hibernate-dev@lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> -------------------------
>>>>>> Best Regards,
>>>>>>
>>>>>> Strong Liu <stliu at hibernate.org <http://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 <mailto:st...@hibernate.org>
>>>> http://hibernate.org
>>>
>>> -------------------------
>>> Best Regards,
>>>
>>> Strong Liu <stliu at hibernate.org <http://hibernate.org/>>
>>> http://about.me/stliu/bio
>>>
>>
>> --
>> st...@hibernate.org
>> http://hibernate.org
>
> --
> st...@hibernate.org
> http://hibernate.org
-------------------------
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
