directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B G" <fitz...@gmail.com>
Subject RE: [ApacheDS] Error logging
Date Fri, 10 Oct 2008 22:09:17 GMT
I saw your response...thanks.
The error mentioned in the JIRA is the one I saw when referring to similiar
logic in the directory code that I use myself. When I do the same logic as
mentioned in the JIRA comments, but instead using a DirContext.lookup as
opposed to DefaultCoreSession.lookup,  I will get an error like the
following. I believe this should be a warning as well.

2008-10-10 11:21:38,218 [pool-1-thread-2] ERROR
org.apache.directory.server.ldap.handlers.ReferralAwareRequestHandler -
NO_SUCH_OBJECT: failed for     SearchRequest
        baseDn : '2.5.4.3=applications,0.9.2342.19200300.100.1.25=vms'
        filter : '(2.5.4.0=*:[1])'
        scope : base object
        typesOnly : false
        Size Limit : no limit
        Time Limit : no limit
        Deref Aliases : deref Always
        attributes :
: Attempt to search under non-existant entry: cn=applications,dc=vms
org.apache.directory.shared.ldap.exception.LdapNameNotFoundException:
Attempt to search under non-existant entry: cn=applications,dc=vms
    at
org.apache.directory.server.core.exception.ExceptionInterceptor.assertHasEntry(ExceptionInterceptor.java:581)
    at
org.apache.directory.server.core.exception.ExceptionInterceptor.search(ExceptionInterceptor.java:552)
    at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:1251)
    at
org.apache.directory.server.core.authz.DefaultAuthorizationInterceptor.search(DefaultAuthorizationInterceptor.java:503)
    at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:1251)
    at
org.apache.directory.server.core.authz.AciAuthorizationInterceptor.search(AciAuthorizationInterceptor.java:1027)
    at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:1251)
    at
org.apache.directory.server.core.authn.AuthenticationInterceptor.search(AuthenticationInterceptor.java:404)
    at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:1251)
    at
org.apache.directory.server.core.normalization.NormalizationInterceptor.search(NormalizationInterceptor.java:182)
    at
org.apache.directory.server.core.interceptor.InterceptorChain.search(InterceptorChain.java:860)
    at
org.apache.directory.server.core.DefaultOperationManager.search(DefaultOperationManager.java:365)
    at
org.apache.directory.server.core.DefaultCoreSession.search(DefaultCoreSession.java:451)
    at
org.apache.directory.server.ldap.handlers.SearchHandler.doSimpleSearch(SearchHandler.java:358)
    at
org.apache.directory.server.ldap.handlers.SearchHandler.handleIgnoringReferrals(SearchHandler.java:611)
    at
org.apache.directory.server.ldap.handlers.SearchHandler.handleIgnoringReferrals(SearchHandler.java:72)
    at
org.apache.directory.server.ldap.handlers.ReferralAwareRequestHandler.handle(ReferralAwareRequestHandler.java:145)
    at
org.apache.directory.server.ldap.handlers.ReferralAwareRequestHandler.handle(ReferralAwareRequestHandler.java:66)
    at
org.apache.directory.server.ldap.handlers.LdapRequestHandler.messageReceived(LdapRequestHandler.java:171)
    at
org.apache.directory.server.ldap.handlers.LdapRequestHandler.messageReceived(LdapRequestHandler.java:46)
    at
org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:141)
    at
org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:181)
    at
org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:570)
    at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
    at
org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
    at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
    at
org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:58)
    at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:180)
    at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
    at
org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
    at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
    at
org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:220)
    at
org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
    at java.lang.Thread.run(Thread.java:595)

---------- Forwarded message ----------
From: B G <fitzbew@gmail.com>
Date: Fri, Oct 10, 2008 at 10:48 AM
Subject: [ApacheDS] Error logging
To: users <users@directory.apache.org>


I use apache directory embedded in an application and I have recently
upgraded from version 1.5.1 to 1.5.4. I have noticed that there has been
quite a bit of change, but what I am questioning now is the change in
logging behavior. In the past I have had code which will do a lookup to see
if a context exists and then create it if not...this being the case on first
start. I see similiar code in the directory itself. In 1.5.1 this did not
result in errors being logged, but now it result in numerous stack traces
getting logged as errors. I can of course suppress these with logging
configuration, but I am forced to turn off error logging on some high level
directory classes that I hesitate to do, but the choice of having all these
stack traces logged in not desirable as well. It seems that if a lookup
fails this at most should be considered a warning with the appropriate
exception being thrown. I am curious as to the thinking behind this change.

Thanks...

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message