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

[Mark Proctor]

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.

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

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