Yup. When this was written, Jettison was the only choice.
Regards -- Dejan Bosanac Senior Software Engineer | FuseSource Corp. [email protected] | fusesource.com skype: dejan.bosanac | twitter: @dejanb blog: http://www.nighttale.net ActiveMQ in Action: http://www.manning.com/snyder/ On Wed, Sep 12, 2012 at 11:43 AM, Claus Ibsen <[email protected]> wrote: > On Wed, Sep 12, 2012 at 11:36 AM, Dejan Bosanac <[email protected]> wrote: >> +100 >> >> We definitely should start moving into that direction. There's to much >> stuff in activemq-core at the moment and the main problem is xbean >> generation as you mentioned. If we sort that for 5.8 we can remove all >> spring stuff out of it and also move separate stores, plugins and >> stuff to their own modules. >> >>> 4) >>> There is also the FTP support which uses commons net. We could >>> consider moving that into a separate module as well. >> >> FTP is used for blob support and I think we can move that >> >>> 5) >>> Somehow activemq-core has dependency to Jettison. I cannot see a >>> reason why. Anyone ? >> >> Jettison is used for Stomp JSON support (along with XStream). That's >> overdue for revisiting as well. >> > > Maybe we should stick with one JSON library like Jackson. That is a > very popular library and fast. > > There is also gson > https://code.google.com/p/google-gson/ > > >> Regards >> -- >> Dejan Bosanac >> Senior Software Engineer | FuseSource Corp. >> [email protected] | fusesource.com >> skype: dejan.bosanac | twitter: @dejanb >> blog: http://www.nighttale.net >> ActiveMQ in Action: http://www.manning.com/snyder/ >> >> >> On Wed, Sep 12, 2012 at 10:34 AM, Claus Ibsen <[email protected]> wrote: >>> Hi >>> >>> I have also been looking a bit on activemq-core, and the many JAR >>> dependencies it currently has. >>> Currently we have a mix of mandatory and optional JARs. >>> >>> I suggest we work towards reducing this and moving pieces from the >>> core, into separate maven modules. >>> >>> 1) >>> For example the MQTT client could possible fit in a new activemq-mqtt >>> module. >>> >>> 2) >>> Also there is a org.apache.activemq.util.XStreamFactoryBean that is >>> only used for an unit test. >>> I dont think its acitvemq-core business to have Spring factory beans >>> for the XStream library. That is either Spring or XStream business, >>> not ActiveMQ. I suggest to remove this dependency from the core. End >>> users can create their own factory bean or use some other way. >>> >>> 3) >>> LevelDB store. This is a bit more tricky. The implementation of the >>> store is in a separate module at >>> org.fusesource.mq.leveldb.LevelDBStore. But there is an adapter in the >>> activemq-core source code. >>> >>> * >>> * @org.apache.xbean.XBean element="levelDB" >>> * >>> */ >>> public class LevelDBPersistenceAdapter extends LevelDBStore { >>> } >>> >>> As you can see it used XBean to generate it into the broker schema file. >>> >>> I wonder if we can come up with some may in the future to make this >>> more separated. So we can have "shallow" adapters in the >>> activemq-core, but that is not tied at compile time to the >>> implementation. This is how we do it in Camel, with for example >>> DataFormats (they get generated in the Camel XSD schema, but is not >>> runtime tied to the camel-core). >>> >>> Ah look at the JDBC store, they have some FactoryFinder to find the >>> impl. Maybe we can use that for LevelDB? >>> >>> This would allow us then to move the levelDB store to a >>> activemq-leveldb module, and therefore untie the activemq-core from >>> this. >>> >>> >>> 4) >>> There is also the FTP support which uses commons net. We could >>> consider moving that into a separate module as well. >>> >>> 5) >>> Somehow activemq-core has dependency to Jettison. I cannot see a >>> reason why. Anyone ? >>> >>> >>> >>> Sorry if I go overboard, but I want to make activemq-core a leaner >>> module. So its easier for people to slice and dice to use what they >>> need. And to make AMQ more appealing for users (eg its fewer JARs) >>> with plugin/optional features they can choose a la carte. >>> >>> This also makes OSGi easier as today we got a bunch of optional OSGi >>> imports in the MANIFEST.MF of the activemq-core; this is not ideal. >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> FuseSource >>> Email: [email protected] >>> Web: http://fusesource.com >>> Twitter: davsclaus, fusenews >>> Blog: http://davsclaus.com >>> Author of Camel in Action: http://www.manning.com/ibsen > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: [email protected] > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
