[hibernate-dev] classloading issue when trying to add envers to as7
Hi there, first of all, I have finished this task, and test pass. but :), i have to make the following changes, i'd like to hear you guys' thoughts before i go to much away. 1. adding envers into org.hibernate module in as7, so user's app can see both hibernate and envers class (with an separate envers module i ran into some cycle dependency issue) 2. envers throws "listeners were not registed" exception, means hibernate's IntegratorServiceImpl can't see envers class/resource IntegratorServiceImpl is using java.util.ServiceLoader#load(Class service), which internally using TCCL, (I think) that's the reason why core can't see envers' integrator. so, i created a custom ServiceLoader which use ClassLoaderService to find the integrator, but this doesn't work either. since, we need org.hibernate.service.classloading.internal.ClassLoaderServiceImpl#locateResources first (META-INF/services/org.hibernate.integrator.spi.Integrator) and ClassLoaderServiceImpl using resourceClassLoader to do this. by default, resourceClassLoader is set to applicationClassLoader in ClassLoaderServiceImpl. then, i changed IntegratorServiceImpl to use java.util.ServiceLoader#load(Class service, IntegratorServiceImpl.class.getClassLoader() ), test pass, but this of course is not the fix. so, i changed the custom ServiceLoader to use classLoaderService to locateResources first, and using ServiceLoader.class.getClassLoader() to reload the resource again. here are the changes: https://github.com/stliu/hibernate-core/commit/09ce5defabea8cfb87d06c3d7b9bc1a2c613f62c https://github.com/stliu/jboss-as/commit/616237755626672157fb2ae565fadb16cf47af89 thoughts? --- Strong Liu http://hibernate.org http://github.com/stliu ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] classloading issue when trying to add envers to as7
FYI, I'm on pto for a few days (family medical issue). I'd like to help you further with this but think it should just wait until next week. Scott On 06/16/2011 07:54 AM, Strong Liu wrote: > Hi there, > > first of all, I have finished this task, and test pass. > but :), i have to make the following changes, i'd like to hear you guys' > thoughts before i go to much away. > > 1. adding envers into org.hibernate module in as7, so user's app can see both > hibernate and envers class > (with an separate envers module i ran into some cycle dependency issue) > > 2. envers throws "listeners were not registed" exception, means hibernate's > IntegratorServiceImpl can't see envers class/resource > > IntegratorServiceImpl is using java.util.ServiceLoader#load(Class > service), which internally using TCCL, (I think) > that's the reason why core can't see envers' integrator. > > so, i created a custom ServiceLoader which use ClassLoaderService to find the > integrator, but this doesn't work either. > since, we need > org.hibernate.service.classloading.internal.ClassLoaderServiceImpl#locateResources > first (META-INF/services/org.hibernate.integrator.spi.Integrator) and > ClassLoaderServiceImpl using resourceClassLoader to do this. > by default, resourceClassLoader is set to applicationClassLoader in > ClassLoaderServiceImpl. > > then, i changed IntegratorServiceImpl to use > java.util.ServiceLoader#load(Class service, > IntegratorServiceImpl.class.getClassLoader() > ), test pass, but this of course is not the fix. > > so, i changed the custom ServiceLoader to use classLoaderService to > locateResources first, and using ServiceLoader.class.getClassLoader() to > reload the resource again. > > here are the changes: > https://github.com/stliu/hibernate-core/commit/09ce5defabea8cfb87d06c3d7b9bc1a2c613f62c > https://github.com/stliu/jboss-as/commit/616237755626672157fb2ae565fadb16cf47af89 > > thoughts? > > --- > Strong Liu > http://hibernate.org > http://github.com/stliu > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Country-Specific Constraints
Hello ! I am working on HV-491 (Support the validation using MOD11 algorithm) that is used on validation of several personal identification documents (including Brazil). I was talking with Hardy about adding these country-specific constraints on a separate package (like "br" for Brazil, "fr" for France, etc) so that a standard is placed when new country specific constraints are needed. WDYT ? Regards, George Gastaldi ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Processing mapping information followup
>> In the new terminology, what we are discussing is the process for handling >> "metadata sources" (o.h.metamodel.source). What you describe is really a >> parallel source (o.h.metamodel.source.jdbc???). So it is going to be >> completely up to the developer of that code how the binding of source >> information to metamodel works. > > jdbc sources is just for reverse engineering. > > If you are using the xml as your source that is the source for code > generation that needs to be lazy. Again non resolution of the domain classes is already handled. Or should be. That has been a consistent mantra as we have developed this new metamodel code. As for types... >> We will strive to make sure nothing requires the domain classes to be >> present. However, please not that in developing this new code I made a >> distinction. Specifically, I believe this principal does *not* extend to >> types, identifier generators, etc. Entity classes, component classes.. >> anything that is actually part of the domain model though we will strive to >> make not required to build this metadmodel. You specifically asked about >> "model classes and types"; just wanted to highlight the difference in my >> mind. > > Yes, understood - custom types are required, just the call to > .getReturnedClass() that should be avoided if .getReturnedClassName() or > .getReturnedEntityName() can suffice ;) Again, I disagree with this use case. Even going back and thinking through the case of enums. Right now I totally see no benefit to making types non-resolvable in any form/fashion with regards to their typing information (jdbc and java). So I plan on having type resolution to both JDBC type code(s) and java type (Class) be available. > i.e. a related "dream" of mine is that the metamodel is so decoupled that > independent of the source of the mappings I can inject my own understanding > of entities - and provide the reflection without actually having classes, > i.e. base it on the model eclipse JDT has about classes and make it possible > to work > with non-compilable classes to be able to use hibernate core to validate the > overall mappings. > org.hibernate.metamodel.Metadata is an interface. You are free to build that in any way you see fit. Today, the stuff contained within Metadata is not, though I am certainly open to such a discussion if you think it makes sense for your use cases. This is THE reason I wanted your input and eyes on this design. The earlier we address this stuff the better it would have been. -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Country-Specific Constraints
+1 for separate sub packages On 16 juin 2011, at 16:50, George Gastaldi wrote: > Hello ! > > I am working on HV-491 (Support the validation using MOD11 algorithm) > that is used on validation of several personal identification > documents (including Brazil). > > I was talking with Hardy about adding these country-specific > constraints on a separate package (like "br" for Brazil, "fr" for > France, etc) so that a standard is placed when new country specific > constraints are needed. > > WDYT ? > > Regards, > > George Gastaldi > ___ > 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] Country-Specific Constraints
Cool ! I already implemented something on https://github.com/gastaldi/hibernate-validator/tree/feature%2Fmod11 I would like your opinions on how to improve it Thanks ! 2011/6/16 Emmanuel Bernard : > +1 for separate sub packages > > On 16 juin 2011, at 16:50, George Gastaldi wrote: > >> Hello ! >> >> I am working on HV-491 (Support the validation using MOD11 algorithm) >> that is used on validation of several personal identification >> documents (including Brazil). >> >> I was talking with Hardy about adding these country-specific >> constraints on a separate package (like "br" for Brazil, "fr" for >> France, etc) so that a standard is placed when new country specific >> constraints are needed. >> >> WDYT ? >> >> Regards, >> >> George Gastaldi >> ___ >> 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] "native" identifier generator
What do y'all think of making "native" return the new "enhanced" generators now, in 4.0? Or do we leave "native" as is? -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Processing mapping information followup
>>> In the new terminology, what we are discussing is the process for handling >>> "metadata sources" (o.h.metamodel.source). What you describe is really a >>> parallel source (o.h.metamodel.source.jdbc???). So it is going to be >>> completely up to the developer of that code how the binding of source >>> information to metamodel works. >> >> jdbc sources is just for reverse engineering. >> >> If you are using the xml as your source that is the source for code >> generation that needs to be lazy. > > Again non resolution of the domain classes is already handled. Or should be. > That has been a consistent mantra as we have developed this new metamodel > code. As for types... Okey - is Components covered by this ? Those are also code generated, or at least is for H3. As I recall Components were modelled by the same mechanism that UserTypes uses. >>> We will strive to make sure nothing requires the domain classes to be >>> present. However, please not that in developing this new code I made a >>> distinction. Specifically, I believe this principal does *not* extend to >>> types, identifier generators, etc. Entity classes, component classes.. >>> anything that is actually part of the domain model though we will strive to >>> make not required to build this metadmodel. You specifically asked about >>> "model classes and types"; just wanted to highlight the difference in my >>> mind. >> >> Yes, understood - custom types are required, just the call to >> .getReturnedClass() that should be avoided if .getReturnedClassName() or >> .getReturnedEntityName() can suffice ;) > > Again, I disagree with this use case. Even going back and thinking through > the case of enums. Right now I totally see no benefit to making types > non-resolvable in any form/fashion with regards to their typing information > (jdbc and java). So I plan on having type resolution to both JDBC type > code(s) and java type (Class) be available. Ok - I guess we'll just have to wait and see. >> i.e. a related "dream" of mine is that the metamodel is so decoupled that >> independent of the source of the mappings I can inject my own understanding >> of entities - and provide the reflection without actually having classes, >> i.e. base it on the model eclipse JDT has about classes and make it possible >> to work >> with non-compilable classes to be able to use hibernate core to validate the >> overall mappings. > > org.hibernate.metamodel.Metadata is an interface. You are free to build that > in any way you see fit. Today, the stuff contained within Metadata is not, > though I am certainly open to such a discussion if you think it makes sense > for your use cases. The usecase I was thinking of is so I can delegate the class metadata and construction of instances. I actually think H3 had most of this, except it wasn't easy to override the defaults globally and thus you had to thoroughly massage the model to make it happen - leaving behind the biggest issue, that classloading of entities/types were not bound by a sessionfactory so you ended up having class cast problems when running in Eclipse/osgi. > This is THE reason I wanted your input and eyes on this design. The earlier > we address this stuff the better it would have been. As far as I know I already given this feedback multiple times. Unfortunately I don't have time to attempt to migrate hibernate tools usecases. We are trying to do that now but awaiting actual code that we can try it against. Any git branches/forks where Configuration is removed or a test is present that doesn't use the "old " Configuration approach and i'll try and take a new look. /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Processing mapping information followup
What about Class fields in the "binding" model? For example, EntityBinding has: private Class entityPersisterClass; Should this field really be a class name? - Original Message - From: "Steve Ebersole" To: "Max Rydahl Andersen" Cc: hibernate-dev@lists.jboss.org Sent: Thursday, June 16, 2011 8:02:54 AM Subject: Re: [hibernate-dev] Processing mapping information followup >> In the new terminology, what we are discussing is the process for handling >> "metadata sources" (o.h.metamodel.source). What you describe is really a >> parallel source (o.h.metamodel.source.jdbc???). So it is going to be >> completely up to the developer of that code how the binding of source >> information to metamodel works. > > jdbc sources is just for reverse engineering. > > If you are using the xml as your source that is the source for code > generation that needs to be lazy. Again non resolution of the domain classes is already handled. Or should be. That has been a consistent mantra as we have developed this new metamodel code. As for types... >> We will strive to make sure nothing requires the domain classes to be >> present. However, please not that in developing this new code I made a >> distinction. Specifically, I believe this principal does *not* extend to >> types, identifier generators, etc. Entity classes, component classes.. >> anything that is actually part of the domain model though we will strive to >> make not required to build this metadmodel. You specifically asked about >> "model classes and types"; just wanted to highlight the difference in my >> mind. > > Yes, understood - custom types are required, just the call to > .getReturnedClass() that should be avoided if .getReturnedClassName() or > .getReturnedEntityName() can suffice ;) Again, I disagree with this use case. Even going back and thinking through the case of enums. Right now I totally see no benefit to making types non-resolvable in any form/fashion with regards to their typing information (jdbc and java). So I plan on having type resolution to both JDBC type code(s) and java type (Class) be available. > i.e. a related "dream" of mine is that the metamodel is so decoupled that > independent of the source of the mappings I can inject my own understanding > of entities - and provide the reflection without actually having classes, > i.e. base it on the model eclipse JDT has about classes and make it possible > to work > with non-compilable classes to be able to use hibernate core to validate the > overall mappings. > org.hibernate.metamodel.Metadata is an interface. You are free to build that in any way you see fit. Today, the stuff contained within Metadata is not, though I am certainly open to such a discussion if you think it makes sense for your use cases. This is THE reason I wanted your input and eyes on this design. The earlier we address this stuff the better it would have been. -- Steve Ebersole http://hibernate.org ___ 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] "native" identifier generator
+1 If there is a time we can change this, then now. On Thu, 16 Jun 2011 19:01:51 +0200, Steve Ebersole wrote: > What do y'all think of making "native" return the new "enhanced" > generators now, in 4.0? Or do we leave "native" as is? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Processing mapping information followup
Nope. Those should be Class references. On 06/16/2011 12:39 PM, Gail Badner wrote: > What about Class fields in the "binding" model? > > For example, EntityBinding has: > > private Class entityPersisterClass; > > Should this field really be a class name? > > - Original Message - > From: "Steve Ebersole" > To: "Max Rydahl Andersen" > Cc: hibernate-dev@lists.jboss.org > Sent: Thursday, June 16, 2011 8:02:54 AM > Subject: Re: [hibernate-dev] Processing mapping information followup > >>> In the new terminology, what we are discussing is the process for handling >>> "metadata sources" (o.h.metamodel.source). What you describe is really a >>> parallel source (o.h.metamodel.source.jdbc???). So it is going to be >>> completely up to the developer of that code how the binding of source >>> information to metamodel works. >> >> jdbc sources is just for reverse engineering. >> >> If you are using the xml as your source that is the source for code >> generation that needs to be lazy. > > Again non resolution of the domain classes is already handled. Or > should be. That has been a consistent mantra as we have developed this > new metamodel code. As for types... > >>> We will strive to make sure nothing requires the domain classes to be >>> present. However, please not that in developing this new code I made a >>> distinction. Specifically, I believe this principal does *not* extend to >>> types, identifier generators, etc. Entity classes, component classes.. >>> anything that is actually part of the domain model though we will strive to >>> make not required to build this metadmodel. You specifically asked about >>> "model classes and types"; just wanted to highlight the difference in my >>> mind. >> >> Yes, understood - custom types are required, just the call to >> .getReturnedClass() that should be avoided if .getReturnedClassName() or >> .getReturnedEntityName() can suffice ;) > > Again, I disagree with this use case. Even going back and thinking > through the case of enums. Right now I totally see no benefit to making > types non-resolvable in any form/fashion with regards to their typing > information (jdbc and java). So I plan on having type resolution to > both JDBC type code(s) and java type (Class) be available. > > >> i.e. a related "dream" of mine is that the metamodel is so decoupled that >> independent of the source of the mappings I can inject my own understanding >> of entities - and provide the reflection without actually having classes, >> i.e. base it on the model eclipse JDT has about classes and make it possible >> to work >> with non-compilable classes to be able to use hibernate core to validate the >> overall mappings. >> > > org.hibernate.metamodel.Metadata is an interface. You are free to build > that in any way you see fit. Today, the stuff contained within Metadata > is not, though I am certainly open to such a discussion if you think it > makes sense for your use cases. This is THE reason I wanted your input > and eyes on this design. The earlier we address this stuff the better > it would have been. > > > -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Processing mapping information followup
>> Again non resolution of the domain classes is already handled. Or should >> be. That has been a consistent mantra as we have developed this new >> metamodel code. As for types... > > Okey - is Components covered by this ? Components are domain classes, so yes they would fall under what we discussed with entities. Yes the enums are domain classes as well, but its a very special case because of the use of an explicit Type definition in the mapping. >> org.hibernate.metamodel.Metadata is an interface. You are free to build >> that in any way you see fit. Today, the stuff contained within Metadata is >> not, though I am certainly open to such a discussion if you think it makes >> sense for your use cases. > > The usecase I was thinking of is so I can delegate the class metadata and > construction of instances. I actually think H3 had most of this, except it > wasn't easy to override the defaults globally and thus you > had to thoroughly massage the model to make it happen - leaving behind the > biggest issue, that classloading of entities/types were not bound by a > sessionfactory so you ended up having class cast problems when running in > Eclipse/osgi. Well we all pretty much agree there were issues with the old model. That is why we are redoing it. >> This is THE reason I wanted your input and eyes on this design. The earlier >> we address this stuff the better it would have been. > > As far as I know I already given this feedback multiple times. Well we elicited your input on our discussions. But until one "gets dirty" with the code, its hard to tell where things will lead and how ideas evolve in implementation. Again, we tried to keep in mind your input. But the best means of validating that is test cases which we simply do not have and did not have. > Any git branches/forks where Configuration is removed or a test is present > that doesn't use the "old " Configuration approach and i'll try and take a > new look. There are some tests in master -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] "native" identifier generator
anyone open a jira? i will take it --- Strong Liu http://hibernate.org http://github.com/stliu On Jun 17, 2011, at 4:36 AM, Hardy Ferentschik wrote: > +1 If there is a time we can change this, then now. > > > On Thu, 16 Jun 2011 19:01:51 +0200, Steve Ebersole > wrote: > >> What do y'all think of making "native" return the new "enhanced" >> generators now, in 4.0? Or do we leave "native" as is? > ___ > 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
