Thanks for you attention Bryan,
to make it more clear...
OpenSSO/OpenAM J2EE policy Agents is packaged within 'agent.jar'
Classes within 'agent.jar' need classes from 'openssoclientsdk.jar'.
To make the 'realm' work both have to be put into <domain-dir>lib.
Now I have an application you wants to leverage 'OpenSSO client SDK' (so
classes/methods from 'openssoclientsdk.jar').
'OpenSSO client SDK' has some bootstrapping code , f.e. to get the URL of
the OpenSSO server, service user and service password
This bootstrapping is done by the class 'SystemProperties' receiding within
openssoclientsdk.jar.
It reads the resource bundle 'AMConfig'.
If I put the resource bundle <domain-dir>/lib/classes then the agent gets
the wrong configuration.
If I package the resource bundle with the app it's not found because the
common classloader does not 'see' it (as he is higher in the delegation
path).
As all this is '3rd party' code I can not change anything ...., but the
packaging of the application.
IIRC this has been possible with GF 2.1.1 because it has a different class
loader* *hierarchy (and the shared chain classloader).
Do to the new class loader hierarchy it's very troublesome to migrate
application from GF 2.1.1 to GF 3.1.1 ... :-(
-Bernhard
On Mon, Nov 28, 2011 at 9:59 PM, <forums_at_java.net> wrote:
> 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<http://forums.java.net/node/867610>
>
>
>
--
IT-Consulting Bernhard Thalmayr
- Painstaking Minds -
83620 Vagen (Munich area)
Germany