Menu
▾
▴
Re: [ebxmlms-develop] JMSMessageListener contrib?
|
From: Patrick Y. <kc...@ce...> - 2004-01-20 09:20:10
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> Ronard,<br> <br> Thanks. I have one question. It seems to me that you want to create different types of listeners (jms, http, etc.). After making that, your plan is to rely on those listeners to build a web based gui without sending commands through msh servlet. Am I right?<br> <br> Regards, -Patrick<br> <br> <br> Ronald van Kuijk wrote:<br> <blockquote type="cite" cite="mid...@ab..."> <meta content="text/html; " http-equiv="Content-Type"> <title></title> <meta name="GENERATOR" content="MSHTML 6.00.2800.1276"> <div><span class="137593210-14012004"><font size="2" color="#0000ff" face="Arial">Patrick,</font></span></div> <div><span class="137593210-14012004"></span> </div> <div><span class="137593210-14012004"><font size="2" color="#0000ff" face="Arial">I've been looking into the MessageServiceHandler code last night to look into issues for making it possible to have a web based gui without tunnelling command's through the msh servlet. I've seen that the response object is used many layers deep and started refactoring some parts of the MessageServiceHandler to make it possible to give the commands in another way. This is almost working, without changing much of the code, regarding functionality. Al the refactoring took place mainly in the processCommand method. I've taken out the necessity for the response object in this method and created one additional method for those commands that currently realy need the response object (getMessage, getMessageByID etc...) So besides the processCommand and ProcessMessage, there now is a processMessageCommand method.</font></span></div> <div><span class="137593210-14012004"></span> </div> <div><span class="137593210-14012004"><font size="2" color="#0000ff" face="Arial">Once this is done (at least for myself, but if you are interested, I'm happy to contribute it), I think it would be possible to spend some time to see whether we can really start implementing the jms:// kind of uri's, or maybe don't do it based on the uri, but create different listeners types (JMSListerner, HTTPListener, FileListener, etc...) each with their own type of config (including static appContext configurations?)</font></span></div> <div><span class="137593210-14012004"></span> </div> <div><span class="137593210-14012004"><font size="2" color="#0000ff" face="Arial">Great btw, to see the persistence layer be made configurable, i've seen some things were checked in. Is the api stable enough to start working on a database persistence layer for the messages?</font></span></div> <div><span class="137593210-14012004"></span> </div> <div><span class="137593210-14012004"><font size="2" color="#0000ff" face="Arial">Ronald</font></span></div> <div><span class="137593210-14012004"></span> <br> </div> </blockquote> <br> </body> </html> |
