Custom BRMS security - location of custom java class
by KEVIN_CHEONG＠CRGL-THIRDPARTY.COM
Hi,
I finally have time to work on this again.
I was looking around in the Seam tutorials (security topic) and I found out how to write a custom class for security. I'm starting out with a really simple example and I have attached the code I am using below. My issue now is that I don't know where the class is to be placed in the drools-brms war file that is being edited. I have tried placing it alongside the other security files (package: org.drools.brms.server.security), but that isn't working. It seems to me like there is some other config file which needs to be edited to provide the name of the additional class? Any help will be really appreciated.
Thanks!
In my components.xml file:
<security:identity authenticate-method="#{authenticator.authenticate}" />
This is the java class:
package org.drools.brms.server.security;
import org.jboss.seam.security.Identity;
import org.jboss.seam.annotations.*;
@Name("authenticator")
public class Authenticator {
private static final String valid_user = "admin";
private static final String valid_password = "password";
public boolean authenticate() {
String username = Identity.instance().getUsername();
String password = Identity.instance().getPassword();
if((username.equals(valid_user)) && (password.equals(valid_password))) {
return true;
}
return false;
}
}
17 years, 10 months
Re.Problems with looping
by thomas kukofka
*Hello,
I tried this but it still loops:
public boolean equals(Object o) {
if(o instanceof OutputObject) {
OutputObject other = (OutputObject)o;
if (this.type != other.type) {
return false;
}
if (this.type == OutputObject.Type.LEVEL) {
if (this.getStringPropertyValue(OutputObject.SEGMENTNAME) !=
other.getStringPropertyValue(OutputObject.SEGMENTNAME)) {
return false;
}
return true;
}
return true;
}
else {
return false;
}
}
** public int hashCode() {
int hash = 37;
hash ^= type.hashCode();
return hash;
}
**If I understand it right I have to overwrite check the equality of all
fields which must be identical to for two objects which are seen equal.
Fields which can have different values for equal objects don't have to be
checked in the equals()-method. In my rule there is an update of the
OutputObject:
**rule "Assess Level"
dialect "java"
no-loop
when
io: InputObject(type == InputObject.Type.OBSERVATION)
ewhsMap: HashMap() from io.getMapParameters()
ewhs: HashMap() from ewhsMap.get("EWHS")
segment: String() from ewhs.keySet()
oo: OutputObject (type == OutputObject.Type.LEVEL,
stringParameters["SEGMENTNAME"] == segment)
ewh: Number() from ewhs.get(segment)
eval(ewh.doubleValue() >= 0.5 && ewh.doubleValue() < 3.0)
then
oo.setIntPropertyValue(OutputObject.SEGMENTLEVEL, "WARNING");
update(oo);
System.out.println( "Warning Segment " + segment + " has warning
level WARNING");
end
Thomas
**Greg Barton* greg_barton at yahoo.com
<rules-users%40lists.jboss.org?Subject=%5Brules-users%5D%20Problems%20with...>
*Fri Aug 1 12:03:55 EDT 2008
*Did you implement equals() and hashCode()?
Implementing them isn't hard. Implementing them well
can be tricky, but for these purposes a simple
implementation will do. Basically, with equals() you
want to compare the stuff contained in the objects.
With hashCode() you want to produce an integer that
can be used in HashMaps. The only restriction is
that, if o1.equals(o2) == true, then o1.hashCode() ==
o2.hashCode(). (The reverse is not necessarily true.)
The easiest way to implement these is to just compare
the fields that define the state of your object:
public class Foo {
int bar;
String bas;
public boolean equals(Object o) {
if(o instanceof Foo) {
Foo other = (Foo)o;
return bar == other.bar && bas != null &&
bas.equals(other.bas);
} else {
return false;
}
}
public int hashCode() {
int hash = 37;
hash ^= bar;
if(bas != null) {
hash ^= bas.hashCode();
}
return hash;
}
}
One good way to make this easier is to use the jakarta
commons EqualsBuilder and HashCodeBuilder classes.
They also help you implement them "well," especially
hashCode.
GreG
17 years, 10 months
Re: [rules-users] "Not" Non-Existential Quantifier
by ringsah＠comcast.net
Okay, I understand now. I had incorrectly assumed that the "applicant == $applicant" constraint was using identity. Not a big deal to work around. It seems like you would most often want to use identity in constraints, but I guess you have to provide for those cases when you need to use equality. Maybe there should be two different operators. Just my two ¢.
Anyway, thanks.
-Hans
-------------- Original message --------------
From: "Edson Tirelli" <tirelli(a)post.com>
Oh, I see.
Unfortunately in this case, there is nothing we can do about it, because the rules are behaving exactly as they were supposed to behave:
NegativeResult(applicant == $applicant)
As you can see, they are telling the application to use the equals comparison in the constraint:
applicant == $applicant
A fact should not change it's identity once it is asserted, so, either you use a constant "equals()/hashcode()" implementation, or you use constraints on an immutable ID:
NegativeResult(applicantId == $applicant.id)
You can also fallback to java "identity" check by using eval, but it is ugly... :)
NegativeResult( eval( applicant == $applicant) )
[]s
Edson
2008/8/4 <ringsah(a)comcast.net>
Edson,
I finally succeeded in coming up with a simple test case that shows the problem. I have attached the necessary files, which include a test case, three fact objects, and the drl.
One key to this test are the fact that the Applicant fact object has an "equals" method that tests for equality of its attributes, rather than identity. A second key is that the applicant object is updated after it is inserted.
It appears that what is happening is that an activation is created for the rule that uses "not" when the applicant is inserted. Then, when the applicant is updated, a second activation is created for that rule. It should be cancelling the previous activation, but doesn't find it because the Applicant instance no longer "equals" the fact object that caused the activation.
Thanks!
-Hans
-------------- Original message --------------
From: "Edson Tirelli" <tirelli(a)post.com>
Hans,
Your reasoning is correct. There should not be 2 instances of ApplicantStatus in the working memory.
Can you provide a test case showing the problem? we have test cases here using "not" and logical assertions, and it works properly.
Thanks,
Edson
2008/7/31 <ringsah(a)comcast.net>
How is "
not" supposed to work with insertLogical? Assume I have two different rules whose conditions are mutually exclusive, like the following:
rule
"Rule One"
when
not NegativeResult()
then
insertLogical(new ApplicantStatus("Approved"));
end
rule
"Rule Two"
when
NegativeResult()
then
insertLogical(new ApplicantStatus("Denied"));
end
Assume that the above two rules are the only way an
ApplicantStatus fact can be inserted into working memory. I would expect, after all rules are run, that it would be impossible for there to be one ApplicantStatus with "Approved" as its reason, and another with "Denied" as its reason, in the working memory.
I would expect that, before any
NegativeResult is inserted, that rule one could run, and insert an ApplicantStatus fact with an "Approved" reason. Then, after a NegativeResult is inserted, that rule two could run, and insert an ApplicantStatus fact with a "Denied" reason. At this point I would expect that the original ApplicantStatus fact, with an "Approved" reason, would be retracted, since the conditions under which it was inserted are no lon! ger true.
This is not what I am observing, however. I am finding
ApplicantStatus facts with both reasons in working memory at the end of the rules run. Should "not" work as I expect with regard to inserting a fact via insertLogical()? Or is this a known limitation, or simply the way it is designed to work?
Thanks,
-Hans
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
---------- Mensagem encaminhada ----------
From: ringsah(a)comcast.net
To: Rules Users List <rules-users(a)lists.jboss.org>
Date: Mon, 04 Aug 2008 13:49:37 +0000
Subject: Re: [rules-users] "Not" Non-Existential Quantifier
---------- Mensagem encaminhada ----------
From: "Edson Tirelli" <tirelli(a)post.com>
To: "Rules Users List" <rules-users(a)lists.jboss.org>
Date: Thu, 31 Jul 2008 17:41:39 +0000
Subject: Re: [rules-users] "Not" Non-Existential Quantifier
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
17 years, 10 months
Re: [rules-users] "Not" Non-Existential Quantifier
by ringsah＠comcast.net
Edson,
I finally succeeded in coming up with a simple test case that shows the problem. I have attached the necessary files, which include a test case, three fact objects, and the drl.
One key to this test are the fact that the Applicant fact object has an "equals" method that tests for equality of its attributes, rather than identity. A second key is that the applicant object is updated after it is inserted.
It appears that what is happening is that an activation is created for the rule that uses "not" when the applicant is inserted. Then, when the applicant is updated, a second activation is created for that rule. It should be cancelling the previous activation, but doesn't find it because the Applicant instance no longer "equals" the fact object that caused the activation.
Thanks!
-Hans
-------------- Original message --------------
From: "Edson Tirelli" <tirelli(a)post.com>
Hans,
Your reasoning is correct. There should not be 2 instances of ApplicantStatus in the working memory.
Can you provide a test case showing the problem? we have test cases here using "not" and logical assertions, and it works properly.
Thanks,
Edson
2008/7/31 <ringsah(a)comcast.net>
How is "
not" supposed to work with insertLogical? Assume I have two different rules whose conditions are mutually exclusive, like the following:
rule
"Rule One"
when
not NegativeResult()
then
insertLogical(new ApplicantStatus("Approved"));
end
rule
"Rule Two"
when
NegativeResult()
then
insertLogical(new ApplicantStatus("Denied"));
end
Assume that the above two rules are the only way an
ApplicantStatus fact can be inserted into working memory. I would expect, after all rules are run, that it would be impossible for there to be one ApplicantStatus with "Approved" as its reason, and another with "Denied" as its reason, in the working memory.
I would expect that, before any
NegativeResult is inserted, that rule one could run, and insert an ApplicantStatus fact with an "Approved" reason. Then, after a NegativeResult is inserted, that rule two could run, and insert an ApplicantStatus fact with a "Denied" reason. At this point I would expect that the original ApplicantStatus fact, with an "Approved" reason, would be retracted, since the conditions under which it was inserted are no lon! ger true.
This is not what I am observing, however. I am finding
ApplicantStatus facts with both reasons in working memory at the end of the rules run. Should "not" work as I expect with regard to inserting a fact via insertLogical()? Or is this a known limitation, or simply the way it is designed to work?
Thanks,
-Hans
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
17 years, 10 months
RE: [rules-users] "Not" Non-Existential Quantifier
by ringsah＠comcast.net
The default - identity.
-------------- Original message --------------
From: "Fenderbosch, Eric" <Eric.Fenderbosch(a)fedex.com>
How is your rule base configured, with identity or equality assert behavior?
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of ringsah(a)comcast.net
Sent: Monday, August 04, 2008 9:59 AM
To: Rules Users List
Subject: Re: [rules-users] "Not" Non-Existential Quantifier
Edson,
I finally succeeded in coming up with a simple test case that shows the problem. I have attached the necessary files, which include a test case, three fact objects, and the drl.
One key to this test are the fact that the Applicant fact object has an "equals" method that tests for equality of its attributes, rather than identity. A second key is that the applicant object is updated after it is inserted.
It appears that what is happening is that an activation is created for the rule that uses "not" when the applicant is inserted. Then, when the applicant is updated, a second activation is created for that rule. It should be cancelling the previous activation, but doesn't find it because the Applicant instance no longer "equals" the fact object that caused the activation.
Thanks!
-Hans
-------------- Original message --------------
From: "Edson Tirelli" <tirelli(a)post.com>
Hans,
Your reasoning is correct. There should not be 2 instances of ApplicantStatus in the working memory.
Can you provide a test case showing the problem? we have test cases here using "not" and logical assertions, and it works properly.
Thanks,
Edson
2008/7/31 <ringsah(a)comcast.net>
How is "
not" supposed to work with insertLogical? Assume I have two different rules whose conditions are mutually exclusive, like the following:
rule
"Rule One"
when
not NegativeResult()
then
insertLogical(new ApplicantStatus("Approved"));
end
rule
"Rule Two"
when
NegativeResult()
then
insertLogical(new ApplicantStatus("Denied"));
end
Assume that the above two rules are the only way an
ApplicantStatus fact can be inserted into working memory. I would expect, after all rules are run, that it would be impossible for there to be one ApplicantStatus with "Approved" as its reason, and another with "Denied" as its reason, in the working memory.
I would expect that, before any
NegativeResult is inserted, that rule one could run, and insert an ApplicantStatus fact with an "Approved" reason. Then, after a NegativeResult is inserted, that rule two could run, and insert an ApplicantStatus fact with a "Denied" reason. At this point I would expect that the original ApplicantStatus fact, with an "Approved" reason, would be retracted, since the conditions under which it was inserted are no lon! ger true.
This is not what I am observing, however. I am finding
ApplicantStatus facts with both reasons in working memory at the end of the rules run. Should "not" work as I expect with regard to inserting a fact via insertLogical()? Or is this a known limitation, or simply the way it is designed to work?
Thanks,
-Hans
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
17 years, 10 months
issue with .drl file to .brl file conversion
by JigarP
Hi,
I am using below code to convert .brl to .drl. but i do not know that how
it will put import statement and package name in our new .drl file which we
define in rule.package file. which will be input for processing all rules.
Below is my code snippet.
String fileName = "SampleTest.brl";
File file = new File(fileName);
String fileAsString="";
fileAsString = FileUtils.readFileToString(file);
BRXMLPersistence read = (BRXMLPersistence) BRXMLPersistence.getInstance();
BRDRLPersistence write = (BRDRLPersistence)
BRDRLPersistence.getInstance();
String outputDRL = write.marshal(read.unmarshal(fileAsString));
System.out.println(outputDRL);
String packagefile = resolvePackageFile();
final PackageBuilder builder = new PackageBuilder();
try {
builder.addPackageFromDrl( new StringReader(packagefile),new
StringReader(fileName));
} catch (DroolsParserException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
I have below questions.
1) can we just write single rule using GUI Editor?(once it convert into .brl
file ) or we can write multiple rules in same file using brl.
2) How can we get actual .brl file from .drl file ( as it should have
import, package and lots of rules). what is the procedure to achieve this.
Please reply so we can get real usage of Drool GUI Rule plug-in.
Regards,
Jigar
--
View this message in context: http://www.nabble.com/issue-with-.drl-file-to-.brl-file-conversion-tp1868...
Sent from the drools - user mailing list archive at Nabble.com.
17 years, 10 months
using CEP
by Yoni Mazar
Hi all,
In our business, most of the facts have a time-stamp attribute. In our
business-logic, we often try to analyze the relations between facts using
these attributes.
For example:
1) finding two adjacent labResults with an increasing value
2) checking whether 3 facts are consecutive
3) counting the number of facts fulfilling a specific constraint within a
specific time window.
We were happy to read (in the blog) about the new CEP feature which is about
to be added to drools 5.0.
* Where can we find more detailed description of CEP?
* Can we use CEP in a stateless session?
* Can we apply temporal-reasoning on the predefined time-stamp attributes,
and not on the fact assertion time?
For example, assuming we have a history of labResults, can we configure the
event to use the exisiting effectiveTime attribute? Can we avoid changing
the session timer from the calling application in order to do that?
* Can we use CEP to analyze the data in the examples above?
Many thanks for the help, Yoni
--
View this message in context: http://www.nabble.com/using-CEP-tp18797169p18797169.html
Sent from the drools - user mailing list archive at Nabble.com.
17 years, 10 months
determinism with rulebase partitioning
by Mark Proctor
We have rulebase partitioning almost working, this allows parallel
evaluation of a rulebase. For stateless lessions with no agenda this
will allow for much faster executions, where you don't care about
deterministic execution. However for deterministic execution its more
complicated. The current plan is to have an agenda per parition, which
means that we no longer have rulebase wide deterministic execution
order, only with the partition itself. The user is unlikely to be aware
of the created partitions, so won't be aware of the unditermistic
behavour of their rulebase. Anyone have any input on mechanisms users
can do to help the rulebase know what needs to be executed
deterministically and what doesn't?
Mark
17 years, 10 months
Re: [rules-users] JSR-94 and JEE integration
by Rainer Langbehn
The "Rules Framework" project @ sourceforge,
http://sourceforge.net/projects/rules/,
addresses this scenario, especially the JSR 94 based JCA resource adapter
and the
JSR 94 based Stateless Decision Service.
Rainer
Knoster wrote:
>
> Hi,
> i would like to integrate drools in jee. to be more flexible i was loking
> at jsr-94. as i suppose jsr-94 only addresses j2se environment, my
> question is: how it is possible to use drools with this specs from an ejb3
> session bean? my thoughts about this brought me to the idea of injecting
> the rules-administrator via resource annotation to prevent the container
> always doing a class.forname(..) lookup. to define a j2se resource in a
> jee container a jca might be the best way to integrate and to assure the
> jee specs will not be violated. but this seams a lot of overhead to me.
> how do u use drools in your jee applications when not relying on the brms?
> any help or ideas on integrating drools with jsr-94 in jee would be great.
>
> Knosta
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
View this message in context: http://www.nabble.com/JSR-94-and-JEE-integration-tp17751072p18749348.html
Sent from the drools - user mailing list archive at Nabble.com.
17 years, 10 months
