[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Fwd: OpenWire status
From:       James Strachan <james.strachan () gmail ! com>
Date:       2006-02-27 8:35:59
Message-ID: D85E671E-56CE-4E90-992D-5ABA28E46F97 () gmail ! com
[Download RAW message or body]

Resending as this mail seemed to vanish en-route.

Begin forwarded message:

> From: James Strachan <james.strachan@gmail.com>
> Date: 24 February 2006 18:51:26 GMT
> To: activemq-dev@geronimo.apache.org
> Subject: OpenWire status
>
> I've spent a while working on the C# client (openwire-dotnet  
> module) and we've a working client that can create connections,  
> sessions, producers, consumers and send, receive and acknowledge  
> messages using the underlying OpenWire transport. Yay!
>
> I've started a page to document it further here...
> http://docs.codehaus.org/display/ACTIVEMQ/OpenWire+dotNet
>
>
> As part of this effort I refactored the Groovy scripts somewhat to  
> really simplify them down to basic templates with all the clever  
> logic in a Java class (to make it easier to edit & test etc). I'm  
> pretty happy with the OpenWire infrastructure, it appears to work  
> very well. (I still need to refactor the scripts to generate the  
> JUnit/NUnit tests but the classes & marshalling code is all done now).
>
> I just thought I'd brain dump here the things which are not 100%  
> ideal though all are quite easy to live with...
>
>
> * dealing with errors.
>
> You can enable stack traces in the WireFormatInfo. (BTW I  
> refactored WireFormatInfo to avoid bitwise flags going into an int  
> - which are hard to keep in sync across languages - to use boolean  
> flags instead). If you enable stack traces then you get nested  
> exceptions with full stack trace information. Right now I had to  
> manually write the marshalling for this type in C# (I added  
> BrokerError and StackTraceElement as types). Ideally these would be  
> commands in OpenWire that just fall out for free along with all the  
> other code generation.
>
> * knowing what commands are auto-generated versus what are manually  
> created.
>
> In the C++ and C# OpenWire bindings the scripts auto-created all  
> the commands but then a bunch of them were hand coded after that  
> (the destinations and message classes which derive from Message).  
> Its not a major big deal, as the manually edited classes never  
> change and don't have much data in them (a base class has the data)  
> but it would be nice to separate out the auto-generated classes  
> from the ones-that-must-be-editted in a slightly cleaner way. Not a  
> big deal this one though :)
>
> * client testing
>
> We've started creating some .Net NUnit tests to try out the  
> OpenWire.Net client against an ActiveMQ broker. The Java unit test  
> cases don't clearly split up the tests of just the client versus  
> tests which test everything; it'd be good to come up with a good  
> suite of tests that we need to create for each language that really  
> test out the behaviour of the client. We can test out the broker in  
> Java-land; we don't need to retest it in C# and C++ as well; we  
> mostly just need to test that the on-the-wire commands work. Over  
> time I'm sure we'll come up with a good list of features to test in  
> a client (e.g. standard JMS headers, custom headers, durable/non- 
> durable messaging, create/stop consumers, test selectors work, sync  
> v async consumption, transactions etc).
>
>
> All in all I'm very impressed with the OpenWire infrastructure  
> (good job Hiram!:), while at first its way more complex than Stomp  
> (which is ideal for writing clients quickly), its looking like  
> OpenWire will support full JMS clients in other languages with  
> minimal work. I'm impressed with how clean and simple the .Net  
> client turned out to be - here's hoping the C++ client is just as  
> simple - yet powerful.

James
-------
http://radio.weblogs.com/0112098/


[prev in list] [next in list] [prev in thread] [next in thread]