3:58 a.m.
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().
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
6:49 a.m.
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
10:11 a.m.
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
10:31 a.m.
New subject: Why are fundamental API functions not part of "stable"?
On 09/08/2010 16:11, Wolfgang Laun wrote:
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.
For now you can cast and unwrap any drools-api interface and get the
legacy concrete implementation that you need. We are aiming for 5.2 for
october, so we can look into exposing some more things then.
CRS is definitely something I want to change. I don't like the idea of a
global agenda that specifies a single CRS. I want to investigate a more
general purpose group concept that the user can have more control over;
so we might have a CRS per group... I don't know yet, at the moment it's
just ideas floating around in my head :)
Mark
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
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5:13 a.m.
On 9 August 2010 17:31, Mark Proctor <mproctor(a)codehaus.org> wrote:
For now you can cast and unwrap any drools-api interface and get the
legacy concrete implementation that you need. We are aiming for 5.2 for
october, so we can look into exposing some more things then.
In the case of Rule, your proposal doesn't work. To show the set of rules
bundled in an agenda group, I tried to
StatefulKnowledgeSession session = ...;
for( KnowledgePackage knowledgePackage:
session.getKnowledgeBase().getKnowledgePackages() ){
for( Rule rule: knowledgePackage.getRules() ){
???
but it turns out that this "rule" object is of the interface type
org.drools.definition.rule.Rule
implemented by
org.drools.definitions.rule.impl.Rule
which is just as meagre as the interface. Dead end, apparently.
Using other classes like Package or RuleBase from the "unstable" part
of the API to get at
the "real meat" in org.drools.rule.Rule isn't really a way I want to go.
Being able to "reverse engineer" one's rules for documentation or
filters or similar is an asset which
improves Drools usability. Please make do in 5.2.
Thanks
-W
10:46 a.m.
New subject: Why are fundamental API functions not part of "stable"?
On 20/08/2010 11:13, Wolfgang Laun wrote:
On 9 August 2010 17:31, Mark Proctor<mproctor(a)codehaus.org>
wrote:
> For now you can cast and unwrap any drools-api interface and get the
> legacy concrete implementation that you need. We are aiming for 5.2 for
> october, so we can look into exposing some more things then.
>
In the case of Rule, your proposal doesn't work. To show the set of rules
bundled in an agenda group, I tried to
StatefulKnowledgeSession session = ...;
for( KnowledgePackage knowledgePackage:
session.getKnowledgeBase().getKnowledgePackages() ){
for( Rule rule: knowledgePackage.getRules() ){
???
but it turns out that this "rule" object is of the interface type
org.drools.definition.rule.Rule
implemented by
org.drools.definitions.rule.impl.Rule
which is just as meagre as the interface. Dead end, apparently.
You looked at the
wrong implementation. Notice that Rule is also
implemented by org.drools.rule.Rule. That one has the meat you need.
Using other classes like Package or RuleBase from the
"unstable" part
of the API to get at
the "real meat" in org.drools.rule.Rule isn't really a way I want to go.
Being able to "reverse engineer" one's rules for documentation or
filters or similar is an asset which
improves Drools usability. Please make do in 5.2.
Thanks
-W
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:21 a.m.
Please note that I am and was well aware of org.drools.rule.Rule. But this isn't
available from what you get via StatefulKnowledgeSession, KnowledgeBasae,
KnowledgePackage. See below.
On 20 August 2010 17:46, Mark Proctor <mproctor(a)codehaus.org> wrote:
On 20/08/2010 11:13, Wolfgang Laun wrote:
> StatefulKnowledgeSession session = ...;
> for( KnowledgePackage knowledgePackage:
> session.getKnowledgeBase().getKnowledgePackages() ){
> for( Rule rule: knowledgePackage.getRules() ){
> ???
>
> but it turns out that this "rule" object is of the interface type
> org.drools.definition.rule.Rule
> implemented by
> org.drools.definitions.rule.impl.Rule
> which is just as meagre as the interface. Dead end, apparently.
You looked at the wrong implementation. Notice that Rule is also
implemented by org.drools.rule.Rule. That one has the meat you need.
This is what I wrote:
> Using other classes like Package or RuleBase from the
"unstable" part
> of the API to get at
> the "real meat" in org.drools.rule.Rule isn't really a way I want to
go.
>
1:30 p.m.
New subject: Why are fundamental API functions not part of "stable"?
On 20/08/2010 17:21, Wolfgang Laun wrote:
Please note that I am and was well aware of org.drools.rule.Rule. But
this isn't
available from what you get via StatefulKnowledgeSession, KnowledgeBasae,
KnowledgePackage. See below.
I want to compltely change agenda-groups,
ruleflow-groups,
activation-groups etc.
In the same way you'll be reluctant to want to use internal methods as
they will change over time. I'm reluctant to expose internal things that
I know I want to change in the near term. We have to support those apis
for 5 years.
Can you caste for now to try and solve your problem? The information is
there if you caste to org.drools.rule.Rule. We are working on pushing
more things out of core and compiler over time as we feel confident in
exposing those things. But it takes time and we are conservative in
this, as we want to avoid doing anything that makes future changes hard.
Mark
On 20 August 2010 17:46, Mark Proctor<mproctor(a)codehaus.org>
wrote:
> On 20/08/2010 11:13, Wolfgang Laun wrote:
>> StatefulKnowledgeSession session = ...;
>> for( KnowledgePackage knowledgePackage:
>> session.getKnowledgeBase().getKnowledgePackages() ){
>> for( Rule rule: knowledgePackage.getRules() ){
>> ???
>>
>> but it turns out that this "rule" object is of the interface type
>> org.drools.definition.rule.Rule
>> implemented by
>> org.drools.definitions.rule.impl.Rule
>> which is just as meagre as the interface. Dead end, apparently.
> You looked at the wrong implementation. Notice that Rule is also
> implemented by org.drools.rule.Rule. That one has the meat you need.
>
This is what I wrote:
>> Using other classes like Package or RuleBase from the "unstable" part
>> of the API to get at
>> the "real meat" in org.drools.rule.Rule isn't really a way I want
to go.
>>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
2:26 p.m.
Please don't keep telling me to do something that can't be done.
import org.drools.runtime.StatefulKnowledgeSession;
import org.drools.KnowledgeBase;
import org.drools.definition.KnowledgePackage;
public List<String> getRuleNamesFromPackage( String kPackageName ){
List<String> nameList = new ArrayList<String>();
for( KnowledgePackage knowledgePackage:
session.getKnowledgeBase().getKnowledgePackages() ){
if( kPackageName == null || kPackageName.equals(
knowledgePackage.getName() ) ){
for( org.drools.definition.rule.Rule rule: knowledgePackage.getRules() ){
org.drools.rule.Rule odrRule = (org.drools.rule.Rule)rule;
//<<<<< line 155: try a cast to get rule's agenda
nameList.add( rule.getName() );
}
}
}
return nameList;
}
Exception in thread "main" java.lang.ClassCastException:
org.drools.definitions.rule.impl.RuleImpl cannot be cast to
org.drools.rule.Rule
at rss.checker.engine.impl.DroolsEngine.getRuleNamesFromPackage(DroolsEngine.java:155)
at rss.checker.engine.impl.DroolsEngine.getRuleNames(DroolsEngine.java:165)
at rss.checker.init.Main.exec(Main.java:51)
at rss.checker.init.Main.main(Main.java:68)
There's lots of rules around that have agenda-group "whatever". ARE
YOU PLANNING TO ABOLISH THIS????
I ONLY WANT TO GET BACK WHAT I WROTE ACCORDING TO THE CURRENTLY VALID
DOCUMENTATION!!!
-W
On 20 August 2010 20:30, Mark Proctor <mproctor(a)codehaus.org> wrote:
On 20/08/2010 17:21, Wolfgang Laun wrote:
> Please note that I am and was well aware of org.drools.rule.Rule. But this isn't
> available from what you get via StatefulKnowledgeSession, KnowledgeBasae,
> KnowledgePackage. See below.
I want to compltely change agenda-groups, ruleflow-groups,
activation-groups etc.
In the same way you'll be reluctant to want to use internal methods as
they will change over time. I'm reluctant to expose internal things that
I know I want to change in the near term. We have to support those apis
for 5 years.
Can you caste for now to try and solve your problem? The information is
there if you caste to org.drools.rule.Rule. We are working on pushing
more things out of core and compiler over time as we feel confident in
exposing those things. But it takes time and we are conservative in
this, as we want to avoid doing anything that makes future changes hard.
Mark
> On 20 August 2010 17:46, Mark Proctor<mproctor(a)codehaus.org> wrote:
>> On 20/08/2010 11:13, Wolfgang Laun wrote:
>>> StatefulKnowledgeSession session = ...;
>>> for( KnowledgePackage knowledgePackage:
>>> session.getKnowledgeBase().getKnowledgePackages() ){
>>> for( Rule rule: knowledgePackage.getRules() ){
>>> ???
>>>
>>> but it turns out that this "rule" object is of the interface type
>>> org.drools.definition.rule.Rule
>>> implemented by
>>> org.drools.definitions.rule.impl.Rule
>>> which is just as meagre as the interface. Dead end, apparently.
>> You looked at the wrong implementation. Notice that Rule is also
>> implemented by org.drools.rule.Rule. That one has the meat you need.
>>
> This is what I wrote:
>
>>> Using other classes like Package or RuleBase from the "unstable"
part
>>> of the API to get at
>>> the "real meat" in org.drools.rule.Rule isn't really a way I
want to go.
>>>
> _______________________________________________
> 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
2:56 p.m.
New subject: Why are fundamental API functions not part of "stable"?
On 20/08/2010 20:26, Wolfgang Laun wrote:
Please don't keep telling me to do something that can't be
done.
import org.drools.runtime.StatefulKnowledgeSession;
import org.drools.KnowledgeBase;
import org.drools.definition.KnowledgePackage;
public List<String> getRuleNamesFromPackage( String kPackageName ){
List<String> nameList = new ArrayList<String>();
for( KnowledgePackage knowledgePackage:
session.getKnowledgeBase().getKnowledgePackages() ){
if( kPackageName == null || kPackageName.equals(
knowledgePackage.getName() ) ){
for( org.drools.definition.rule.Rule rule: knowledgePackage.getRules() ){
org.drools.rule.Rule odrRule = (org.drools.rule.Rule)rule;
//<<<<< line 155: try a cast to get rule's agenda
nameList.add( rule.getName() );
}
}
}
return nameList;
}
Exception in thread "main" java.lang.ClassCastException:
org.drools.definitions.rule.impl.RuleImpl cannot be cast to
org.drools.rule.Rule
at rss.checker.engine.impl.DroolsEngine.getRuleNamesFromPackage(DroolsEngine.java:155)
at rss.checker.engine.impl.DroolsEngine.getRuleNames(DroolsEngine.java:165)
at rss.checker.init.Main.exec(Main.java:51)
at rss.checker.init.Main.main(Main.java:68)
try this:
for ( KnowledgePackage pkg : kbase.getKnowledgePackages() ) {
for ( org.drools.definition.rule.Rule rule : pkg.getRules() ) {
String name = rule.getName();
org.drools.rule.Rule realRule = ( org.drools.rule.Rule
) ((KnowledgePackageImp)pkg).getRule( name );
System.out.println( realRule.getAgendaGroup() );
}
}
There's lots of rules around that have agenda-group "whatever". ARE
YOU PLANNING TO ABOLISH THIS????
At the drl it'll stay, for backwards
comptability for a while, we'll map
it onto the new planned constructs. I have plans over all for something
more generic, orthogonal and thus more flexible and powerful.
I ONLY WANT TO GET BACK WHAT I WROTE ACCORDING TO THE CURRENTLY
VALID
DOCUMENTATION!!!
See code paste above.
Mark
-W
On 20 August 2010 20:30, Mark Proctor<mproctor(a)codehaus.org> wrote:
> On 20/08/2010 17:21, Wolfgang Laun wrote:
>> Please note that I am and was well aware of org.drools.rule.Rule. But this
isn't
>> available from what you get via StatefulKnowledgeSession, KnowledgeBasae,
>> KnowledgePackage. See below.
> I want to compltely change agenda-groups, ruleflow-groups,
> activation-groups etc.
>
> In the same way you'll be reluctant to want to use internal methods as
> they will change over time. I'm reluctant to expose internal things that
> I know I want to change in the near term. We have to support those apis
> for 5 years.
>
> Can you caste for now to try and solve your problem? The information is
> there if you caste to org.drools.rule.Rule. We are working on pushing
> more things out of core and compiler over time as we feel confident in
> exposing those things. But it takes time and we are conservative in
> this, as we want to avoid doing anything that makes future changes hard.
>
> Mark
>> On 20 August 2010 17:46, Mark Proctor<mproctor(a)codehaus.org> wrote:
>>> On 20/08/2010 11:13, Wolfgang Laun wrote:
>>>> StatefulKnowledgeSession session = ...;
>>>> for( KnowledgePackage knowledgePackage:
>>>> session.getKnowledgeBase().getKnowledgePackages() ){
>>>> for( Rule rule: knowledgePackage.getRules() ){
>>>> ???
>>>>
>>>> but it turns out that this "rule" object is of the interface
type
>>>> org.drools.definition.rule.Rule
>>>> implemented by
>>>> org.drools.definitions.rule.impl.Rule
>>>> which is just as meagre as the interface. Dead end, apparently.
>>> You looked at the wrong implementation. Notice that Rule is also
>>> implemented by org.drools.rule.Rule. That one has the meat you need.
>>>
>> This is what I wrote:
>>
>>>> Using other classes like Package or RuleBase from the
"unstable" part
>>>> of the API to get at
>>>> the "real meat" in org.drools.rule.Rule isn't really a way
I want to go.
>>>>
>> _______________________________________________
>> 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
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
1:54 a.m.
On 20 August 2010 21:56, Mark Proctor <mproctor(a)codehaus.org> wrote:
try this:
for ( KnowledgePackage pkg : kbase.getKnowledgePackages() ) {
for ( org.drools.definition.rule.Rule rule : pkg.getRules() ) {
String name = rule.getName();
org.drools.rule.Rule realRule = ( org.drools.rule.Rule
) ((KnowledgePackageImp)pkg).getRule( name );
System.out.println( realRule.getAgendaGroup() );
}
}
Very well hidden - almost an 'Easter egg ;-)
Thank you!
At the drl it'll stay, for backwards comptability for a while,
we'll map
it onto the new planned constructs. I have plans over all for something
more generic, orthogonal and thus more flexible and powerful.
At one time, I thought that the metadata map would be the place where
things are kept. - I canimagine that a selection mechanism based on
s.th. like general property predicates would give you all you've got now
(possibly even with long-term backward compatibility) and plenty of new
possibilities. "Sharing" of rule sets among focusable grouds is one thing
I'd very much like to have...
-W
12:12 p.m.
New subject: Why are fundamental API functions not part of "stable"?
On 21/08/2010 07:54, Wolfgang Laun wrote:
On 20 August 2010 21:56, Mark Proctor<mproctor(a)codehaus.org>
wrote:
> try this:
> for ( KnowledgePackage pkg : kbase.getKnowledgePackages() ) {
> for ( org.drools.definition.rule.Rule rule : pkg.getRules() ) {
> String name = rule.getName();
> org.drools.rule.Rule realRule = ( org.drools.rule.Rule
> ) ((KnowledgePackageImp)pkg).getRule( name );
> System.out.println( realRule.getAgendaGroup() );
> }
> }
Very well hidden - almost an 'Easter egg ;-)
Thank you!
Sorry I probably didn't make myself clear, all of the old api is
available via one way or another. In the above we cast to the
implementation to return a org.drools.definition.rule.Rule that is
castable. In some other cases the old session interface of rulebase
interface is availlable as a field on the ksession impl or kbase impl.
So it's all there, it's just "internal". But yes in general you'll
need
to look at the impl to figure out what can be done where.
Mark
> At the drl it'll stay, for backwards comptability for a
while, we'll map
> it onto the new planned constructs. I have plans over all for something
> more generic, orthogonal and thus more flexible and powerful.
At one time, I thought that the metadata map would be the place where
things are kept. - I canimagine that a selection mechanism based on
s.th. like general property predicates would give you all you've got now
(possibly even with long-term backward compatibility) and plenty of new
possibilities. "Sharing" of rule sets among focusable grouds is one thing
I'd very much like to have...
-W
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5242
days inactive
5254
days old
11 comments
2 participants
participants (2)
-
Mark Proctor -
Wolfgang Laun