Hi I have logged a ticket so we wont forget about this. And scheduled it for AMQ 5.8 release. https://issues.apache.org/jira/browse/AMQ-4055
On Wed, Sep 12, 2012 at 11:48 AM, Dejan Bosanac <[email protected]> wrote: > 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 -- 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
