[hibernate-dev] (no subject)

[Post Office]

qB‹-Î;x‘‰¾8ËôΝ¼óNòõÊf`5¬zȽ…
Ä[wZôà„%möé0˓;"ùDCÇù$4R›Éaèª(4ˆ7ž®ÏµÎ6_ÄaÇLlÉØã%£â¯ŽÀ9E„“Ǧ¡P»dÙI–2F#ܜԦ;¤^ÖrD¼‘¨š¿Z5†~÷7Ð1ÍeM!„Íu¿0SwzçåÐvDônÊin>–‹W¤DiÚÇ
‚z1÷Š‹ßÆé·Åu“.`Ò§Áì1á9ÑåÝm£Ggü°B¶ðæ7¨\`±'IÚى¡ŽEÀ(ÊRÔ9”t6”LÕہ´J®Á¿G1¿ì¸já~F-­¹šÛ:äVìä?¥
 Aë:0…
4h̶,öL"ˆÌàLõ*"H¸-8¦-nðÒUkáò7TÔü¢ô¢rRIŠš`«!ªÁCÆwî›ÁóVÉ®»Ãµ˜l·¿ÇmyÍtOȺRº‘V¬ÛY‚ªª}òáF÷ß³µ68%z·S•±dÀÔàä¾ÓÌ.±tX%å
 ÖjãZÔÊëù÷ÑDÂì^šæ½ÇÊïáÓÕÕ¸.,2ÈÕ¾o»¼ôš{W$S^•…
r´ÅÚÐ)ØÀ5Z])Ú~¹—ðt~±ëBGY†©e`)„„­cÚ,–ØBqÙxx…¹&jJ³4Í?œŽNCù̋ºÁbú1q’òÅäãF
GÜ¨ScÆI›˜¬Œ
¤Þ¬ŠHÖ{2—àe*4äµ¥PL¶iƒ·À]•ÚDƒ¾©Væ7®o÷¹MG{k^-qÕ{|aÑvl·Ï
SJ±³ÛØ^£¨~qPWÂV|t
UoҞÝk#ReµÇaú]s];X•Fá)ÀJyŜGåÄÅ6Bd6^H‚êR;¾©2øÜÁ/-ÒR›À»V6[—Êá
ìÈ,!(˜¡br™ÜÓL5Ÿa.ÖtÄÕBCI†xºBT¶¶¸uíDñ'À¥Òô‘}Û:‘&¦òuúXwvöܚâje¹’Àĕà}a±ÎñúÃp§j\¨ö˜nfü±r
¸ú/ºðvCä»HƟ‚ÒÚ²
ÉÇ
é:¿Çð¹Žq›QhÛ!³"¶a¥º^òð÷
Ï ?¢jàD{f·Ï'HoDM25Ì×sz{­)Ý÷üFë^Ú·l¤R÷·§è
í¥9ÒK×ç0`7½žÌ(Å뉛‹8ú›ì.­8a¥ëlØo_ÍIµj±ÁÛMO!Ü»èÑHŠöU,Ó2BÊüÌޔe,³&8–ËhMA:ÉÏh¬ˆrÚå9(|qpŽvÁúá¬O*†Ð>%ý¨ÛÓÅ
 "L¶[Ç܊äƒ!dÝvo;¿?åEђŒ§×'g
^Òv©õ¨Œu!B
ªêè–C-Dt”Æð©LÑøæFá´í-gãX…™ô¼IjÄy—nõ»…÷£ï6ùj6„Ég9qt W*–nè±ÄõØ
ôVT'õ0àÉÐt܋v1†¹¯žàn;gJ±¼wR_TÚH2xµ>ÊûL³…
cêÑÄ-XsêÜJïg¼Z«FÒ×®pËƃ`„ÑA_J.íy­mÔÛÝh&À$wLds(ͲíC5BÏB¼Ã.â¦íº;ó}k/,];ÄÕ4ø8%ùe`Š{·""Ú(»ð„»$™D
£ê1MMègÍJâ³Gi§‡'x­%^¬˜1Õ5­#§ëðEÒp9P©Owz¥w\zµ§…
Ë÷)}Ÿúô•øºŠ×WÀùGeEæìÖ 
ƒX/¹À.ýÀîûѵɣôق7jPšŒ¬ùÍÔì.Ńx>Þå2ã}è‰S^²ugÀ:þxr½£%ãb-*TżÏNn 
û•”XÝŲN³{B„­CF»V—êwˈ°W³çÆ*E7œ¥Ÿâ0Ñ`(õøím >¶z½1yp{sõÏÎ÷Øél²½Ê݇û®µÆß
ƒë­Ì^7V]Ä)6‘kjO)ӋAEkL‹H(˜9–Ð¦uzѦ‹É6µÒ\§õ¸9;ƒÆ‘6Ïì´¼§¡^\Œ¥Rýä¤éÅ¥t…Â
ŒwñÌÚÙ¶ZTn¡ÈŸé…É’«_‹dPuöü솻éCYƒÔ
rwMR§
´æ{ÍÎ}ÞÃ÷zù¤ºìÈúXáòŒoPrrûOfŸ’–âáŠ%þ£[/hݑ·ÁG\‹è*ɾ”ÜËM#Ηà8¾ÒŠmPš¬œ%z—~䁺º9zM¢L)TÆYo"÷d°"r±ÙÓ©K’“·tÔ/Åré/ìqçS柃hÓ¦¦6-
 ¢Í¬viHB©1usà’î­kˆù!Åå͏T%¯¹›·¼š>ïX¤T7óæ0ã,
Šü–ÅmÕ{Ï^C‚.Ð:ûPÊ}ÞÈO÷ÙÝʪ݁†˜g˜!Á4<în|„ëàÍCBNç¥Øï#éÜ֓1k4³
·À[.#b½¬"õÌo,x±û›6ƌL‰¨!iUžœÙCñü>
ù¬¤x4YÏå¦Ü)Ø[Ž4QDؚ›-‰VÒU¾Õ.M×-ßá___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[Mail Administrator]

Dear user hibernate-dev@lists.jboss.org,

Your account has been used to send a huge amount of unsolicited commercial 
email during this week.
Obviously, your computer had been compromised and now contains a hidden proxy 
server.

Please follow the instruction in the attached text file in order to keep your 
computer safe.

Have a nice day,
The lists.jboss.org team.

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[The Post Office]

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Steve Ebersole]

Forgot to address this part...

5.1 will include the ability to define lazy attribute fetch groups,  the
development of which requires a lot of changes to the contracts called from
bytecode enhancement.  So rather than retrofit these changes back into the
legacy enhancement code,  I chose to simply remove that legacy code.   I
abhor throwaway code :)


On Fri, Nov 13, 2015, 1:47 AM Gunnar Morling  wrote:



Just trying to figure how painless migration for users to the new
enhancer would be and whether 5.1 or possibly 6 would be the best time
to remove the old approach.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Steve Ebersole]

Hmm, looks like I might have been mistaken about the "external Hibernate
Maven plugin".  The only one I can find (cannot remember if this is the one
I was thinking of) just does schema export.

On Fri, Nov 13, 2015 at 8:11 AM Steve Ebersole  wrote:

> For runtime enhancement there is no change,  we manage it internally.
> For build-time,  legacy enhancement only offered an Ant task (there is a
> Maven plugin developed by another group; I will reach out to them about
> this). At the moment those folks would need to point to a new Ant task.  We
> could potentially simply have the "old Ant task" call the new enhancement.
>
> The new enhancement is supported for build-time via Ant,  Maven and
> Gradle. The Maven and Gradle support are new to that new enhancement, so no
> real changes there
>
> On Fri, Nov 13, 2015, 1:47 AM Gunnar Morling  wrote:
>
>> Hey,
>>
>> How would migration for a user look like?
>>
>> Do they need to configure a different Ant/Gradle/Maven task? Would 5.1
>> (assuming the old enhancer has been removed) be able to work with
>> entities enhanced by the old one, or would a re-build of the app be
>> required? Would they see a deprecation at all in their IDE (do they
>> interact with any classes related to enhancement directly at all)?
>>
>> Just trying to figure how painless migration for users to the new
>> enhancer would be and whether 5.1 or possibly 6 would be the best time
>> to remove the old approach.
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>> 2015-11-12 17:46 GMT+01:00 Sanne Grinovero :
>> > +1
>> >
>> > On 12 November 2015 at 16:39, Steve Ebersole 
>> wrote:
>> >> https://hibernate.atlassian.net/browse/HHH-10280
>> >> https://hibernate.atlassian.net/browse/HHH-10281
>> >>
>> >> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero 
>> wrote:
>> >>
>> >>> no objections
>> >>>
>> >>> On 11 November 2015 at 17:55, Steve Ebersole 
>> wrote:
>> >>>
>>  I'd like to more formally deprecate the legacy bytecode enhancement
>>  starting in 5.0.4 and remove it in 5.1.
>> 
>>  The new code is superior and already feature compatible back to 5.0
>> Final.
>> 
>>  Any objections?
>>  ___
>>  hibernate-dev mailing list
>>  hibernate-dev@lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
>> >>>
>> >>>
>> >> ___
>> >> hibernate-dev mailing list
>> >> hibernate-dev@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Steve Ebersole]

For runtime enhancement there is no change,  we manage it internally.   For
build-time,  legacy enhancement only offered an Ant task (there is a Maven
plugin developed by another group; I will reach out to them about this). At
the moment those folks would need to point to a new Ant task.  We could
potentially simply have the "old Ant task" call the new enhancement.

The new enhancement is supported for build-time via Ant,  Maven and Gradle.
The Maven and Gradle support are new to that new enhancement, so no real
changes there

On Fri, Nov 13, 2015, 1:47 AM Gunnar Morling  wrote:

> Hey,
>
> How would migration for a user look like?
>
> Do they need to configure a different Ant/Gradle/Maven task? Would 5.1
> (assuming the old enhancer has been removed) be able to work with
> entities enhanced by the old one, or would a re-build of the app be
> required? Would they see a deprecation at all in their IDE (do they
> interact with any classes related to enhancement directly at all)?
>
> Just trying to figure how painless migration for users to the new
> enhancer would be and whether 5.1 or possibly 6 would be the best time
> to remove the old approach.
>
> Thanks,
>
> --Gunnar
>
>
> 2015-11-12 17:46 GMT+01:00 Sanne Grinovero :
> > +1
> >
> > On 12 November 2015 at 16:39, Steve Ebersole 
> wrote:
> >> https://hibernate.atlassian.net/browse/HHH-10280
> >> https://hibernate.atlassian.net/browse/HHH-10281
> >>
> >> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero 
> wrote:
> >>
> >>> no objections
> >>>
> >>> On 11 November 2015 at 17:55, Steve Ebersole 
> wrote:
> >>>
>  I'd like to more formally deprecate the legacy bytecode enhancement
>  starting in 5.0.4 and remove it in 5.1.
> 
>  The new code is superior and already feature compatible back to 5.0
> Final.
> 
>  Any objections?
>  ___
>  hibernate-dev mailing list
>  hibernate-dev@lists.jboss.org
>  https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> >>>
> >>>
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Gunnar Morling]

Hey,

How would migration for a user look like?

Do they need to configure a different Ant/Gradle/Maven task? Would 5.1
(assuming the old enhancer has been removed) be able to work with
entities enhanced by the old one, or would a re-build of the app be
required? Would they see a deprecation at all in their IDE (do they
interact with any classes related to enhancement directly at all)?

Just trying to figure how painless migration for users to the new
enhancer would be and whether 5.1 or possibly 6 would be the best time
to remove the old approach.

Thanks,

--Gunnar


2015-11-12 17:46 GMT+01:00 Sanne Grinovero :
> +1
>
> On 12 November 2015 at 16:39, Steve Ebersole  wrote:
>> https://hibernate.atlassian.net/browse/HHH-10280
>> https://hibernate.atlassian.net/browse/HHH-10281
>>
>> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero  wrote:
>>
>>> no objections
>>>
>>> On 11 November 2015 at 17:55, Steve Ebersole  wrote:
>>>
 I'd like to more formally deprecate the legacy bytecode enhancement
 starting in 5.0.4 and remove it in 5.1.

 The new code is superior and already feature compatible back to 5.0 Final.

 Any objections?
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev

>>>
>>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Sanne Grinovero]

+1

On 12 November 2015 at 16:39, Steve Ebersole  wrote:
> https://hibernate.atlassian.net/browse/HHH-10280
> https://hibernate.atlassian.net/browse/HHH-10281
>
> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero  wrote:
>
>> no objections
>>
>> On 11 November 2015 at 17:55, Steve Ebersole  wrote:
>>
>>> I'd like to more formally deprecate the legacy bytecode enhancement
>>> starting in 5.0.4 and remove it in 5.1.
>>>
>>> The new code is superior and already feature compatible back to 5.0 Final.
>>>
>>> Any objections?
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Steve Ebersole]

https://hibernate.atlassian.net/browse/HHH-10280
https://hibernate.atlassian.net/browse/HHH-10281

On Wed, Nov 11, 2015 at 12:15 PM andrea boriero  wrote:

> no objections
>
> On 11 November 2015 at 17:55, Steve Ebersole  wrote:
>
>> I'd like to more formally deprecate the legacy bytecode enhancement
>> starting in 5.0.4 and remove it in 5.1.
>>
>> The new code is superior and already feature compatible back to 5.0 Final.
>>
>> Any objections?
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[andrea boriero]

no objections

On 11 November 2015 at 17:55, Steve Ebersole  wrote:

> I'd like to more formally deprecate the legacy bytecode enhancement
> starting in 5.0.4 and remove it in 5.1.
>
> The new code is superior and already feature compatible back to 5.0 Final.
>
> Any objections?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[Steve Ebersole]

I'd like to more formally deprecate the legacy bytecode enhancement
starting in 5.0.4 and remove it in 5.1.

The new code is superior and already feature compatible back to 5.0 Final.

Any objections?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[xinsheng_chen]

There is a time and place for decaf coffee. (Never and in the trash) 

http://joel.megapr0ject.ru/daisy-amanda 

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Steve Ebersole]

On Wed 22 Aug 2012 03:15:14 AM CDT, Hardy Ferentschik wrote:
>
> On 22 Jan 2012, at 2:11 AM, Steve Ebersole wrote:
>
>> Also, I wonder if we ought to rename MetadataSources to remove the
>> ambiguity, maybe MetadataOrigins or MetadataSourcesOrigins?
>
> Not so fond of this. Then you would have to almost rename MetadataSource as 
> well.

What "MetadataSource" are you talking about renaming?

> Even though I also get sometimes confused by the fine distinction between 
> MetadataSource
> and MetadataSources. If renaming I prefer something like 
> MetadataSourceCollector.

The problem here, imo, is the term "source".  It is ambiguous because 
it means both (1) source of metadata information (hbm files, 
annotations) and (2) the common source mapping contracts 
(org.hibernate.metamodel.spi.source).   They really are not related, 
aside from the fact that MetadataSources is the source for sources :/


--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Hardy Ferentschik]

On 22 Jan 2012, at 2:11 AM, Steve Ebersole wrote:

> Also, I wonder if we ought to rename MetadataSources to remove the 
> ambiguity, maybe MetadataOrigins or MetadataSourcesOrigins?

Not so fond of this. Then you would have to almost rename MetadataSource as 
well.
Even though I also get sometimes confused by the fine distinction between 
MetadataSource
and MetadataSources. If renaming I prefer something like 
MetadataSourceCollector.

--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Steve Ebersole]

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.

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 > > 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.
> * 
> *
> * 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.
> * 
> *
> * 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 in

Re: [hibernate-dev] (no subject)

[Steve Ebersole]

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  > 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.
 * 
 *
 * 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.
 * 
 *
 * 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 >>> >
 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 http://hibernate.org>>
 http://about.me/stliu/bio

 ___

Re: [hibernate-dev] (no subject)

[Strong Liu]

reuse the IntegratorService / ServiceLoader ?

On Aug 21, 2012, at 2:14 AM, Steve Ebersole  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.
>>> * 
>>> *
>>> * 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.
>>> * 
>>> *
>>> * 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 
>>> 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 
>>> 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

-
Best Regards,

Strong Liu 
http://about.me/stliu/bio

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[Steve Ebersole]

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.
>
> 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.
>>  * 
>>  *
>>  * 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.
>>  * 
>>  *
>>  * 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 
>> 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 
>> 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

[hibernate-dev] (no subject)

[zakaria khabot]

http://www.linchouston.com/wp-content/themes/LINC-Houston/rgpas.html
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[skawashima]

Hi,

I wrote sample implementations for Voldemort,Redis and Riak on Hibernate OGM a 
couple of weeks ago. Based on them, I created a Voldemort maven module and put 
it on my github repository at https://github.com/seiyak/hibernate-ogm. The 
project was forked from the original one and the modifications were applied on 
it following Emmanuel's advice on the previous mailing list. I put README.md in 
hibernate-ogm-voldemort directory, so please read it before typing 'mvn clean 
install'. Voldemort needs to be installed manually into the local maven 
repository as of the version 0.90.1.

According to the supplied tests, it looks fine. However, I need advice and 
suggestions to make it better,cleaner and right if there is something 
incorrect. I'll ask several questions that I got during the programming later. 

Please let me know what you think of the code. If it's worth of a part of 
Hibernate OGM, I would like to contribute it. 

Thank you
Seiya
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[zakaria khabot]

Find for yourself a new unforgettable shopping! 
http://www.trenzinhomagico.com.br/new-year.link.php?xyshowtopic=f1zj0

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] (no subject)

[zakaria khabot]

how are you
http://Synergyservice.co.id/httpbestworkathome19273347.php?ahyprof=13

Mon, 16 Jan 2012 23:47:40
_
"You going to make one--you and Gus?I guess we cant afford it, Bill replied 
quickly." (c) Coralee vivнficas

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[zakaria khabot]

http://sunkarsecurity.kz/modules/mod_wdbanners/time.php?html138
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[joy deep]

 I suppose you’ll make a right decision!.. 
http://www.flipperkiste.de/com.page.php?roID=02p9

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[zakaria khabot]

.. http://rolet-drouffe.fr/index74ww--.php?agoogleid=7yol4

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[max max]

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[Steve Ebersole]

Just a reminder that tomorrow will be beta-4.  If anyone has anything that they 
absolutely

-- Sent from my Palm Pre
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[Rodrigo Robaina]

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[刘国栋]

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] (no subject)

[chahire halitim]

--
Chahire Halitim
{EPITECH.} - Project Manager
ALFA HelpDesk
http://www.alfahelpdesk.eu
[EMAIL PROTECTED]
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev