RE: [ebxmlms-develop] JMSMessageListener contrib?

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

Thanks Peter, saves me a lot of time comming to the same conclusion.
 
In addition to this, I'm looking into creating a web based
monitoring/management functionality for Hermes based on struts and even
a web base test-client. Currently the management things are realy
tightly integrated with the messaging servlet. Splitting management
functionality into another url (/msh-console?) and even splitting of the
management functionality completely would probably make it easier to
have some general serverside message processing. 
 
Anyone interested in this? I volunteer to refactor this part, but since
it is also related closely with the persistency layer, maybe I should
wait until that as landed fully.
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: zondag 11 januari 2004 23:14
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] JMSMessageListener contrib?



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... <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
<http://www.perforce.com/perforce/loadprog.html>  
> > _______________________________________________ 
> > ebxmlms-develop mailing list 
> > ebx...@li... 
> > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
<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
<http://www.perforce.com/perforce/loadprog.html>  
> _______________________________________________ 
> ebxmlms-develop mailing list 
> ebx...@li... 
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
<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.