DynamicProxy2 behavior?

[bittercoder]

Hi All,

I've been having a few issues getting an old Monorail/ActiveRecord
project (which hasn't been touched for about 18 months) updated to
trunk - as mentioned here in this post:

http://groups.google.com/group/castle-project-users/browse_thread/thread/89adf8b29e8b51d1?hl=en

I've figured out that the main issue is that Data Binding is failing,
because a property on the generated Nhibernate proxy has periods in
it's name - the property is called
"NHibernate.Proxy.INHibernateProxy.HibernateLazyInitializer" - this is
confusing the Data Binder, because it assumes there are no periods in
the names of properties - so for example in this method it incorrectly
splits the property name causing a "node is not Composite but still
need to recurse" exception to be thrown.

From Binder/Node.cs:

public Node GetChildNode(String name)
{
int index = name.IndexOf(".");

if (!name2Node.Contains(name) && index != -1)
{
string firstNodeName = name.Substring(0, index);
string remainingName = name.Substring(index + 1);

var innerNode = (Node) name2Node[firstNodeName];

if (innerNode != null && innerNode.NodeType == NodeType.Composite)
{
return (innerNode as CompositeNode).GetChildNode(remainingName);
}

throw new BindingException("node is not Composite but still need to
recurse to {0}", remainingName);
}

return (Node) name2Node[name];
}

I can fix the data binder in this case to deal with the oddly named
parameter - but I'm surprised this hasn't affected anyone else
building MonoRail/ActiveRecord solutions. Thoughts?


Cheers,

- Alex

[G. Richard Bellamy]

I've not run into this. A patch would be really welcome, as I'm
planning on realeasing tomorrow, and I'd love to have this fixed for
the release. Otherwise, I'll work on it tomorrow, if you want to
create a ticket in Donjon.

Sent from my mobile device. Please excuse any errors or omissions.

> --
>
> You received this message because you are subscribed to the Google
> Groups "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com
> .
> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en
> .
>
>

[Krzysztof Koźmic]

The dots are the result of change from few months back, that now all
non-virtually implemented interface members are implemented explicitly,
to allow scenarios where two interfaces have members with the same
signature.
All the tests were passing so I assumed that change did not affect anyone.

Fixing this would be really appreciated, and sorry for the issues. Had
our tests caught it, I would have fixed it myself.

Krzysztof

[Alex Henderson]

Hi All,

Only just got a chance to look at this now - I've got a quick and dirty fix for the problem (below), by changing the ShouldIgnoreProperty(...) method of DataBinder (FYI - I think this would be quite handy as a protected virtual method, so you can enhance the include/exclude property logic).

I'm a little confused though because while trying to write a test case for the Binder project, I created a class implementing an explicit interface which had a single read/write property.  The compiler generates the getter and setter for the explicit interface's property as private (and Final) method's - so the DataBinder never even attempts to bind against these properties, as they're not public (so I couldn't reproduce the error) - but it appears DynamicProxy is generating these methods as public!

At any rate I can provide a test case and fix for the Binder project - but it will require that I extract the call to fetch a types properties  (i.e. PropertyInfo[] props = instanceType.GetProperties(PropertiesBindingFlags)) into a protected virtual method, so I can override it to "simulate" the behavior of dynamic proxy creating public explicit interface property getter/setter methods which get returned with the rest of the public properties.

So... Is there some reason DP is making these explicit interface methods public... Thoughts?

private bool ShouldIgnoreProperty(PropertyInfo prop, string nodeFullName)

{

    // special case for explicitly implemented interface members who are public...

    if (prop.Name.Contains(".")) return true;

bool allowed = true;

bool disallowed = false;

string propId = string.Format("{0}.{1}", nodeFullName, prop.Name);

if (allowedPropertyList != null)

{

allowed = Array.BinarySearch(allowedPropertyList, propId, CaseInsensitiveComparer.Default) >= 0;

}

if (excludedPropertyList != null)

{

disallowed = Array.BinarySearch(excludedPropertyList, propId, CaseInsensitiveComparer.Default) >= 0;

}

return (!allowed) || (disallowed);

}

2009/11/27 Krzysztof Koźmic <krzyszto...@gmail.com>

[Krzysztof Koźmic]

Alex,

thanks for looking into this.

DP is making explicit interface methods private, take a look at
GeneratorUtil.ObtainInterfaceMethodAttributes method

I just ran a test, and it does work as expected:
.method private hidebysig newslot virtual final instance int32
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:2.0.0.0:b77a5c561934e089/System.Int32>
*IOne.OneMethod
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://DynamicProxyGenAssembly2::a621a9e7e5c32e69/Castle.Proxies.IOneProxy/IOne.OneMethod%28%29:Int32>*()
cil managed

Can you create a reproduction where the methods are public? This might
be a DP bug then.

> * // special case for explicitly implemented interface members who
> are public...*
> * if (prop.Name.Contains(".")) return true;*

>
> bool allowed = true;
> bool disallowed = false;
>
> string propId = string.Format("{0}.{1}", nodeFullName, prop.Name);
>
> if (allowedPropertyList != null)
> {
> allowed = Array.BinarySearch(allowedPropertyList, propId,
> CaseInsensitiveComparer.Default) >= 0;
> }
> if (excludedPropertyList != null)
> {
> disallowed = Array.BinarySearch(excludedPropertyList, propId,
> CaseInsensitiveComparer.Default) >= 0;
> }
>
> return (!allowed) || (disallowed);
> }
>

> 2009/11/27 Krzysztof Ko�mic <krzyszto...@gmail.com
> <mailto:krzyszto...@gmail.com>>

> <mailto:castle-pro...@googlegroups.com>.

> > To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com

> <mailto:castle-project-devel%2Bunsu...@googlegroups.com>.

> > For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
> >
> >
> >
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Castle Project Development List" group.
> To post to this group, send email to
> castle-pro...@googlegroups.com

> <mailto:castle-pro...@googlegroups.com>.

> To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com

> <mailto:castle-project-devel%2Bunsu...@googlegroups.com>.

[Alex Henderson]

I'll have a look at this tomorrow and see If I can put together a I repro.

I notice the version of DP2 I have is 2.1.0.6171 - as per the Monorail/Libs folder - I'm wondering if this might be a DP bug that's since been fixed in later revisions - what revision correlates to the DP2 2.1 release?

Guess we'll find out tomorrow when I try making a reproduction of the issue :)

Cheers,

 - Alex

2009/11/29 Krzysztof Koźmic <krzyszto...@gmail.com>

> 2009/11/27 Krzysztof Koźmic <krzyszto...@gmail.com

[Krzysztof Koźmic]

Alex,

v2.1 is rev 5640. Current trunk is 6371, so it may be very well as you said, that it's some issue that we fixed since then.
It would be appreciated if you could verify whether or not this still exists in the trunk so we can fix it before we release v2.2 beta (which I was hoping to do today, but we can postpone it a few days if needed).

cheers,

Krzysztof

Alex Henderson wrote:

I'll have a look at this tomorrow and see If I can put together a I repro.

I notice the version of DP2 I have is�2.1.0.6171 - as per the Monorail/Libs folder - I'm wondering if this might be a DP bug that's since been fixed in later revisions - what revision correlates to the DP2 2.1 release?

Guess we'll find out tomorrow when I try making a reproduction of the issue :)

Cheers,

ďż˝- Alex

2009/11/29 Krzysztof Ko�mic <krzyszto...@gmail.com>

Alex,

thanks for looking into this.

DP is making explicit interface methods private, take a look at
GeneratorUtil.ObtainInterfaceMethodAttributes method

I just ran a test, and it does work as expected:
.method private hidebysig newslot virtual final instance int32
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:2.0.0.0:b77a5c561934e089/System.Int32>
*IOne.OneMethod
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://DynamicProxyGenAssembly2::a621a9e7e5c32e69/Castle.Proxies.IOneProxy/IOne.OneMethod%28%29:Int32>*()
cil managed

Can you create a reproduction where the methods are public? This might
be a DP bug then.

Alex Henderson wrote:
> Hi All,
>
> Only just got a chance to look at this now - I've got a quick and
> dirty fix for the problem (below), by changing the
> ShouldIgnoreProperty(...) method of DataBinder (FYI - I think this
> would be quite handy as a protected virtual method, so you can enhance
> the include/exclude property logic).
>
> I'm a little confused though because while trying to write a test case
> for the Binder project, I created a class implementing an explicit

> interface which had a single read/write property. �The compiler

> generates the getter and setter for the explicit interface's property
> as private (and Final) method's - so the DataBinder never even
> attempts to bind against these properties, as they're not public (so I
> couldn't reproduce the error) - but it appears DynamicProxy is
> generating these methods as public!
>
> At any rate I can provide a test case and fix for the Binder project -
> but it will require that I extract the call to fetch a types

> properties ďż˝(i.e. PropertyInfo[] props =

> instanceType.GetProperties(PropertiesBindingFlags)) into a protected
> virtual method, so I can override it to "simulate" the behavior of
> dynamic proxy creating public explicit interface property
> getter/setter methods which get returned with the rest of the public
> properties.
>
> So... Is there some reason DP is making these explicit interface
> methods public... Thoughts?
>
> private bool ShouldIgnoreProperty(PropertyInfo prop, string nodeFullName)
> {

> * ďż˝ ďż˝// special case for explicitly implemented interface members who
> are public...*
> * � �if (prop.Name.Contains(".")) return true;*

>
> bool allowed = true;
> bool disallowed = false;
>
> string propId = string.Format("{0}.{1}", nodeFullName, prop.Name);
>
> if (allowedPropertyList != null)
> {
> allowed = Array.BinarySearch(allowedPropertyList, propId,
> CaseInsensitiveComparer.Default) >= 0;
> }
> if (excludedPropertyList != null)
> {
> disallowed = Array.BinarySearch(excludedPropertyList, propId,
> CaseInsensitiveComparer.Default) >= 0;
> }
>
> return (!allowed) || (disallowed);
> }
>

> 2009/11/27 Krzysztof Ko�mic <krzyszto...@gmail.com

> <mailto:krzyszto...@gmail.com>>

>
> ďż˝ ďż˝ The dots are the result of change from few months back, that now all
> ďż˝ ďż˝ non-virtually implemented interface members are implemented
> ďż˝ ďż˝ explicitly,
> ďż˝ ďż˝ to allow scenarios where two interfaces have members with the same
> ďż˝ ďż˝ signature.
> ďż˝ ďż˝ All the tests were passing so I assumed that change did not affect
> ďż˝ ďż˝ anyone.
>
> ďż˝ ďż˝ Fixing this would be really appreciated, and sorry for the issues. Had
> ďż˝ ďż˝ our tests caught it, I would have fixed it myself.
>
> ďż˝ ďż˝ Krzysztof
>
> ďż˝ ďż˝ bittercoder wrote:
> ďż˝ ďż˝ > Hi All,
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > I've been having a few issues getting an old Monorail/ActiveRecord
> ďż˝ ďż˝ > project (which hasn't been touched for about 18 months) updated to
> ďż˝ ďż˝ > trunk - as mentioned here in this post:
> ďż˝ ďż˝ >
> ďż˝ ďż˝ >
> ďż˝ ďż˝ http://groups.google.com/group/castle-project-users/browse_thread/thread/89adf8b29e8b51d1?hl=en
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > I've figured out that the main issue is that Data Binding is
> ďż˝ ďż˝ failing,
> ďż˝ ďż˝ > because a property on the generated Nhibernate proxy has periods in
> ďż˝ ďż˝ > it's name - the property is called
> ďż˝ ďż˝ > "NHibernate.Proxy.INHibernateProxy.HibernateLazyInitializer" -
> ďż˝ ďż˝ this is
> ďż˝ ďż˝ > confusing the Data Binder, because it assumes there are no
> ďż˝ ďż˝ periods in
> ďż˝ ďż˝ > the names of properties - so for example in this method it
> ďż˝ ďż˝ incorrectly
> ďż˝ ďż˝ > splits the property name causing a "node is not Composite but still
> ďż˝ ďż˝ > need to recurse" exception to be thrown.
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > From Binder/Node.cs:
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > public Node GetChildNode(String name)
> ďż˝ ďż˝ > {
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ int index = name.IndexOf(".");
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ if (!name2Node.Contains(name) && index != -1)
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ {
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ string firstNodeName = name.Substring(0, index);
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ string remainingName = name.Substring(index + 1);
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ var innerNode = (Node) name2Node[firstNodeName];
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ if (innerNode != null && innerNode.NodeType ==
> ďż˝ ďż˝ NodeType.Composite)
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ {
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ return (innerNode as
> ďż˝ ďż˝ CompositeNode).GetChildNode(remainingName);
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ }
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ ďż˝ throw new BindingException("node is not Composite
> ďż˝ ďż˝ but still need to
> ďż˝ ďż˝ > recurse to {0}", remainingName);
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ }
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > ďż˝ ďż˝ ďż˝ return (Node) name2Node[name];
> ďż˝ ďż˝ > }
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > I can fix the data binder in this case to deal with the oddly named
> ďż˝ ďż˝ > parameter - but I'm surprised this hasn't affected anyone else
> � � > building MonoRail/ActiveRecord solutions. �Thoughts?
> ďż˝ ďż˝ >
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > Cheers,
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > ďż˝- Alex
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > --
> ďż˝ ďż˝ >
> ďż˝ ďż˝ > You received this message because you are subscribed to the
> ďż˝ ďż˝ Google Groups "Castle Project Development List" group.
> ďż˝ ďż˝ > To post to this group, send email to
> ďż˝ ďż˝ castle-pro...@googlegroups.com

> ďż˝ ďż˝ <mailto:castle-pro...@googlegroups.com>.

> ďż˝ ďż˝ > To unsubscribe from this group, send email to
> ďż˝ ďż˝ castle-project-d...@googlegroups.com

> ďż˝ ďż˝ <mailto:castle-project-devel%2Bunsu...@googlegroups.com>.

> ďż˝ ďż˝ > For more options, visit this group at
> ďż˝ ďż˝ http://groups.google.com/group/castle-project-devel?hl=en.
> ďż˝ ďż˝ >
> ďż˝ ďż˝ >
> ďż˝ ďż˝ >
>
> ďż˝ ďż˝ --
>
> ďż˝ ďż˝ You received this message because you are subscribed to the Google
> ďż˝ ďż˝ Groups "Castle Project Development List" group.
> ďż˝ ďż˝ To post to this group, send email to
> ďż˝ ďż˝ castle-pro...@googlegroups.com

> ďż˝ ďż˝ <mailto:castle-pro...@googlegroups.com>.

> ďż˝ ďż˝ To unsubscribe from this group, send email to
> ďż˝ ďż˝ castle-project-d...@googlegroups.com

> ďż˝ ďż˝ <mailto:castle-project-devel%2Bunsu...@googlegroups.com>.

> ďż˝ ďż˝ For more options, visit this group at
> ďż˝ ďż˝ http://groups.google.com/group/castle-project-devel?hl=en.

>
>
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Castle Project Development List" group.
> To post to this group, send email to
> castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

[Alex Henderson]

Hi Krzysztof,

I have tested against trunk versions of Core & DP2 - all works without problems.

So it looks to be a non-issue if you use trunk - just don't use the version of DP2 that comes in the Monorail/lib/net-3.5 or ActiveRecord/lib/net3.5/ folders like I did :) - I'm guessing once 2.2 is released then ActiveRecord/Monorail will get updated as well?

As an aside, I know it's not all that relevant when using the Binder with Monorail - but when using LinFu proxy v1.0.3 - instead of DP2 - the binder throws the exception (below).

I'm guessing this is a bug with the NHibernate LinFu proxy generator - when I get some time I might look into it further... 

Cheers,

 - Alex

Castle.MonoRail.Framework.MonoRailException: Error processing MonoRail request. Action Save on controller Product ---> Castle.MonoRail.Framework.MonoRailException: Error building method arguments. Last param analyzed was product with value '' ---> Castle.Components.Binder.BindingException: Unexpected item on the stack: found Seller, expecting Product

   at Castle.Components.Binder.DataBinder.PopInstance(Object instance, String prefix)

   at Castle.MonoRail.ActiveRecordSupport.ARDataBinder.PopInstance(Object instance, String prefix)

   at Castle.Components.Binder.DataBinder.InternalRecursiveBindObjectInstance(Object instance, String prefix, CompositeNode node)

   at Castle.Components.Binder.DataBinder.InternalRecursiveBindObjectInstance(Object instance, String prefix, Node node)

   at Castle.Components.Binder.DataBinder.InternalBindObject(Type instanceType, String paramPrefix, Node node, Boolean& succeeded)

   at Castle.Components.Binder.DataBinder.InternalBindObject(Type instanceType, String paramPrefix, Node node)

   at Castle.Components.Binder.DataBinder.BindObject(Type targetType, String prefix, String excludedProperties, String allowedProperties, CompositeNode treeRoot)

   at Castle.MonoRail.ActiveRecordSupport.ARDataBinder.BindObject(Type targetType, String prefix, String exclude, String allow, String expect, CompositeNode treeRoot)

   at Castle.MonoRail.ActiveRecordSupport.ARDataBindAttribute.Bind(IEngineContext context, IController controller, IControllerContext controllerContext, ParameterInfo parameterInfo)

   at Castle.MonoRail.Framework.SmartDispatcherController.BuildMethodArguments(ParameterInfo[] parameters, IRequest request, IDictionary`2 actionArgs)

   --- End of inner exception stack trace ---

   at Castle.MonoRail.Framework.SmartDispatcherController.BuildMethodArguments(ParameterInfo[] parameters, IRequest request, IDictionary`2 actionArgs)

   at Castle.MonoRail.Framework.ExtJSController.InvokeMethod(MethodInfo method, IRequest request, IDictionary`2 actionArgs) in C:\dev\Projects\Catch\EnterpriseTester\app\src\MonoRail.ModuleFramework\ExtJS\ExtJSController.cs:line 181

   at Castle.MonoRail.Framework.ActionMethodExecutorCompatible.Execute(IEngineContext engineContext, IController controller, IControllerContext context)

   at Castle.MonoRail.Framework.Controller.RunActionAndRenderView()

   at Castle.MonoRail.Framework.Controller.Process(IEngineContext engineContext, IControllerContext context)

   at Castle.MonoRail.Framework.BaseHttpHandler.Process(HttpContext context)

   --- End of inner exception stack trace ---

   at Castle.MonoRail.Framework.BaseHttpHandler.Process(HttpContext context)

   at Castle.MonoRail.Framework.BaseHttpHandler.ProcessRequest(HttpContext context)

   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

2009/11/29 Krzysztof Koźmic <krzyszto...@gmail.com>

Alex,

v2.1 is rev 5640. Current trunk is 6371, so it may be very well as you said, that it's some issue that we fixed since then.
It would be appreciated if you could verify whether or not this still exists in the trunk so we can fix it before we release v2.2 beta (which I was hoping to do today, but we can postpone it a few days if needed).

cheers,

Krzysztof

Alex Henderson wrote:

I'll have a look at this tomorrow and see If I can put together a I repro.

I notice the version of DP2 I have is 2.1.0.6171 - as per the Monorail/Libs folder - I'm wondering if this might be a DP bug that's since been fixed in later revisions - what revision correlates to the DP2 2.1 release?

Guess we'll find out tomorrow when I try making a reproduction of the issue :)

Cheers,

 - Alex

2009/11/29 Krzysztof Koźmic <krzyszto...@gmail.com>

Alex,

thanks for looking into this.

DP is making explicit interface methods private, take a look at
GeneratorUtil.ObtainInterfaceMethodAttributes method

I just ran a test, and it does work as expected:
.method private hidebysig newslot virtual final instance int32
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:2.0.0.0:b77a5c561934e089/System.Int32>
*IOne.OneMethod
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://DynamicProxyGenAssembly2::a621a9e7e5c32e69/Castle.Proxies.IOneProxy/IOne.OneMethod%28%29:Int32>*()
cil managed

Can you create a reproduction where the methods are public? This might
be a DP bug then.

Alex Henderson wrote:
> Hi All,
>
> Only just got a chance to look at this now - I've got a quick and
> dirty fix for the problem (below), by changing the
> ShouldIgnoreProperty(...) method of DataBinder (FYI - I think this
> would be quite handy as a protected virtual method, so you can enhance
> the include/exclude property logic).
>
> I'm a little confused though because while trying to write a test case
> for the Binder project, I created a class implementing an explicit

> interface which had a single read/write property.  The compiler

> generates the getter and setter for the explicit interface's property
> as private (and Final) method's - so the DataBinder never even
> attempts to bind against these properties, as they're not public (so I
> couldn't reproduce the error) - but it appears DynamicProxy is
> generating these methods as public!
>
> At any rate I can provide a test case and fix for the Binder project -
> but it will require that I extract the call to fetch a types

> properties  (i.e. PropertyInfo[] props =

> instanceType.GetProperties(PropertiesBindingFlags)) into a protected
> virtual method, so I can override it to "simulate" the behavior of
> dynamic proxy creating public explicit interface property
> getter/setter methods which get returned with the rest of the public
> properties.
>
> So... Is there some reason DP is making these explicit interface
> methods public... Thoughts?
>
> private bool ShouldIgnoreProperty(PropertyInfo prop, string nodeFullName)
> {

> *    // special case for explicitly implemented interface members who
> are public...*
> *    if (prop.Name.Contains(".")) return true;*

>
> bool allowed = true;
> bool disallowed = false;
>
> string propId = string.Format("{0}.{1}", nodeFullName, prop.Name);
>
> if (allowedPropertyList != null)
> {
> allowed = Array.BinarySearch(allowedPropertyList, propId,
> CaseInsensitiveComparer.Default) >= 0;
> }
> if (excludedPropertyList != null)
> {
> disallowed = Array.BinarySearch(excludedPropertyList, propId,
> CaseInsensitiveComparer.Default) >= 0;
> }
>
> return (!allowed) || (disallowed);
> }
>

> 2009/11/27 Krzysztof Koźmic <krzyszto...@gmail.com

> <mailto:krzyszto...@gmail.com>>

>
>     The dots are the result of change from few months back, that now all

>     non-virtually implemented interface members are implemented

>     explicitly,

>     to allow scenarios where two interfaces have members with the same

>     signature.

>     All the tests were passing so I assumed that change did not affect

>     anyone.

>
>     Fixing this would be really appreciated, and sorry for the issues. Had

>     our tests caught it, I would have fixed it myself.
>

>     Krzysztof
>
>     bittercoder wrote:
>     > Hi All,
>     >

>     > I've been having a few issues getting an old Monorail/ActiveRecord

>     > project (which hasn't been touched for about 18 months) updated to

>     > trunk - as mentioned here in this post:
>     >
>     >

>     http://groups.google.com/group/castle-project-users/browse_thread/thread/89adf8b29e8b51d1?hl=en

>     >
>     > I've figured out that the main issue is that Data Binding is

>     failing,

>     > because a property on the generated Nhibernate proxy has periods in

>     > it's name - the property is called

>     > "NHibernate.Proxy.INHibernateProxy.HibernateLazyInitializer" -
>     this is

>     > confusing the Data Binder, because it assumes there are no

>     periods in

>     > the names of properties - so for example in this method it

>     incorrectly

>     > splits the property name causing a "node is not Composite but still

>     > need to recurse" exception to be thrown.
>     >

>     > From Binder/Node.cs:
>     >
>     > public Node GetChildNode(String name)
>     > {

>     >       int index = name.IndexOf(".");
>     >

>     >       if (!name2Node.Contains(name) && index != -1)

>     >       {

>     >               string firstNodeName = name.Substring(0, index);

>     >               string remainingName = name.Substring(index + 1);
>     >

>     >               var innerNode = (Node) name2Node[firstNodeName];
>     >

>     >               if (innerNode != null && innerNode.NodeType ==

>     NodeType.Composite)
>     >               {
>     >                       return (innerNode as
>     CompositeNode).GetChildNode(remainingName);
>     >               }
>     >

>     >               throw new BindingException("node is not Composite

>     but still need to

>     > recurse to {0}", remainingName);
>     >       }
>     >

>     >       return (Node) name2Node[name];

>     > }
>     >
>     > I can fix the data binder in this case to deal with the oddly named

>     > parameter - but I'm surprised this hasn't affected anyone else

>     > building MonoRail/ActiveRecord solutions.  Thoughts?
>     >
>     >
>     > Cheers,
>     >
>     >  - Alex
>     >

>     > --
>     >
>     > You received this message because you are subscribed to the
>     Google Groups "Castle Project Development List" group.
>     > To post to this group, send email to
>     castle-pro...@googlegroups.com

>     <mailto:castle-pro...@googlegroups.com>.

>     > To unsubscribe from this group, send email to

>     castle-project-d...@googlegroups.com

>     <mailto:castle-project-devel%2Bunsu...@googlegroups.com>.

>     > For more options, visit this group at
>     http://groups.google.com/group/castle-project-devel?hl=en.
>     >
>     >
>     >
>
>     --
>
>     You received this message because you are subscribed to the Google
>     Groups "Castle Project Development List" group.
>     To post to this group, send email to
>     castle-pro...@googlegroups.com

>     <mailto:castle-pro...@googlegroups.com>.

>     To unsubscribe from this group, send email to

>     castle-project-d...@googlegroups.com

>     <mailto:castle-project-devel%2Bunsu...@googlegroups.com>.

[Krzysztof Koźmic]

Alex,

Cool, so I'm gonna scrape this.
I suggested other project leaders to do a .0.1 release when we push new
DP, but its up to them.

About LinFu, you may be right that it's possible it's its bug. LinFu is
much less mature than Castle DP.
If you get to the bottom to it, and it turns out to be Castle issue,
it'll get proper attention :)

cheers,

Krzysztof

PS

how is your Windsor series going?

> 2009/11/29 Krzysztof Ko�mic <krzyszto...@gmail.com
> <mailto:krzyszto...@gmail.com>>

>
> Alex,
>
> v2.1 is rev 5640. Current trunk is 6371, so it may be very well as
> you said, that it's some issue that we fixed since then.
> It would be appreciated if you could verify whether or not this
> still exists in the trunk so we can fix it before we release v2.2
> beta (which I was hoping to do today, but we can postpone it a few
> days if needed).
>
> cheers,
>
> Krzysztof
>
>
> Alex Henderson wrote:
>> I'll have a look at this tomorrow and see If I can put together a
>> I repro.
>>
>> I notice the version of DP2 I have is 2.1.0.6171 - as per the
>> Monorail/Libs folder - I'm wondering if this might be a DP bug
>> that's since been fixed in later revisions - what revision
>> correlates to the DP2 2.1 release?
>>
>> Guess we'll find out tomorrow when I try making a reproduction of
>> the issue :)
>>
>> Cheers,
>>
>> - Alex
>>

>> 2009/11/29 Krzysztof Ko�mic <krzyszto...@gmail.com
>> <mailto:krzyszto...@gmail.com>>

>> > 2009/11/27 Krzysztof Ko�mic <krzyszto...@gmail.com
>> <mailto:krzyszto...@gmail.com>

>> > <mailto:krzyszto...@gmail.com

>> > <mailto:castle-pro...@googlegroups.com

>> <mailto:castle-pro...@googlegroups.com>>.
>> > > To unsubscribe from this group, send email to
>> > castle-project-d...@googlegroups.com
>> <mailto:castle-project-devel%2Bunsu...@googlegroups.com>
>> >

>> <mailto:castle-project-devel%2Bunsu...@googlegroups.com
>> <mailto:castle-project-devel%252Buns...@googlegroups.com>>.

>> > > For more options, visit this group at
>> > http://groups.google.com/group/castle-project-devel?hl=en.
>> > >
>> > >
>> > >
>> >
>> > --
>> >
>> > You received this message because you are subscribed to
>> the Google
>> > Groups "Castle Project Development List" group.
>> > To post to this group, send email to
>> > castle-pro...@googlegroups.com
>> <mailto:castle-pro...@googlegroups.com>

>> > <mailto:castle-pro...@googlegroups.com

>> <mailto:castle-pro...@googlegroups.com>>.
>> > To unsubscribe from this group, send email to
>> > castle-project-d...@googlegroups.com
>> <mailto:castle-project-devel%2Bunsu...@googlegroups.com>
>> >

>> <mailto:castle-project-devel%2Bunsu...@googlegroups.com
>> <mailto:castle-project-devel%252Buns...@googlegroups.com>>.

>> <mailto:castle-project-d...@googlegroups.com>.