RE: Fw: RE: [Hibernate] Complex class loaders hierarchy
It is very simple, cglib must define proxy in application classloader (the same as domain class loader), it doe's not mater how you find this clasloader, but it must be the same for proxy and for domain class (delegation to package visibility method throws IllegalAccessError if classes are in different "runtime packages"). Proxy must see hibernate and cglib classes to work, so hibernate and cglib must be in the same or in the parent classloader. Sorry if I confused you, it is not related to j2ee classloading stuff. This rule is valid for all use cases. --- Scott M Stark <[EMAIL PROTECTED]> wrote: > The class loading structure of a j2ee app is vendor > specific. For any > given component the correct starting point is the > thread context class > loader. That class loader should have visibility > into parent class > loaders as needed. > > > -Original Message- > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > On > > Behalf Of baliuka juozas > > Sent: Thursday, June 16, 2005 12:12 AM > > To: [EMAIL PROTECTED]; > hibernate-devel@lists.sourceforge.net > > Subject: Re: Fw: RE: [Hibernate] Complex class > loaders hierarchy > > > > I do not think it is possible to find the the best > way for > > this stuff, but we expected hibernate (and cglib) > classes > > will be in the same or in the parent classloader > (asumption > > is based on j2ee container class loading stuff). > It must be > > better to use this asumption, it has more chances > to be maintained. > > > --- > SF.Net email is sponsored by: Discover Easy Linux > Migration Strategies > from IBM. Find simple to follow Roadmaps, > straightforward articles, > informative Webcasts and more! Get everything you > need to get up to > speed, fast. > http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > ___ > hibernate-devel mailing list > hibernate-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Mixing and
On Jun 16, 2005, at 8:31 PM, Emmanuel Bernard wrote: This complexify the annotations (user experience, not the binding code), so I'm wondering whether I should allow this kind of structure or not. Also check: http://opensource.atlassian.com/projects/hibernate/browse/ HHH-539 Yep, used it recently for a customer who had a composite primary key with some fields also part of a composite foreign key (would need duplicate column mapping): PROD_ID It's used as a literal join condition. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] Mixing and
Title: [Hibernate] Mixing and yes - i remember some mapping support case that had this. Just cant remember the case ;) /max From: [EMAIL PROTECTED] on behalf of Emmanuel BernardSent: Thu 16-06-2005 20:31To: hibernate-devel@lists.sourceforge.netSubject: [Hibernate] Mixing and Hi guys,Have you ever seen a mix and match between formulas and columns in amapping. foo2 + barThis complexify the annotations (user experience, not the binding code),so I'm wondering whether I should allow this kind of structure or not.Emmanuel ___Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! MessengerTéléchargez cette version sur http://fr.messenger.yahoo.com---SF.Net email is sponsored by: Discover Easy Linux Migration Strategiesfrom IBM. Find simple to follow Roadmaps, straightforward articles,informative Webcasts and more! Get everything you need to get up tospeed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click___hibernate-devel mailing listhibernate-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] Mixing and
Hi guys, Have you ever seen a mix and match between formulas and columns in a mapping. foo2 + bar This complexify the annotations (user experience, not the binding code), so I'm wondering whether I should allow this kind of structure or not. Emmanuel ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: Fw: RE: [Hibernate] Complex class loaders hierarchy
The class loading structure of a j2ee app is vendor specific. For any given component the correct starting point is the thread context class loader. That class loader should have visibility into parent class loaders as needed. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of baliuka juozas > Sent: Thursday, June 16, 2005 12:12 AM > To: [EMAIL PROTECTED]; hibernate-devel@lists.sourceforge.net > Subject: Re: Fw: RE: [Hibernate] Complex class loaders hierarchy > > I do not think it is possible to find the the best way for > this stuff, but we expected hibernate (and cglib) classes > will be in the same or in the parent classloader (asumption > is based on j2ee container class loading stuff). It must be > better to use this asumption, it has more chances to be maintained. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: Fw: RE: [Hibernate] Complex class loaders hierarchy
--- Max Rydahl Andersen <[EMAIL PROTECTED]> wrote: > > > > I do not think it is possible to find the the best > way > > for this stuff, but we expected hibernate (and > cglib) > > classes will be in the same or in the parent > > classloader (asumption is based on j2ee container > > class loading stuff). It must be better to use > this > > asumption, it has more chances to be maintained. > > Well, unfortunately not. > > Our classloading should try to do as ReflectHelper > does. > > look in ctxthread first and then in the class own > classloader. Yes, it is the right way on container ( container will set the right classloader it will be the same as we need ) > > that is the right way to do it in J2EE, not the > other way around. Proxy classloader doe's not conflict with ReflectHelper for very simple reason, it uses domain class loader (domain class is loaded by ReflectHelper). Proxy is defined in the same classloader as domain class. This classloader can be from any context, but it must be the same as application classloader. Package visibility domain classes and mebers can not work in the other way (IllegalAccessError). Cglib and hibernate interfaces are public and this stuff can be in the same or in the parent class loader. > > As I understand it cglib in this case only look in > its own classloader. Class loader is a parameter in cglib, default is a super class loader (it is the right class loader for public and for package visibility classes) > > -max > > > --- "Ivan S. Dubrov" <[EMAIL PROTECTED]> wrote: > > > >> > > >> >cant see your attachement (at netcafe ,), but im > >> quite sure this is not the right solution to this > >> *eclipse* problem ,) > >> > > >> >And I cant recall having this issue when > installing > >> own classloader. > >> > > >> >you should go to eclipse and look for the bug > >> talking about buddy classloading which can handle > >> >this via eclipse classloader madness. > >> > > >> >max > >> > >> No. This is not bug. I understand all Eclipse > >> classloaders "madness". This is feature :) > >> > >> I'll try to describe it again. I do not want make > my > >> entity classes "see" hibernate jar's (because I > want > >> to support pluggable persistence layers, for > example > >> via Hibernate or via JDBC, etc). Saying it > another > >> way, classloader of mine entity classes do not > see > >> hibernate classes - I just _want_ it to be this > way. > >> But when Hibernate generates proxy factory, it > uses > >> default Enhancer "create" method, look at the > >> snippet: > >> > >> return (Factory) Enhancer.create( > >> (interfaces.length==1) ? > >> persistentClass : null, > >> interfaces, > >> NULL_METHOD_INTERCEPTOR > >> ); > >> > >> If you look into the Enhancer source code, you'll > >> see that if classloader was not set explicitly it > >> uses superclass (the class that will be used as > >> superclass for generated proxy) classloader. And > the > >> superclass in this case is mine entity class. So > >> CGLib tries to generate proxy using my entity > >> classloader. But interfaces array contains > >> HibernateProxy interface, and this is class from > >> Hibernate jar, so it is not seen from my entity > >> classloader (this is by desire). So CGLib fails > to > >> generate proxy (with an exception of > >> ClassNotFoundException). > >> > >> That's the problem. I've solved it very simple - > in > >> case of CodeGenerationException thrown from the > >> Enhancer.create(), I call Enhancer again, but > with > >> classloader explicitly set to the > >> Thread.currentThread().getContextClassLoader(). I > >> think this is OK, since ReflectHelper already > uses > >> thread context classloader to load entities > (that's > >> why my entity is loaded by the Hibernate > >> successfully, despite the fact that it is in the > >> different classloader than Hibernate itself). > >> > >> I think the current behaviour of Hibernate is > >> inconsistent - it can load entity classes from > >> unrelated classloader (using the thread context > >> classloader), but it fails to generate proxies > for > >> them (since it requires classloader of entity > >> classes to see HibernateProxy class). > >> > >> The better way, of course, will be the ability to > >> pass Hibernate classloader that will be used both > >> for loading entity and generating proxy for it. > >> > >> > >> > >> > > > --- > >> This SF.Net email is sponsored by: NEC IT Guy > Games. > >> How far can you shotput > >> a projector? How fast can you ride your desk > chair > >> down the office luge track? > >> If you want to score the big prize, get to know > the > >> little guy. > >> Play to win an NEC 61" plasma display: > >> http://www.necitguy.com/?r=20 > >> ___ > >> hibernate-devel mailing list > >> hibernate-devel@lists.sourceforge.net > >> > > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > >> > > > > > >
Re: Fw: RE: [Hibernate] Complex class loaders hierarchy
I do not think it is possible to find the the best way for this stuff, but we expected hibernate (and cglib) classes will be in the same or in the parent classloader (asumption is based on j2ee container class loading stuff). It must be better to use this asumption, it has more chances to be maintained. Well, unfortunately not. Our classloading should try to do as ReflectHelper does. look in ctxthread first and then in the class own classloader. that is the right way to do it in J2EE, not the other way around. As I understand it cglib in this case only look in its own classloader. -max --- "Ivan S. Dubrov" <[EMAIL PROTECTED]> wrote: > >cant see your attachement (at netcafe ,), but im quite sure this is not the right solution to this *eclipse* problem ,) > >And I cant recall having this issue when installing own classloader. > >you should go to eclipse and look for the bug talking about buddy classloading which can handle >this via eclipse classloader madness. > >max No. This is not bug. I understand all Eclipse classloaders "madness". This is feature :) I'll try to describe it again. I do not want make my entity classes "see" hibernate jar's (because I want to support pluggable persistence layers, for example via Hibernate or via JDBC, etc). Saying it another way, classloader of mine entity classes do not see hibernate classes - I just _want_ it to be this way. But when Hibernate generates proxy factory, it uses default Enhancer "create" method, look at the snippet: return (Factory) Enhancer.create( (interfaces.length==1) ? persistentClass : null, interfaces, NULL_METHOD_INTERCEPTOR ); If you look into the Enhancer source code, you'll see that if classloader was not set explicitly it uses superclass (the class that will be used as superclass for generated proxy) classloader. And the superclass in this case is mine entity class. So CGLib tries to generate proxy using my entity classloader. But interfaces array contains HibernateProxy interface, and this is class from Hibernate jar, so it is not seen from my entity classloader (this is by desire). So CGLib fails to generate proxy (with an exception of ClassNotFoundException). That's the problem. I've solved it very simple - in case of CodeGenerationException thrown from the Enhancer.create(), I call Enhancer again, but with classloader explicitly set to the Thread.currentThread().getContextClassLoader(). I think this is OK, since ReflectHelper already uses thread context classloader to load entities (that's why my entity is loaded by the Hibernate successfully, despite the fact that it is in the different classloader than Hibernate itself). I think the current behaviour of Hibernate is inconsistent - it can load entity classes from unrelated classloader (using the thread context classloader), but it fails to generate proxies for them (since it requires classloader of entity classes to see HibernateProxy class). The better way, of course, will be the ability to pass Hibernate classloader that will be used both for loading entity and generating proxy for it. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: Fw: RE: [Hibernate] Complex class loaders hierarchy
I do not think it is possible to find the the best way for this stuff, but we expected hibernate (and cglib) classes will be in the same or in the parent classloader (asumption is based on j2ee container class loading stuff). It must be better to use this asumption, it has more chances to be maintained. --- "Ivan S. Dubrov" <[EMAIL PROTECTED]> wrote: > > > >cant see your attachement (at netcafe ,), but im > quite sure this is not the right solution to this > *eclipse* problem ,) > > > >And I cant recall having this issue when installing > own classloader. > > > >you should go to eclipse and look for the bug > talking about buddy classloading which can handle > >this via eclipse classloader madness. > > > >max > > No. This is not bug. I understand all Eclipse > classloaders "madness". This is feature :) > > I'll try to describe it again. I do not want make my > entity classes "see" hibernate jar's (because I want > to support pluggable persistence layers, for example > via Hibernate or via JDBC, etc). Saying it another > way, classloader of mine entity classes do not see > hibernate classes - I just _want_ it to be this way. > But when Hibernate generates proxy factory, it uses > default Enhancer "create" method, look at the > snippet: > > return (Factory) Enhancer.create( > (interfaces.length==1) ? > persistentClass : null, > interfaces, > NULL_METHOD_INTERCEPTOR > ); > > If you look into the Enhancer source code, you'll > see that if classloader was not set explicitly it > uses superclass (the class that will be used as > superclass for generated proxy) classloader. And the > superclass in this case is mine entity class. So > CGLib tries to generate proxy using my entity > classloader. But interfaces array contains > HibernateProxy interface, and this is class from > Hibernate jar, so it is not seen from my entity > classloader (this is by desire). So CGLib fails to > generate proxy (with an exception of > ClassNotFoundException). > > That's the problem. I've solved it very simple - in > case of CodeGenerationException thrown from the > Enhancer.create(), I call Enhancer again, but with > classloader explicitly set to the > Thread.currentThread().getContextClassLoader(). I > think this is OK, since ReflectHelper already uses > thread context classloader to load entities (that's > why my entity is loaded by the Hibernate > successfully, despite the fact that it is in the > different classloader than Hibernate itself). > > I think the current behaviour of Hibernate is > inconsistent - it can load entity classes from > unrelated classloader (using the thread context > classloader), but it fails to generate proxies for > them (since it requires classloader of entity > classes to see HibernateProxy class). > > The better way, of course, will be the ability to > pass Hibernate classloader that will be used both > for loading entity and generating proxy for it. > > > > --- > This SF.Net email is sponsored by: NEC IT Guy Games. > How far can you shotput > a projector? How fast can you ride your desk chair > down the office luge track? > If you want to score the big prize, get to know the > little guy. > Play to win an NEC 61" plasma display: > http://www.necitguy.com/?r=20 > ___ > hibernate-devel mailing list > hibernate-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
