directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Possible NPE when shutting down server??
Date Sat, 21 Jul 2007 20:48:52 GMT

On Jul 21, 2007, at 11:42 AM, Emmanuel Lecharny wrote:

> Hi David,
> strange problem... Have you had a look at the AbstractServerTest class
> we are using for our integration tests (it's in server-unit project)?
> src/main/java/org/apache/directory/server/unit/ 
> We are extending tests from this class so that the setup() and
> teardown() methods are common.
> Let us know if you have the same pb with it.

I haven't tried it but imagine it would work since it supplies  
identity and security credentials to shut down the server, and the  
npe I saw was caused by them not being there.  I think more and more  
there's a bad design or bug here:  either the security credentials  
should be checked BEFORE shutting down the server (and problems  
reported with something other than an NPE) or you shouldn't need  
security credentials from inside the same vm.

Let me ask again.... checkSecuritySettings is a half-hearted attempt  
to see if a vague resemblance to security credentials were supplied.   
Why is this check even present in AbstractContextFactory?  It seems  
to me that this class should either rely on something else taking  
care of security (in which case the checkSecuritySettings method  
should be removed) or it should actually check that the credentials  
are valid and that they authorize the action being attempted.

Again, the behavior I'm seeing is that when you try to shut down the  
server and don't supply any credentials, the server is in fact shut  
down, and then it throws an NPE.  I'm fairly sure that this is not  
appropriate behavior, but I don't know whether the shutdown should  
succeed with no objection or if an exception (probably not an NPE)  
should be thrown and the server remain running.

david jencks

> On 7/19/07, David Jencks <> wrote:
>> I'm trying to resuscitate and update the geronimo-apacheds
>> integration and have run into some behavior I don't understand.  Due
>> to lack of internet access when I started I'm using up to date trunk
>> with my xbean-spring mods, but they don't affect this situation
>> compared to regular trunk.
>> In a unit test I'm starting the server with
>> new InitialDirectoryContext(env); which appears to be working ok
>> and stopping it with
>> new InitialDirectoryContext(env) from a shutdown config which is
>> getting an NPE which seems less than appropriate.
>> The code gets into AbstractContextFactory.getInitialContext and on
>> line 115 the server is shut down setting the
>> DefaultDirectoryService.startupConfiguration to null, as seems
>> appropriate.
>> Then on line 146 of AbstractContextFactory we call
>> service.getJndiContext which first does this:
>>          checkSecuritySettings( principal, credential,  
>> authentication );
>>          if ( !started )
>>          {
>>              return new DeadContext();
>>          }
>> and checkSecuritySettings uses startupConfiguration on line 437, thus
>> throwing the NPE.
>> So, this doesn't seem quite right to me.
>> 1. The server has already been shut down by the time we are trying to
>> get the context, so either returning a DeadContext() from
>> AbstractContextFactory after shutting down the server or from
>> DefaultDirectoryService.getJndiContext before checking the security
>> settings seems reasonable.  This would fix my immediate problem
>> 2.  Why is DefaultDirectoryService checking security settings at
>> all?  It's not checking authentication or authorization, just doing
>> some minimal consistency checks, so why not rely on whatever is
>> checking those?  This seems to me like a big separation of concerns
>> problem.
>> 3. Have I missed something or is the usual way to start and stop the
>> server through these new IniitialDirectoryContext() calls?  Is there
>> a reason it isn't started more directly through spring?  I don't see
>> how your'e going to fire up a new jvm through a new
>> InitialDirectoryContext() call, so starting a server is in vm anyway,
>> and allowing remote stopping seems.... like something you might not
>> want to make too easy.
>> thanks
>> david jencks
> -- 
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

View raw message