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
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
