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.l...@gmail.com <mailto:wolfgang.l...@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
