Uploaded image for project: 'Directory Studio'
  1. Directory Studio
  2. DIRSTUDIO-1061

RawSchemaDefinition always shows single hyphen/dash (empty) for attributes or classes

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M9 (2.0.0.v20150606-M9)
    • Component/s: studio-schemaeditor
    • Labels:
      None
    • Environment:
      openSUSE 13.1 x86_64
      NetIQ eDirectory 8.8 SP8 backend
      OpenLDAP backend
      ApacheDS 2.0.0 (within Apache Directory Studio)

      Description

      A part of Apache Directory Studio I use a fair bit is the view of the RawSchemaDefinition within the Schema Editor. Attempting to use this in M9 (where I'm 99.99% sure it worked in M8, or whatever the previous public milestone was from 2013) yields nothing but the hyphen/dash that indicates nothing is there.

      Steps to duplicate:
      Point to a directory (ldap.forumsys.com:389 is public and duplicates the problem)
      Click on Root DSE
      LDAP (menu): Open Schema Editor
      Click on any class or attribute and attempt to get information when expanding the RawSchemaDefinition field.

      Expected Results: Show the raw schema definition.

      Actual Results: No raw schema definition anymore.

      Reproducible: Always

      I pointed to three different types of servers in case something was amiss with one of their schema representations, but all of them exhibit the same symptom, including the built-in ApacheDS instance that I created anew in Studio M9.

        Activity

        Hide
        dajoker Aaron Burgemeister added a comment -

        I can work around it reliably by setting this when calling the ApacheDirectoryStudio binary:

        GTK2_RC_FILES=/usr/share/themes/Default/gtk-2.0-key/gtkrc

        I realized I was not starting the nightly build with the script I have that starts my main build. This line, which I think I started using with M8, does good things, whatever it's doing behind the scenes. Since I think I found it from some notes on this site, this is probably a valid workaround, and not a regression of any kind. Sorry for not doing better testing originally.
        AB

        Show
        dajoker Aaron Burgemeister added a comment - I can work around it reliably by setting this when calling the ApacheDirectoryStudio binary: GTK2_RC_FILES=/usr/share/themes/Default/gtk-2.0-key/gtkrc I realized I was not starting the nightly build with the script I have that starts my main build. This line, which I think I started using with M8, does good things, whatever it's doing behind the scenes. Since I think I found it from some notes on this site, this is probably a valid workaround, and not a regression of any kind. Sorry for not doing better testing originally. AB
        Hide
        seelmann Stefan Seelmann added a comment -

        Aaron, I was not able to reproduce your problem with unresponsive schema browser. I downloaded 2.0.0.v20150701 linux 64 bit, I was able to browse through all OC, AT, matching rules, etc.

        Show
        seelmann Stefan Seelmann added a comment - Aaron, I was not able to reproduce your problem with unresponsive schema browser. I downloaded 2.0.0.v20150701 linux 64 bit, I was able to browse through all OC, AT, matching rules, etc.
        Hide
        dajoker Aaron Burgemeister added a comment - - edited

        Stefan,

        Thank-you for the quick answers.

        The nightly build resolves the issue satisfactorily, though there is a new issue when going into the Schema Browser. Specifically, when opening the Schema Browser everything looks fine until you click on one of the listed classes (it always opens to the Classes tab so far) and nothing happens. Trying to close the Schema Browser also does not work (seems unresponsive all around) but if I click on any other tab in the Schema Browser (Attributes, Syntaxes, etc.) it seems to come back to life, and from then on everything works, including going back to the Classes tab. Per the original bug report, once I can click on a class, attribute, or otherwise, I can see the RawSchemaDefinition as expected by clicking on that to expand it, so that is wonderful. I would report this other issue as a new bug, but being the 20150701 nightly build I'm not sure I should do that. Also, the Schema Browser is much slower than the current M9 build's, but again this is a nightly and who knows how many changes are in the works, optimizations left out for a final build, etc. If you would like a new bug report for the Schema Browser symptom described above, please confirm and I'll open that for you.

        Unit tests, understandable. The fixed line (just a few characters, as seems to be the case most of the time) looks so simple, and I'm glad I didn't pursue this as I never would have worked that out so well. The tests I will trust work; it looks like one of the files checks to match a regex that a raw schema definition has 'NAME' somewhere in it, which is a safe assumption for every class and attribute raw schema definition in existence I think, so that makes sense.

        One quick edit: the link to the version repository did not work unless I took the 'r' out of the last parameter, resulting in the following: https://svn.apache.org/viewvc?view=revision&revision=1687861

        Thanks for everything.

        Show
        dajoker Aaron Burgemeister added a comment - - edited Stefan, Thank-you for the quick answers. The nightly build resolves the issue satisfactorily, though there is a new issue when going into the Schema Browser. Specifically, when opening the Schema Browser everything looks fine until you click on one of the listed classes (it always opens to the Classes tab so far) and nothing happens. Trying to close the Schema Browser also does not work (seems unresponsive all around) but if I click on any other tab in the Schema Browser (Attributes, Syntaxes, etc.) it seems to come back to life, and from then on everything works, including going back to the Classes tab. Per the original bug report, once I can click on a class, attribute, or otherwise, I can see the RawSchemaDefinition as expected by clicking on that to expand it, so that is wonderful. I would report this other issue as a new bug, but being the 20150701 nightly build I'm not sure I should do that. Also, the Schema Browser is much slower than the current M9 build's, but again this is a nightly and who knows how many changes are in the works, optimizations left out for a final build, etc. If you would like a new bug report for the Schema Browser symptom described above, please confirm and I'll open that for you. Unit tests, understandable. The fixed line (just a few characters, as seems to be the case most of the time) looks so simple, and I'm glad I didn't pursue this as I never would have worked that out so well. The tests I will trust work; it looks like one of the files checks to match a regex that a raw schema definition has 'NAME' somewhere in it, which is a safe assumption for every class and attribute raw schema definition in existence I think, so that makes sense. One quick edit: the link to the version repository did not work unless I took the 'r' out of the last parameter, resulting in the following: https://svn.apache.org/viewvc?view=revision&revision=1687861 Thanks for everything.
        Hide
        seelmann Stefan Seelmann added a comment -
        Show
        seelmann Stefan Seelmann added a comment - No plan for 2.0.0-M10 release. You can try nightly build here: https://builds.apache.org/view/A-D/view/Directory/job/dir-studio/ Confirmation from you that the bug is fixed is highly welcomed. Unit test is difficult, but SWTBot based integration test has beed added: https://svn.apache.org/viewvc?view=revision&revision=r1687861
        Hide
        dajoker Aaron Burgemeister added a comment -

        Thanks for the update! This is pretty great for me.

        If I may intrude, is it possible to get an updated JAR, or is there an ETA for M10's release? Should I just try a nightly build (I assume those work, but never noticed much difference in them in the past when I tried for similar reasons) to avoid manual work for others here? If nothing else I'd be happy to test in my various environments and provide verification/confirmation that it works for all of my tests. If I knew how to create a unit test I'd do that too.

        Again, thanks for the quick turnaround.

        Show
        dajoker Aaron Burgemeister added a comment - Thanks for the update! This is pretty great for me. If I may intrude, is it possible to get an updated JAR, or is there an ETA for M10's release? Should I just try a nightly build (I assume those work, but never noticed much difference in them in the past when I tried for similar reasons) to avoid manual work for others here? If nothing else I'd be happy to test in my various environments and provide verification/confirmation that it works for all of my tests. If I knew how to create a unit test I'd do that too. Again, thanks for the quick turnaround.
        Hide
        seelmann Stefan Seelmann added a comment -

        I think it makes sense to suport the '_' because we also allow it (at least in relaxed mode) in descr/qdstring like the NAME.

        Anyway, it's fixed in Studio by changeing the key to an xstring: http://svn.apache.org/r1687861

        Show
        seelmann Stefan Seelmann added a comment - I think it makes sense to suport the '_' because we also allow it (at least in relaxed mode) in descr/qdstring like the NAME. Anyway, it's fixed in Studio by changeing the key to an xstring: http://svn.apache.org/r1687861
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Good catch, Stefan. The pb was introduced by commit http://svn.apache.org/r1664350. The side effect is pretty vicious, and was visible in Studio M9 because this version use the API's version where this change has been injected.

        That raises a question : should we support '_' in the Strings.toUpperCase() method ?

        Show
        elecharny Emmanuel Lecharny added a comment - Good catch, Stefan. The pb was introduced by commit http://svn.apache.org/r1664350 . The side effect is pretty vicious, and was visible in Studio M9 because this version use the API's version where this change has been injected. That raises a question : should we support '_' in the Strings.toUpperCase() method ?
        Hide
        elecharny Emmanuel Lecharny added a comment -

        You may be right. I quite remember that at some point, we decided to support '_' in schema, but I can't see where this bug was introduced.

        Show
        elecharny Emmanuel Lecharny added a comment - You may be right. I quite remember that at some point, we decided to support '_' in schema, but I can't see where this bug was introduced.
        Hide
        seelmann Stefan Seelmann added a comment -

        The problem seems to be AbstractSchemaObject.addExtension() method, this uses Strings.toUpperCase() which expects that the key only contains [A-Za-z0-9.-]. I think when we just change the key to X-RAW-SCHEMA-DEFINITION is will work. I'm quite sure in past it already was someting with "X-...".

        Show
        seelmann Stefan Seelmann added a comment - The problem seems to be AbstractSchemaObject.addExtension() method, this uses Strings.toUpperCase() which expects that the key only contains [A-Za-z0-9.-] . I think when we just change the key to X-RAW-SCHEMA-DEFINITION is will work. I'm quite sure in past it already was someting with "X-...".
        Hide
        elecharny Emmanuel Lecharny added a comment -

        The pb is deep deep into the schema browser, AFAICT. When we initialize the table containing the list of schema objetcs, we grab the schema from the connection, in SchemaPage.refresh(), line 129 :

                ...
                else if ( getConnection() != null )
                {
                    schema = getConnection().getSchema();
                }
                ...
        

        Here, the list of objects stored into map are already using the wrong key for extensions.

        Show
        elecharny Emmanuel Lecharny added a comment - The pb is deep deep into the schema browser, AFAICT. When we initialize the table containing the list of schema objetcs, we grab the schema from the connection, in SchemaPage.refresh() , line 129 : ... else if ( getConnection() != null ) { schema = getConnection().getSchema(); } ... Here, the list of objects stored into map are already using the wrong key for extensions.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Note that I had to replace the unicode 0x00 char in the previous screen by '0x00', otherwise JIRA does not accept the comment...

        Show
        elecharny Emmanuel Lecharny added a comment - Note that I had to replace the unicode 0x00 char in the previous screen by '0x00', otherwise JIRA does not accept the comment...
        Hide
        elecharny Emmanuel Lecharny added a comment -

        It's clearly a bug. I'm investigating why the raw schema is not exposed, when it's actually available.

        The pb is that we try to fetch the raw format from a Map using the key RAW_SCHEMA_DEFINITION_LDIF_VALUE when the present key is RAW0 '0x00' SCHEMA '0x00' DEFINITION '0x00' LDIF '0x00' VALUE (note : there are 0x00 chars where '_' are expected).
        If I replace the String with '_' with the one with 0x00, I get the raw format.

        Now to understand why we are storing a key with 0x00 in place of '_'...

        Show
        elecharny Emmanuel Lecharny added a comment - It's clearly a bug. I'm investigating why the raw schema is not exposed, when it's actually available. The pb is that we try to fetch the raw format from a Map using the key RAW_SCHEMA_DEFINITION_LDIF_VALUE when the present key is RAW0 '0x00' SCHEMA '0x00' DEFINITION '0x00' LDIF '0x00' VALUE (note : there are 0x00 chars where '_' are expected). If I replace the String with '_' with the one with 0x00, I get the raw format. Now to understand why we are storing a key with 0x00 in place of '_'...

          People

          • Assignee:
            seelmann Stefan Seelmann
            Reporter:
            dajoker Aaron Burgemeister
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development