Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.0
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Windows XP SP1.3 w/JRE 1.5_16

      Description

      Lets say your are editing a copy of a source file with your new fancy contest sensitive editor.
      Everything looks great, you make some changes save the file, and later look at the file with a text editor. Much to your surprise all the comments you worked so hard to put in have been stripped by the editor!

      Well that is what happens in Directory Studio's configuration editor.
      The default server.xml file that comes with Dierctory Server has comments in it
      After editing with Directory Studio's configuration editor, they are gone.

      You wouldn't accept this behaviour with a source file?

      Comments should be passed through.....or maybe an option default YES

        Activity

        Hide
        Emmanuel Lecharny added a comment -

        That's perfectly sensible ...

        Thanks for this report !

        Show
        Emmanuel Lecharny added a comment - That's perfectly sensible ... Thanks for this report !
        Hide
        Felix Knecht added a comment -

        Please correct me if I'm wrong Pierre-Arnaud, but to me it looks like the configuration is loaded in the classes ServerXmlIOV*. After parsing the configuration is stored in a 'ServerConfiguration' (data-) bean but not in a DOM tree and any 'unnecessary' data is drop. This means that the design isn't made to handle additional data like comments. Neither to keep comments from an already existing configuration file nor to add comments when creating a new configuration.

        IMO there has to be a change in design to respect already existing comments. What about reading/creating the configuration into a DOM tree and validate the tree against a schema/dtd (what we should have anyway )?

        WDOT?

        Show
        Felix Knecht added a comment - Please correct me if I'm wrong Pierre-Arnaud, but to me it looks like the configuration is loaded in the classes ServerXmlIOV*. After parsing the configuration is stored in a 'ServerConfiguration' (data-) bean but not in a DOM tree and any 'unnecessary' data is drop. This means that the design isn't made to handle additional data like comments. Neither to keep comments from an already existing configuration file nor to add comments when creating a new configuration. IMO there has to be a change in design to respect already existing comments. What about reading/creating the configuration into a DOM tree and validate the tree against a schema/dtd (what we should have anyway )? WDOT?
        Hide
        Emmanuel Lecharny added a comment -

        That should be possible, as soon as the configuration will be stable. The server-xbean project generates a XSD file, which could be used to parse the file and keep the comment.

        Show
        Emmanuel Lecharny added a comment - That should be possible, as soon as the configuration will be stable. The server-xbean project generates a XSD file, which could be used to parse the file and keep the comment.
        Hide
        Felix Knecht added a comment -

        Wouldn't it make sense to have the release version of apacheds in the namespace of the configuration file?
        I the XSD file this could be achieved by adding
        Index: xbean-spring/pom.xml
        ===================================================================
        — xbean-spring/pom.xml (Revision 744642)
        +++ xbean-spring/pom.xml (Arbeitskopie)
        @@ -150,7 +150,7 @@
        <executions>
        <execution>
        <configuration>

        Show
        Felix Knecht added a comment - Wouldn't it make sense to have the release version of apacheds in the namespace of the configuration file? I the XSD file this could be achieved by adding Index: xbean-spring/pom.xml =================================================================== — xbean-spring/pom.xml (Revision 744642) +++ xbean-spring/pom.xml (Arbeitskopie) @@ -150,7 +150,7 @@ <executions> <execution> <configuration> <namespace> http://apacheds.org/config/1.0 </namespace> + <namespace> http://apacheds.org/config/$ {pom.version} </namespace> <schema>target/xbean/$ {pom.artifactId} .xsd</schema> </configuration> <goals>
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Oh yeah...

        I've been asking for that... for years now...

        Having the version number in the namespace is very nice idea.
        At the time, I was more thinking to a specific version="$

        {pom.version}

        " attribute.
        But your idea is way better, more elegant.

        Show
        Pierre-Arnaud Marcelot added a comment - Oh yeah... I've been asking for that... for years now... Having the version number in the namespace is very nice idea. At the time, I was more thinking to a specific version="$ {pom.version} " attribute. But your idea is way better, more elegant.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        About, the ServerXmlIOV* classes, you're completely right.

        I very like the idea you're proposing.
        What about the ServerConfiguration* classes?
        Are we keeping them but mapping the access methods to be searching an internal DOM tree stored in them (replacing the existing internal structure)?

        Did I get this right?

        Thanks

        Show
        Pierre-Arnaud Marcelot added a comment - About, the ServerXmlIOV* classes, you're completely right. I very like the idea you're proposing. What about the ServerConfiguration* classes? Are we keeping them but mapping the access methods to be searching an internal DOM tree stored in them (replacing the existing internal structure)? Did I get this right? Thanks
        Hide
        Felix Knecht added a comment -

        Are we keeping them ..
        I thought this could be a way to go.

        Namespace ...
        Of course we also need to make sure that the namespace also goes into the server.xml. This can probably be done by filtering the default server.xml located in apacheds/server-xml/src/main/resources during build.

        Show
        Felix Knecht added a comment - Are we keeping them .. I thought this could be a way to go. Namespace ... Of course we also need to make sure that the namespace also goes into the server.xml. This can probably be done by filtering the default server.xml located in apacheds/server-xml/src/main/resources during build.
        Hide
        Felix Knecht added a comment -

        I can find schemas for the version 1.5.2, 1.5.3, 1.5.4,1.5.5-SNAPSHOT (see http://repo1.maven.org/maven2/org/apache/directory/server/apacheds-xbean-spring/).
        The config editor supports also versions 1.5.0,1.5.1. Do there exist also schemas for these versions?

        Show
        Felix Knecht added a comment - I can find schemas for the version 1.5.2, 1.5.3, 1.5.4,1.5.5-SNAPSHOT (see http://repo1.maven.org/maven2/org/apache/directory/server/apacheds-xbean-spring/ ). The config editor supports also versions 1.5.0,1.5.1. Do there exist also schemas for these versions?
        Hide
        Emmanuel Lecharny added a comment -

        No, we didn't used xbeans for 1.50/1. What about supporting only the 1.5.[2-5] versions ?

        Show
        Emmanuel Lecharny added a comment - No, we didn't used xbeans for 1.50/1. What about supporting only the 1.5. [2-5] versions ?

          People

          • Assignee:
            Unassigned
            Reporter:
            Roger (Skip) Dooley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development