Menu
▾
▴
Re: [ebxmlms-develop] JMSMessageListener contrib?
|
From: Ronald v. K. <rv...@ab...> - 2004-01-29 15:31:04
|
It is generic and I definately like to contribute it. I'll draw up a
short summary of changes I made to several files in hermes and why.
Many changes are not final, just changes to get things working. Maybe
you guys (galls?) have different ideas about how it should be done.
Maybe I did some real "stupid" things, but don't hesitate to mention
that (or 'fix' them ;-) )
Ok... here I go.
There are two main issues to get a fully implemented web-gui. The first
is that generating a command is only possible from within the same
package as the command class. This could be the Request class, but that
is fully http oriented. The second issue is that sending/issueing
command is only possinblr from within the MessageServiceHandler class
itself or via the servlet.
Regarding the generation of commands I could have started adapting the
Request class to make it less http oriented and usable directly in the
server. Since this class does a lot more than just generating commands
and almost all the methods contained something like
/**
* Gets the isHalted attribute of the Request object
*
* @return The isHalted value
* @exception RequestException Description of the Exception
*/
public boolean getIsHalted() throws RequestException {
final Command command =
new Command(CommandConstants.QUERY_MSH_STATUS, null);
final HttpURLConnection connection = sendCommand(command);
Map result = expectMapResponse(connection, "Cannot get MSH Status");
String s = (String) result.get(Constants.QUERY_RESULT_MSH_STATUS);
if (s == null) {
throw new RequestException(
"Cannot get MSH status; Invalid response from MSH");
} else {
boolean b = Boolean.valueOf(s).booleanValue();
return b;
}
}
with the HttpURLConnection, I was not comfortable adapting it, so
started cutting/pasting methods to a new MessageServiceHandlerControl
class and this method became
public boolean isHalted()
throws MessageServiceHandlerException, RequestException{
Command mshCommand = new
Command(CommandConstants.QUERY_MSH_STATUS, null);
CommandResult cr = messageServiceHandler.processCommand(mshCommand);
Map result = cr.getResultMap();
//expectMapResponse(connection, "Cannot get MSH Status");
String s = (String) result.get(Constants.QUERY_RESULT_MSH_STATUS);
if (s == null) {
throw new RequestException(
"Cannot get MSH status");
} else {
boolean b = Boolean.valueOf(s).booleanValue();
return b;
}
}
The CommandResult object was created to contain a boolean status, a Map
and a Document, depending on the type of command and what it returns. I
currently only 'converted' 4 commands, since I just wanted to see what I
would run in to. If the Request class could be made generic in one way
or another, or refactor it and split it into two classes that's fine by
me. Duplicating things is not the way to go (although cloning me is one
thing my boss would not mind ;-) )
To be able to use the processCommand I refactored it to not require a
response object. The response of the processCommand now is a
CommandResult object mentioned before. In the doPost, the CommandResult
is parsed and the correct type of response is send back. The only 3
commands that (currently) still need the response object are put in a
separate method processMessageCommand. After this, the processCommand
can be used in other ways as well, either directly from another class
(the new MessageServiceHandlerControl which is accessed from the
web-gui) or the JMSMonitor, which only accepts sendMessage commands,
nothing else. The MessageServiceHandlerControl can by default not get
access MessageServiceHandler, so I added
final MessageServiceHandlerControl messageServiceHandlerControl
= MessageServiceHandlerControl.getInstance();
messageServiceHandlerControl.setMessageServiceHandler(this);
to the MessageServiceHandler.
Again, the attached code is pre-alpha and should, in combination with
the explanation above, just be used to 'get the idea'
Attached are:
MessageServiceHandler.java
MessageServiceHandlerControl.java
Command.java
CommandResult.java
Exceptionhandling should be better, security should be taken into
account more, etc....etc...etc...
The webapp is in an even earlier stage, so I'll not attach that (yet)
Best,
Ronald
Patrick Yee wrote:
> Just curious. :-)
> If you think the web based gui is generic, please contribute it.. :-)
> Regards, -Patrick
>
>
> ----- Original Message -----
> *From:* Ronald van Kuijk <mailto:rv...@ab...>
> *To:* 'ebx...@li...'
> <mailto:%27e...@li...%27>
> *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
>
|
