RE: [ebxmlms-develop] JMS URI proposal

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

You mean you use JMS from within a servlet engine without using JNDI? Do 
you explicitely provide a connectionfactory class, etc?

By context and provider url, you mean the java.naming.factory.initial 
and  java.naming.provider.url property? Or something with a hashtable, 
properties like

    Hashtable properties = new Hashtable();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,  
"<initial-context-factory-class>");
    properties.put(Context.PROVIDER_URL, "<provider-url>");
    Context context = new InitialContext(properties);

or something like this in a propety file.

In these cases, you *are* using JNDI.

If it is nothing like this, could you give an example for the 
parameters/property file you use.

Ronald


    -----Oorspronkelijk bericht-----
    *Van:* Mayne, Peter [mailto:Pet...@ap...]
    *Verzonden:* woensdag 28 januari 2004 3:39
    *Aan:* 'ebx...@li...'
    *Onderwerp:* RE: [ebxmlms-develop] JMS URI proposal

    I've managed to get by so far without using JNDI, so I have no idea
    how to configure a JNDI provider to specify these things. You'd have
    to document it carefully.

    In my properties files I specify context factory, provider URL,
    queue connection factory, and queue name. I don't know how you get
    by without specifying the provider specific things in the URI.

    Given that its easy to dedicate a queue to Hermes, I don't see any
    need for other parameters. I assume sensible defaults such as
    persistent messages.

    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: Wednesday, 28 January 2004 11:52 AM
     > To: Ebxmlms-Develop (E-mail)
     > Subject: [ebxmlms-develop] JMS URI proposal
     >
     >
     > All,
     >
     > For the return-path of messages to be delivered in a JMS Queue,
    there
     > has been a discussion of a jms: uri. Whether a uri is right or
    wrong,
     > hermes uses it internally. There are several options (see
     > http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&q=p3
    <http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&q=p3>)
     >
     > I'm in favour of using the JNDI based one, without the
     > provider specific
     > things, so
     >
     > jms:///queue?connectionFactory=<conn-factory-jndi-name>&destin
     > ation=<dest-jndi-name>
     >
     > Meaning, it's a queue (not a topic) with a connectionFactory that is
     > fetched by looking it up in the default initialcontext by the
    name of
     > <conn-factory-jndi-name>. The queue is also looked-up in the jndi
    tree
     > by the name of <dest-jndi-name>.
     >
     > Does anybody have other ideas or see the need for using additional
     > properties like delivermode, priority etc..?
     >
     > Best,
     >
     > 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
     >

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.