On 20/04/2011 22:19, ljnelson wrote: > I filed a pull request to fix this issue: > https://github.com/droolsjbpm/drools/pull/7 I just checked the code and it seems we have two conflict approaches. So currently the method you are replacing calls: public ObjectMarshallingStrategyStore getObjectMarshallingStrategyStore() { if ( this.marshallingStore == null ) { this.marshallingStore = new ObjectMarshallingStrategyStore( (ObjectMarshallingStrategy[]) this.environment.get( EnvironmentName.OBJECT_MARSHALLING_STRATEGIES ) ); } return this.marshallingStore; } Notice it uses the environment. That means you must inject yoru strategies into the ENV and they will get picked up. But on the other hand we clearly made strategies part of the MarshallingConfiguration which is a member field on DefaultMarshaller and currently being ignored. I'm not sure why we have both at this stage, will need to sleep on it to refresh my mind on the best way forward. Mark > Best, > Laird > > -- > View this message in context: http://drools.46999.n3.nabble.com/Serialization-errors-bug-JBRULES-2976-f... > Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com. > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

On Thu, Apr 21, 2011 at 1:56 AM, Wolfgang Laun <wolfgang.laun(a)gmail.com <mailto:wolfgang.laun@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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