Hi all It may be a very big breaking change!
Best Regards, Alex 2012/11/28 Patrick Earl <[email protected]> > This sounds like a better alternative to me... what think others? > > > On Tue, Nov 27, 2012 at 7:16 AM, Fabian Schmied > <[email protected]>wrote: > >> Just a comment: you could use >> System.Runtime.Serialization.FormatterServices.GetUninitializedObject >> to create an instantiate a type (verifiably) without calling its >> constructor. >> >> On Tuesday, November 27, 2012 9:24:30 AM UTC+1, Richard (gmail) wrote: >> >>> Hi Patrick, >>> >>> I made the change to make the generated assemblies pass PeVerify: >>> https://nhibernate.jira.com/**browse/NH-2857<https://nhibernate.jira.com/browse/NH-2857> >>> >>> >>> I’d agree with the argument that the (default) constructor that NH uses >>> shouldn’t be doing anything unusual, but obviously we can’t enforce that. >>> >>> If there is now a situation that we can get a stack overflow using >>> (just) NHibernateUtil.IsInitialized, then that should probably be fixed. >>> I’m not so sure about casting the object directly to an IProxy and relying >>> on the underlying implementation of Interceptors though – it’s not clear to >>> me how someone would decide what is acceptable/reasonable external >>> behaviour for that. In addition, I think the original Castle proxy would >>> have behaved like this too? >>> >>> Also, if you mark the default constructor as private, then the proxy has >>> no choice but to bypass it (and behave the way it did prior to that fix). >>> Does that help? >>> >>> Cheers, >>> Richard >>> >>> >>> *From:* Patrick Earl >>> *Sent:* Tuesday, November 27, 2012 4:57 AM >>> *To:* nhibernate-development >>> *Subject:* [nhibernate-development] Calling base constructor in proxies >>> >>> I noticed (due to a stack overflow) that proxies now call their base >>> constructor. That behaviour is a little scary to me since proxies are not >>> real objects and the real objects might have interaction with the world >>> that isn't supposed to happen with proxy objects. I suppose the argument >>> could be made that the constructor should not be doing anything remotely >>> interesting, but on the other hand, constructors should produce objects >>> that don't need additional initialization. >>> >>> The stack overflow itself was from an interesting combination of changes >>> in the latest NH. First, it calls the base constructor. Second, the >>> dynamic proxy was changed to call "base.Method()" if the interceptor was >>> not set. Since there is no "base.Method()" I assume that it ends up >>> calling the same method again, resulting in the mysterious stack overflow. >>> >>> Basically my code was doing something like NHibernateUtil.IsInitialized( >>> **a) and when it went to get the HibernateLazyInitializer property it >>> overflowed the stack. I ended up fixing this by changing my condition as >>> follows: >>> >>> a is IProxy && (a as IProxy).Interceptor != null && >>> NHibernateUtil.IsInitialized(**a) >>> >>> Perhaps the code to check for uninitialized proxies inside of >>> NHibernateUtil needs to be improved. Perhaps a flag could be present to >>> disable calling the base constructor when not needed for a medium trust >>> environment. Thoughts on this interesting situation? Has anyone else run >>> into problems related to calling the base constructor? >>> >>> Patrick Earl >>> >> >> On Tuesday, November 27, 2012 9:24:30 AM UTC+1, Richard (gmail) wrote: >>> >>> Hi Patrick, >>> >>> I made the change to make the generated assemblies pass PeVerify: >>> https://nhibernate.jira.com/**browse/NH-2857<https://nhibernate.jira.com/browse/NH-2857> >>> >>> I’d agree with the argument that the (default) constructor that NH uses >>> shouldn’t be doing anything unusual, but obviously we can’t enforce that. >>> >>> If there is now a situation that we can get a stack overflow using >>> (just) NHibernateUtil.IsInitialized, then that should probably be fixed. >>> I’m not so sure about casting the object directly to an IProxy and relying >>> on the underlying implementation of Interceptors though – it’s not clear to >>> me how someone would decide what is acceptable/reasonable external >>> behaviour for that. In addition, I think the original Castle proxy would >>> have behaved like this too? >>> >>> Also, if you mark the default constructor as private, then the proxy has >>> no choice but to bypass it (and behave the way it did prior to that fix). >>> Does that help? >>> >>> Cheers, >>> Richard >>> >>> >>> *From:* Patrick Earl >>> *Sent:* Tuesday, November 27, 2012 4:57 AM >>> *To:* nhibernate-development >>> *Subject:* [nhibernate-development] Calling base constructor in proxies >>> >>> I noticed (due to a stack overflow) that proxies now call their base >>> constructor. That behaviour is a little scary to me since proxies are not >>> real objects and the real objects might have interaction with the world >>> that isn't supposed to happen with proxy objects. I suppose the argument >>> could be made that the constructor should not be doing anything remotely >>> interesting, but on the other hand, constructors should produce objects >>> that don't need additional initialization. >>> >>> The stack overflow itself was from an interesting combination of changes >>> in the latest NH. First, it calls the base constructor. Second, the >>> dynamic proxy was changed to call "base.Method()" if the interceptor was >>> not set. Since there is no "base.Method()" I assume that it ends up >>> calling the same method again, resulting in the mysterious stack overflow. >>> >>> Basically my code was doing something like NHibernateUtil.IsInitialized( >>> **a) and when it went to get the HibernateLazyInitializer property it >>> overflowed the stack. I ended up fixing this by changing my condition as >>> follows: >>> >>> a is IProxy && (a as IProxy).Interceptor != null && >>> NHibernateUtil.IsInitialized(**a) >>> >>> Perhaps the code to check for uninitialized proxies inside of >>> NHibernateUtil needs to be improved. Perhaps a flag could be present to >>> disable calling the base constructor when not needed for a medium trust >>> environment. Thoughts on this interesting situation? Has anyone else run >>> into problems related to calling the base constructor? >>> >>> Patrick Earl >>> >> >
