RE: [ebxmlms-develop] JMSMessageListener contrib?

[Ronald v. K. <rv...@ab...>]

Yes, but commands in the web based gui go to the processCommand method.
(Which is in the servlet). I do not (necessarily) want the JMS listener
to be able to stop, start, etc the server. Just a sending and receiving
messages. Why do you ask this? Should I take some things into accout?
 
Ronald

-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: dinsdag 20 januari 2004 10:20
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] JMSMessageListener contrib?


Ronard,

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?

Regards, -Patrick


Ronald van Kuijk wrote:


Patrick,
 
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.
 
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?)
 
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?
 
Ronald




------------------------------------------------------- The SF.Net email
is sponsored by EclipseCon 2004 Premiere Conference on Open Tools
Development and Integration See the breadth of Eclipse activity.
February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop