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
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 t
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 matte
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 or
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
Please!
Thank you for providing the solution.
[]s
Edson
2007/7/12, Chris West <[EMAIL PROTECTED]>:
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 suspe
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.
