>Also on a separate note.  Perhaps I've done the wrong thing here in 
>> trying to get others interested in asn1 by refactoring it.  A massive 
>> restructuring may not have been the best route to go.  Perhaps we can 
>> see if you can first massage out the Snacc4J deps instead.  I'm 
>> realizing my approach to cross reactivity might have been flawed  :( .

> You're doing good here, no worry. There's been a lot of work put into the
> asn1 suproject obviously and you're right it's pretty hard to just jump in 
> and understand everything straight. Focusing on the snacc dependency is a
> good idea. Do you have more details on this?

Well yeah I had an crazy (overdone) solution outlined in the JIRA on this:

http://issues.apache.org/jira/browse/DIRSNICKERS-61

Half the stuff I said is a crock of %2&^@%#(s^@F#.  Perhaps I was out
of my mind.   
 
However I've changed my mind on the approach and think the best way to
do it is to just  embed the bytes into the testcase in a byte array for the PDU.
You can use the LDAP common library to generate the PDU by setting the
provider to use the Snacc4J  and dump the result to a file.  Then use the
contents of the file to build the byte[].  Basically instead of all this XML and
base64 stuff just put the bytes into a testcase constant and the Req/Resp
object used for the comparison is also a testcase constant.
Then you can decode the byte[] with our asn1 lib and compare with this
object.  Conversely you can encode with our lib and compare with the 
byte[].

It does stink that you have to write a little program for generating the PDU
and generate one for each test case in the libraries tests.

Does this help?  

Thanks,
Alex