Looks interesting. I would try to limit external dependencies by
taking out Spring. I have a tiny abstraction layer for JMS written in
Java (and another in JavaFX), where I feed in a Properties object with
all the parameters (server location, authentication, etc.) and get
quick access to various topic consumers and producers. I suspect that
involving the properties object is not going to be very idiomatic
clojure.
On Nov 24, 8:50 pm, Luc Prefontaine <[EMAIL PROTECTED]>
wrote:
> We use a synchronous layer to JMS queues implemented in Java to hook our
> Clojure code to the messaging world.
>
> Two Java classes to implement a consumer and a producer with some common
> inheritance are used.
> We had already some Java implementation so we just beefed it up a bit to
> make more robust.
>
> We use Spring to load beans so loading a consumer look like this:
>
> (defn create-producer-consumer [name]
> (get-bean name)
> )
>
> The Spring bean being something similar to this:
>
> class="org.apache.activemq.pool.PooledConnectionFactory">
> ref="connectionSimpleFactoryBean" />
>
>
> class="com.softaddicts.products.higiebus.tools.jms.Consumer">
>
> value="HIGIEBUS.QUEUES.BUS_DATA?consumer.exclusive=true" />
> ref="connectionFactoryBean" />
>
>
>
>
>
> Now we have small wrappers in Clojure like these:
>
> (defn read-message
> "Consume messages"
> [consumer]
> (. consumer receive)
> )
>
> (deftrace send-message
> ;; "Send messages"
> [producer msg]
> (. producer send msg)
> )
>
> (defn peek-text-message
> "Peek at messages"
> [consumer]
> (let [message (. consumer browse)]
> (if (not (nil? message)) (. message getText))
> )
> )
>
> and so on for commits, rollbacks, . The Java classes handle
> connection/release of resources, cleanup when the JVM exits,
> We use the wrappers to protect ourselves from later changes in the
> implementation.
>
> We use ActiveMq 5.1 with master slave redundancy.
>
> Eventually we want to create a wrapper to allow Clojure functions to be
> called asynchronously but we are not there yet,
> mainly because we have other priorities.
>
> Using the Spring framework is certainly is a viable option, we look at
> to reuse existing code and getting Clojure code called directly
> in an asynchronous fashion.
>
> We start the consumers in separate thread. polling for messages through
> read-message and consort. This at least gives us some
> asynchronous processing illusion for the moment.
>
> We expect to shrink the Java code down to a certain size in the next
> months and shift more stuff to Clojure
> but meanwhile we had to take the shortest path and that implied reusing
> existing stuff from the first stage prototype.
> We are scheduled to be in production in the next 8 weeks.
> Clojure was targeted for the routing layer in our message bus, that's
> were the immediate benefits are (dispatch logic, message cloning, ...)
>
> For now we have a resilient implementation ready for production so it's
> satisfactory considering I heard about Clojure in September...
> Since the beta book is in progress, i am also catching up rapidly about
> the language and expect to spit out more elegant code in the
> near future :)))
>
> Luc
>
> On Mon, 2008-11-24 at 16:36 -0800, falcon wrote:
> > What is the best way of accessing Java Messaging Service though
> > Clojure?
>
> > Sounds like Rich has already experimented, with good results:
> > >>rhickey: I did some playing (in Clojure) with JMS and OpenMQ and it was
> > >>awesome, easy, fun and vert fast, with pro level docs from Sun
> > (http://clojure-log.n01se.net/date/2008-09-08.html)
>
> > Thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
