|
From: Ronald v. K. <rv...@ab...> - 2004-01-30 02:00:18
|
Hi all,
I currently have a JMSMonitor implemented like the MailMonitor is
implemented. It is an innerclass with all the same halt, resume,
shutdown methods. The difference (currently) is that it requires a
Command object. To have the Command object available in the 'client'
(which is not in the same package) so it can generate the command and
put it in the JMSQueue, I had to make the Command class and the
Command(Serializable content, EbxmlMessage ebxmlMessage) constructor
public. I do not see this as a security issue, since instantiating a
command object does not mean it will be processed. The security should
be on the JMSQueue if needed just like it is on the doPost. Any objections?
It works like a charm and fast as well. The disadvantage of the current
implementation is that it is /in/ MessageServiceHandler, which means it
cannot be compiled just for a servlet engine. There are two solutions to
this problem that spring to mind, both which at least require it to
become an external class, but that's the simple part and follow some
interface
The relatively simple solution is to reserve a element in the config
file e.g. externalMonitor which takes a classname as value.
e.g.
<externalMonitors>
<externalMonitor>net.vankuijk.messaging.ebxml.JMSMonitor</externalMonitor>
<externalMonitor>any.domain.package.AnExternalMonitorImpl</externalMonitor>
</externalMonitors>
There can be some generic mechanism in the MessageServiceHandler to
create instances of all externalMonitors on startup. Each
externalMonitorImpl should take care of it's own properties. The thing
is that I cannot think of any other implementations, so it could be even
a full configuration in the general config file
<!--uncomment the next segment if you want a JMSMonitor -->
<JMSMonitor>
<ClassName>net.vankuijk.messaging.ebxml.JMSMonitor</ClassName>
<JNDIFactoryName>QueueFactory</JNDIFactoryName>
<JNDIQueueName>queue/JMSMonitor</JNDIQueueName>
<ReceiveTimeout>5000</ReceiveTimeout>
</JMSMonitor>
Please, comment on this. Next things to work on :
- Accept a message in plaintext (textmesssage in JMS) as well as an
objectmessage with a command in it.
- Implement the return way, so messages received from external MSH's can
be delivered in a JMS queue
Ronald
|