DisplayTag

DisplayTag does not load displaytag.properties if library and config file placed in different classloaders

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0 RC2
  • Fix Version/s: 1.0
  • Component/s: None
  • Labels:
    None
  • Application server:
    Tomcat 5.5.4

Description

I recently placed displaytag-1.0-rc2.jar in tomcat's shared classloader (${tomcat.home}/shared/lib) instead of the webapp classloader and noticed that all my localized column titles disappeared. After a short investigation it turned out that the displaytag.properties placed in web application (which contains config for locale.provider=org.displaytag.localization.I18nStrutsAdapter) is not loaded.

I placed a copy of displaytag.properties in the same classloader as the displaytag-1.0-rc2.jar (that is: ${tomcat.home}/shared/classes ), and voila, it works perfectly.

The bottomline: displaytag.properties is usually strongly related with particular web application while displaytag library might be shared across aplications. It should be possible to have a configuration as described above.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dominik Drzewiecki added a comment -
Having referred to the docs and tought on it a bit, I came to the conclusion that there is no way to refer to the webapp classloader from the classes loaded in the shared classloader, is there? (while the opposite *IS* possible via ClassLoader ClassLoader.getParent()). However, I still think that the config I described makes sense, but there seems that there is no reasonable solution (I'd have to stick with placing the displaytag.jar in the webapp classloader)
Show
Dominik Drzewiecki added a comment - Having referred to the docs and tought on it a bit, I came to the conclusion that there is no way to refer to the webapp classloader from the classes loaded in the shared classloader, is there? (while the opposite *IS* possible via ClassLoader ClassLoader.getParent()). However, I still think that the config I described makes sense, but there seems that there is no reasonable solution (I'd have to stick with placing the displaytag.jar in the webapp classloader)
Hide
Permalink
Dominik Drzewiecki added a comment -
Yet another thought.

Struts library, when placed in the shared classloader *is* capable of loading resource bundles from webapp classloader. This is done via obtaining an executing thread classloader.

ClassLoader classLoader = Thread.currentThread().getContextClassLoader();

I am not absolutely sure if this could apply to this case, but I think it is worth further investigation.
Show
Dominik Drzewiecki added a comment - Yet another thought. Struts library, when placed in the shared classloader *is* capable of loading resource bundles from webapp classloader. This is done via obtaining an executing thread classloader. ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); I am not absolutely sure if this could apply to this case, but I think it is worth further investigation.
Hide
Permalink
fabrizio giustina added a comment -
committed in cvs for 1.0. Displaytag can now load properties file from the thread classloader. You should still be careful on placing displaytag jar in server libs since, because of caching, properties will be shared among different web applications.
Show
fabrizio giustina added a comment - committed in cvs for 1.0. Displaytag can now load properties file from the thread classloader. You should still be careful on placing displaytag jar in server libs since, because of caching, properties will be shared among different web applications.
Hide
Permalink
Anonymous added a comment -
Thanks !!! ;-)
Show
Anonymous added a comment - Thanks !!! ;-)
Hide
Permalink
fabrizio giustina added a comment -
Marking fixed issue as closed.
Show
fabrizio giustina added a comment - Marking fixed issue as closed.

People

  • Reporter:
    Dominik Drzewiecki
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: