Announcement Announcement Module
No announcement yet.
Tomcat / JaxWS / Spring Problem Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tomcat / JaxWS / Spring Problem

    I've had this thread running in the Core Container forum for a couple of weeks and have not had any success in a useful response. Hopefully I'll have more luck here...

    You can read the full thread here:

    But to summarise, I have a Tomcat JaxWs application which uses an application core in Spring. So I have some bridging code in my web-service handler that finds and uses Spring-configured objects. It then goes wrong. The summary in the other thread reads like this:

    Okay, so a brief summary of what I know so far (in the hope that someone out there can relate):
    - You have to set the contextConfigLocation web.xml param. If you don't, it looks for applicationContext.xml
    - All beans loaded through the contextConfigLocation have their shutdown hooks called correctly
    - Bean instances loaded through the contextConfigLocation param are NOT accesible through the SingletonBeanFactory
    - If you specify a parentContextKey you must also specify a locatorFactorySelector
    - parentContextKey loaded beans are accessible through the ContextSingletonBeanFactoryLocator and are accessible from the bridging code
    - Beans aquired through the ContextSingletonBeanLocator (whether through the parentContextKey config or through the bridging code) DO NOT have shutdown hooks called

    This all seems to make it pretty unusable for the basic case of sharing bean instances - particularly the last point. If the SingletonBeanFactory correctly called the shut-down hooks I could work around this behaviour by specifying an empty file in the contextConfigLocation.

    Can anyone confirm this behaviour?

    It looks like I might have to abandon the bridging code and have the shared objects keep a static reference to themselves when instantiated so that the bridging code can access that instead Or alternatively write my own Singleton manager that the shared objects register themselves with.

    Not good.