1 2 Previous Next 15 Replies Latest reply on Feb 8, 2010 11:17 AM by Clebert Suconic

    Configuration changes

    Clebert Suconic Master

      Currently the JMSManager is taking a XML stream, parsing the configuration and taking it directly to the Server.

       

      Per https://jira.jboss.org/jira/browse/HORNETQ-166, we would need to always parse the XML into some internal object. And it should also be possible to call the Deployer.deploy(JMSConfiguration).

       

      Other projects in AS6 (such as TorqueBox) want to leverage that functionality and call the deploy(JMSConfiguration) directly instead of sending a XML stream.

       

       

      I'm considering implementing HORNETQ-166 so I would have the deployment as AS6 using that funcionality.

       

       

      Any thoughts?

        • 1. Re: Configuration changes
          Tim Fox Master
          I think that's fine, as long as it's done consistently across both core and JMS.
          • 2. Re: Configuration changes
            Clebert Suconic Master

            Few things I don't understand.

             

             

            I - Why AddressSettings is not exposed on FileConfiguration / Configuration? That's also part of the main config?

             

            II - From what I have seen on the AS6 integration, redploying a destinations file will make us to delete queues, and then add them back. Is that considered a problem? (if it is I don't know how we could do it otherwise)

             

             

            Also, the deployers are currently using URL. That's fine for standalone but I don't have an URL while on the AS. so I may need to add a few methods.

            • 3. Re: Configuration changes
              Tim Fox Master

              1. Regarding AddressSettings - this is a good point. I actually noticed this a few weeks ago but forgot to add a JIRA.

               

              Also, currently there is no way to configure address settings, e.g. set an address page size using the management API - this is a big omission and needs to be fixed.

               

              2. Redployment of destinations.

               

              Undeploying a destination *does not* mean deleting it! We had this conversation before a few times if you remember.

              • 4. Re: Configuration changes
                Andy Taylor Master

                you can add address settings like such

                 

                server.getAddressSettingsRepository().addMatch(address, addressSettings);

                • 5. Re: Configuration changes
                  Tim Fox Master

                  ataylor wrote:

                   

                  you can add address settings like such

                   

                  server.getAddressSettingsRepository().addMatch(address, addressSettings);

                  That's not available using the management api

                  • 6. Re: Configuration changes
                    Clebert Suconic Master

                    you can add address settings like such

                     

                    server.getAddressSettingsRepository().addMatch(address, addressSettings);

                     

                     

                    A lot of what's on the configuration is also exposed somewhere else. For instance it's possible to add acceptors directly on the HornetQ objects, and still you can add those on the Fileconfiguration.

                     

                     

                    My issue now is the deployment life cycle is controlled through MC Beans. I would need something on HornetQ to parse a XML file into a POJO, and have MC calling a method within HornetQ. TorqueBox will also need that kind of feature.

                     

                    So, instead of having the deployers to take directly a XML, I would need them to take POJOs and the MC on the AS would be able to deal with them.

                    • 7. Re: Configuration changes
                      Clebert Suconic Master

                      More questions:

                       

                      - Why did we make address-settings and security-settings part of hornetq's main configuration? for me it looks like it should be on a separate configuration.. like you can redeploy the queues settings but not the whole configuration.

                       

                      - Also.. it's possible to define a hornetq-queues.xml with the entire main configuration on it. It seems it should be a separate schema.

                       

                      - Can we also make the address and security settings as part of the JMS XSD? Right now it's not possible to define in a single file both security and queue settings.

                      • 8. Re: Configuration changes
                        Clebert Suconic Master


                        Why these changes are necessary?

                         

                        The life cycle of deployements is controlled by the MicroContainer. On the application server every deployment descriptor is parsed as a simple POJO, and injection is used to invoke methods on the necessary beans.

                         

                        When the deployment file is gone, the MC will invoke some method on the POJO (such as stop) and it can take proper actions from there.

                         

                        Currently the deployment at HornetQ is done by just simple URLs, and it won't be possible to use the MC way of doing things.

                         

                         

                        It would be possible to hack around it by creating a deployer that would accept the HornetQ config files, but that would be "a hack", and AS developers are complaining about creating any deployers on that style.

                         

                         

                        Besides other projects (such as TorqueBox) currently need this kind of functionality, where the deployment metadata (the simple POJO for the parsed XML) is used.

                         

                         

                        Currently our POJOs mostly represent the XMLs (with the exception of address-settings and security-settings on the config). So, we would need to change to deployers to always parse the XML into configuration and then deploy the configuration POJOs instead of XML nodes.

                        • 9. Re: Configuration changes
                          Andy Taylor Master
                          Can you explain a bit more how the AS deployers work. It was my impression that they would pick up a config file, say hornet-queues.xml, and process each element. So from a HornetQ pov these deployers would be used instead of ours(or in conjunction with ours).
                          • 10. Re: Configuration changes
                            Clebert Suconic Master
                            was my impression that they would pick up a config file, say hornet-queues.xml, and process each element.

                             

                            That's not how it's done. (maybe the AS guys will be able to provide more info here)

                             

                            You parse the XML into a POJO, instatiate it on the MC, and let the Micro Container do the rest.

                             

                            In fact, most of deployers are using JBossXB to do the parsing automagically. I'm already avoiding that step by using manual parsing, but I still need to parse the XML into a POJO.

                            • 11. Re: Configuration changes
                              Andy Taylor Master

                              can u give a simple example.

                               

                              If 'we' parse the xml, i.e. we have written the deployer, dont we just pass this xml straight onto our deployers, changing them to accept xml instead of URL's

                              • 12. Re: Configuration changes
                                Clebert Suconic Master

                                What the deployers on AS is supposed to do is:

                                 

                                JMSQueues config = whateverClass.parseTheDeploymentAsAPOJO(InputStream);

                                return config;

                                 

                                The MicroContainer should take that object and inject it where is needed.

                                 

                                Bob McWhirter wrote a pseudo code of what we should be doing here:

                                 

                                 

                                http://gist.github.com/291873

                                • 13. Re: Configuration changes
                                  Clebert Suconic Master

                                  Is that ok if I at least add address-settings and security-settings to hornetq-jms.xml? (not just for the AS integration, I'm talking about standalone also)

                                  • 14. Re: Configuration changes
                                    Tim Fox Master

                                    clebert.suconic@jboss.com wrote:

                                     

                                    Is that ok if I at least add address-settings and security-settings to hornetq-jms.xml? (not just for the AS integration, I'm talking about standalone also)

                                    I'm not sure that is a good idea.

                                     

                                    AddressSettings and SecuritySettings deal with core addresses - not JMS queue/topic names so this would be confusing to the user, since they'd have to prefix everything with jms.queue and jms.topic etc

                                    1 2 Previous Next