Need help manually publishing a message

I have a business service which registers a user. The service method doesn't have a return value so the @Publisher annotation is out of the question. What I need to do is to publish an event with the user object to a JMS topic for further processing.

I would like to add a line in my service method akin to the following:

Code:

---

outputChannel.send(user)

---

...And have Spring Integration transform my user to a message and send it off to JMS.

Here's my integration config thus far:

Code:

---

<jee:jndi-lookup id="cf" jndi-name="jms/cf" expected-type="javax.jms.ConnectionFactory" />
<jms:publish-subscribe-channel id="completedUserRegistrations" connection-factory="cf" topic-name="mytopic" />

---

I don't think setting up my Spring Integration objects are a problem. It's really a question of how do I inject some Spring Integration component into my existing service to publish? I haven't seen any examples where Java Code actually kicks off the publishing and I searched the Reference Doc and read Maning's MEAP Spring Integration in Action.

Why not change your method to return a Message and put your user object to its payload? And then you can set up a service-activator to use the method to send out the message to a channel, then connect that channel to the jms:outbound-channel-adapter.

Of course you can inject a channel to your service and use the channel to send out message, but obviously it is not a good implementation to spring integration.

You can use SpEL expressions to bind other values to the Message payload (e.g. #args[0]). Can you show the signature of the service method?

Thanks,
Mark

xugingyang, I am installing SI as part of an implementation upgrade. I am decoupling my implementation components but I don't have the ability to modify the public API. I have no desire to expose a Message<?> to the outside world; within the network of implementation components, that would be acceptable of course.

Mark, the signature is:

Code:

---

void registerUser(User user)

---

Mark, what appeals to me though is for my registerUser() implementation to actually have the code to trigger the message/event. This will allow me to code where/when events can be sent out and allow me to mock the sending during unit testing. For example, I would prefer a simple interface like this:

Code:

---

public interface UserEventTriggers {
  void publishRegistrationEvent(User user);
}

---

And my UserEventImpl would be wired up with the correct MessageChannel and use MessageBuilder to create the message.

What are your thoughts?

Hello.
You may go here: http://static.springsource.org/sprin...nevent-inbound

Artem

I could locally publish events from my ApplicationContext and have an SI inbound-channel-adapter receive it? Pretty neat. What else do I need to send the receiving event to a JMS Topic?

You can simply add a JMS outbound-channel-adapter that references the Topic as its destination. However, if you don't want to go through the ApplicationEvent step, you can also use the Spring Integration MessagingTemplate. It provides simple methods like convertAndSend(someObjectThatShouldBeThePayload).

As far as testing, you can just connect something other than the JMS channel-adapter to the channel that the MessagingTemplate is sending to... then you can grab Messages there instead (e.g. use a QueueChannel).

Hope that gives you some more ideas.
-Mark

Mark, I did some more reading of the Reference Documentation. It seems that I can simply use <si:publish-subscribe-channel> since my JMS Topic producer and consumer are within the same process. This means I won't need an <si:outbound-channel-adapter>, right, to send a message?

If they are in the same process, you might not even need to use JMS (in fact the core "publish-subscribe-channel" would not... only the one in the "jms" namespace). Is that what you are thinking? Or if not, can you describe why you need JMS? (distributed systems, persisting messages within a TX, etc).

-Mark

Sorry Mark. I meant <jms:publish-subscribe-channel> above because I need (1) the message to be persisted in the event of a system failure and (2) the producer to be of the XA transaction with JDBC. While today both the producer and consumer are in the same process, if it becomes too much on the single process to handle both sides, I will split the two up and retain the underlying JMS setup. Does that make sense?