JMS Adaptor

[Bill Graham <bi...@gmail.com>]

hi,

I have a need for a Chukwa JMS adaptor, so I was planning on writing one and
contributing it. Before open a JIRA and getting started though, I wanted to
run my ideas past the group. Here's what I'm thinking:

- oah.chukwa.datacollection.adaptor.jms
This is the package where the code will live. Creating a new package since
there will be a couple of related classes.

- JMSAdaptor
This is the main class that will connect to a JMS topic, listen for messages
and add chunks to the receiver. It uses a JMSMessageTransformer to transform
the message to a byte array.

- JMSMessageTransformer
An interface that knows how to transform a JMSMessage into a byte array with
the following method:
  public byte[] transform(javax.jms.Message message);

- JMSTextMessageTransformer
This will be the default transformer, which transforms a
javax.jms.TextMessage's payload into a byte array

- JMSMessagePropertyTransformer
This is what I'd personally need so I might add this as well. It takes a
collection of ordered message property names and a delimiter and returns a
byte array made using the corresponding property values.

- Configuration would look something like this:
add JMSAdaptor <brokerURL> -t <topicName> [-s <JMSSelector>] [-x
<transformerName>] [-p <transformerProperties>] <offset>

- New dependancies
Sun's JMS
Sun's J2EE Management
Apache ActiveMQ
Apache Commons Pool

This first pass would only work with a topic but subsequent releases could
work with a queue if the need arises. The selector is to filter on certain
types of messages. TransformerName is to override the default transformer
and transformerProperties is whatever properties it takes.

So that's what I'm thinking. Please let me know if you have comments, about
naming, functionality, structure, configuration, etc.

thanks,
Bill

Re: JMS Adaptor

[Ariel Rabkin <as...@gmail.com>]

Sounds good. Though note that the datatype is a mandatory part of the
add command, so your syntax will need (slight) modification.

On Thu, Apr 1, 2010 at 4:50 PM, Bill Graham <bi...@gmail.com> wrote:
> hi,
>
> I have a need for a Chukwa JMS adaptor, so I was planning on writing one and
> contributing it. Before open a JIRA and getting started though, I wanted to
> run my ideas past the group. Here's what I'm thinking:
>
> - oah.chukwa.datacollection.adaptor.jms
> This is the package where the code will live. Creating a new package since
> there will be a couple of related classes.
>
> - JMSAdaptor
> This is the main class that will connect to a JMS topic, listen for messages
> and add chunks to the receiver. It uses a JMSMessageTransformer to transform
> the message to a byte array.
>
> - JMSMessageTransformer
> An interface that knows how to transform a JMSMessage into a byte array with
> the following method:
>   public byte[] transform(javax.jms.Message message);
>
> - JMSTextMessageTransformer
> This will be the default transformer, which transforms a
> javax.jms.TextMessage's payload into a byte array
>
> - JMSMessagePropertyTransformer
> This is what I'd personally need so I might add this as well. It takes a
> collection of ordered message property names and a delimiter and returns a
> byte array made using the corresponding property values.
>
> - Configuration would look something like this:
> add JMSAdaptor <brokerURL> -t <topicName> [-s <JMSSelector>] [-x
> <transformerName>] [-p <transformerProperties>] <offset>
>
> - New dependancies
> Sun's JMS
> Sun's J2EE Management
> Apache ActiveMQ
> Apache Commons Pool
>
> This first pass would only work with a topic but subsequent releases could
> work with a queue if the need arises. The selector is to filter on certain
> types of messages. TransformerName is to override the default transformer
> and transformerProperties is whatever properties it takes.
>
> So that's what I'm thinking. Please let me know if you have comments, about
> naming, functionality, structure, configuration, etc.
>
> thanks,
> Bill
>
>



-- 
Ari Rabkin asrabkin@gmail.com
UC Berkeley Computer Science Department