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

Note that I had to replace the unicode 0x00 char in the previous screen by '0x00', otherwise JIRA does not accept the 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.

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

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.

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 ?

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

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.

• 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

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.

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.

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