Well in the case of 'openssoclientsdk.jar' the problem is...
it has a Singleton Hashmap within 'SystemProperties' which need to be
'filled' differently for Webapps (and if possible for EJBs) which are
using the SDK directly and for the Agent (consisting of a 'realm
implemenation' and servlet filter).
If I don't put 'openssoclientsdk.jar' into the WAR and DON'T use
'delegate=false' the 'SystemProperties' are not set correctly because it
does not find a ResourceBundle called 'AMConfig'. (Except I put this
into <domain-dir-lib>)
BUT if I place the RB there then the Agent (triggered through the
servlet filter used by another Webapp) will get wrong values in the
SystemProperties.
This might be a design issue of 'SystemProperties' from OpenSSO/OpenAM....
Pointers to overcome this are highly appreciated. I could try to change
the design of 'SystemProperties' (at least in OpenAM).
TIA,
Bernhard
On 12/01/2011 02:33 AM, forums_at_java.net wrote:
> The child-first class loading behavior from the servlet spec
> ('delegate=false' here) can be problematic for WARs that bundle jar files
> that duplicate classes higher up in the class loader heirarchy. If
> org.Foo.class is defined in the common loader, for example, and that same
> class is defined in the web loader, the two Class instances are distinct
> types: you can't cast an object created from one to the other type, even
> though the types have the exact same name. This is the infamous
> ClassCastException problem, but there are other more insidious variations
> that result in LinkageErrors; both kinds of errors are extremely
> frustrating
> and hard to diagnose. Most servers have switched this behavior off by
> default
> because these problems do occur, though clearly not with every web app.
>
> This feature is really only needed when you explicitly DO want to duplicate
> classes or resources (the latter in your case). Duplicating resources is
> certainly safer than duplicating classes. Even duplicating classes is often
> safe, but this is hard to predict because it really depends on exactly
> if or
> how the duplicate classes interact; generally, if they never come in
> contact
> there will be no error.
>
>
> --
>
> [Message sent by forum member 'batsatt']
>
> View Post: http://forums.java.net/node/867610
>
>
>
--
Painstaking Minds
IT-Consulting Bernhard Thalmayr
Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
Tel: +49 (0)8062 7769174
Mobile: +49 (0)176 55060699
bernhard.thalmayr_at_painstakingminds.com - Solution Architect
This e-mail may contain confidential and/or privileged information.If
you are not the intended recipient (or have received this email in
error) please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.