directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject RE: Snickers ASTs
Date Mon, 19 Apr 2004 14:24:44 GMT
Hey Alan,

> -----Original Message-----
> From: Alan D. Cabrera []
> I've got the compiler to generate some useful ASTs.  I want to try my hand
> on translating to the LDAP code.  It looks like you've been busy and may
> have the POJOs already written.  Do you have any pointers on where I
> should look?

Here's my current status:

I got the BER decoder runtime to a state where I can add rules 
to the digester and have it actually build a containment tree using 
the LDAP PDU objects within the org.apache.ldap.common.message 
package.  These LDAP message POJOs are equivalent to the POJO stubs 
that your compiler will generate.  I have already written 
rules for the BERDigester to decode the following LDAP PDUs:

DeleteResponse ( testcase fails )

While writing the rules I discovered that several tactics can be 
used to manage the stack of the digester and may have to go back to 
make the BindRequest a bit cleaner (it was the first one). 


I've been thinking about how we're going to interface the two halves 
- allow me to think out loud and please correct me where I'm wrong:

1). Compiler (buildtime) generates POJO stubs which are used by
the runtime to build the containment tree of a PDU.  The stubs 
are generated according to the ASN.1 spec for the protocol. 
The Java stub classes are generated by the compiler's Java 

2). There most probably will be support in snickers for more 
than one encoding i.e. BER, DER, PER, and/or XER in the future.

3). Besides the generated POJO stubs and the runtime we need 
to generate (encoding specific) classes that tell the runtime
how to marshal and demarshal PDUs into their containment trees
using the POJO stubs.  I view these classes as the primary 
interface between the buildtime and the runtime.

As you know I've built the BER decoder piece (not even touched 
the idea of encoding yet) using the digester pattern.  You add
rules describing the nesting pattern of Tags and the digester 
fires them.  I can whip up some documentation on this if that's
better for you.  The code is not the best in the world and is
complex due to its nature as a state machine.  However I think
the rule based and stack based approach may make building the
compiler code easier but you'll have to be the judge of that.
Please when looking at this know that much of it needs to be
cleaned up and refactored to be a bit more sensible.

What I'm thinking is for the BER runtime the compiler might
generate the digester rules as well as the POJO stubs.  Again
the rules part is BER codec specific and only for decodes - 
how we're going to do the encodes is still not clear to me 
but it should not be that hard I would think.

Take a look at the following to see what I'm talking about
in terms of digester rules.  We can start discussing this and
how the compiler generate the rules if that's the direction we
want to go.  Perhaps we generate an existing set of generic rules
and just have the compiler generate the class that preps the 
digester by adding the rules using nesting patterns.  Below I have 
the links to the JIRA issues describing what I have done 
as well as a link into the svn repo where these rules can be 

Here's where the LDAP specific rules are in svn:

Here's a really good example of how you add the rules to the 
digester take a look specifically at the testBindResponse() 

Here's the whole set of issues on the snickers LDAP provider:

Here's the top level issue for creating rules with all the dependent 
issues that show how the PDU specific rules have been created:

Just select the dependent issues like and you'll see 
all my notes on how the rules do what they do taking the Tag
nesting pattern into account.  

Forgive the long email but there's lots of stuff and I wanted to 
get it all out to you.


View raw message