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 
[email protected] 
https://lists.jboss.org/mailman/listinfo/rules-users   
  
 _______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users


                
---------------------------------
 Вы уже с Yahoo!?
 Испытайте обновленную и улучшенную Yahoo! Почту!
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users

Reply via email to