Re: [rules-users] Re: Using JDK dynamic proxies as facts
Chris,
I'll try to dig it a little too. My problem is that I need to proxy concrete
classes as they are generated from XSD using Castor. If I find workaround I'll
let you know.
Oleg.
Chris West [EMAIL PROTECTED] wrote: Oleg,
So far I have not been successful. I've just posted my thoughts to this list
(under the subject The effect of not using shadow facts). Concerning the
class names, my rules only match on an interface type implemented by the
proxies, so the actual class type of the instance does not matter.
-Chris
On 7/13/07, Oleg Yavorsky [EMAIL PROTECTED] wrote: Chris,
I'm thinking about using dynamic proxies in my rules too. I'll be glad to hear
about your success with them. I think that there could be problem with matching
of facts as they won't be of original class but of Proxy$... one. CGLIB
approach doesn't have such problem as it just modifies original classes'
bytecode. I could be wrong, anyway.
Oleg.
Mark Proctor [EMAIL PROTECTED] wrote:That is not the only thing that
determines shadowing. If you look the shadowing is actually determined here:
if ( !ruleBase.getConfiguration().isShadowProxy() || cls == null
|| !ruleBase.getConfiguration().isShadowed( cls.getName() ) ) {
return;
}
By default shadowing is turned on for all (none final) bjects, except stuff in
the org.drools namespace, you have to set exclusion lists.too. So if your
package has a null namespace it will still attempt to shadow it.
Mark
Chris West wrote: OK, I just solved my own problem. My proxy had no package,
since the jdk based proxy is only in a package if it has at least 1 non public
interface, according to the javadoc.
The suspect code beginning on line 333 is:
String pkgName = cls.getPackage().getName();
if ( org.drools.reteoo.equals( pkgName ) ||
org.drools.base.equals( pkgName ) ) {
// We don't shadow internal classes
this.shadowEnabled = false;
return;
}
The getPackage() method returns null. In this case, it would be good if JBoss
Rules handled the null and went on to shadow the object anyway, since it is
obviously not in the org.drools packages.
Now I'll continue trying to build a test case for my original problem.
Shall I enter a JIRA for this issue?
Thanks,
-Chris West
On 7/12/07, Chris West [EMAIL PROTECTED] wrote:Hello,
I'm trying to use objects that are generated as dynamic proxies (through the
java.lang.reflect.Proxy class) as facts in JBoss Rules 4.0 MR3. My project was
using CGLib to generate proxies, and they were working just fine in 3.0.6.
However, when I tried 4.0, the CGLib based proxies seemed to have a final
method that kept the proxies from being proxied as shadow facts. So I rewrote
my code to try to use JDK based proxies, and version 4.0 MR3 accepts them and
apparently creates shadow facts, but now my rules don't fire correctly.
So, in an attempt to create a simple program to illustrate the problem, I ran
into a different problem. The attached eclipse project illustrates this
problem.
The error is:
java.lang.NullPointerException
at org.drools.reteoo.Rete$ObjectTypeConf.init(Rete.java:333)
at org.drools.reteoo.Rete.assertObject(Rete.java :152)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at
org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.insert
(AbstractWorkingMemory.java:772)
at org.drools.common.AbstractWorkingMemory.insert
(AbstractWorkingMemory.java:584)
at com.sample.DroolsTest.main(DroolsTest.java:42)
Has anyone successfully used JDK based dynamic proxies as facts?
Thanks,
-Chris West
-
___ rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-
Вы уже с Yahoo!?
Испытайте обновленную и улучшенную Yahoo! Почту!
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-
Вы уже с Yahoo!? Испытайте обновленную и улучшенную. Yahoo! Почту!___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Ответ: Re: [rules-users] Re: Using JDK d ynamic proxies as facts
Ronald,
I use Ant task too but in my usecase I'd like to add additional property to
objects on a fly (actually collection of parents) so I can check it on a LHS.
Currently I use eval on external objects (identity map with child and
associated parents). I don't know yet if this approach viable at all but if I
manage to add such a property I'll get rid of eval thus having advantages of
properties caching and indexing. Time will show...
Oleg.
Ronald R. DiFrango [EMAIL PROTECTED] wrote: Oleg,
Are you generating the Castor classes on the fly? I am successfully using
Castor generated classes within the rules engine without any proxy classes. My
process is that I use the Castor ant task to generate objects based upon my
schema. I then develop my rules against the Castor generated objects. These
work just fine with stock JBoss Rules, so the question is why the proxy
classes?
Ron
On 7/17/07, Oleg Yavorsky [EMAIL PROTECTED] wrote: Chris,
I'll try to dig it a little too. My problem is that I need to proxy concrete
classes as they are generated from XSD using Castor. If I find workaround I'll
let you know.
Oleg.
Chris West [EMAIL PROTECTED] wrote:
Oleg,
So far I have not been successful. I've just posted my thoughts to this list
(under the subject The effect of not using shadow facts). Concerning the
class names, my rules only match on an interface type implemented by the
proxies, so the actual class type of the instance does not matter.
-Chris
On 7/13/07, Oleg Yavorsky [EMAIL PROTECTED] wrote: Chris,
I'm thinking about using dynamic proxies in my rules too. I'll be glad to hear
about your success with them. I think that there could be problem with matching
of facts as they won't be of original class but of Proxy$... one. CGLIB
approach doesn't have such problem as it just modifies original classes'
bytecode. I could be wrong, anyway.
Oleg.
Mark Proctor [EMAIL PROTECTED] wrote: That is not the only thing
that determines shadowing. If you look the shadowing is actually determined
here:
if ( !ruleBase.getConfiguration().isShadowProxy() || cls == null
|| !ruleBase.getConfiguration().isShadowed( cls.getName() ) ) {
return;
}
By default shadowing is turned on for all (none final) bjects, except stuff in
the org.drools namespace, you have to set exclusion lists.too. So if your
package has a null namespace it will still attempt to shadow it.
Mark
Chris West wrote: OK, I just solved my own problem. My proxy had no package,
since the jdk based proxy is only in a package if it has at least 1 non public
interface, according to the javadoc.
The suspect code beginning on line 333 is:
String pkgName = cls.getPackage().getName();
if ( org.drools.reteoo.equals( pkgName ) ||
org.drools.base.equals( pkgName ) ) {
// We don't shadow internal classes
this.shadowEnabled = false;
return;
}
The getPackage() method returns null. In this case, it would be good if JBoss
Rules handled the null and went on to shadow the object anyway, since it is
obviously not in the org.drools packages.
Now I'll continue trying to build a test case for my original problem.
Shall I enter a JIRA for this issue?
Thanks,
-Chris West
On 7/12/07, Chris West [EMAIL PROTECTED] wrote: Hello,
I'm trying to use objects that are generated as dynamic proxies (through the
java.lang.reflect.Proxy class) as facts in JBoss Rules 4.0 MR3. My project was
using CGLib to generate proxies, and they were working just fine in 3.0.6.
However, when I tried 4.0, the CGLib based proxies seemed to have a final
method that kept the proxies from being proxied as shadow facts. So I rewrote
my code to try to use JDK based proxies, and version 4.0 MR3 accepts them and
apparently creates shadow facts, but now my rules don't fire correctly.
So, in an attempt to create a simple program to illustrate the problem, I ran
into a different problem. The attached eclipse project illustrates this
problem.
The error is:
java.lang.NullPointerException
at org.drools.reteoo.Rete$ObjectTypeConf.init(Rete.java:333)
at org.drools.reteoo.Rete.assertObject(Rete.java :152)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java
:70)
at org.drools.common.AbstractWorkingMemory.insert
(AbstractWorkingMemory.java:772)
at org.drools.common.AbstractWorkingMemory.insert
(AbstractWorkingMemory.java:584)
at com.sample.DroolsTest.main (DroolsTest.java:42)
Has anyone successfully used JDK based dynamic proxies as facts?
Thanks,
-Chris West
-
___ rules
Re: [rules-users] Re: Using JDK dynamic proxies as facts
Chris,
I'm thinking about using dynamic proxies in my rules too. I'll be glad to hear
about your success with them. I think that there could be problem with matching
of facts as they won't be of original class but of Proxy$... one. CGLIB
approach doesn't have such problem as it just modifies original classes'
bytecode. I could be wrong, anyway.
Oleg.
Mark Proctor [EMAIL PROTECTED] wrote:That is not the only thing that
determines shadowing. If you look the shadowing is actually determined here:
if ( !ruleBase.getConfiguration().isShadowProxy() || cls == null
|| !ruleBase.getConfiguration().isShadowed( cls.getName() ) ) {
return;
}
By default shadowing is turned on for all (none final) bjects, except stuff in
the org.drools namespace, you have to set exclusion lists.too. So if your
package has a null namespace it will still attempt to shadow it.
Mark
Chris West wrote: OK, I just solved my own problem. My proxy had no package,
since the jdk based proxy is only in a package if it has at least 1 non public
interface, according to the javadoc.
The suspect code beginning on line 333 is:
String pkgName = cls.getPackage().getName();
if ( org.drools.reteoo.equals( pkgName ) ||
org.drools.base.equals( pkgName ) ) {
// We don't shadow internal classes
this.shadowEnabled = false;
return;
}
The getPackage() method returns null. In this case, it would be good if JBoss
Rules handled the null and went on to shadow the object anyway, since it is
obviously not in the org.drools packages.
Now I'll continue trying to build a test case for my original problem.
Shall I enter a JIRA for this issue?
Thanks,
-Chris West
On 7/12/07, Chris West [EMAIL PROTECTED] wrote: Hello,
I'm trying to use objects that are generated as dynamic proxies (through the
java.lang.reflect.Proxy class) as facts in JBoss Rules 4.0 MR3. My project was
using CGLib to generate proxies, and they were working just fine in 3.0.6.
However, when I tried 4.0, the CGLib based proxies seemed to have a final
method that kept the proxies from being proxied as shadow facts. So I rewrote
my code to try to use JDK based proxies, and version 4.0 MR3 accepts them and
apparently creates shadow facts, but now my rules don't fire correctly.
So, in an attempt to create a simple program to illustrate the problem, I ran
into a different problem. The attached eclipse project illustrates this
problem.
The error is:
java.lang.NullPointerException
at org.drools.reteoo.Rete$ObjectTypeConf.init(Rete.java:333)
at org.drools.reteoo.Rete.assertObject(Rete.java:152)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at
org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772)
at org.drools.common.AbstractWorkingMemory.insert
(AbstractWorkingMemory.java:584)
at com.sample.DroolsTest.main(DroolsTest.java:42)
Has anyone successfully used JDK based dynamic proxies as facts?
Thanks,
-Chris West
-
___ rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-
Вы уже с Yahoo!?
Испытайте обновленную и улучшенную Yahoo! Почту!___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
