[rules-dev] Serialization errors; bug JBRULES-2976 filed

[Mark Proctor]

On 16/05/2011 06:14, Mark Proctor wrote:
> Edson applied the pull request and I tweaked it further.
> -this.strategyStore was missing from unmarshall, to make it reflect 
> the patch.
> -MarshallerProviderImpl.newMarshaller should not default to serialized 
> strategy, but instead pass a null strategy. Allowing it to fallback to 
> what's provided in the ksession/enviornment
>
> The behaviour now is that if no strategy is provided it will fallback 
> to what's in the ksession/environment, if one is provided it will 
> always use that for marshalling and unmarshalling. I updated the 
> javadocs on the factory class to reflect this.
I should add that if nothing is specified explicite and nothing can be 
found in the ksession or enviornment, it then fallsback to serialization.

m
>
> Mark
>
> On 21/04/2011 14:07, Laird Nelson wrote:
>> On Thu, Apr 21, 2011 at 1:56 AM, Wolfgang Laun 
>> <wolfgang.laun at gmail.com <mailto:wolfgang.laun at gmail.com>> wrote:
>>
>>     It seems to me that an environment is not the best place for an
>>     operation that
>>     could depend on the session and/or a client's request. It could
>>     be used additionally,
>>     but not without the direct approach.
>>
>>
>> For the record I totally agree.
>>
>> Context, in case it helps: I am in the process of migrating off of a 
>> heavily used stateless session bean that--right now--creates 
>> StatefulKnowledgeSessions and serializes them to the database in 
>> between calls.  I've enabled equality checking (vs. identity 
>> checking) in the knowledge base, but for some reason after about 20 
>> serialization/deserialization cycles the app server runs out of memory.
>>
>> I am assuming that JBRULES-2048 is in play here; I was hoping that by 
>> supplying my own marshalling strategy I could control how the 
>> serialization/deserialization happens and avoid the memory leak.
>>
>> Best,
>> Laird
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110516/5d2f54e2/attachment.html