1 2 3 4 Previous Next 149 Replies Latest reply on Mar 24, 2010 8:55 AM by ataylor Go to original post
      • 15. Re: Integration with AS6
        timfox
        And we don't expose any "implementation details" in HornetQ config.
        • 16. Re: Integration with AS6
          emuckenhuber

          Ok, good. I was not talking about creating yet another set of configuration for a mythical "generic" messaging system.

           

          What i wanted to describe is the metadata driven approach of integrating other components into jboss-as. This should give you the flexibilty to reuse any existing configuration format from HornetQ. Furthermore it should be possible to register e.g. queues in MC and allow injection in POJOs directly - not requiring changes to the HornetQ project itself, in case you would be interested in something like that.

          • 17. Re: Integration with AS6
            timfox

            I assume I'm just not "getting" it (yet).

             

            What is wrong with the current way we configure HornetQ?

             

            Why would we need to make changes for integration in JBoss AS?

             

            What am I missing here?

            • 18. Re: Integration with AS6
              clebert.suconic

              The application server supports deployment of queues on the deployment descriptors.  As far I we have talked I believe we still need to support that.. and the AS will need a deployer for that. (Since they don't want ugly MC or MBeans definitions through XMLs).

               

              And we also need to support Queue creation through an abstract interface. That interface needs to be either supported through the Application Server itself or on the testsuite. Personally I don't see any difference on where it stays.   I will just develop it for now and decide if stays only on the testsuite or on the application server itself. We can move it to either direction we need later.

              • 19. Re: Integration with AS6
                brian.stansberry

                Quick reply here; I'll reply more fully after the Monday morning round of status conf calls.

                 

                Some of the confusion you have, Tim, probably comes from the fact that when I posted I'd been told HornetQ had no deployment configuration files, all was done via API and was meant to remain that way. That looks to have been a misunderstanding. Clearly the AS use case requires configuration files; a purely embedded HornetQ usage may not. If you start from the premise that nothing exists, then you propose something generic.

                 

                I have no objection to using HornetQ's configuration format, only issue is that the content should be able to embedded as a fragment in a future overall domain.xml config file, which should be possible with any good schema, so I'm not concerned about that. The real goal here is to integrate HornetQ.

                 

                The deployer chain architecture is a core part of how the AS does things; all deployments need to move through that. But I can't imagine that will be difficult to integrate. It basically requires parsing the configuration into an object model representing the configuration (which you probably already have code to do), some simple glue code to tie that into the overall deployer chain, some logic to take the configuration object model and create actual destination objects (which you probably already have), and some glue code to tie that bit into the deployer chain.

                • 20. Re: Integration with AS6
                  timfox

                  Sorry, I still don't get it.

                   

                  Why do I need to parse our configuration and pass it to JBoss AS?

                   

                  If HornetQ does it's own deployment  - why is this necessary?

                   

                  I don't see that JBoss AS needs to be involved at all the HornetQ configuration.

                  • 21. Re: Integration with AS6
                    clebert.suconic

                    The issue is how users are going to be able to add destinations as part of their deployments.

                     

                     

                    Say, an user is deploying an MDB and it is connected to the Orders destinations.

                     

                    You need to be able to define the Queue somewhere within the EAR.

                    • 22. Re: Integration with AS6
                      wolfc

                      That is actually no longer the case. Now the creation is delegated to other deployers.

                      See https://jira.jboss.org/jira/browse/JBAS-5114 and https://jira.jbos.org/jira/browse/JBAS-6013.

                      • 23. Re: Integration with AS6
                        brian.stansberry

                        timfox wrote:

                         

                        Sorry, I still don't get it.

                         

                        Why do I need to parse our configuration and pass it to JBoss AS?

                         

                        If HornetQ does it's own deployment  - why is this necessary?

                         

                        I don't see that JBoss AS needs to be involved at all the HornetQ configuration.

                         

                        AFAICT, HornetQ at startup scans it's classpath for configurations. I don't see any hot deployment scanning. I don't see an ability to deploy stuff that isn't yet on the classpath when the MC starts HornetQ. (The "deploy" dir for example, is not on the classpath.) I don't see how to analyze package structures where not all content is a classpath resource and find and extract the configuration. I don't see an ability to combine configuration changes that were made via an admin console and persisted so that they still take effect after restart.

                         

                        Maybe I'm wrong and all these capabilities exist in HornetQ. And maybe Remy's gone and added them all to JBoss Web and Steve's added them all to Hibernate and Carlo's got them in EJB3 and Pete's done it in Weld. Even if that were the case, I'm sure all those impls would be different and would likely have conflicts. The AS as a whole would be incoherent. That's unacceptable, so the AS has a deployment framework and an SPI that services that want to integrate have to implement. It's a pretty simple thing to do, particularly since you've already got the key stuff.

                         

                        Why parse the destination configuration and pass it to JBoss AS? I'll rephrase that: why separate the parsing into a metadata object from the creation of the runtime service described by that metadata, delegating the connecting of the 2 steps to the deployment framework SPI? Technically, you could do both in one deployer, but in the AS it's, well, sucky. Breaking the process into 2 steps is preferable:

                         

                        1) It allows the second step to happen without the first step, as long as *something* creates the metadata object. Bob McWhirter could write a deployer that takes whatever describes a queue in the Ruby world, use it to create a HornetQ metadata object, and pass it on. Voila, RoR apps running in the AS runtime use HornetQ. (Can't find the link, but he's already done something like that for JBM destinations.) Andrew Rubinger could do something else for JBoss Embedded -- users describe a queue programatically and ask JBoss Embedded to deploy it. A JBoss Embedded user shouldn't have to understand how to find and invoke on HornetQ to do that; they should delegate to the JBoss Embedded deployment API.

                         

                        2) It allows other deployers in the chain to act on / react to the metadata before the final installation of the destination. I don't have any particular example of how this is useful for a destination, but the concept is used all over the place for other types of deployments.

                         

                        3) The above are just descriptions of benefits of separation of concerns, which is generally A Good Thing.

                         

                        4) All the other deployments in the AS are broken up this way, so it's going to be easier for folks (support, maintenance engineers) to understand how HornetQ integrates if it follows the same pattern.

                        • 24. Re: Integration with AS6
                          clebert.suconic

                          We talked about this on IRC@hornetQ yesterday.

                           

                           

                          I will be trying to create a deployer that will delegate to the HornetQ deployer, reusing what we already have in terms of parsing and deploying at hornetQ.

                          • 25. Re: Integration with AS6
                            timfox

                            HornetQ _does_ do hot deployment of resources on the classpath.

                             

                            I think your JBoss AS spectacles are obscuring your view here

                             

                            Bear in mind that HornetQ is a standalone server that functions completely outside JBoss AS without any JBoss  AS dependencies - this is probably the most common way people use HornetQ.

                             

                            That's why we have our own deployers, do our own deployment, hot deploy etc. We are not just a "service" of JBoss AS.

                             

                            Regarding persistence of config, then that's also something we should be doing already, if you've spotted some property where that's not working, that's a bug which we can easily fix. Remember that this persistence also needs to be available in our embedded or standalone configuration where there is no AS, and no profile service.

                            • 26. Re: Integration with AS6
                              brian.stansberry

                              BTW, when poking around with this last night I noticed that the HornetQ pom's in repository.jboss.org have incorrect artifact id's, e.g. http://repository.jboss.org/maven2/org/hornetq/hornetq-core/2.0.0.CR3/hornetq-core-2.0.0.CR3.pom

                               

                              <project>
                                <modelVersion>4.0.0</modelVersion>
                                <groupId>org.hornetq</groupId>
                                <artifactId>hornetq-bootstrap</artifactId>
                                <version>2.0.0.CR3</version>
                              </project>
                              

                               

                              It seems they all list "hornetq-bootstrap" as their artifactId. I suspect that will cause maven to barf when you try if you tried to add those components into the AS build.

                              • 27. Re: Integration with AS6
                                ataylor
                                thanks for pointing that out, fixing it now
                                • 28. Re: Integration with AS6
                                  timfox

                                  And, btw, you'd almost certainly find the same for any messaging system that you wanted to integrate into JBoss AS, they'll do all this stuff already, themselves.

                                   

                                  It's not reasonable to expect them to rewrite themselves just so they can be run in JBoss AS.

                                   

                                  Also, like I mentioned before it's an awful user experience to have people configure HornetQ one way when running standalone and forcing them to do it a different way when running in JBoss AS.

                                   

                                  We already have quite a few HornetQ users running HornetQ in JBoss AS, they run a script and hey presto, it's integrated.

                                   

                                  Let's not make this integration any more complex than it needs to be, and it could be pretty simple.

                                  • 29. Re: Integration with AS6
                                    brian.stansberry

                                    timfox wrote:

                                     

                                    HornetQ _does_ do hot deployment of resources on the classpath.

                                     

                                    I think your JBoss AS spectacles are obscuring your view here

                                     

                                    Bear in mind that HornetQ is a standalone server that functions completely outside JBoss AS without any JBoss  AS dependencies - this is probably the most common way people use HornetQ.

                                     

                                    That's why we have our own deployers, do our own deployment, hot deploy etc. We are not just a "service" of JBoss AS.

                                     

                                    Regarding persistence of config, then that's also something we should be doing already, if you've spotted some property where that's not working, that's a bug which we can easily fix. Remember that this persistence also needs to be available in our embedded or standalone configuration where there is no AS, and no profile service.

                                     

                                    Like I said, maybe you've already done all the stuff I listed. I did a pretty cursory look at code and docs. I congratulate you on getting all of the above working; it's a huge accomplishment. But that doesn't change the fact that the AS needs to be a coherent runtime, not just a collection of independent servers each of which does similar things completely differently with no coordination.

                                     

                                    I completely understand the need to maintain your own standalone capabilities and not have AS requirements screw them up. I expect for all the standalone capabilities you provide that the AS also provides, we'll have to have a discussion of how to coordinate. Hopefully in most cases the result is simple AS glue code that delegates to existing HornetQ functionality. That's pretty much what you've concluded re: destination deployment.

                                    1 2 3 4 Previous Next