5 Replies Latest reply on Dec 20, 2012 11:15 AM by Andy Taylor

    repackaging client/server/core classes

    Andy Taylor Master

      Ive made a commit at https://github.com/andytaylor/hornetq/commit/ec1fbcdad2a85fb0dac809f4c7b3c0bcf2c905c2 in which i have repacked all the core classes int 3 modules client/server and core, the reasons for this are

       

      1. currently we just 'guess' which classes are needed for the hornetq-core-client.jar and pull them out at build time, this is not very maintainable, several times when classes have been added or moved they have been missed and users then need to add the core jar to their classpath.

      2. help us create/fix/maintain a better API, we have lots ofplaces where we have leaky abstractions or just plain wrong API's.

       

      What we actually ship in each jar is unimportant, for now i have in each jar just the classes from its module but we can change this if we want, i.e. add the core classes into the client jar.

       

      As part of doing this i had to fix/change the following:

       

      1. PacketDecoder.java - this was used on both the client and the server so pulled in nearly every class in core, it also meant that we had a dodgy API where servermessage was needed on the client side and vice versa, I have changed this to 2 implementations and solved this.

      2. Configuration also pulled in all the server classes and was used on the client so i have created a new class HornetQDefaultConfiguration to hold all conf defaultts.

      3. created 2 new loggers

      4. ConnectionLifeCycleListener.java was used on the client but had a method connectionCreated which passed in an Acceptor. Ive changed this to use a Typed parameter but maybe there is a better way to do this.

       

      could I have any ones thoughts on this please? also if we merge this we should all review the current API, i.e. we have stuff in API and stuff in SPI and core so its a bit confusing

        • 1. Re: repackaging client/server/core classes
          borges Novice

          Hi Andy,

           

          I just went through all of your changes, it looks like a much needed and welcome improvement to the current status.

           

          +1

           

          [...]

           

          Regarding the ConnectionListener. I can see that placing the Acceptor there will pull loads of classes. One much narrower solution than

           

                        ConnectionLifeCycleListener<T>

          void connectionCreated(T acceptor, Connection connection, ProtocolType protocol);

           

          would be to use


          void connectionCreated(HornetQComponent acceptor, Connection connection, ProtocolType protocol);

           

          BTW, it seems that ConnectionLifeCycleListener is used in both projects (server and client) but the specific method only on hq-server. Can't we just add a new interface ServerConnectionLifeCycleListener that extends the original interface and contains connectionCreated(Acceptor, ProtocolType)?

          • 2. Re: repackaging client/server/core classes
            Clebert Suconic Master

            +1 I looked at the chnages....   very nice work Andy!

            • 3. Re: repackaging client/server/core classes
              Andy Taylor Master

              i will take a look at Francisco's suggestions tomorrow and do a PR

              • 4. Re: repackaging client/server/core classes
                Matthew Giannini Newbie

                Just need a little clarification on this change. I am embedding HornetQ server 2.3.0.BETA3 and using the file based configuration to configure the server. I expected I would only need to depend on hornetq-server, but it looks like I must now depend on hornetq-core-client as well. If I don't add this dependency I get:

                 

                 

                Exception in thread "main" java.lang.NoClassDefFoundError: org/hornetq/api/config/HornetQDefaultConfiguration

                        at org.hornetq.core.config.impl.ConfigurationImpl.<init>(ConfigurationImpl.java:181)

                        at org.hornetq.core.config.impl.FileConfiguration.<init>(FileConfiguration.java:31)

                        at org.hornetq.core.server.embedded.EmbeddedHornetQ.initStart(EmbeddedHornetQ.java:84)

                        at org.hornetq.core.server.embedded.EmbeddedHornetQ.start(EmbeddedHornetQ.java:74)

                 

                Caused by: java.lang.ClassNotFoundException: org.hornetq.api.config.HornetQDefaultConfiguration

                        at java.net.URLClassLoader$1.run(Unknown Source)

                        at java.net.URLClassLoader$1.run(Unknown Source)

                        at java.security.AccessController.doPrivileged(Native Method)

                        at java.net.URLClassLoader.findClass(Unknown Source)

                        at java.lang.ClassLoader.loadClass(Unknown Source)

                        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)

                        at java.lang.ClassLoader.loadClass(Unknown Source)

                        ... 6 more

                 

                 

                It was unexpected to have to add a dependency on the client jar in order to embed the server. Could you clarify if this is the expected behavior?

                 

                Thanks.

                • 5. Re: repackaging client/server/core classes
                  Andy Taylor Master

                  yes, the server also acts as a client in some cases so needs the client jar.