directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <directory-...@incubator.apache.org>
Subject [jira] Commented: (DIREVE-101) schemaSubentry support
Date Sat, 04 Dec 2004 06:01:22 GMT
     [ http://nagoya.apache.org/jira/browse/DIREVE-101?page=comments#action_56183 ]
     
Alex Karasulu commented on DIREVE-101:
--------------------------------------

For the record according to the last paragraph here in section 3.4 of RFC 2251 the subschemaSubentry
need not be present on replicas but must be present on servers that can be written to (that
master data).

Section 3.4 of http://www.faqs.org/rfcs/rfc2251.html

   "If the server does not master entries and does not know the locations
    of schema information, the subschemaSubentry attribute is not present
    in the root DSE.  If the server masters directory entries under one
    or more schema rules, there may be any number of values of the
    subschemaSubentry attribute in the root DSE."

Basically any authoritative area may contain subentries with schema attributes to which these
Root DSE attributes (schemaSubentries) refer to.  For now we do not have the infrastructure
in place for AAs; nor do other servers like iPlanet for that matter.  We can play it safe
for now and have only one point for all schema settings again like iPlanet.  Basically there
is only one AA with the entire schema superset for the DIT mastered by the Eve DSA.  We can
evolve this over time to get more sophisticated as we introduce AAs.

To enable this support we are going to need to dynamically build the subentry referred to
by these attributes.  The entry essentially will not exist in any backing store.  It will
be generated on the fly from schema objects stored within respective schema object registries
and should be way faster than reading an entry on disk.  We can use the schema interceptor
service to do this.  However we are going to need to change the interceptor framework to allow
bypassing the actual intercepted call.  This is needed to prevent the attempt to lookup these
non-existant entires within a backing store.  I'll add subtasks to this improvement if I can
for this work.



> schemaSubentry support
> ----------------------
>
>          Key: DIREVE-101
>          URL: http://nagoya.apache.org/jira/browse/DIREVE-101
>      Project: Directory Eve
>         Type: Improvement
>   Components: schema
>  Environment: Java
>     Reporter: Mark Swanson
>     Assignee: Alex Karasulu
>      Fix For: 0.8.0

>
> >I'm trying to add a user with JXplorer and receive:
> >"Because there is no schema currently published by the directory, adding a new 
> >entry is unavailable.".
> >
> >  
> >
> Ahhhh right now there is very minimal schema support.  I have not added 
> anything for the schemaSubentry.  Actually this would be really easy to 
> do.  All the schema objects exist within the system in memory within 
> registries.  I just need to have a subschemaSubentry attribute in the 
> RootDSE pointing to something like cn=schema or something which 
> dynamically creates an entry by doing a toString on all objects in the 
> registry.  Yeah this is like a 3-8 hour task.  It should be done for 
> 0.8.0 for sure to make anything useful.  We may not enable schema 
> checking at this point but we sure do need to have a subschemaSubentry. 
> Lots of clients need it to create forms for adding new entries.  That's 
> how they figure out the attributes needed.  Ok Mark can you file this in 
> JIRA too and I'll get to it.  I'll try to get to this one soon as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message