[j-nsp] Commit script: xsltMaxDepth

[Serge Vautour]

Phil and I have been exchanging emails. For the benefit of the list, this turned 
out to be a bug in Junos. Phil says it'll be fixed in a future release. I was on 
10.4R4. The bug has to do with trying to issue an emit-change while the context 
is in get-chassis-inventory instead the config. As a work around, Phil suggested 
to bring the context back to the config by adding a "for-each ($dot)" before the 
emit-change. This worked!

Serge



----- Original Message ----
From: Phil Shafer <phil at juniper.net>
To: Serge Vautour <serge at nbnet.nb.ca>; Serge Vautour <sergevautour at yahoo.ca>
Cc: juniper-nsp at puck.nether.net
Sent: Wed, June 1, 2011 5:21:17 PM
Subject: Re: [j-nsp] Commit script: xsltMaxDepth 

Serge Vautour writes:
>I'm not a programmer but can usually find a way to code what I want. I've 
>written a few basic commit & event scripts and they work. This one is getting 
>very long - lots of for-each loops inside loops.

The issue isn't looping, but infinite recursion.  If a template
calls itself (or another template that calls the first), it will
hit a limit (3000 calls) that will prevent it from eating all memory
on the box.

So look at the call paths of your script to see which call is at
fault.

>This is mostly because I can't 
>find a way to store data in a hash in reference that data later (that's what I 
>would do in perl). 

The XSLT language (and SLAX-1.0) don't allow mutable variables,
but you can build the XML equivalent of hashes by building
XML content.  For example:

var $typedefs := {
    <typedef name="dnsname"> {
        <match> {
            <regex> "^[a-zA-Z0-9._-]{1,255}$";
            <message> "must contain 1-255 letters, numbers and characters";
        }
    }
    <typedef name="ip-address"> {
        <match> {
            <regex> "^[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}$";
            <message> "must be a valid IP address";
        }
    }
    <typedef name="ip-prefix"> {
        <match> {
            <regex> 
"^[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}/[0-9]{1,2}$";
            <message> "must be a valid IP prefix";
        }
    }
}

This hash can be consulted using normal XPath expressions:

        var $td = $typedefs/*[@name == $type];
        if ($td && $td/match/regex) {
            var $re = jcs:regex($td/match/regex, $response);
            ...
        }

The content doesn't have to be static, like this example, but could
be build from other data.  For example, you could take the results
of the <get-chassis-inventory> RPC and turn them into a hash that
maps the slot number to the fpc type.

Thanks,
Phil