[rules-users] What should I insert into the working memory?

Wolfgang Laun wolfgang.laun at gmail.com
Sun Nov 28 12:31:07 EST 2010


2010/11/28 Chris Selwyn <chris at selwyn-family.me.uk>

>  Hi Wolfgang,
>
> Thanks for the helpful response.
>
> I do find myself using "contains" and "memberof" quite a lot depending on
> whether I am going "up" or "down" the tree structure. Is this a performance
> problem? Is it better to use "from"?
>

contains and memberof are OK to use; they are 1st class "citizen" operators.


> Thanks for the hint about adding the "parent" pointer in the child. I'll
> have to think about that one because the schema is actually shared with
> external trading partners.
>

The addition I propose has no influence on the XML data; it'll just let you
generate what you need in you JAXB generated classes. Or a simple XSLT
transformation might create the xjc input from the "official" XML schema.


> I guess I could have an "external" version and and "internal" version but
> then I would have 2 versions to maintain and that is not very desirable.
>

Consider the XSLT proposal.


> As someone else has asked, I do actually make modifications to the model
> that I want to return to the client. So it is not read-only. That means I
> would then have to do a post-rule processing pass to null out the parent
> pointers (otherwise I would have cycles in the graph!) before returning the
> answer. Actually... @XmlTransient will probably have the desired effect.
>

This is an annotation you can add when you start from hand-coded Java. But
it shouldn't be a problem to write rules (or Java code) setting all the
parent pointer to null before you marshal everything back.


>
> (Thinks: I wonder whether it would be possible to write a JAXB plugin to do
> this stuff and make the generated classes more "rules-friendly")
>

There's no generally applicable procedure, I'd say.


>
> Thanks also for the hint about the code injection plugin. I was not aware
> of that. I have just done some investigation into that and I find that the
> code-injection plugin is present  in my Glassfish server but is not named in
> the META-INF/services/com.sun.tools.xjc.Plugin file. So I'm not sure that I
> can use it without getting a separate installation of JAXB.
>

This is a deficiency in some JAXB version that (I think) is distributed with
Java 1.6.x. You can add the missing line to the file, and it'll work; or you
can get the latest JAXB release and use this, superceding what comes with
JDK.

-W


>
> Chris
>
>
> On 28/11/2010 13:12, Wolfgang Laun wrote:
>
> An XML schema just fitting your XML data will frequently not result in a
> class
> hierarchy that's well suited for writing rules.
>
> One point deals with representing the parent-child relationship, especially
> when there are multiple children of a kind, i.e., the parent class contains
> a
> List<?>. You have this in XML the natural way; you lose it when you just
> insert parents and children.  If extending the XML schema is possible, you
> can add another element with minOccurs="0" to the Child complexType of
> type Parent and set the reference to the current parent when you walk the
> object tree. (You can erase the List<?> in the parent.) This avoids the
> frequent use of the "from" clause in conditions.
>
> You may also have to handle repeated occurrences of elements that are
> "equal" as objects but appear in full XML text; this is usually simple to
> handle
> with a temporary Set, but you'll have to add hashCode and equals to the
> JAXB generated classes using the code injection plugin.
>
> Inserting just the root element is not advisable, as you are well aware of.
>
> -W
>
>
>
>
> On 28 November 2010 12:38, Chris Selwyn <chris at selwyn-family.me.uk> wrote:
>
>> I am working on a project that is using Drools to perform validation of
>> hierarchical XML messages.
>>
>> So I have passed the XSDs through JAXB and have a set of interrelated
>> Java objects.
>> One of these objects (naturally) represents the root of the messages and
>> the others represent the intermediate and leaf nodes of the message.
>>
>> My question is: Should I traverse the tree and insert each object into
>> the working memory or should I just insert the root object into the
>> working memory?
>>
>> If I insert each object into the memory then I have a lot of flexibility
>> about how I write my rules... I can start by focussing on the particular
>> part of the message that I want to detect an error in.
>> However, I then have to perform a whole bunch of "joining" clauses to
>> correctly "connect up" to the other objects in the working memory.
>> (This is how I am doing it at the moment... I have a mechanism that uses
>> the Java Introspector. It identifies by package name which parts of the
>> data model get inserted into the WM)
>>
>> On the other hand, I could just insert the root object into the WM. This
>> means that I would have to write really complicated where clauses on the
>> root object but very much simplifies the WM loading process.
>>
>> All of the examples that I have seen have a very simple flat
>> (non-hierarchical) structure that don't really give a hint as to what a
>> "best practice" might be.
>>
>> Any suggestions/insights welcome :-)
>>
>> Chris Selwyn
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1170 / Virus Database: 426/3284 - Release Date: 11/27/10
>
>
> _______________________________________________
> 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/20101128/df4fa5c6/attachment.html 


More information about the rules-users mailing list