jxplorer-users — For user discussion and install help

[Jxplorer-users] Re: Losing connection loading db

[Chris B. <ch...@pe...>]

Hi Alan,

      It may be that your jvm ran out of memory - you could try using  
the batch script to start and setting arguments to the jvm such as:
-Xmx512m -Xms256m
to increase the default allocation of memory when you start your jvm  
(mx is max, ms is min)

... I have to say that jxplorer is *not* a good tool to use for large  
data sets at a single level; once you get over a couple of thousand  
entries displayed, the java 'swing' tree component really starts to  
grind...

     - Chris

On 27/08/2005, at 5:41 AM, Alan Batie wrote:

> Hi; I just found jxplorer, and it's great! (and this from a died-in- 
> the-wool command line user ;-) ).
>
> But...
>
> We have a 22000+ entry ldap database, and when it's loading it in  
> the Explore section on connection, it gets about halfway through  
> and croaks:
>
> Search partially failed! - only 12,491 entries returned
>
> javax.naming.CommunicationException: connection closed [Root  
> exception is java.io.IOException: connection closed]
> (the server process stays running, so it's not crashing ---  
> openldap 2.2.27)
>     at com.sun.jndi.ldap.LdapCtx.getSearchReply(LdapCtx.java:1883)
>     at com.sun.jndi.ldap.LdapNamingEnumeration.getNextBatch 
> (LdapNamingEnumeration.java:110)
>     at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl 
> (LdapNamingEnumeration.java:197)
>     at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore 
> (LdapNamingEnumeration.java:170)
>     at com.ca.commons.naming.DXOps.postParseNameClassPairs 
> (DXOps.java:170)
>     at com.ca.commons.naming.DXOps.rawSearchOneLevel(DXOps.java:254)
>     at com.ca.commons.jndi.JNDIOps.list(JNDIOps.java:737)
>     at com.ca.directory.jxplorer.broker.JNDIBroker.unthreadedList 
> (JNDIBroker.java:728)
>     at com.ca.directory.jxplorer.broker.Broker.doListQuery 
> (Broker.java:388)
>     at com.ca.directory.jxplorer.broker.Broker.processRequest 
> (Broker.java:202)
>     at com.ca.directory.jxplorer.broker.JNDIBroker.processRequest 
> (JNDIBroker.java:360)
>     at com.ca.directory.jxplorer.broker.Broker.processQueue 
> (Broker.java:158)
>     at com.ca.directory.jxplorer.broker.JNDIBroker.processQueue 
> (JNDIBroker.java:877)
>     at com.ca.directory.jxplorer.broker.Broker.run(Broker.java:124)
>     at java.lang.Thread.run(Thread.java:552)
> Caused by: java.io.IOException: connection closed
>     at com.sun.jndi.ldap.LdapClient.ensureOpen(LdapClient.java:1648)
>     at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java: 
> 661)
>     at com.sun.jndi.ldap.LdapCtx.getSearchReply(LdapCtx.java:1881)
>     ... 14 more
>
>
> -- 
> NOTE TO OUTLOOK USERS: Some versions of Outlook have a bug in
> dealing with digitally signed email like the one you're now reading:
> when replying, before clicking Send, go to the Tools menu and make
> sure that "Digitally Sign" is not checked (unless you actually
> have a digital certificate, but most people don't yet --- see
> https://www.thawte.com/email/ for information on getting one and
> why you should.  Feel free to ask me for help!).
>
> Alan Batie - Peak System Administrator
>
>

Re: [Jxplorer-users] DSMLv2 support in v3.2beta1

[Chris B. <ch...@pe...>]

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 <ch...@pe...> 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 <ch...@pe...> 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 <ch...@pe...> 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
>
>

Re: [Jxplorer-users] DSMLv2 support in v3.2beta1

[Jack S. <jac...@ya...>]

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 <ch...@pe...> 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 <ch...@pe...> 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 <ch...@pe...> 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 
 

Re: [Jxplorer-users] DSMLv2 support in v3.2beta1

[Chris B. <ch...@pe...>]

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 <ch...@pe...> 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 <ch...@pe...> 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,
>>>>>
>>>>> I'm wondering if the DSMLv2 connection setup
>>>>>
>> code
>>
>>>>>
>>>>>
>>>> has
>>>>
>>>>
>>>>> changed in v3.2beta1 (from v3.1). When using
>>>>>
>> v3.1
>>
>>>>>
>>>>>
>>>> I
>>>>
>>>>
>>>>> was able to successfully connect to a DSMLv2
>>>>>
>>>>>
>>>> service.
>>>>
>>>>
>>>>> When using v3.2beta1, the connection setup
>>>>>
>> doesn't
>>
>>>>> complete. I see the namingcontext DNs in the
>>>>>
>>>>>
>>>> "Explore"
>>>>
>>>>
>>>>> window, but the schema doesn't seem to be read.
>>>>>
>> It
>>
>>>>> seems to hang while reading the schema with a
>>>>> "reading..." message. Is this a known bug?
>>>>>
>>>>> Thanks,
>>>>> Jack
>>>>>
>>>>>
>>>>>
>> __________________________________________________
>>
>>>>> Do You Yahoo!?
>>>>> Tired of spam?  Yahoo! Mail has the best spam
>>>>>
>>>>>
>>>> protection around
>>>>
>>>>
>>>>> http://mail.yahoo.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> -------------------------------------------------------
>
>>>
>>>
>>>>> 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
>>>>> Jxp...@li...
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> https://lists.sourceforge.net/lists/listinfo/jxplorer-users
>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> ____________________________________________________
>>
>>> Start your day with Yahoo! - make it your home
>>>
>> page
>>
>>> http://www.yahoo.com/r/hs
>>>
>>>
>>>
>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

Re: [Jxplorer-users] DSMLv2 support in v3.2beta1

[Jack S. <jac...@ya...>]

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 <ch...@pe...> 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 <ch...@pe...> 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,
> >>>
> >>> I'm wondering if the DSMLv2 connection setup
> code
> >>>
> >> has
> >>
> >>> changed in v3.2beta1 (from v3.1). When using
> v3.1
> >>>
> >> I
> >>
> >>> was able to successfully connect to a DSMLv2
> >>>
> >> service.
> >>
> >>> When using v3.2beta1, the connection setup
> doesn't
> >>> complete. I see the namingcontext DNs in the
> >>>
> >> "Explore"
> >>
> >>> window, but the schema doesn't seem to be read.
> It
> >>> seems to hang while reading the schema with a
> >>> "reading..." message. Is this a known bug?
> >>>
> >>> Thanks,
> >>> Jack
> >>>
> >>>
> __________________________________________________
> >>> Do You Yahoo!?
> >>> Tired of spam?  Yahoo! Mail has the best spam
> >>>
> >> protection around
> >>
> >>> http://mail.yahoo.com
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
>
-------------------------------------------------------
> >
> >>> 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
> >>> Jxp...@li...
> >>>
> >>>
> >>
> >>
> >
>
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
> >
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> ____________________________________________________
> > Start your day with Yahoo! - make it your home
> page
> > http://www.yahoo.com/r/hs
> >
> >
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Jxplorer-users] Re: Problem with "LDAP: error code 17"

[Chris B. <ch...@pe...>]

Hi Thomas,

     the easiest way to get support is using the jxplorer mailing  
lists at sourceforge; you may also find a question has already been  
answered!

     To work out your problem, the best thing to do might be to check  
the logging on your server.  I'd suspect there was some subtle  
difference in the attribute name - in the table editor the attribute  
name is read from the schema, while in the html view it usually  
depends on what the writer of the html form wrote in the html.

     The first thing you need to do is figure out which attribute is  
giving you trouble - the server logs, or turning lots of logging on  
in JXplorer, should tell you which it is.  (Note that there was a  
problem in the most recent but one version of JX that prevented BER  
tracing working; yesterdays release should work however).

     cheers,

          Chris

On 18/08/2005, at 11:49 PM, Thomas Karlsson wrote:

> Hello.
>
> I don't know if it is possible to get some support for JXplorer, I
> didn't find anything about support but saw your name as a contact  
> person
> on the wb side.
> We are evaluating JXplorer for a easier way to administrate our Novell
> eDirectory (ver 8.7.3). All works well except for one thing. When I
> update an attribute on a user (as address or telephone number) in the
> HTML View I got the following message when I click on the Submit
> button:
>
> javax.naming.directory.InvalidAttributeIdentifierException:
>  [LDAP: error code 17 - Undefined Attribute Type];
> remaining name 'cn=SKO0029,ou=BUT,ou=DET,o=NGAB'
>
> Altering the same attribute in the Table Editor works ok, the problem
> is only in the HTML View. I have tried different attributes on  
> different
> objects logged in as different users with the same result.
>
> Do you know if ther is somthing we can to to fix this?
>
> Best regards
> Thomas Karlsson
> Nilson Group
> Varberg, Sweden
>

Re: [Jxplorer-users] DSMLv2 support in v3.2beta1

[Chris B. <ch...@pe...>]

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 <ch...@pe...> 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,
>>>
>>> I'm wondering if the DSMLv2 connection setup code
>>>
>> has
>>
>>> changed in v3.2beta1 (from v3.1). When using v3.1
>>>
>> I
>>
>>> was able to successfully connect to a DSMLv2
>>>
>> service.
>>
>>> When using v3.2beta1, the connection setup doesn't
>>> complete. I see the namingcontext DNs in the
>>>
>> "Explore"
>>
>>> window, but the schema doesn't seem to be read. It
>>> seems to hang while reading the schema with a
>>> "reading..." message. Is this a known bug?
>>>
>>> Thanks,
>>> Jack
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam
>>>
>> protection around
>>
>>> http://mail.yahoo.com
>>>
>>>
>>>
>>>
>>
>>
> -------------------------------------------------------
>
>>> 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
>>> Jxp...@li...
>>>
>>>
>>
>>
> https://lists.sourceforge.net/lists/listinfo/jxplorer-users
>
>>>
>>>
>>
>>
>>
>
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>

Re: [Jxplorer-users] DSMLv2 support in v3.2beta1

[Jack S. <jac...@ya...>]

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 <ch...@pe...> 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,
> >
> > I'm wondering if the DSMLv2 connection setup code
> has
> > changed in v3.2beta1 (from v3.1). When using v3.1
> I
> > was able to successfully connect to a DSMLv2
> service.
> > When using v3.2beta1, the connection setup doesn't
> > complete. I see the namingcontext DNs in the
> "Explore"
> > window, but the schema doesn't seem to be read. It
> > seems to hang while reading the schema with a
> > "reading..." message. Is this a known bug?
> >
> > Thanks,
> > Jack
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> >
> >
>
-------------------------------------------------------
> > 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
> > Jxp...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
> >
> 
> 



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

RE: [Jxplorer-users] DSMLv2 support in v3.2beta1

[Ersvaer, T. <Tru...@ca...>]

Hi Jack,

There have been changes in JXplorer re DSML.  JXplorer now uses it's own
DSML provider for communicating to a DSML server.  However, I can't
verify in which version of JXplorer the changes were applied.  Chris
should be able to answer this.

I'm not sure that I understand your problem.  What I gather is that you
attempted to connect to a DSML server using JXplorer.  It succeeds but
you see some (but not all) unexpected schema information in the Explorer
tab?  It sounds like there is a node in the tree that hangs with the
text "reading..."?

Perhaps you could send us a screen shot of this behaviour along with
more information...
1) Operating system
2) Java version
3) What DSML server are you using (and the version).
4) How does your DSML server know what Directory to talk to?

Regards,
Trudi.


-----Original Message-----
From: jxp...@li...
[mailto:jxp...@li...] On Behalf Of Jack
Smith
Sent: Tuesday, 16 August 2005 11:59 AM
To: jxp...@li...
Subject: [Jxplorer-users] DSMLv2 support in v3.2beta1

Hi,

I'm wondering if the DSMLv2 connection setup code has
changed in v3.2beta1 (from v3.1). When using v3.1 I
was able to successfully connect to a DSMLv2 service.
When using v3.2beta1, the connection setup doesn't
complete. I see the namingcontext DNs in the "Explore"
window, but the schema doesn't seem to be read. It
seems to hang while reading the schema with a
"reading..." message. Is this a known bug?

Thanks,
Jack

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20


-------------------------------------------------------
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
Jxp...@li...
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Jxplorer-users] Re: Is jxplorer with SSL working with IBM Tivoli Direcotry Server 6.0?

[Chris B. <ch...@pe...>]

Hi Chris,

    JX SSL works fine with  most SSL enabled directories - it simply  
uses the standard built in java ssl sockets.  Most likely the problem  
is to do with not setting up the certificates correctly; check the  
certificates in the keystore carefully, and if you are using SASL  
(client authenticated SSL) make sure you have the correct private key  
associated with your client certificate.

    The debug procedure is
    a) make sure normal, non-ssl connection works (which I gather it  
does)
    b) make sure basic server authenticated SSL works - this tells  
you that JX has the right server certificate
    c) attempt client authenticated SSL, carefully checking the  
client certificate and private key

    ... if step c fails, try turning on 'full' logging and you can  
debug the ssl handshake... (and do the same at the server end) but 9  
times out of 10, it's because the client cert and key hasn't been set  
up properly :-)

    - Chris

On 17/08/2005, at 12:12 AM, KG_gmail wrote:

> Hi,
>
> so far I had no successfull try to setup ssl connection  
> (Authenticated SSL).
>
> all my clients of LDAP server uses SSL (key databases maintained using
> gsk7ikm) works perfectly.
>
> jexplorer without SSL works perfectly.
>
> regards,
> Chris
>

[Jxplorer-users] DSMLv2 support in v3.2beta1

[Jack S. <jac...@ya...>]

Hi,

I'm wondering if the DSMLv2 connection setup code has
changed in v3.2beta1 (from v3.1). When using v3.1 I
was able to successfully connect to a DSMLv2 service.
When using v3.2beta1, the connection setup doesn't
complete. I see the namingcontext DNs in the "Explore"
window, but the schema doesn't seem to be read. It
seems to hang while reading the schema with a
"reading..." message. Is this a known bug?

Thanks,
Jack

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com