RE: [Springframework-developer] Jndi accessor superclass / JMS

[Mark P. <mar...@co...>]

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Les A. Hazlewood
> Sent: Wednesday, June 30, 2004 9:26 AM
> To: spr...@li...
> Subject: [Springframework-developer] Jndi accessor superclass / JMS
> 
> 
> Hi folks,
> 
> I'm working (meddling?) with the sandbox JMS code with Mark 
> and I have a question about JNDI lookups.
> 
> I'm creating a JmsTemplate class that allows one to specify a 
> ConnectionFactory jndi name and a Destination jndi name, both 
> of which are needed to send and receive messages in JMS.
> 
> They are both resources that are usually requested from JNDI 
> as two different lookups.
> 
> Now, I am making a JmsAccessor class (following the lead of 
> HibernateAccessor
> --> HibernateTemplate pattern) that handles acquiring those 
> two objects.  
> --> I
> wanted to subclass AbstractJndiLocator so I could utilize the 
> resourceRef and JndiTemplate support already there, but 
> AbstractJndiLocator expects only one object to be located.
> 
> Would it be prudent to create a superclass of 
> AbstractJndiLocator called AbstractJndiAccessor that provides 
> everything except specifying a jndiName and doing a singular 
> lookup?  Then subclasses could do as many lookups as they 
> require during their afterPropertiesSet() methods.  
> AbstractJndiLocator would still do its singular lookup, but 
> other subclasses could do more than one...
> 
> Or maybe I'm off base architecturally?  Maybe my JmsAccessor 
> should use OO delegation and use two concrete instances of 
> AbstractJndiLocator to do the two separate lookups?
> 
> I like the first approach better since the second involves 
> extraneous code (methods in turn call identical delegate 
> methods for setting JndiTemplate, resourceRef, etc).  Also my 
> OO philosophy is that more specific (limiting) features of a 
> class exist lower in the hierarchy.  I consider a single 
> lookup a limiting feature than what could exist in a superclass.
> 

I put jms destination look ups (and dynamic destination creation) in the
jms.support package, JmsAdmin.java  I remember thinking there might be a
better way but can't think of it right now..  JmsTemplate delegates to
JmsAdmin for its look ups...

> At the end of the day, I would like something as simple as:
> 
> JmsTemplate jmsTemplate =
>     new JmsTemplate(connectionFactoryName, destinationName);
> 
> jmsTemplate.send(Object payload, Map messageProperties);
> 
> I don't know...maybe its too early to be thinking about this 
> stuff yet? ;)
> 

My 2cents...It isn't too early.  I didn't add support for setting the
default message destination for a producer.  That can be done asap.
The Bean<->Message converter class is just about ready for inclusion in the
sandbox.  I was just about to add it, along with corresponding methods no
the JmsSender such as you indicate, but took a step back to think about how
to better handle the QOS settings (TTL, persistent...)

> Thoughts?
> 
> Regards,
> 
> Les
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & 
> Training. Attend Black Hat Briefings & Training, Las Vegas 
> July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>