JmsMessagingExceptionTranslator package tangle [SPR-12064]

[spring-projects-issues]

Stéphane Nicoll opened SPR-12064 and commented

The addition of JmsMessagingExceptionTranslator created a package tangle.

That class uses MessageConversionException (from the .convert sub-package and DestinationResolutionException (from the .destination sub-package).

In the .convert sub-package, MessagingMessageConverter uses the header mapping facility from the support package

In the .destination sub-package, JmsDestinationAccessor uses the JmsAccessor base class

Since JmsDestinationAccessor isn't new, JmsMessagingExceptionTranslator can't really sit in the .support package and have dependencies to some of the sub-packages. It looks like it should go back to the root package.

---

Affects: 4.1 RC2

Issue Links:

• JmsMessagingTemplate should not throw JmsException directly [SPR-12038] #16654 JmsMessagingTemplate should not throw JmsException directly

Referenced from: commits c06ac06

[spring-projects-issues]

Juergen Hoeller commented

Hmm, the root jms package shouldn't depend on any support subpackages either... I suppose we'll have to put JmsMessagingExceptionTranslator into a different jms subpackage then, or create a new support subpackage for it.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

After a bit of back and forth, it occured to me that the whole use of a generic MessageExceptionTranslator mechanism is rather non-ideal here: It's syntactically modelled along the lines of PersistenceExceptionTranslator but serves a different semantic role...

PersistenceExceptionTranslator is implemented by the resource factories of all our target technologies, and discovered by a generic exception translator interceptor that finds PersistenceExceptionTranslators by type in the application context. This is why it's typed to evaluate any RuntimeException. Notably, it is not being used as a customization strategy for a specific technology, e.g. not as a setter on any Hibernate support class, where specific typing for the local exception base class would be preferable.

For local customization of exception translation mechanisms, we rather use protected template methods which specifically convert the exceptions within a target technology. I've revised JmsMessagingTemplate to delegate to such a convertJmsException method now, which feels more natural and effectively leaves MessagingExceptionTranslator without a well-defined role, which is why I've opted for removing that interface altogether for the time being. As a positive side effect, the package tangle disappears along with it...

Juergen