Re: [ebxmlms-develop] JMSMessageListener contrib?

[Patrick Y. <kc...@ce...>]

Just curious. :-)
If you think the web based gui is generic, please contribute it.. :-)
Regards, -Patrick

  ----- Original Message -----=20
  From: Ronald van Kuijk=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, January 20, 2004 5:29 PM
  Subject: RE: [ebxmlms-develop] JMSMessageListener contrib?


  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