[rules-users] ClassCastException and other problems
Nagaraju runkana
runkana.nagaraju at gmail.com
Tue Jun 10 02:51:03 EDT 2008
Hi Edson,
i have some problem...
*core_preference_text* this my table name.Row like "VARIABLE_CODE"
VARCHAR2(60 BYTE)"
i need write dsl,dslr files related data validation to the table.
1. variable_code should be unieque per enterprise_id
2. variable_code can not be updated
give me some suggestion ..how to write dsl,dslr file related two
conditions.ASAP..
=====
Chanti
On Fri, Jun 6, 2008 at 8:19 PM, Edson Tirelli <tirelli at post.com> wrote:
>
>
> Drools 5 implements a completely new propagation algorithm that
> allowed us to get rid of shadow proxies from the core engine. So, you will
> not have the problem.
>
> But for 4.0.x, if you are a community user, best you can do is open a
> JIRA with a test case to reproduce your problem. If we release a 4.0.8
> version, we can fix your issue there, but at this moment we don't know if
> there will be a 4.0.8 release or if the next release will be 5.0.
> If you are a Drools subscriber at Red Hat, then you can simply open a
> support case there and they will fix and provide a patch for you.
>
>
> []s
> Edson
>
>
>
> 2008/6/6 Sibylle Duerr <sibylle.duerr at mymail.ch>:
>
>> Thanks Edson,
>>
>> but the collections do return an empty collection. hm, I just tested this
>> ones again and it worked fine. no exception when the set was empty. I will
>> keep an eye on this and test some more but seems to work now for me.
>>
>> and for the other problem I then hope for 5.0 :).
>>
>> and what about the last problem I described before?
>>
>> best regards
>> Sibylle
>>
>>
>>
>> Edson Tirelli wrote:
>>
>>>
>>>
>>> Sibylle,
>>>
>>> Unfortunately, this is the way it was implemented to be, under a
>>> kind-of "fail-fast" philosophy we were following. I do think there is value
>>> in changing things in 5.0 so that, for instance:
>>>
>>> ProcessModel($activities : activities) from $models
>>>
>>> Simply does not match, instead of raises a CCE, in case the model is a
>>> TypeModel.
>>> But for 4.0.x, that is how things work.
>>>
>>> The only suggestion I can give you is, in your second problem, to not
>>> return null on your collections. Simply return empty collections:
>>>
>>> class Project {
>>> ...
>>> public List getModels() {
>>> if( this.models == null ) {
>>> return Collections.emptyList();
>>> }
>>> return this.models;
>>> }
>>> ...
>>> }
>>> This is usually a good thing, unless you have a specific semantics
>>> for null collections in your domain model.
>>>
>>> []s
>>> Edson
>>>
>>> 2008/6/6 Sibylle Duerr <sibylle.duerr at mymail.ch>:
>>>
>>> Hi there,
>>>
>>> I have three issues, where I'm not sure if these are bugs in
>>> drools, or if this is just the way it has to be.
>>>
>>> the used classes in this case are:
>>>
>>> Project
>>> Model
>>> ProcessModel extends Model
>>>
>>> only the Project is in the working memory, because I didn't want
>>> to load all elements due to performance issues (there can be
>>> thousends of elements to load at startup).
>>>
>>> if I have the following rule:
>>>
>>> Project($models : models)
>>> ProcessModel($activities : activities) from $models
>>>
>>> there happen to be two problems. if the project does not only
>>> contain ProcessModels but also TypeModels or others (all extend
>>> Model), this leads to a ClassCastException.
>>> I can solve this by writing the rule as follows:
>>>
>>> Project($models : models)
>>> $m : Model(eval($m instanceof ProcessModel)) from $models
>>> ProcessModel($activities : activities) from $m
>>>
>>> but this is not really nice and I hope there is a better solution
>>> for this, is there?
>>>
>>> the second problem this rule gives me, is when the set 'models' is
>>> empty. that will also throw an exception. to solve this I write:
>>>
>>> $p : Project(eval($p.hasModels()), $models : models)
>>> $m : Model(eval($m instanceof ProcessModel)) from $models
>>> ProcessModel($activities : activities) from $m
>>>
>>> and I need to use this in each case where I have possible empty sets.
>>>
>>>
>>> the last problem I encountered when I tried to load all elements
>>> to the working memory and then redefine some rules. used classes:
>>>
>>> Aggregation extends DomainElement
>>>
>>> rule:
>>>
>>> Aggregation(owner.owner != type.owner)
>>>
>>> causes some exception. the root exception is a ClassCastException:
>>> ProxyShadowProxy cannot be cast to Aggregation.
>>> when I rewrite the rule as:
>>>
>>> $element : DomainElement(eval($element instanceof Aggregation))
>>> Aggregation(owner.owner != type.owner) from $element
>>>
>>> everything works fine. but that again is not a nice solution.
>>>
>>> any help?
>>>
>>> best regards
>>> sibylle
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>>
>>>
>>> --
>>> Edson Tirelli
>>> JBoss Drools Core Development
>>> Office: +55 11 3529-6000
>>> Mobile: +55 11 9287-5646
>>> JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.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/20080610/6424b87b/attachment.html
More information about the rules-users
mailing list