repackaging client/server/core classes

[ataylor]

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

[borges]

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)?

[clebert.suconic]

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

[ataylor]

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

[mgiannini]

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.

[ataylor]

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