[jira] Created: (DIRSERVER-964) Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");

This part:
If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.
Is supposed to be:
If I manually attempt to lookup the DirContext that the binding.getObject represents, I get a DirContext instance.




Ole Ersoy (JIRA) wrote:

> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
> ---------------------------------------------------------------------------------------------------
>
>                  Key: DIRSERVER-964
>                  URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>              Project: Directory ApacheDS
>           Issue Type: Bug
>             Reporter: Ole Ersoy
>              Fix For: pre-2.0
>
>
> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.
>
>  

Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
---------------------------------------------------------------------------------------------------

                 Key: DIRSERVER-964
                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
             Project: Directory ApacheDS
          Issue Type: Bug
            Reporter: Ole Ersoy
             Fix For: pre-2.0


See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/DIRSERVER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ole Ersoy updated DIRSERVER-964:
--------------------------------

    Attachment: SelfContainedBindingTest.java

> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-964
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Ole Ersoy
>             Fix For: pre-2.0
>
>         Attachments: SelfContainedBindingTest.java
>
>
> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Howdy,

See if adding these dependencies help:

      <dependency>
         <groupId>org.apache.directory.server</groupId>
         <artifactId>apacheds-core</artifactId>
         <version>1.0.0</version>
      </dependency>
     
      <dependency>
         <groupId>org.slf4j</groupId>
         <artifactId>nlog4j</artifactId>
         <version>1.2.25</version>
      </dependency>

The test creates a hot partition, so it needs the core dependency.

Hopefully that does the trick,
- Ole

    [ https://issues.apache.org/jira/browse/DIRSERVER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503180 ]

Ole Ersoy commented on DIRSERVER-964:
-------------------------------------

I'm just going intuition for this.  The following asserts pass:

          assertEquals("cn=L1,cn=L0,ou=test", binding.getName());
          assertFalse(binding.isRelative());

To me it seems like this should pass:

          assertEquals("cn=L1", binding.getName());
          assertTrue(binding.isRelative());

It seems like binding.getName() is returning what binding.getNameInNamespace() should return.  It also seems like binding.isRelative() should be true, since the object the binding should contain should be a DirContext instance that is relative to L0.

> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-964
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Ole Ersoy
>             Fix For: pre-2.0
>
>         Attachments: SelfContainedBindingTest.java
>
>
> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/jira/browse/DIRSERVER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503182 ]

Emmanuel Lecharny commented on DIRSERVER-964:
---------------------------------------------

Hi,

the test does not compile :
        configuration.setContextPartitionConfigurations( partitions );
does not exist.

Which version of ADS are you using ?

> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-964
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Ole Ersoy
>             Fix For: pre-2.0
>
>         Attachments: SelfContainedBindingTest.java
>
>
> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Emmanuel Lecharny]

Haaa !!!


bad bad bad :)

Don't use ADS 1.0.0, it won't work with Dynamic schema !!!

Emmanuel

PS : I now have the test working, hmmm, failing, but differently :)


Ole Ersoy a écrit :

> Howdy,
>
> See if adding these dependencies help:
>
>      <dependency>
>         <groupId>org.apache.directory.server</groupId>
>         <artifactId>apacheds-core</artifactId>
>         <version>1.0.0</version>
>      </dependency>
>          <dependency>
>         <groupId>org.slf4j</groupId>
>         <artifactId>nlog4j</artifactId>
>         <version>1.2.25</version>
>      </dependency>
>
> The test creates a hot partition, so it needs the core dependency.
>
> Hopefully that does the trick,
> - Ole
>
>
>

    [ https://issues.apache.org/jira/browse/DIRSERVER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503189 ]

Emmanuel Lecharny commented on DIRSERVER-964:
---------------------------------------------

I have changed the test to use :
configuration.setPartitionConfigurations( partitions );

now, I have another pb : it's not a selfcontained test. I have to launch ADS beside the test in order to make it happy. It would be better and easier to fgollow thes tests in server-unit for such self-contained tests.

ok, when I launch ADS beside, here is what  I get :
org.apache.directory.shared.ldap.exception.LdapSchemaViolationException: Attribute cn not declared in objectClasses of entry cn=L0,ou=test
        at org.apache.directory.server.core.schema.SchemaService.assertAllAttributesAllowed(SchemaService.java:1767)
        at org.apache.directory.server.core.schema.SchemaService.check(SchemaService.java:1704)
        at org.apache.directory.server.core.schema.SchemaService.add(SchemaService.java:1722)
        at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
        at org.apache.directory.server.core.operational.OperationalAttributeService.add(OperationalAttributeService.java:171)
        at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
        at org.apache.directory.server.core.exception.ExceptionService.add(ExceptionService.java:205)
        at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
        at org.apache.directory.server.core.interceptor.BaseInterceptor.add(BaseInterceptor.java:100)
        at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
        at org.apache.directory.server.core.authz.AuthorizationService.add(AuthorizationService.java:411)
        at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
        at org.apache.directory.server.core.referral.ReferralService.add(ReferralService.java:292)
        at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
        at org.apache.directory.server.core.authn.AuthenticationService.add(AuthenticationService.java:213)
        at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
        at org.apache.directory.server.core.normalization.NormalizationService.add(NormalizationService.java:117)
        at org.apache.directory.server.core.interceptor.InterceptorChain.add(InterceptorChain.java:698)
        at org.apache.directory.server.core.partition.PartitionNexusProxy.add(PartitionNexusProxy.java:352)
        at org.apache.directory.server.core.partition.PartitionNexusProxy.add(PartitionNexusProxy.java:340)
        at org.apache.directory.server.core.jndi.ServerContext.createSubcontext(ServerContext.java:328)
        at org.apache.directory.server.core.jndi.ServerContext.createSubcontext(ServerContext.java:305)
        at javax.naming.InitialContext.createSubcontext(InitialContext.java:464)
        at SelfContainedBindingTest.testNullBinding(SelfContainedBindingTest.java:99)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
        at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

You have to use createSubContext( Name, Attributes )

> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-964
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Ole Ersoy
>             Fix For: pre-2.0
>
>         Attachments: SelfContainedBindingTest.java
>
>
> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/DIRSERVER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny updated DIRSERVER-964:
----------------------------------------

    Attachment: SelfContainedBindingTest.java

Attached a test which works well.

I there still a pb ?

> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-964
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Ole Ersoy
>             Fix For: pre-2.0
>
>         Attachments: SelfContainedBindingTest.java, SelfContainedBindingTest.java
>
>
> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Emmanuel Lecharny wrote:
> Haaa !!!
>
>
> bad bad bad :)
>
> Don't use ADS 1.0.0, it won't work with Dynamic schema !!!
Hang on though.  I'm using 1.5 for the server.  I assume you mean use
the 1.5 for the dependency needed for the hot partitioning as well.  
I'll try upping that.  When you say the tests are failing do you mean,
they are passing, which means that they are actually failing.  I set
them up so that they would pass...

Ole

SNIP

Supposedly we added a feature that allows us to do
ctx.createSubcontext("cn=test")... without attributes (There's an RFC
for this I think).  The server just adds the necessary ObjectClass for
us.  It runs fine in my tests.  Yes, the server does have to be run
besides the test.  I have to look at the other setup stuff to figure out
how to get around that.

Emmanuel Lecharny (JIRA) wrote:

>     [ https://issues.apache.org/jira/browse/DIRSERVER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503189 ]
>
> Emmanuel Lecharny commented on DIRSERVER-964:
> ---------------------------------------------
>
> I have changed the test to use :
> configuration.setPartitionConfigurations( partitions );
>
> now, I have another pb : it's not a selfcontained test. I have to launch ADS beside the test in order to make it happy. It would be better and easier to fgollow thes tests in server-unit for such self-contained tests.
>
> ok, when I launch ADS beside, here is what  I get :
> org.apache.directory.shared.ldap.exception.LdapSchemaViolationException: Attribute cn not declared in objectClasses of entry cn=L0,ou=test
> at org.apache.directory.server.core.schema.SchemaService.assertAllAttributesAllowed(SchemaService.java:1767)
> at org.apache.directory.server.core.schema.SchemaService.check(SchemaService.java:1704)
> at org.apache.directory.server.core.schema.SchemaService.add(SchemaService.java:1722)
> at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
> at org.apache.directory.server.core.operational.OperationalAttributeService.add(OperationalAttributeService.java:171)
> at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
> at org.apache.directory.server.core.exception.ExceptionService.add(ExceptionService.java:205)
> at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.add(BaseInterceptor.java:100)
> at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
> at org.apache.directory.server.core.authz.AuthorizationService.add(AuthorizationService.java:411)
> at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
> at org.apache.directory.server.core.referral.ReferralService.add(ReferralService.java:292)
> at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
> at org.apache.directory.server.core.authn.AuthenticationService.add(AuthenticationService.java:213)
> at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1142)
> at org.apache.directory.server.core.normalization.NormalizationService.add(NormalizationService.java:117)
> at org.apache.directory.server.core.interceptor.InterceptorChain.add(InterceptorChain.java:698)
> at org.apache.directory.server.core.partition.PartitionNexusProxy.add(PartitionNexusProxy.java:352)
> at org.apache.directory.server.core.partition.PartitionNexusProxy.add(PartitionNexusProxy.java:340)
> at org.apache.directory.server.core.jndi.ServerContext.createSubcontext(ServerContext.java:328)
> at org.apache.directory.server.core.jndi.ServerContext.createSubcontext(ServerContext.java:305)
> at javax.naming.InitialContext.createSubcontext(InitialContext.java:464)
> at SelfContainedBindingTest.testNullBinding(SelfContainedBindingTest.java:99)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
>
> You have to use createSubContext( Name, Attributes )
>
>  
>> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
>> ---------------------------------------------------------------------------------------------------
>>
>>                 Key: DIRSERVER-964
>>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>>             Project: Directory ApacheDS
>>          Issue Type: Bug
>>            Reporter: Ole Ersoy
>>             Fix For: pre-2.0
>>
>>         Attachments: SelfContainedBindingTest.java
>>
>>
>> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.
>>    
>
>  

OK - I updated

      <dependency>
         <groupId>org.apache.directory.server</groupId>
         <artifactId>apacheds-core</artifactId>
         <version>1.5.0</version>
      </dependency>

To 1.5.0 and my tests are still passing.  They are supposed to be green.

Ole Ersoy (JIRA) wrote:

> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
> ---------------------------------------------------------------------------------------------------
>
>                  Key: DIRSERVER-964
>                  URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>              Project: Directory ApacheDS
>           Issue Type: Bug
>             Reporter: Ole Ersoy
>              Fix For: pre-2.0
>
>
> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.
>
>  

Yes - Cause you are cheating :-)  I'm able to create a context without
specifying the attributes.  Alex or Stefan pointed out earlier that the
reason I can do this is because the server now supports some RFC that
says it's ok to do this.   Also, the tests are not supposed to pass.  
When they start failing then maybe it is fixed.  This is if my
assumptions with respect to how this is supposed to work are right though.

You added the person ObjectClass so that the contexts are created.  Now
the tests pass.  But you should be able to run the test just as is.  
What I'm wondering is "Should the test be green?".
It seems to me that assertNull( binding.getObject() ); should not pass.  
The reason for this is that I can lookup the context and when I do it is
an instance of a DirContext.  So I think I should be able to get an
instance from the binding.  

assertEquals( "cn=L1,cn=L0,ou=test", binding.getName() ); based on my
intuition should fail.  It seems like assertEquals(
"cn=L1,cn=L0,ou=test", binding.getNameInNamspace() ); should pass.  I'm
thinking that getName() would return the RDN and getNameInNamespace
should return the DN.

SNIP

Hmmm.  I updated my test with this:

========================================
         Attributes attributes                    =
             new BasicAttributes();
         Attribute attribute                        =
             new BasicAttribute(
                     "objectClass",
                     "top");
         attribute.add("subentry");
         

         directoryContextL0                       =
              (DirContext)
              testPartitionContext.
              createSubcontext(l0RDN, attributes);

         directoryContextL1                       =
              (DirContext)
              directoryContextL0.
              createSubcontext(l1RDN, attributes);
========================================

I think the subentry ObjectClass is part of the RFC that allows this
ctx.createSubcontext("cn=test")....When I try running the test above I
get this:

org.apache.directory.server.core.interceptor.InterceptorException:
Unexpected exception. [Root exception is java.lang.NullPointerException]
    at
org.apache.directory.server.core.interceptor.InterceptorChain.throwInterceptorException(InterceptorChain.java:1510)
    at
org.apache.directory.server.core.interceptor.InterceptorChain.access$700(InterceptorChain.java:52)
    at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1189)



Emmanuel Lecharny (JIRA) wrote:

>      [ https://issues.apache.org/jira/browse/DIRSERVER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Emmanuel Lecharny updated DIRSERVER-964:
> ----------------------------------------
>
>     Attachment: SelfContainedBindingTest.java
>
> Attached a test which works well.
>
> I there still a pb ?
>
>  
>> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
>> ---------------------------------------------------------------------------------------------------
>>
>>                 Key: DIRSERVER-964
>>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>>             Project: Directory ApacheDS
>>          Issue Type: Bug
>>            Reporter: Ole Ersoy
>>             Fix For: pre-2.0
>>
>>         Attachments: SelfContainedBindingTest.java, SelfContainedBindingTest.java
>>
>>
>> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.
>>    
>
>  

    [ https://issues.apache.org/jira/browse/DIRSERVER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503264 ]

Ole Ersoy commented on DIRSERVER-964:
-------------------------------------

Strange.  I bumped my apache-core dependency to 1.5.0 and then tried running your test Emmanuel (After closing eclipse and then opening again).  Now I get this exceptionN:

java.lang.NoSuchMethodError: org.apache.directory.server.core.configuration.MutableStartupConfiguration.setPartitionConfigurations(Ljava/util/Set;)V
        at org.apache.tuscany.das.ldap.selfcontained.test.SelfContainedBindingTest.createDASPartition(SelfContainedBindingTest.java:152)
        at org.apache.tuscany.das.ldap.selfcontained.test.SelfContainedBindingTest.setUp(SelfContainedBindingTest.java:32)

Are you using this dependency?

      <dependency>
         <groupId>org.apache.directory.server</groupId>
         <artifactId>apacheds-core</artifactId>
         <version>1.5.0</version>
      </dependency>

I tried running eclipse:clean eclipse:eclipse and I still get the same exception.

Thanks,
- Ole

> Binding does not return DirContext Object's when creating by doing ctx.createSubcontext("cn=test");
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-964
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-964
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Ole Ersoy
>             Fix For: pre-2.0
>
>         Attachments: SelfContainedBindingTest.java, SelfContainedBindingTest.java
>
>
> See test.  I expect assertNull(binding.getObject()); to fail, but it passes.  If I manually attempt to lookup the DirContext that the same DirContext instance, I get a real directory context.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Emmanuel Lecharny]

> Hang on though.  I'm using 1.5 for the server.  I assume you mean use
> the 1.5 for the dependency needed for the hot partitioning as well.  
> I'll try upping that.  When you say the tests are failing do you mean,
> they are passing, which means that they are actually failing.  I set
> them up so that they would pass...

I now have a success, but I had to modify seriously the test. I have
added it as an attachment to the JIRA

>
> Ole
>
> SNIP
>

[Emmanuel Lecharny]

Ole Ersoy a écrit :

> Supposedly we added a feature that allows us to do
> ctx.createSubcontext("cn=test")... without attributes (There's an RFC
> for this I think).  The server just adds the necessary ObjectClass for
> us.  It runs fine in my tests.  

Well, ADS 1.5.1-SNAPSHOT does not allows that? The pb is that JNDI
createSubContext applied to LDAP not ony bind to the server *but* also
create an entry, which must be valid. As you used a cn in the DN, this
cn *must* be presebt as an attribute. This is the reason wh you must use
the createSubContext( Name, Attributes ) and not the other one.

> Yes, the server does have to be run besides the test.  I have to look
> at the other setup stuff to figure out how to get around that.

Yeah, this would be better. Look at what we have in server-ubit (but
core-unit would be better and faster)

>
>

[Emmanuel Lecharny]

Ole Ersoy a écrit :

> Yes - Cause you are cheating :-)  I'm able to create a context without
> specifying the attributes.  Alex or Stefan pointed out earlier that
> the reason I can do this is because the server now supports some RFC
> that says it's ok to do this.  

Can you pointing me to those RFCs ?

> Also, the tests are not supposed to pass.  When they start failing
> then maybe it is fixed.  This is if my assumptions with respect to how
> this is supposed to work are right though.
>
> You added the person ObjectClass so that the contexts are created.  
> Now the tests pass.  But you should be able to run the test just as
> is.  What I'm wondering is "Should the test be green?".

I get it red, not green without my additions.

>
> It seems to me that assertNull( binding.getObject() ); should not
> pass.  The reason for this is that I can lookup the context and when I
> do it is an instance of a DirContext.  

My understanding is that you are doing a getObject() on a binding
requestion for a null value (""), so you get nothing back. Now, the
semantic of this call is not clear to me.

> So I think I should be able to get an instance from the binding.
> assertEquals( "cn=L1,cn=L0,ou=test", binding.getName() ); based on my
> intuition should fail.  It seems like assertEquals(
> "cn=L1,cn=L0,ou=test", binding.getNameInNamspace() ); should pass.  
> I'm thinking that getName() would return the RDN and
> getNameInNamespace should return the DN.
>
> SNIP
>

[Emmanuel Lecharny]

Ole Ersoy a écrit :

> Hmmm.  I updated my test with this:
>
> ========================================
>         Attributes attributes                    =
>             new BasicAttributes();
>         Attribute attribute                        =
>             new BasicAttribute(
>                     "objectClass",
>                     "top");
>         attribute.add("subentry");
>        
>         directoryContextL0                       =
>              (DirContext)
>              testPartitionContext.
>              createSubcontext(l0RDN, attributes);
>
>         directoryContextL1                       =
>              (DirContext)
>              directoryContextL0.
>              createSubcontext(l1RDN, attributes);
> ========================================
>
> I think the subentry ObjectClass is part of the RFC that allows this
> ctx.createSubcontext("cn=test")....When I try running the test above I
> get this:
>
> org.apache.directory.server.core.interceptor.InterceptorException:
> Unexpected exception. [Root exception is java.lang.NullPointerException]

Plain normal. Unless you put the attribute into the attributes, you will
get this NPE :
attributes.put( attribute );

Now, what is *not* plain normal, is that the server returns a NPE !!!

Can you fill a JIRA for this nasty NPE ?

Thanks !

Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
>
>> Yes - Cause you are cheating :-)  I'm able to create a context without
>> specifying the attributes.  Alex or Stefan pointed out earlier that
>> the reason I can do this is because the server now supports some RFC
>> that says it's ok to do this.  
>
> Can you pointing me to those RFCs ?

Alex said it's RFC 2713
http://mail-archives.apache.org/mod_mbox/directory-dev/200704.mbox/%3Ca32f6b020704031322g2dc0cc69w1a3551997d9856b8@...%3E

>
>> Also, the tests are not supposed to pass.  When they start failing
>> then maybe it is fixed.  This is if my assumptions with respect to how
>> this is supposed to work are right though.
>>
>> You added the person ObjectClass so that the contexts are created.  
>> Now the tests pass.  But you should be able to run the test just as
>> is.  What I'm wondering is "Should the test be green?".
>
> I get it red, not green without my additions.
>
>>
>> It seems to me that assertNull( binding.getObject() ); should not
>> pass.  The reason for this is that I can lookup the context and when I
>> do it is an instance of a DirContext.  
>
> My understanding is that you are doing a getObject() on a binding
> requestion for a null value (""), so you get nothing back. Now, the
> semantic of this call is not clear to me.

Well, a while back Stefan gave me this code for getting and iterating through all child contexts of a specific context:

NamingEnumeration enm = ctx.listBindings("");
while (enm.hasMore()) {
  Binding b = (Binding) enm.next();
  if (b.getObject() instanceof Context) {
    Context child = (Context) b.getObject();
  }
}

It's worked before.  In this instance L0 could have multiple subcontexts like L1A, L1B, L1C, etc.  I'd like to get those DirContext instances, so I can grab the cn attribute.


SNIP