lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: Lucene.Net 3.0.3 and medium trust
Date Tue, 14 Aug 2012 16:16:27 GMT
We should probably try and have unit tests that will spin up medium
trust app domains and run some basic tests in them, so we don't
accidentally ship with something big like this.  That is what I
initially tried to do to reproduce this bug on my end, but the code
that I would which should have created a medium trust app domain
wasn't working.  I had to create an ASP.NET project and give it medium
trust to repro.  I'm sure there's a way to do it, though.


Thanks,
Christopher

On Tue, Aug 14, 2012 at 9:08 AM, Christopher Currens
<currens.chris@gmail.com> wrote:
> Inheriting from WeakReference was the problem.  I'm just going to
> remove the wrapper entirely, it doesn't give us any real benefit.  The
> code has already been pushed.
>
>
> Thanks,
> Christopher
>
> On Tue, Aug 14, 2012 at 8:46 AM, Prescott Nasser <geobmx540@hotmail.com> wrote:
>> It'd be nice to understand where this issue is coming from as it wasn't in 2.9.4
rather than jumping to a quick fix imo. I'll dig a bit myself
>> ~P
>>
>>> Date: Tue, 14 Aug 2012 17:32:29 +0200
>>> From: sisve@devhost.se
>>> To: lucene-net-dev@lucene.apache.org
>>> Subject: Re: Lucene.Net 3.0.3 and medium trust
>>>
>>> Hi,
>>>
>>> It got worse. Building a custom AttributeFactory can only handle a few
>>> cases, I needed to subclass _every_ TokenStream/TokenFilter to override
>>> all attribute-handling methods (AddAttribute, GetAttribute, etc), and
>>> all analyzers to use these streams, to use a dictionary with strong
>>> references just for medium trust... I gave up before doing that. ;)
>>>
>>> Is there any use cases where we need to garbage collect attributes
>>> before the stream/attribute source is closed? Changing to a normal
>>> dictionary seems like a quick fix.
>>>
>>> // Simon
>>>
>>>
>>> On 2012-08-14 17:21, Christopher Currens wrote:
>>> > It must be something we've missed, as we want to target medium trust
>>> > locations in the future.  I can't think of anything off the top of my
>>> > head that would require medium trust, though, let alone unmanaged
>>> > code.  I'll dive into this.
>>> >
>>> >
>>> > Thanks,
>>> > Christopher
>>> >
>>> > On Mon, Aug 13, 2012 at 10:01 PM, Simon Svensson <sisve@devhost.se>
wrote:
>>> >> Hi,
>>> >>
>>> >> I'm having trouble upgrading a web application running under medium
trust
>>> >> from 2.9.4 to 3.0.3. Code that previously worked now throws a
>>> >> SecurityException.
>>> >>
>>> >> [SecurityException: Request for the permission of type
>>> >> 'System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0,
>>> >> Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
>>> >>     Lucene.Net.Support.WeakKey`1..ctor(T key) +0
>>> >>     Lucene.Net.Support.WeakDictionary`2.get_Item(TKey key) +113
>>> >>     Lucene.Net.Util.DefaultAttributeFactory.GetClassForInterface() +178
>>> >>     Lucene.Net.Util.DefaultAttributeFactory.CreateAttributeInstance()
+95
>>> >>     Lucene.Net.Util.AttributeSource.AddAttribute() +375
>>> >>     Lucene.Net.Analysis.CharTokenizer..ctor(TextReader input) +126
>>> >>     Lucene.Net.Analysis.WhitespaceTokenizer..ctor(TextReader in) +37
>>> >>
>>> >>
>>> >> The DefaultAttributeFactory, via WeakReference, requires
>>> >> SecurityPermissionFlag.UnmanagedCode which is not present under medium
>>> >> trust. There's an AttributeFactory.DEFAULT_ATTRIBUTE_FACTORY which I
could
>>> >> to replace the DefaultAttributeFactory, but it's readonly. I'm rewriting
my
>>> >> code to call the constructor overload (on tokenizers) accepting an
>>> >> AttributeFactory, but this means that I cannot use any existing Analyzer
>>> >> since they don't provide an extension points to change the AttributeFactory.
>>> >>
>>> >> Is medium trust [using default classes] dropped in 3.0.3, or is this
>>> >> something we've missed?
>>> >>
>>> >> // Simon
>>>
>>

Mime
View raw message