You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by B G <fi...@gmail.com> on 2008/10/10 19:48:23 UTC

[ApacheDS] Error logging

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...

Re: [ApacheDS] Error logging

Posted by Emmanuel Lecharny <el...@gmail.com>.
B G wrote:
> 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.
>   
It has been fixed yesturday :
https://issues.apache.org/jira/browse/DIRSERVER-1278

Just tell us if it's the very same error you have.

Thanks !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

RE: [ApacheDS] Error logging

Posted by B G <fi...@gmail.com>.
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 <fi...@gmail.com>
Date: Fri, Oct 10, 2008 at 10:48 AM
Subject: [ApacheDS] Error logging
To: users <us...@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...