btw SyncrhonisedWorkingMemory used the same interface as WorkingMemory.
StatefulSession just extends WorkingMemory, so the API change for you
should be minimal.
Mark
Mark Proctor wrote:
Arjun,
3.1 was never a final release, it was a milestone release, 4.0 MR2 is
just a continuation of this, the api and language won't fully
stabalise and you can expect bugs unil we do a candidate release.
ShadowFacts were finished and shouldn't be visible to the user,
however code generation in Java has known problems - which hibernate
proxies also suffer from - where classes must have a default
constructor and must not use the final modifier. Thanks to Objenesis,
http://objenesis.googlecode.com/svn/docs/index.html, M2 was able to
get over the default constructor limitation, but there is nothing we
can do about final. The work towards allowing ShadowFacts to be
optional is additional to this, i.e. its a new feature. As said before
these are milestone releases, aimed to give you a "snapshot" at our
R&D progress, we give no guarantees and you must expect rough edges
and big changes - the rewards are you help us make a much better 4.0
final release.
Backwards compatability is always an issue, but that's why we did the
version number change, we believe the changes and the advantages
gained make this worth while.
Mark
Arjun Dhar wrote:
> Mark Proctor <mproctor <at> codehaus.org> writes:
>
>
>> Sorry thats the stateful working memory interface, StatefulSession -
>> just incase my opening paragraph confuses anyone.
>> Mark Proctor wrote:
>>
>
>
> Hi Appreciate the quick response and accept all that is written; as for 1 and
> 3.2.
>
> TECHNICAL
> ================================
> [1]
> "Can you show me a use case where you neeed
>
>> access to the WorkingMemory from a StatelessSession"
>>
> ... Conceptually No, since you have it covered by allowing a person to Assert a
> list at a time (Faster when doing Batch mode; this is what I was doing) ,
> except had built a wrapper method On the 'WorkingMemory' to achieve this. So
> will just have to do re-factoring to my code which again will not be backward
> compatible.
>
> ..So to summarize: Code written for JBoss Rules 4 may not work for 3.0 and 3.1.
> If that isnt and enginerring issue then kindly ignore.
>
> [3.2]
> Suggestion:: If Shadows are not fully implemented then they should be
> encapsulated and not be visible to users. From porting from 3.0 to 3.1 a
> NullPointerException due to a feature not to be delivered, can be considered a
> bug. From a blind QA perspective 3.2 is a bug!
>
>
> ROOT CAUSE
> ================================
> ... I think if we look at both these points and from a project level, there is
> an issue of Backward Compatibility. I guess you guys have your hands full to
> care about that.
>
> ...But seriously, I understand the constraints you guys have to work with :o)
> but wanted to let you know that while I'm a critic (hope am not being picky)
> I'm also a big fan on what
> is being built.
>
> Thanks again!
> Arjun
>
>
>
> _______________________________________________
> 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