Hi Jack,
that sounds like a good idea! I'll stick that in pronto :-).
thanks for tracking the problem down!
*Sigh* - a future rewrite of JXplorer will use the OIDs, which
will avoid this sort of problem. I note that RFC 2252 uses the same
capitalisation as JXplorer (i.e. mixed case) but the case insensitive
way is much safer...
- Chris
On 20/08/2005, at 9:28 AM, Jack Smith wrote:
Hi Chris,
So the problem indeed had to do with the case of
attribute names. JX expects "subschemaSubentry",
"attributeTypes", etc. while the underlying directory
I'm working with always returns lower-case attribute
names. I feel really silly for not noticing the
existence of jxplorer.jar yesterday.
I changed the following line in DsmlContext.java and
all's well :-)
BasicAttributes atts = new BasicAttributes();
TO
BasicAttributes atts = new BasicAttributes(true);
(This causes the case to be ignored in the attribute
set while looking for attributes by name)
Maybe you might want to consider this to bypass the
case-mismatch problem? I'm not sure if the Attributes
returned by
javax.naming.InitialContext.getAttributes() are
case-insensitive or not. So you might still need need
to handle case-mismatch in the code.
Thanks for the help,
Jack
--- Chris Betts <[EMAIL PROTECTED]> wrote:
Hi Jack,
the only DMSL servers I have tried it against
is CA's eTrust
Directory DSML option, and some DSML feeds from
other CA products.
Others have used it for other products though -
however the problem
here isn't a DSML problem, it's a sub schema entry
identification
problem. The relevant code is, as you've guessed,
in SchemaOps, in
the method 'getSchemaRoot'. If you're having
trouble with the
logging, stick in System.out statements :-).
Um, as for the logging, all I can unhelpfully
say is that it
works for me :-). Try grabbing the latest version
from sourceforge,
we made some changes to the logging in that, it
might be slightly
better (It's what I just tested a moment ago, and it
printed out the
getSchemaRoot() log messags fine...).
cheers,
Chris
P.S. The other thing you could try is tracing the
DSML calls, to see
what really is going on... your server might be able
to do this, or
you can use a monitoring proxy...
On 19/08/2005, at 1:43 PM, Jack Smith wrote:
Hi Chris,
I looked over the schema-related code. I thought
maybe
the case of the attribute name should be
identical,
i.e. if JX is looking for subschemaSubentry but
the
DSML server returns subschemasubentry, it might
lead
to JX not finding the attribute. But that doesn't
seem
to be the case. I finally changed all occurrences
of
"cn=schema" in SchemaOps.java to the DN returned
by my
DSML server ("cn=subschemasubentry"), but that
hasn't
fixed the problem either.
Can you tell me what DSML servers you'll have
tested
JX with. Maybe looking at the DSML returned by one
of
those servers would shed some light.
Also, how do I get the log messages in
SchemaOps.java
to actually be logged. Setting the logging level
to
ALL+BER didn't help.
Thanks,
Jack
--- Chris Betts <[EMAIL PROTECTED]> wrote:
Interesting; it doesn't sound like a DSML problem
then, but a schema
checking problem.
If JX is working correctly, it should check the
root
entry for the
'subschemaSubentry' attribute, which tells it
where
the schema is
held. However many directories don't seem to
publish this correctly,
so if it can't get anything sensible from the
subschema subentry
attribute, it defaults to using 'cn=schema'
(which
is what many
servers use anyway).
It sounds like the first step isn't working for
you
for some reason?
Although I'm at a loss as to why it should have
worked before but not
now; this stuff is at a much higher level than
the
actual protocol.
If you want to look at the code yourself, it's in
'com.ca.commons.jndi.SchemaOps.java', in the
method
'getSchemaRoot()'.
- Chris
On 18/08/2005, at 5:21 AM, Jack Smith wrote:
Chris,
I looked at the HTTP packets being exchanged
between
JXplorer and the DSML server, and it seems that
JXplorer v3.2beta1 searches for "cn=schema"
while
looking for the schema even though the DSML
server
indicates that the subschema subentry is located
at
"cn=subschemasubentry". This seems to cause the
schema
reading to hang.
I am currently using a DSML server that I wrote
up.
The DSML I send back during connection setup
looks
ok,
but maybe there's something JXplorer is not
expecting.
Where can I find a list of DSML servers that
JXplorer
has been tested with? I can use one of them as a
reference setup as I work on my DSML server.
Thanks,
Jack
--- Chris Betts <[EMAIL PROTECTED]> wrote:
Hi Jack,
yes, the DSML handling has changed - the
original was based on
Sun code, and there are possible licensing
issues
with that, as well
as some quality problems. The new DSML code is
much
lighter weight,
but has only been tested with a handful of DSML
providers. If you
find problems with the DSML code, and can
figure
out
what they are,
we'll happily fix it up :-).
- Chris
On 16/08/2005, at 11:58 AM, Jack Smith wrote:
Hi,
=== message truncated ===
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jxplorer-users mailing list
Jxplorer-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
