Issue 1:
Thomas Whitmore opened SPR-1662 and commented

Hi Juergen, people,

Working on a project now I'd like to use Spring to configure the Dispatcher behaviour of DispatcherServlet; which seems impossible since it's outside the BeanFactory Context.

On a recent Struts -> Spring transition project, referencing from Struts Dispatcher to Spring-created Beans was wanted alongside some use of the Spring Dispatcher. Available and recommended solutions seemed to either create duplicate BeanFactories, or to hit some kind of infinite recursion loop, or to be unable to find the BeanFactory due to initialization issues.

It seems that the coupling of Dispatcher and BeanFactory behaviour directly into the Dispatcher Servlet, may be a less-than-perfect architectural structure.

The Struts -> Spring transition in particular wasted a lot of time trying to integrate these alongside, without suffering infinite recursion. We found it insoluble in the end and needed to convert everything to Spring to continue (a rather costly decision, and also a significant hurdle which some might have chosen not to cross).

These seemed at the time to be general issues, which would affect many Development Transitions from other frameworks/ code into Spring. Much of it was the issue of Referencing beans from outside Spring, versus Creating an entirely new bean factory.

As possible improvement in these areas, I'd like to propose the following :-

allow separation of Dispatcher behaviour from SpringServlet bean-factory creation and loading

Dispatcher could then be created/ configured explicitly within Spring; defaulted if not

SpringServlet to handle bean-factory loading; still parameterized from Servlet Params

allow Dispatcher.HandlerMappings to be specified

(single HandlerMapping can currently be set as a servlet-param, but this is outside Spring)

SpringServlet able to be registered/ found globally; both during loading and once complete

And, less generally but still important :-

Struts integration plugs able to find SpringServlet/ or other bean factory; rather than forcing to load a duplicate.

(recent work may have progressed towards covering this.)

Your thoughts ?

FYI, on the previous project I also implemented Struts Tag -> Spring message resolution support (cleanly) and Struts Validator support from outside Struts (a blatant hack). Overall I found there was rather a lot of work in several areas to implement the transition from Struts -> Spring. Since this must be one of the most common migration paths, surely this would benefit from some smoothing...

Unfortunately I've since moved on, and may only have some of the source code for the above components. Let me know if you'd like me to have a hunt for it.

Cheers,

T

Affects: 1.2.6

Issue 2:
Tyler Nelson opened SPR-1300 and commented

In LocalSessionFactory mappingLocations can have duplicate hbm.xml files as resource[]. However this can cause

org.hibernate.MappingException: duplicate import when LocalSessionFactory loads the same hbm.xml multiple times.

This can be handled by putting a quick lookup check before a new mappingLocation is added or by saving mappingLocations as a Set of Resources.

This can happen when the hbm.xml files exist in both src and classes in a development enviorment. So it isnt an issue with prod. And there is dev workaround(By manuall deleting the extra files or fixing the classpath ). Also one would could say that the build process classpath should address this problem. But it would still be a nice to have.

Affects: 1.2.4

1 votes, 1 watchers