Below is a printout of another new exception that is thrown intermittently since upgrading NHibernate from 0.9.1 to 1.0.1. Can anyone please shed some light on this? The classes I am trying to load from the db are not abstract, and the same method call that threw this exception often works, so I don't think it's a problem with my code. But I'm eager to learn.

Can anyone help? Thanks in advance.

{"Creating a proxy instance failed"}
[NHibernate.HibernateException]: {"Creating a proxy instance failed"}
Data: {System.Collections.ListDictionaryInternal}
HelpLink: null
InnerException: {"Argument 'baseClass' must be a concrete class"}
Message: "Creating a proxy instance failed"
Source: "NHibernate"
StackTrace: " at NHibernate.Proxy.CastleProxyFactory.GetProxy(Object id, ISessionImplementor session)\r\n at NHibernate.Persister.AbstractEntityPersister.CreateProxy(Object id, ISessionImplementor session)\r\n at NHibernate.Impl.SessionImpl.DoLoadByClass(Type clazz, Object id, Boolean checkDeleted, Boolean allowProxyCreation)\r\n at NHibernate.Impl.SessionImpl.InternalLoad(Type clazz, Object id)\r\n at NHibernate.Type.ManyToOneType.ResolveIdentifier(Object id, ISessionImplementor session)\r\n at NHibernate.Type.EntityType.ResolveIdentifier(Object id, ISessionImplementor session, Object owner)\r\n at NHibernate.Impl.SessionImpl.InitializeEntity(Object obj)\r\n at NHibernate.Loader.Loader.InitializeEntitiesAndCollections(IList hydratedObjects, Object resultSetId, ISessionImplementor session)\r\n at NHibernate.Loader.Loader.DoQuery(ISessionImplementor session, QueryParameters queryParameters, Object optionalObject, Object optionalId, Object[] optionalCollectionKeys, Boolean returnProxies)\r\
n at NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections(ISessionImplementor session, QueryParameters queryParameters, Object optionalObject, Object optionalId, Object[] optionalCollectionKeys, Boolean returnProxies)\r\n at NHibernate.Loader.Loader.LoadCollection(ISessionImplementor session, Object[] ids, IType[] types)\r\n at NHibernate.Loader.Loader.LoadCollection(ISessionImplementor session, Object id, IType type)\r\n at NHibernate.Loader.OneToManyLoader.Initialize(Object id, ISessionImplementor session)\r\n at NHibernate.Collection.AbstractCollectionPersister.Initialize(Object key, ISessionImplementor session)\r\n at NHibernate.Impl.SessionImpl.InitializeCollection(PersistentCollection collection, Boolean writing)\r\n at NHibernate.Collection.PersistentCollection.ForceInitialization()\r\n at NHibernate.Impl.SessionImpl.InitializeNonLazyCollections()\r\n at NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections(ISessionImplementor session, QueryParameters queryParamete
rs, Object optionalObject, Object optionalId, Object[] optionalCollectionKeys, Boolean returnProxies)\r\n at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters)\r\n at NHibernate.Loader.Loader.List(ISessionImplementor session, QueryParameters queryParameters, ISet querySpaces, IType[] resultTypes)\r\n at NHibernate.Hql.QueryTranslator.List(ISessionImplementor session, QueryParameters queryParameters)\r\n at NHibernate.Impl.SessionImpl.Find(String query, QueryParameters parameters)"
TargetSite: {NHibernate.Proxy.INHibernateProxy GetProxy(System.Object, NHibernate.Engine.ISessionImplementor)}

Can you give more details about the query you are running and the mapping of the classes used?

In preparing this response, I found the guilty class. But I don't know why it doesn't work the way I've got designed. Here's the layout:

Mapping file:



Then I have these classes:


Does that help? What am I doing wrong? I found that if I changed the AbstractBase class to be concrete, that the problem went away. But I want the class to be abstract, as it fits the model and forces overriding certain methods. And I'm sure I've seen examples on the Internet of abstract base classes working.

I know what the problem is.
Dynamic Proxy will not let you proxy an abstract class that has abstract method unless you explicitly says that you are willing to handle calls to an abstract method on the proxy in the interceptor level.

I'm not sure how NHibernate can solve the problem, though.

Has anyone looked further at this? Is there a solution to having an abstract class with abstract methods so you don't get these exceptions?

Symon.

I think that using an interface for the proxy might work-around this issue, no?

Hi,

I am new to NHibernate. How can I workaround this issue? Is it by making interface with the same methods as abstract class have and then specify it in mapping file? Or there is something more I must do?

Please can you post simple example?

Thanks. David

Proxying abstract classes should work correctly in NH 1.0.2.

Hey Sergey,

I'm still seeing this problem - I have an abstract class DeliveryDomain which has an abstract method GetInterimReport and a concrete DeliveryProfile class which exposes a property of type DeliveryDomain which should return proxies of DeliveryDomain objects or concrete implementations.

When a proxy is created for the created the following exception is thrown which seems to indicate that there's a problem with abstract methods:



I'm using 1.0.2, so can you suggest anything I might be doing wrong?

Cheers,

Symon.

Interesting. The abstract method was an internal abstract method so on a hunch I changed it to a public abstract method and the exception is no longer thrown.

Is this a bug, or are non-public abstract methods illegal for some reason?

Symon.

Hi Symon,

I think the problem is especially the "internal" visibility, because it is not visible and cannot be overriden outside of your assembly. The protected abstract method will work fine.

Generally, NHibernate itself has a problem with internal methods. It is quite different problem, but look here http://forum.hibernate.org/viewtopic.php?t=958791 and always have on mind that you must think about NHibernate when using internal methods. It's a pitty.

David

Ah, thanks for the feedback David!

Your link got me to thinking...since we're after an internal member because we don't want that member to be visible outside our assembly but proxies are derived classes that need to be able to access the members and they *are* outside the assembly then we need provide for that level of visibility.

Based on that assumption using protected internal abstract (or virtual if they're not abstract) members should do the trick; from my understanding they're accessible from inside all derived classes regardless of whether or not they are in the current assembly and they are otherwise invisible outside the current assembly.

I've not tested this in any detail, but changing the members to protected internal abstract has prevented the exception I was seeing and things *seem* to be working as expected.

I'll post back when I've had a chance to test this properly.

Cheers,

Symon.

Well, it seems to work.

A method exposed using proected internal abstract that is overridden in a derived class can be proxied fine and when the method is called on the proxy from inside the assembly where the class was declared the entity is loaded and the method executed. The method is not visible from outside the assembly, so we seem to get the best of both worlds.

Don't know if the info is of any use to you David, but thanks for making me think about it.

Cheers,

Symon.

Symon,

thanks for info - I did not tried it but as I read your post, I think it wïll also solve my problem :-).

David

In .NET2.0 you can use InternalsVisibleTo assembly-level attribute to allow DynamicProxy access to internal members of your assembly, see DynamicProxy change log for an example (version 1.4.7).