10 Replies Latest reply on Nov 2, 2007 12:33 PM by Michael Jackson

    updating xml attributes via grammer

      I have a configuration file that I've defined as using the xml config grammer. Structurally the XML looks something like this:


      <b attr1="some value">some other value</b>


      I'd like to change the value of the attribute (in bold) via bladelogic, but all I see in the configuration file, using the live configuration view, is the values of the elements. Is there a grammer file to alllow for this? Is there a way to use xpath notation to reference the value I want to change? Anyone have a way?

        • 1. Re: updating xml attributes via grammer

          You might need to perform two actions in your BLPackage here - one to remove the entry, and another to re-insert the correct one.


          If that does not work it could be that you need to define a custom XML grammar. Have a look at C:\Program Files\BladeLogic\OM\scripts\xml.gm. It's got some good instructions on how to go about creating new XML grammar files.


          Whenever you create a new Grammar file you need to make the app server aware of it. Check out the BLCLI API (Start -> Programs -> BladeLogic -> BLCLI Help) for more info.

          • 2. Re: updating xml attributes via grammer

            Are you sure there's no other alternatives?


            Removing and then re-inserting seems overly cumbersome. If I could use XPATH I could directly reference the node with something like "/a/b/@attr1". The dom object created by xerces (which one of the docs indicates is the tool used to convert the xml in to a dom object) will contain the attribute as a child of the parent element, but I don't know how much of that the BL developers are exposing to be used. And since I've a large (potentially) number of attributes to be changing I'd prefer to avoid the grammer route as well, otherwise I'll have to write a bunch of them.


            Also where can I make a "feature request"?

            • 3. Re: updating xml attributes via grammer

              Ok, I actually just tested your exact scenario using the XML you defined, and it worked:

              - I first added the file as a configuration file in the Configuration Object Dictionary using the XML grammar

              - Right-click on the configuration file under live browse and select add to depot as BLPackage

              - Open the BLPackage and change Value2 from "some value" to something else.

              - Close, save, and deploy the package back to the server. "some value" got changed to my new value.

              • 4. Re: updating xml attributes via grammer

                Hmm, interesting. Maybe I an issue with how I configured things, I'll take a third look at things. Or perhaps it has something to do with the version of the software we have deployed. What version of BL are you using? I'm on 7.2.

                • 5. Re: updating xml attributes via grammer

                  I'm using 7.3, but I don't think that should make a difference. I'd check to see how you added the entry to the BLPackage. I added it by right-clicking on the top-most node under live configuration, as opposed to drilling down to the specific entry.

                  • 6. Re: updating xml attributes via grammer

                    Hmm, ok, I see what you did. That seems to work, but leads to a second question. I'm deploying the application code in a separate blmodule from the configuration. This allows me to re-play the config at any time in case it gets messed up as part of testing or other changes. If I go this route is BL going to be smart enough to find the attribute if it isn't in the same place any longer? This would also be applicable to an install of a new version of the application code, as I would hope to re-use the same configuration module.

                    • 7. Re: updating xml attributes via grammer

                      It's not the location that matters, it's the path / unique identifier that our grammar uses. The entry could be anywhere in the file, but as long as we can get to that attribute by going down the same node names then you're good to go.

                      • 8. Re: updating xml attributes via grammer

                        The node names are all "mbean", does that make it more difficult? If you want to see what I'm actually working with download jboss' application server (4.0.5 or 4.2.1) and look at the cluster-service.xml file in $JBOSS_HOME/server/all/deploy. Another good one to look at is any of the jboss-service.xml files which are interspersed all over the instance's folder structure.

                        • 9. Re: updating xml attributes via grammer

                          If the node names are all the same, then it might make it a bit more difficult. That's what I was originally talking about when I was mentioning creating a custom grammar. BladeLogic needs to be able to distinguish each line individually, and in order to do this sometimes you need to update your XML grammars (or create new ones) to reflect specific formats that you might come across. What you want to do is have the grammar append the node value to the node name (with an underscore or something), so that we know how to find values in order to update them. I've done it before and it's fairly straightforward from the documentation.

                          • 10. Re: updating xml attributes via grammer

                            Yeah, I figured that. And that puts me back where I started from for the most part. I've got enough configuration files that I don't really want to write grammers for each of them, otherwise I'll forever be in the business of writing grammer files (although I am exagerating a little) and I'd not have the time to work on the application coding I need to be doing. It'd be really nice, and quite a bit faster for me at least, if we could specify where the value should be placed via XPATH because then if the elements are juggled around it won't matter. I can do that via JLI (using the underlying java XML libs), but if I go there I'm trading a fairly easy to read configuration module for something a bit more cryptic


                            Thanks for you help anyway though. I think I'll probably end up using a combination of things.