logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (LOG4NET-265) RemoteFileAppender Tests fail on Windows 7
Date Wed, 07 Sep 2011 08:21:10 GMT

     [ https://issues.apache.org/jira/browse/LOG4NET-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Stefan Bodewig resolved LOG4NET-265.
------------------------------------

    Resolution: Fixed

I was at the point of "the first test always fails" without your changes, likely because of
the .NET 4.0 security related changes made to trunk earlier.  It turned out to be a timing
issue and making the tests wait a bit longer fixed the problem.

Tests pass for me using trunk svn revision 1166042.

> RemoteFileAppender Tests fail on Windows 7
> ------------------------------------------
>
>                 Key: LOG4NET-265
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-265
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>         Environment: Windows 7 32bit
>            Reporter: Rob Prouse
>            Priority: Minor
>             Fix For: 1.2.11
>
>         Attachments: log4net-265.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Compiled the version of log4net in the repository and ran the unit tests. All of the
RemotingAppenderTests fail. Enabling internal logging gives the following error.
> log4net:ERROR [RemotingAppender] ErrorCode: GenericFailure. Failed in SendBufferCallback
> System.Runtime.Serialization.SerializationException: Because of security restrictions,
the type System.Runtime.Remoting.ObjRef cannot be accessed. ---> System.Security.SecurityException:
Request failed.
>    at System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(RuntimeType
type)
>    at System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
> The action that failed was:
> Demand
> The type of the first permission that failed was:
> System.Security.Permissions.SecurityPermission
> The first permission that failed was:
> <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
> version="1"
> Flags="Infrastructure"/>
> The demand was for:
> <PermissionSet class="System.Security.PermissionSet"
> version="1">
> <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
> version="1"
> Flags="Infrastructure"/>
> </PermissionSet>
> The only permitted permissions were:
> <PermissionSet class="System.Security.PermissionSet"
> version="1">
> <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
> version="1"
> Flags="SerializationFormatter"/>
> </PermissionSet>
> The method that caused the failure was:
> System.Runtime.Remoting.Channels.ServerProcessing ProcessMessage(System.Runtime.Remoting.Channels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Channels.ITransportHeaders,
System.IO.Stream, System.Runtime.Remoting.Messaging.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Stream ByRef)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message