Re: [rules-dev] Why are fundamental API functions not part of "stable"?
Apart from the considerations concerning of the "old user base", I
could very well imagine that exposing certain technical
implementation-dependent details is to be avoided. Therefore, I
emphasized the point that there is a "stable" Activation and an access
to Agenda. All that's missing is a getter for the current conflict
set. I doubt very much that you'll do away with that in near or far
future.
I'm currently developing a general purpose event-logging and
peek-into-the-engine package, so I think this constitutes a valid "use
case", in the sense you wrote.
-W
On 09/08/2010, Mark Proctor <mproctor(a)codehaus.org> wrote:
On 09/08/2010 09:58, Wolfgang Laun wrote:
> Trying to provide some debugging functions, I find that
> org.drools.runtime.rule.WorkingMemory (a "stable" interface) lets you
> retrieve
> org.drools.runtime.rule.Agenda (another "stable" interface). But this
> one does not provide access to the current set of Activation objects.
>
> In contrast to this, org.drools.Agenda, which is part of the
> "unstable" Core API, does provide Activation[] getActivations().
We plan to refactor the entire of drools-core and drools-compiler to
reflect drools-api more, so it'll all change. We couldn't do this in one
go, as many people where already using those interfacaes and
implementations; including some JBoss projects.
So instead we decided to introduce a new cleaner api that is knowledge
oriented, rather than rules oriented, and have that wrap the old api. So
that we could move forward with a new api, while not upsetting any of
our old user base, giving them time to move across.
We have taken a very conservative approach with drools-api minimising
what we expose. We instead prefer to wait for valid use cases to
determine what we expose, rather than exposing wait for those use cases
to arise. The reason for this is that the more you expose the harder it
is to change a library over time, due to backwards compatability. So the
conservative aspect gives us more flexability in the long run.
I also have plans around agenda-groups, ruleflow-groups and other types
of groups. I want to completely redesign the concept here to something
more consistent and uniform and also more powerful and flexible. So
again I'm reluctant to expose things, that might stop us making those
changes.
Mark
> Since there is org.drools.runtime.rule.Activation in the "stable"
> part, why is it not possible to retrieve the current activations by
> just using the "stable" API? I would think that concepts such as
> "agenda" and its current set of activations are here to stay. What
> should one do when one wants to implement support functions for Drools
> applications that should have long term stability??
>
> Best
> Wolfgang
> _______________________________________________
> 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