You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Kevin Sonney <ke...@webslingerz.com> on 2000/04/04 01:18:02 UTC
Fixing LDAP Examples
OK, so I've got everything I need to make LDAP work.
But the darn thing was returning the text of the XML document instead of
running the query. Hmm. Well, since Donald was handy (he was teaching a class
at the office today about XML/XSL/XSLT) I asked him about it.
Nobody had explained to me that getting the un-marked up text of the xml
document in your template meant that the processor wasn't processing.
Well, it's the default ldap.xml, so the tags must be right, right?
Nope.
The default ldap.xml is incorrect. To properly run,l it should look like this :
<!-- Being LDAP Example -->
<?xml version="1.0"?>
<?xml-stylesheet href="ldap.xsl" type="text/xsl"?>
<?cocoon-process type="ldap"?>
<?cocoon-process type="xslt"?>
<page>
<ldap-defs>
<ldap-server name="searchlight">
<initializer>com.sun.jndi.ldap.LdapCtxFactory</initializer>
<ldap-serverurl>ldap://ldap.bigfoot.com/</ldap-serverurl>
</ldap-server>
</ldap-defs>
<ldap-query server="searchlight" ldap-searchbase="c=US">
sn=smith*
</ldap-query>
</page>
<!-- end LDAP Example -->
Now, I'm working out the new and improved ldap.xsl to go with it. but *THIS*
document will return data from bigfoot's public LDAP server.
--
- Kevin Sonney
kevin@webslingerZ.com
Re: Fixing LDAP Examples
Posted by Daniel Barclay <Da...@digitalfocus.com>.
Kevin,
Kevin Sonney wrote:
>
> On Mon, 10 Apr 2000, you wrote:
> > Do know why the <?xml-stylesheet href="ldap.xsl" type="text/xsl"?> and
> > <?cocoon-process type="xslt"?> processing instructions are necessary just
> > to get the LDAP processor to run?
> >
> > (Why isn't "<?cocoon-process type="ldap"?>" sufficient?)
>
> Oh, it's sufficent, you just don't get to see it rendered as HTML without the
> xsl. Unless, of course, you rewrite it as XHTML. *grin*
Actually, that wasn't what I meant.
For a while, having just the LDAP processing instruction was not
sufficient. The LDAP processing wouldn't occur unless I had the
Cocoon XSLT processing instruction and the xml-stylesheet processing
instruction in the file. Whenever I tried taking them out, the LDAP
processing didn't run.
Then, at some later point, I could take them out and the LDAP
processing still got done.
It was really weird. I wasn't changing anything except my XML
file and an XSL file.
Has anyone else seen weird behavior or changes in behavior like that?
Daniel
--
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com
Re: Fixing LDAP Examples
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Mon, 10 Apr 2000, you wrote:
> Do know why the <?xml-stylesheet href="ldap.xsl" type="text/xsl"?> and
> <?cocoon-process type="xslt"?> processing instructions are necessary just
> to get the LDAP processor to run?
>
> (Why isn't "<?cocoon-process type="ldap"?>" sufficient?)
Oh, it's sufficent, you just don't get to see it rendered as HTML without the
xsl. Unless, of course, you rewrite it as XHTML. *grin*
Since I don't do too much with Cocoon from the command line, I like to have the
xslt process run.
--
- Kevin Sonney
kevin@webslingerZ.com
Re: Fixing LDAP Examples
Posted by Daniel Barclay <Da...@digitalfocus.com>.
Daniel Barclay wrote:
>
...
> Do know why ...
^^
"Do you know why ...", that is.
--
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com
Re: Fixing LDAP Examples
Posted by Daniel Barclay <Da...@digitalfocus.com>.
Daniel Barclay wrote:
>
...
> Do know why ...
^^
"Do you know why ...", that is.
--
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com
VoxML example working?
Posted by Matthew Langham <ml...@sundn.de>.
Hi
I cant get the cocoon VoxML example to work - its just rendered in the
browser - with no speech to be heard. Has anyone got this running? What am I
missing. And yes I have the VoxML SDK installed.
Matthew
--
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
------------------------------------------------------------------------------------------
...this mail was scanned for viruses by mailserver...
Re: Fixing LDAP Examples
Posted by Daniel Barclay <Da...@digitalfocus.com>.
Kevin Sonney wrote:
>
...> The default ldap.xml is incorrect. To properly run,l it should look like this :
>
...
> <?xml version="1.0"?>
> <?xml-stylesheet href="ldap.xsl" type="text/xsl"?>
>
> <?cocoon-process type="ldap"?>
> <?cocoon-process type="xslt"?>
> <page>
>
> <ldap-defs>
> <ldap-server name="searchlight">
> <initializer>com.sun.jndi.ldap.LdapCtxFactory</initializer>
> <ldap-serverurl>ldap://ldap.bigfoot.com/</ldap-serverurl>
> </ldap-server>
> </ldap-defs>
>
> <ldap-query server="searchlight" ldap-searchbase="c=US">
> sn=smith*
> </ldap-query>
>
> </page>
Do know why the <?xml-stylesheet href="ldap.xsl" type="text/xsl"?> and
<?cocoon-process type="xslt"?> processing instructions are necessary just
to get the LDAP processor to run?
(Why isn't "<?cocoon-process type="ldap"?>" sufficient?)
Daniel
--
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com
Re: Fixing LDAP Examples
Posted by Daniel Barclay <Da...@digitalfocus.com>.
Kevin Sonney wrote:
>
...> The default ldap.xml is incorrect. To properly run,l it should look like this :
>
...
> <?xml version="1.0"?>
> <?xml-stylesheet href="ldap.xsl" type="text/xsl"?>
>
> <?cocoon-process type="ldap"?>
> <?cocoon-process type="xslt"?>
> <page>
>
> <ldap-defs>
> <ldap-server name="searchlight">
> <initializer>com.sun.jndi.ldap.LdapCtxFactory</initializer>
> <ldap-serverurl>ldap://ldap.bigfoot.com/</ldap-serverurl>
> </ldap-server>
> </ldap-defs>
>
> <ldap-query server="searchlight" ldap-searchbase="c=US">
> sn=smith*
> </ldap-query>
>
> </page>
Do know why the <?xml-stylesheet href="ldap.xsl" type="text/xsl"?> and
<?cocoon-process type="xslt"?> processing instructions are necessary just
to get the LDAP processor to run?
(Why isn't "<?cocoon-process type="ldap"?>" sufficient?)
Daniel
--
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com
Re: Fixing LDAP Examples
Posted by Ian Abbott <ia...@cinesite.co.uk>.
Seb wrote:
>
> > (ii) into the java library extension area, e.g. /usr/java/lib/ext (or
> > similar). This is your best option as JNDI is an official Sun extension
> > to Java. Placing the JAR files here will allow Java to find the
> > extensions both from the webserver (you won't need to add them to
> > wrapper.classpath) and from command line *automatically*, which will
> > help if you start playing around with Cocoon CVS tarballs.
>
> This does not work for me. I did not found any library extension area
> (directory) in my /usr/lib/jdk1.2.2/ and it does not work if I put
> them into lib/ext, the JVM does not find them *automatically* :-(
> Should I unzip all jar files (Sorry for the off-topic question) ?
>
Hmm, seems to vary in location from JDK to JDK and from platform to
platform. On the SGI IRIX distribution, it's /usr/java/lib/ext. I've
heard other people report JAVAHOME/jre/lib/ext, and so forth as well. As
for picking up automatically, I assumed this was the case for all JDKs;
the SGI JVM picks everything in ext/ up without having to be referenced
in the classpath, and I'm sure other people such as Pier have mentioned
the extensions folder being used 'automatically'.
However, keeping the JARs in a separate area which is controllable works
just as well. Whether that's somewhere within the servlet engine library
area or elsewhere, as long as you can reference the JAR files within the
servlet engine classpath things should work OK.
If command-line use is required, you can also pass the -extdirs flag to
javac to set the location of Java extensions; for example, javac in SGI
JDK 1.2.1 reports:-
Usage: javac <options> <source files>
where <options> includes:
-g Generate all debugging info
-g:none Generate no debugging info
-g:{lines,vars,source} Generate only some debugging info
-O Optimize; may hinder debugging or enlarge class
files
-nowarn Generate no warnings
-verbose Output messages about what the compiler is
doing
-deprecation Output source locations where deprecated APIs
are used
-classpath <path> Specify where to find user class files
-sourcepath <path> Specify where to find input source files
-bootclasspath <path> Override location of bootstrap class files
-extdirs <dirs> Override location of installed extensions
-d <directory> Specify where to place generated class files
-encoding <encoding> Specify character encoding used by source files
-target <release> Generate class files for specific VM version
As for unzipping the JAR files, I've thought it best to leave them
alone...
Ian
Re: Fixing LDAP Examples
Posted by Sebastien Koechlin I-VISION <sk...@n-soft.com>.
Ian Abbott wrote :
> Basically, to run LDAP, you need the following files:
>
> jndi1_2_1.zip (contains core JNDI 1.2.1)
> ldap1_2_1.zip (contains LDAP service provider 1.2.1)
>
> Unzip these once you've downloaded them from
> http://java.sun.com/products/jndi/ and then either copy the jar files
> (lib/jndi.jar, lib/ldap.jar, lib/jaas.jar, lib/ldapbp.jar and
> lib/providerutil.jar):
>
> (i) into the webserver classpath, e.g. /usr/local/apache/jserv/lib, or
> wherever you keep your various JAR files. Then add the JNDI JARs to the
> server configuration. e.g. for JServ, you'd update wrapper.classpath in
> jserv.properties.
I think this text can be added to the FAQ :
http://xml.apache.org/cocoon/faqs.html#faq-9
Why the LDAP processor doesn't work?
It looks like the LDAP Processor is working.
Problems are now in the example.
About the FAQ : anchor aren't working any more, full of :
<A name=""><!--anchor--></A>
> (ii) into the java library extension area, e.g. /usr/java/lib/ext (or
> similar). This is your best option as JNDI is an official Sun extension
> to Java. Placing the JAR files here will allow Java to find the
> extensions both from the webserver (you won't need to add them to
> wrapper.classpath) and from command line *automatically*, which will
> help if you start playing around with Cocoon CVS tarballs.
This does not work for me. I did not found any library extension area
(directory) in my /usr/lib/jdk1.2.2/ and it does not work if I put
them into lib/ext, the JVM does not find them *automatically* :-(
Should I unzip all jar files (Sorry for the off-topic question) ?
--
Seb
Re: Fixing LDAP Examples
Posted by Ian Abbott <ia...@cinesite.co.uk>.
Kevin Sonney wrote:
>
> You don't need to modify the command line, but you do need to get *ALL* of the
> JNDI jar files from Sun - especially ldap.jar.
>
> I'm pretty sure I don't nee dall of them to make the LDAP processor work,
> but I figure it's better safe than sorry. I *THINK* ldap.jar was included as
> part of the COS package, but don't quote me *grin*
>
ldap.jar (plus jaas.jar, ldapbp.jar, plus a spare copy of
providerutil.jar) come in the LDAP collection of files, also available
from the JNDI download page.
Basically, to run LDAP, you need the following files:
jndi1_2_1.zip (contains core JNDI 1.2.1)
ldap1_2_1.zip (contains LDAP service provider 1.2.1)
Unzip these once you've downloaded them from
http://java.sun.com/products/jndi/ and then either copy the jar files
(lib/jndi.jar, lib/ldap.jar, lib/jaas.jar, lib/ldapbp.jar and
lib/providerutil.jar):
(i) into the webserver classpath, e.g. /usr/local/apache/jserv/lib, or
wherever you keep your various JAR files. Then add the JNDI JARs to the
server configuration. e.g. for JServ, you'd update wrapper.classpath in
jserv.properties.
(ii) into the java library extension area, e.g. /usr/java/lib/ext (or
similar). This is your best option as JNDI is an official Sun extension
to Java. Placing the JAR files here will allow Java to find the
extensions both from the webserver (you won't need to add them to
wrapper.classpath) and from command line *automatically*, which will
help if you start playing around with Cocoon CVS tarballs.
Hope this helps,
Ian
Re: Fixing LDAP Examples
Posted by Kevin Sonney <ke...@webslingerZ.com>.
On Tue, 04 Apr 2000, Sebastien Koechlin I-VISION wrote:
> I found in jndi-1.2.1/examples/api/README something about
> arguments on the JVM command line :
> -Djava.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
> but playing with wrapper.bin.parameters in jserv.properties
> does nothing. And com.sun.jndi.ldap.LdapCtxFactory does
> not exists in jndi.jar
You don't need to modify the command line, but you do need to get *ALL* of the
JNDI jar files from Sun - especially ldap.jar. The Jar files in my JNDI
directory are as follows :
cosnaming.jar
fscontext.jar
jaas.jar
jndi.jar
jndibrowser.jar
ldap.jar
ldapbp.jar
nis.jar
providerutil.jar
rmiregistry.jar
I'm pretty sure I don't nee dall of them to make the LDAP processor work,
but I figure it's better safe than sorry. I *THINK* ldap.jar was included as
part of the COS package, but don't quote me *grin*
--
- Kevin Sonney
kevin@webslingerZ.com
Re: Fixing LDAP Examples
Posted by Sebastien Koechlin I-VISION <sk...@n-soft.com>.
Kevin Sonney a écrit :
>
> On Tue, 04 Apr 2000, you wrote:
> > Error found handling the request.
> > java.lang.NullPointerException
> > at org.apache.cocoon.processor.ldap.LdapDefs.
> > getLdapContext(LdapDefs.java:159)
>
> Right. I saw this more than once. Something is still slightly
> off in the XML, I think.
Ok, one less problem :
It was because I put :
...
<ldap-server name="bigfoot">
...
<ldap-query server="searchlight"...
...
Sorry !
Now I have another error :
javax.naming.NoInitialContextException: Cannot instantiate class:
com.sun.jndi.ldap.LdapCtxFactory. Root exception is
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
(...)
at javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:137)
at org.apache.cocoon.processor.ldap.LdapContextCreator.
getLdapContext(LdapContextCreator.java:82)
(...)
I found in jndi-1.2.1/examples/api/README something about
arguments on the JVM command line :
-Djava.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
but playing with wrapper.bin.parameters in jserv.properties
does nothing. And com.sun.jndi.ldap.LdapCtxFactory does
not exists in jndi.jar
--
Sebastien Koechlin
Re: Fixing LDAP Examples
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Tue, 04 Apr 2000, you wrote:
> Error found handling the request.
> java.lang.NullPointerException
> at org.apache.cocoon.processor.ldap.LdapDefs.
> getLdapContext(LdapDefs.java:159)
Right. I saw this more than once. Something is still slightly off in the XML, I
think.
I cuut/copy/pasted my working version of the file. Could you send yours along
so that James and/or I can look at it?
Or, if you're using the exact same XML file I'm using, I dunno what to tell
you. In my RedHat 6.2/JServ 1.1/Sun JDK 1.2.2/Sun JNDI FCS 1.2.1 it's working
pretty good, except the retun values from bigfoot are...odd.
--
- Kevin Sonney
kevin@webslingerZ.com
Re: Fixing LDAP Examples
Posted by Sebastien Koechlin I-VISION <sk...@n-soft.com>.
Kevin Sonney a écrit :
> The default ldap.xml is incorrect. To properly run,
> it should look like this :
(...)
Ok, it looks better. Instead of Raw XML. I get :
Cocoon 1.7.2
Error found handling the request.
java.lang.NullPointerException
at org.apache.cocoon.processor.ldap.LdapDefs.
getLdapContext(LdapDefs.java:159)
at org.apache.cocoon.processor.ldap.LdapProcessor.
process(LdapProcessor.java:118)
at org.apache.cocoon.Engine.handle(Engine.java:295)
at org.apache.cocoon.Cocoon.service(Cocoon.java:145)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:588)
at org.apache.jserv.JServConnection.
processRequest(JServConnection.java:314)
at org.apache.jserv.JServConnection.run(JServConnection.java:188)
at java.lang.Thread.run(Thread.java:475)
Linux 2.2 - Sun JDK 1.2.2 - ApacheJServ 1.1 - JNDI 1.2.1
jserv.properties:
wrapper.classpath=/usr/lib/apache/jndi.jar
cocoon.properties:
processor.type.ldap=org.apache.cocoon.processor.ldap.LdapProcessor
--
Sebastien Koechlin
RE: Fixing LDAP Examples
Posted by James & Sue Ann Birchfield <js...@home.com>.
I think the examples are mixed up in the release. Just yesterday someone
asked me why it wasn't working for them and sent me the xml file they were
using. The search-base was in the ldap-defs and not the query. If this is
how it is in the release(I will check) then it is wrong. I'll be interested
to see the results of getting it to talk to Bigfoot. They have a funky
looking ldap...:)
=====================================
James Birchfield
Chief Technology Officer
jmbirchfield@proteus-technologies.com
http://www.proteus-technologies.com
=====================================
> -----Original Message-----
> From: Kevin Sonney [mailto:kevin@webslingerz.com]
> Sent: Monday, April 03, 2000 7:18 PM
> To: cocoon-dev@xml.apache.org
> Cc: cocoon-users@xml.apache.org; balld@webslingerz.com
> Subject: Fixing LDAP Examples
>
>
> OK, so I've got everything I need to make LDAP work.
>
> But the darn thing was returning the text of the XML document instead of
> running the query. Hmm. Well, since Donald was handy (he was
> teaching a class
> at the office today about XML/XSL/XSLT) I asked him about it.
>
> Nobody had explained to me that getting the un-marked up text of the xml
> document in your template meant that the processor wasn't processing.
>
> Well, it's the default ldap.xml, so the tags must be right, right?
>
> Nope.
>
> The default ldap.xml is incorrect. To properly run,l it should
> look like this :
>
> <!-- Being LDAP Example -->
> <?xml version="1.0"?>
> <?xml-stylesheet href="ldap.xsl" type="text/xsl"?>
>
> <?cocoon-process type="ldap"?>
> <?cocoon-process type="xslt"?>
> <page>
>
> <ldap-defs>
> <ldap-server name="searchlight">
> <initializer>com.sun.jndi.ldap.LdapCtxFactory</initializer>
> <ldap-serverurl>ldap://ldap.bigfoot.com/</ldap-serverurl>
> </ldap-server>
> </ldap-defs>
>
> <ldap-query server="searchlight" ldap-searchbase="c=US">
> sn=smith*
> </ldap-query>
>
> </page>
> <!-- end LDAP Example -->
>
> Now, I'm working out the new and improved ldap.xsl to go with it.
> but *THIS*
> document will return data from bigfoot's public LDAP server.
>
>
> --
> - Kevin Sonney
> kevin@webslingerZ.com
>
RE: Fixing LDAP Examples
Posted by James & Sue Ann Birchfield <js...@home.com>.
I think the examples are mixed up in the release. Just yesterday someone
asked me why it wasn't working for them and sent me the xml file they were
using. The search-base was in the ldap-defs and not the query. If this is
how it is in the release(I will check) then it is wrong. I'll be interested
to see the results of getting it to talk to Bigfoot. They have a funky
looking ldap...:)
=====================================
James Birchfield
Chief Technology Officer
jmbirchfield@proteus-technologies.com
http://www.proteus-technologies.com
=====================================
> -----Original Message-----
> From: Kevin Sonney [mailto:kevin@webslingerz.com]
> Sent: Monday, April 03, 2000 7:18 PM
> To: cocoon-dev@xml.apache.org
> Cc: cocoon-users@xml.apache.org; balld@webslingerz.com
> Subject: Fixing LDAP Examples
>
>
> OK, so I've got everything I need to make LDAP work.
>
> But the darn thing was returning the text of the XML document instead of
> running the query. Hmm. Well, since Donald was handy (he was
> teaching a class
> at the office today about XML/XSL/XSLT) I asked him about it.
>
> Nobody had explained to me that getting the un-marked up text of the xml
> document in your template meant that the processor wasn't processing.
>
> Well, it's the default ldap.xml, so the tags must be right, right?
>
> Nope.
>
> The default ldap.xml is incorrect. To properly run,l it should
> look like this :
>
> <!-- Being LDAP Example -->
> <?xml version="1.0"?>
> <?xml-stylesheet href="ldap.xsl" type="text/xsl"?>
>
> <?cocoon-process type="ldap"?>
> <?cocoon-process type="xslt"?>
> <page>
>
> <ldap-defs>
> <ldap-server name="searchlight">
> <initializer>com.sun.jndi.ldap.LdapCtxFactory</initializer>
> <ldap-serverurl>ldap://ldap.bigfoot.com/</ldap-serverurl>
> </ldap-server>
> </ldap-defs>
>
> <ldap-query server="searchlight" ldap-searchbase="c=US">
> sn=smith*
> </ldap-query>
>
> </page>
> <!-- end LDAP Example -->
>
> Now, I'm working out the new and improved ldap.xsl to go with it.
> but *THIS*
> document will return data from bigfoot's public LDAP server.
>
>
> --
> - Kevin Sonney
> kevin@webslingerZ.com
>
RE: Fixing LDAP Examples
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Mon, 03 Apr 2000, James & Sue Ann Birchfield wrote:
> I checked through the CVS and found that the LDAP examples are not correct.
> Wish i would have caught that before. I sent Stefano the updated files.
> They should be checked in soon. Sorry for any inconvenience.
Actually, it was a greal learning experience - my first walk through processor
code. *grin* Now, to parse out the BigFoot values - all it's returning right
now is the id attribute to the searchresult node - which is a big ldap url
pointing to their server. Mostly useless, I think.
--
- Kevin Sonney
kevin@webslingerZ.com
RE: Fixing LDAP Examples
Posted by James & Sue Ann Birchfield <js...@home.com>.
I checked through the CVS and found that the LDAP examples are not correct.
Wish i would have caught that before. I sent Stefano the updated files.
They should be checked in soon. Sorry for any inconvenience.
=====================================
James Birchfield
Chief Technology Officer
jmbirchfield@proteus-technologies.com
http://www.proteus-technologies.com
=====================================
> -----Original Message-----
> From: Kevin Sonney [mailto:kevin@webslingerz.com]
> Sent: Monday, April 03, 2000 7:18 PM
> To: cocoon-dev@xml.apache.org
> Cc: cocoon-users@xml.apache.org; balld@webslingerz.com
> Subject: Fixing LDAP Examples
>
>
> OK, so I've got everything I need to make LDAP work.
>
> But the darn thing was returning the text of the XML document instead of
> running the query. Hmm. Well, since Donald was handy (he was
> teaching a class
> at the office today about XML/XSL/XSLT) I asked him about it.
>
> Nobody had explained to me that getting the un-marked up text of the xml
> document in your template meant that the processor wasn't processing.
>
> Well, it's the default ldap.xml, so the tags must be right, right?
>
> Nope.
>
> The default ldap.xml is incorrect. To properly run,l it should
> look like this :
>
> <!-- Being LDAP Example -->
> <?xml version="1.0"?>
> <?xml-stylesheet href="ldap.xsl" type="text/xsl"?>
>
> <?cocoon-process type="ldap"?>
> <?cocoon-process type="xslt"?>
> <page>
>
> <ldap-defs>
> <ldap-server name="searchlight">
> <initializer>com.sun.jndi.ldap.LdapCtxFactory</initializer>
> <ldap-serverurl>ldap://ldap.bigfoot.com/</ldap-serverurl>
> </ldap-server>
> </ldap-defs>
>
> <ldap-query server="searchlight" ldap-searchbase="c=US">
> sn=smith*
> </ldap-query>
>
> </page>
> <!-- end LDAP Example -->
>
> Now, I'm working out the new and improved ldap.xsl to go with it.
> but *THIS*
> document will return data from bigfoot's public LDAP server.
>
>
> --
> - Kevin Sonney
> kevin@webslingerZ.com
>