12 Replies Latest reply on Jul 6, 2010 10:50 AM by bill.burke

    Embeddability/usability is poor: Hints to fix

    bill.burke

      * Your maven artifacts SUCK!

       

      The fact that none of Hornetq's artifacts DO NOT specify their dependencies is a real pain for users (like me) that consume hornetq through maven.  To use anything beyond the core API, we have to walk through build.xml files, and guess which artifact dependencies to add to our poms.

       

      You guys really really need to fix this.  I strongly suggest that you switch to Maven.  It will make your life easier in the long run (but miserable in the short run).

       

      * For embedded, the dependency on JBoss MC is unneccessary.  AFAICT, your beans.xml file is just a glorified set of object allocations.  There's nothing really configurable in there.

       

      * The JMS dependency on JNDI is a real pain in the ass.  Especially if you want to embed HornetQ into Tomcat.  Just read this article on how difficult it is:

       

      http://www.javacodegeeks.com/2010/06/spring-3-hornetq-21-integration.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+JavaCodeGeeks+%28Java+Code+Geeks%29

       

      It sucks that I have to write a HornetQ bootstrap class that doesn't depend on MC, JNDI, nor JMX and allow hornetq-configuration.xml, hornetq-jms.xml, and hornetq-users.xml files to be bootstrapped from it without depending on these components.  Its going to be  a real pain to navigate through your code to do this.

       

      In the near future, I strongly suggest that you write an example program that integrates HornetQ with Tomcat and Jetty.  You'll see immediately how piss-poor HornetQ is to integrate with.  Other than this, I really love HornetQ!!!

        • 1. Re: Embeddability/usability is poor: Hints to fix
          bill.burke

          I've put some classes together that are a bit simpler that what you have now.  One thing I did was to modify JMSServerManagerImpl so that it wasn't dependent on JNDI and you could plug-in your own registry like:

           

          public interface ComponentRegistry
          {
             Object lookup(String name);
             boolean bind(String name, Object obj);
             void unbind(String name);

           

             void close();
          }

           

          This would allow users to re-use all the nice logic within JMSServerManagerImpl, yet be able to remove the JNDI dependency.  For the MC dependency, I just defined a class that did the same logic embedded in hornetq-beans.xml.

           

          I haven't tested anything yet, so I'll post links to the files next week sometime.

          • 2. Re: Embeddability/usability is poor: Hints to fix
            timfox

            Bill Burke wrote:

             


            * For embedded, the dependency on JBoss MC is unneccessary.  AFAICT, your beans.xml file is just a glorified set of object allocations.  There's nothing really configurable in there.

            For embedded you don't use MC, there should be no code dependency on it. Perhaps you are referring to the standalone configuration which uses JBoss MC?

             

            http://hornetq.sourceforge.net/docs/hornetq-2.1.1.Final/user-manual/en/html/architecture.html

             

            http://hornetq.sourceforge.net/docs/hornetq-2.1.1.Final/user-manual/en/html/using-server.html#using-server.configuration

             

            Bill Burke wrote:

             


             

            * The JMS dependency on JNDI is a real pain in the ass.  Especially if you want to embed HornetQ into Tomcat.  Just read this article on how difficult it is:

             

            http://www.javacodegeeks.com/2010/06/spring-3-hornetq-21-integration.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+JavaCodeGeeks+%28Java+Code+Geeks%29


            HornetQ has a layered approach - HornetQ core has no dependencies on anything other than Netty. The server side JMS server manager has a dependency on JNDI, but that's because it's only real purpose in life is to put objects in JNDI - so it must have a dependency on it.

             

            If you don't want to put objects into JNDI on the server you don't need this class.

             

            Bill Burke wrote:

             


            It sucks that I have to write a HornetQ bootstrap class that doesn't depend on MC, JNDI, nor JMX and allow hornetq-configuration.xml, hornetq-jms.xml, and hornetq-users.xml files to be bootstrapped from it without depending on these components.  Its going to be  a real pain to navigate through your code to do this.


            I don't think you need to do this.

             

            We have an example for both core and JMS emdedded in the distro which shows you how to do this.

             

            http://hornetq.sourceforge.net/docs/hornetq-2.1.1.Final/user-manual/en/html/examples.html#d0e1739

             

            http://hornetq.sourceforge.net/docs/hornetq-2.1.1.Final/user-manual/en/html/examples.html#examples.embedded

             

            http://hornetq.sourceforge.net/docs/hornetq-2.1.1.Final/user-manual/en/html/embedding-hornetq.html

             

            It should be possible to embed HornetQ with just a few lines of code. But I guess I'm missing something here

            • 3. Re: Embeddability/usability is poor: Hints to fix
              jmesnil

              Bill Burke wrote:

               

              * Your maven artifacts SUCK!

               

              You guys really really need to fix this.  I strongly suggest that you switch to Maven.  It will make your life easier in the long run (but miserable in the short run).

              I'm not sure it'll make our life easier but it will certainly make life easier for our users. It's something to consider... (even though I'm not a big proponent of mvn)

               

              * The JMS dependency on JNDI is a real pain in the ass.  Especially if you want to embed HornetQ into Tomcat.  Just read this article on how difficult it is:

               

              http://www.javacodegeeks.com/2010/06/spring-3-hornetq-21-integration.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+JavaCodeGeeks+%28Java+Code+Geeks%29

              If I understand you correctly, you want to be able to create JMS resources without binding them to JNDI. They will be injected into the client code as shown in your link instead. Is that correct?

              That is a sensible use case: there is no need for JNDI as long as the clients creates the corresponding client-side JMS resources themselves.

              We could make JNDI binding optional by providing a BindingRegistry API (like you proposed in your other post) and provide both JNDI and no-op implementations.

               

              We could do the same for JMX but I don't see it being a big deal here: JMX is in the Java runtime (no addition deps) and management can be disabled completely (by setting JMXManagementEnable to false in HornetQ server Configuration interface)

              • 4. Re: Embeddability/usability is poor: Hints to fix
                bill.burke

                Couple more things:

                 

                * yes, your life will be easier after you get used to maven.  If you develop within an IDE (eclipse or intellij), your POM because your project file and there's no need to configure the IDE separately.   You'll not have to worry about generating correct poms for the repository.  Users won't have to weed through 3 levels of complex ANT scripts to figure out where you are getting libraries from, config from, etc.  Maven structure is predefined.

                 

                * ASYNCIO should not be the default setting for Journal IO.  Any user not on Linux 2.6+ will get an UnsatisfiedLinkError if they don't know the magic config switch to change the setting to NIO.  They just won't know WTF is going on period and you'll be hit with forum or support requests.

                • 5. Re: Embeddability/usability is poor: Hints to fix
                  timfox

                  Bill Burke wrote:

                   


                   

                  * ASYNCIO should not be the default setting for Journal IO.  Any user not on Linux 2.6+ will get an UnsatisfiedLinkError if they don't know the magic config switch to change the setting to NIO.  They just won't know WTF is going on period and you'll be hit with forum or support requests.

                  When running standalone or in AS, and you're not running Linux or don't have libaio installed, the Journal will automatically fall back to using pure Java NIO, so no config needed and it will just work.

                  • 6. Re: Embeddability/usability is poor: Hints to fix
                    bill.burke

                    Tim Fox wrote:

                     

                    Bill Burke wrote:

                     


                     

                    * ASYNCIO should not be the default setting for Journal IO.  Any user not on Linux 2.6+ will get an UnsatisfiedLinkError if they don't know the magic config switch to change the setting to NIO.  They just won't know WTF is going on period and you'll be hit with forum or support requests.

                    When running standalone or in AS, and you're not running Linux or don't have libaio installed, the Journal will automatically fall back to using pure Java NIO, so no config needed and it will just work.

                    Tim, I was getting UnsatisfiedLinkError.  My environment wasn't finding hornetq-configuration.xml approprietly, IIRC, but this error did show up when it didn't.

                    • 7. Re: Embeddability/usability is poor: Hints to fix
                      bill.burke

                      Jeff Mesnil wrote:

                       

                      Bill Burke wrote:

                       

                      * Your maven artifacts SUCK!

                       

                      You guys really really need to fix this.  I strongly suggest that you switch to Maven.  It will make your life easier in the long run (but miserable in the short run).

                      I'm not sure it'll make our life easier but it will certainly make life easier for our users. It's something to consider... (even though I'm not a big proponent of mvn)

                       

                      * The JMS dependency on JNDI is a real pain in the ass.  Especially if you want to embed HornetQ into Tomcat.  Just read this article on how difficult it is:

                       

                      http://www.javacodegeeks.com/2010/06/spring-3-hornetq-21-integration.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+JavaCodeGeeks+%28Java+Code+Geeks%29

                      If I understand you correctly, you want to be able to create JMS resources without binding them to JNDI. They will be injected into the client code as shown in your link instead. Is that correct?

                      That is a sensible use case: there is no need for JNDI as long as the clients creates the corresponding client-side JMS resources themselves.

                      We could make JNDI binding optional by providing a BindingRegistry API (like you proposed in your other post) and provide both JNDI and no-op implementations.

                       

                      We could do the same for JMX but I don't see it being a big deal here: JMX is in the Java runtime (no addition deps) and management can be disabled completely (by setting JMXManagementEnable to false in HornetQ server Configuration interface)

                       

                      Jeff,

                       

                      I forked JMSServerManagerImpl to add the BindingRegistry API.  See the link below.  There's also some other helper classes to remove the need for hornetq-jboss-beans.xml and to make JMS embeddability be new EmbeddedHornetQJMS().start();

                       

                      http://resteasy.svn.sourceforge.net/viewvc/resteasy/trunk/rest-star/messaging/session/src/main/java/org/jboss/resteasy/star/messaging/integration/

                       

                      I'm thinking of integrating HornetQ with Tomcat using a BindingRegistry that sits in front of ServletContext attributes.  The way Tomcat binds into JNDI is just plain weird and awkward.  Just seems foolish to do all Hornetq initialization in a JNDI ObjectFactory...  Spring users will be able to inject from the Servletcontext attributes to get HornetQ created objects like ConnectionFactory, etc.

                      • 8. Re: Embeddability/usability is poor: Hints to fix
                        bill.burke

                        Bill Burke wrote:

                         

                        Jeff Mesnil wrote:

                         

                        Bill Burke wrote:

                         

                        * Your maven artifacts SUCK!

                         

                        You guys really really need to fix this.  I strongly suggest that you switch to Maven.  It will make your life easier in the long run (but miserable in the short run).

                        I'm not sure it'll make our life easier but it will certainly make life easier for our users. It's something to consider... (even though I'm not a big proponent of mvn)

                         

                        * The JMS dependency on JNDI is a real pain in the ass.  Especially if you want to embed HornetQ into Tomcat.  Just read this article on how difficult it is:

                         

                        http://www.javacodegeeks.com/2010/06/spring-3-hornetq-21-integration.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+JavaCodeGeeks+%28Java+Code+Geeks%29

                        If I understand you correctly, you want to be able to create JMS resources without binding them to JNDI. They will be injected into the client code as shown in your link instead. Is that correct?

                        That is a sensible use case: there is no need for JNDI as long as the clients creates the corresponding client-side JMS resources themselves.

                        We could make JNDI binding optional by providing a BindingRegistry API (like you proposed in your other post) and provide both JNDI and no-op implementations.

                         

                        We could do the same for JMX but I don't see it being a big deal here: JMX is in the Java runtime (no addition deps) and management can be disabled completely (by setting JMXManagementEnable to false in HornetQ server Configuration interface)

                         

                        Jeff,

                         

                        I forked JMSServerManagerImpl to add the BindingRegistry API.  See the link below.  There's also some other helper classes to remove the need for hornetq-jboss-beans.xml and to make JMS embeddability be new EmbeddedHornetQJMS().start();

                         

                        http://resteasy.svn.sourceforge.net/viewvc/resteasy/trunk/rest-star/messaging/session/src/main/java/org/jboss/resteasy/star/messaging/integration/

                         

                        I'm thinking of integrating HornetQ with Tomcat using a BindingRegistry that sits in front of ServletContext attributes.  The way Tomcat binds into JNDI is just plain weird and awkward.  Just seems foolish to do all Hornetq initialization in a JNDI ObjectFactory...  Spring users will be able to inject from the Servletcontext attributes to get HornetQ created objects like ConnectionFactory, etc.

                        Oh, yeah, one more thing...the reason I wanted to do this was so that I could use hornetq-jms.xml configuration files within an embedded environment without having all the JBoss JNDI dependencies (and transitive dependencies).  All the logic for processing this, begins and ends with JMSServerManagerImpl it seems.

                        • 9. Re: Embeddability/usability is poor: Hints to fix
                          timfox

                          Bill Burke wrote:

                           


                          Tim, I was getting UnsatisfiedLinkError.  My environment wasn't finding hornetq-configuration.xml approprietly, IIRC, but this error did show up when it didn't.

                          That's probably because you're using HQ embedded, i.e. instantiating the objects yourself, so bypassing the fallback code. If you were running the actual server from the distro, or in AS this wouldn't be an issue. 99% of people would be running HQ in this way.

                          • 10. Re: Embeddability/usability is poor: Hints to fix
                            ataylor
                            * yes, your life will be easier after you get used to maven.  If you develop within an IDE (eclipse or intellij), your POM because your project file and there's no need to configure the IDE separately.   You'll not have to worry about generating correct poms for the repository.  Users won't have to weed through 3 levels of complex ANT scripts to figure out where you are getting libraries from, config from, etc.  Maven structure is predefined.

                            Youur probably correct, however theres quite an upheaval involved in moving to maven which is why we havent done it yet. All our source is under 1 source tree so we would have to pull out the source for each artifact, create a pom as well as 1 for the test suite and other stuff we have such as being able to run the server from source. It's inevitable that we will move at some point its just when, I'll raise anothe rpost regarding this.

                            • 11. Re: Embeddability/usability is poor: Hints to fix
                              jmesnil

                              Andy Taylor wrote:

                               

                              * yes, your life will be easier after you get used to maven.  If you develop within an IDE (eclipse or intellij), your POM because your project file and there's no need to configure the IDE separately.   You'll not have to worry about generating correct poms for the repository.  Users won't have to weed through 3 levels of complex ANT scripts to figure out where you are getting libraries from, config from, etc.  Maven structure is predefined.

                              Youur probably correct, however theres quite an upheaval involved in moving to maven which is why we havent done it yet. All our source is under 1 source tree so we would have to pull out the source for each artifact, create a pom as well as 1 for the test suite and other stuff we have such as being able to run the server from source. It's inevitable that we will move at some point its just when, I'll raise anothe rpost regarding this.

                              I agree with  Andy: we are consumed by mavenized projects (AS, EAP, Resteasy, others) and we consume mavenized projects (Netty).

                              At this stage, mavenizing HornetQ would help everybody to integrate and resolve dependencies.

                               

                              Afaik, nobody in HornetQ team has extensive knowledge to mavenize HornetQ (as Andy described it)... If we could leverage expertise from JBoss community that'd be great.

                              • 12. Re: Embeddability/usability is poor: Hints to fix
                                bill.burke

                                Tim Fox wrote:

                                 

                                Bill Burke wrote:

                                 


                                Tim, I was getting UnsatisfiedLinkError.  My environment wasn't finding hornetq-configuration.xml approprietly, IIRC, but this error did show up when it didn't.

                                That's probably because you're using HQ embedded, i.e. instantiating the objects yourself, so bypassing the fallback code. If you were running the actual server from the distro, or in AS this wouldn't be an issue. 99% of people would be running HQ in this way.

                                Suggestions and examples on how to unit test might be helpful with HQ + JMS.  I guess I could volunteer to write one so long as it is critiqued to make sure I'm not doing something stupid!