Hi Bernhard,
If I understand correctly, your library 'X' is deployed in a global /lib dir
(install or domain), and the properties file 'Y' is deployed in the same
location. As you have surmised, this makes such global classes and resources
(in the common loader) take precedence over those packaged in an application,
since the common classloader is "higher" up the delegation path. The
'delegate=false' mechanism in the WAR inverts the search order, and so
'fixes' the problem, but that feature is only available at the WAR level so
is not a general solution (and really, I strongly discourage the use of this
anyway, as it can lead to other very difficult to diagnose classloading
issues).
The best workaround is to ensure that 'Y' is only packaged within
applications, not deployed globally; this way, using the thread context class
loader (from methods in library 'X') will find it correctly in the
application. If a global properties file is required, giving it a different
name (or path) to make it unique would be the best bet; yes, this does
require some special case logic, but I don't see any other reasonable
solution.
I assume that you are wrapping the agent to implement the AppservRealm class?
Is it the wrapped code that does the property file lookup? If so, then you
probably can't change the code for the global name change I suggested above,
but could you eliminate the pre-packaged properties file so that only
applications will carry it? If it is your code doing the lookup, give the
workaround a try.
// Bryan
--
[Message sent by forum member 'batsatt']
View Post: http://forums.java.net/node/867610