Menu
▾
▴
Re: [ebxmlms-develop] JMSMessageListener contrib?
|
From: Bob K. <py...@ce...> - 2004-01-15 02:00:11
|
Dear Ronald, The Persistence Layer API is quite stable enough, except two issues. One issue is that I have only done a rough testing on it and fixed some bugs before commit, so a more complete testing may be needed. Another issue is that the export, backup and restore function are not supported on the current API. Therefore, I will write two more interfaces, called BackupablePersistenceHandler and ArchivablePersistenceHandler which extends PersistenceHandler to support backup, restore and archive. The API will be committed today but the logic change will be committed later, and I will do more documentation on how to specify those Persistence Handler on msh.properties.xml later. Thanks for your effort on participating the Hermes development. Regards, Bob Koon 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 > > > > -----Oorspronkelijk bericht----- > Van: Patrick Yee [mailto:kc...@ce...] > Verzonden: woensdag 14 januari 2004 10:44 > Aan: ebx...@li... > Onderwerp: Re: [ebxmlms-develop] JMSMessageListener contrib? > > Peter and Ronald, > > Do you think it is possible to base the generic listener on the > JMS one done by Peter? If so, I would like to invite Peter to > coordinate with Ronald on this. I guess the work flow is as > follows: we need to align the design first, and then make the code > done and then finally post it to the CVS. What do you think? > > Regards, -Patrick > > > Mayne, Peter wrote: > >> Ronald is correct: I'm still using an HTTP listener which just >> passes the message to JMS. >> >> I did go some way to using JMS directly, but the current >> implementation isn't completely broken, so I didn't completely >> fix it. :-) >> >> I would also like to see a more generic listener in Hermes. >> >> PJDM >> -- >> Peter Mayne >> Technology Consultant >> Spherion Technology Solutions >> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 >> T: 61 2 62689727 F: 61 2 62689777 >> >> > -----Original Message----- >> > From: Ronald van Kuijk [mailto:rv...@ab...] >> > Sent: Monday, 12 January 2004 12:24 AM >> > To: ebx...@li... >> > Subject: Re: [ebxmlms-develop] JMSMessageListener contrib? >> > >> > >> > Peter mentioned in previous messages about the JMS listerner >> > that there >> > still is http-tunneling involved in his implementation. >> > Looking at the >> > code of the MessageListener and the Request implementation, I >> > see that >> > this tunneling is the only 'easy' option. I'm thinking >> > however about a >> > more direct delivery of messages through JMS. To achieve >> > this, a lot of >> > the servlet implementation has to change. Since I've read that >> some >> > redesign things are going on (like a separate persistence >> layer, and >> > some monitoring/controling redesign), is there a change that >> > there will >> > be changes in the way messages can be delivered? >> > >> > Ronald >> > >> > Ronald van Kuijk wrote: >> > >> > > Hi all, >> > > >> > > Several months ago, there was a discussion about a >> JMSReceiver with >> > > uri/url issue. Especially Peter Mayne was working on this and >> had a >> > > working implementation for this. >> > > >> > > I'm currently working on an application that will be running >> within >> > > the same applicationserver as Hermes. I therefor like to >> > have a more >> > > closely integrated method for sending and receiving messages. >> I was >> > > thinking of a jms queue between the stub and hermes instead >> > of http. >> > > Is there already some code to start with, or extend? Maybe >> > a kind of >> > > contrib thing? Where I can also my LDAPURLResolver, and >> upcomming >> > > LDAPCertResolver. >> > > >> > > Ronald >> > > >> > > >> > > ------------------------------------------------------- >> > > This SF.net email is sponsored by: Perforce Software. >> > > Perforce is the Fast Software Configuration Management >> > System offering >> > > advanced branching capabilities and atomic changes on 50+ >> platforms. >> > > Free Eval! http://www.perforce.com/perforce/loadprog.html >> > > _______________________________________________ >> > > ebxmlms-develop mailing list >> > > ebx...@li... >> > > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop >> > >> > >> > >> > >> > ------------------------------------------------------- >> > This SF.net email is sponsored by: Perforce Software. >> > Perforce is the Fast Software Configuration Management System >> offering >> > advanced branching capabilities and atomic changes on 50+ >> platforms. >> > Free Eval! http://www.perforce.com/perforce/loadprog.html >> > _______________________________________________ >> > ebxmlms-develop mailing list >> > ebx...@li... >> > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop >> > >> >>The information contained in this email and any attachments to it: >> >>(a) may be confidential and if you are not the intended recipient, any interference with, >>use, disclosure or copying of this material is unauthorised and prohibited; and >> >>(b) may contain personal information of the recipient and/or the sender as defined >>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to >>collect, hold and use such information and any personal information contained in a >>response to this email, for any reasonable purpose in the ordinary course of >>Spherion's >>business, including forwarding this email internally or disclosing it to a third party. All >>personal information collected by Spherion will be handled in accordance with >>Spherion's Privacy Policy. If you have received this email in error, please notify the >>sender and delete it. >> >>(c) you agree not to employ or arrange employment for any candidate(s) supplied in >>this email and any attachments without first entering into a contractual agreement with >>Spherion. You further agree not to divulge any information contained in this document >>to any person(s) or entities without the express permission of Spherion. >> >> >> >> > > ------------------------------------------------------- This > SF.net email is sponsored by: Perforce Software. Perforce is the > Fast Software Configuration Management System offering advanced > branching capabilities and atomic changes on 50+ platforms. Free > Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ ebxmlms-develop > mailing list ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop > |
