[rules-users] Re: Using JDK dynamic proxies as facts
Ronald R. DiFrango
ron.difrango at gmail.com
Tue Jul 17 13:05:05 EDT 2007
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 <oleg_yavorsky at yahoo.com> 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 <crayzfishr at gmail.com>* 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 <oleg_yavorsky at yahoo.com> 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 <mproctor at codehaus.org >* 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 <crayzfishr at gmail.com> 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 at lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> > ------------------------------
> > Вы уже с Yahoo!?
> > Испытайте обновленную и улучшенную Yahoo! Почту!
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> ------------------------------
>
> Вы уже с Yahoo!? Испытайте обновленную и улучшенную. Yahoo! Почту<http://ru.mail.yahoo.com>
> !
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070717/b0bcc894/attachment.html
More information about the rules-users
mailing list