Description

When used in an EAR archive the Digester default classloading/resource loading
implementation makes many major frameworks unusable. For Example, if I use
Struts/Tiles (uses digester) in Web App war files and use Digester from any EJB
component library or in the EAR classloader space either the Tiles definitions
cannot be loaded or other classes cannot be found. This is because Digester by
default sets useContextClassloader = false. Since most users and frameworks
(Struts, Tiles, JSF, etc) do not set useContextClassloader = true, Digester
essentially breaks enterprise Applications where the Digester is used from more
than one module. Note that end users do not control the uses of Digester, the
default useContextClassloader policy should = true.

Patch by changing:

useContextClassloader = false

to:

useContextClassloader = true

//
This solves the problem - which Google turns up endless hits.

Activity

Changed status from blocker. The proposed change certainly can't be implemented
as -is; that would be a major backwards incompatibility. More research is needed
into whether a fix is needed for this, and if so how to do that. Maybe some kind
of properties file lookup so that this feature can be enabled by end users
rather than via the code?

This definitely doesn't block other digester releases...it's the way digester
has behaved for many releases.

Simon Kitching
added a comment - 17/Oct/05 18:38 Changed status from blocker. The proposed change certainly can't be implemented
as -is; that would be a major backwards incompatibility. More research is needed
into whether a fix is needed for this, and if so how to do that. Maybe some kind
of properties file lookup so that this feature can be enabled by end users
rather than via the code?
This definitely doesn't block other digester releases...it's the way digester
has behaved for many releases.

(In reply to comment #1)
> Changed status from blocker. The proposed change certainly can't be implemented
> as -is; that would be a major backwards incompatibility. More research is needed
> into whether a fix is needed for this, and if so how to do that. Maybe some kind
> of properties file lookup so that this feature can be enabled by end users
> rather than via the code?
>
> This definitely doesn't block other digester releases...it's the way digester
> has behaved for many releases.

(In reply to comment #1)
> Changed status from blocker. The proposed change certainly can't be implemented
> as -is; that would be a major backwards incompatibility. More research is needed
> into whether a fix is needed for this, and if so how to do that. Maybe some kind
> of properties file lookup so that this feature can be enabled by end users
> rather than via the code?
>
> This definitely doesn't block other digester releases...it's the way digester
> has behaved for many releases.

A properties file lookup would be ideal. The problem is not so much with
digester itself. It's with the numerous consumers of digester who accept the
default digester behavior and the inability to effect digester's choice of
classloader when digester is an indirect dependency. An optional properties
file would definitely maintain the existing behavior yet allow sufficient
configurability when needed. Thanks.

Craig Miller
added a comment - 18/Oct/05 01:01 (In reply to comment #1)
> Changed status from blocker. The proposed change certainly can't be implemented
> as -is; that would be a major backwards incompatibility. More research is needed
> into whether a fix is needed for this, and if so how to do that. Maybe some kind
> of properties file lookup so that this feature can be enabled by end users
> rather than via the code?
>
> This definitely doesn't block other digester releases...it's the way digester
> has behaved for many releases.
(In reply to comment #1)
> Changed status from blocker. The proposed change certainly can't be implemented
> as -is; that would be a major backwards incompatibility. More research is needed
> into whether a fix is needed for this, and if so how to do that. Maybe some kind
> of properties file lookup so that this feature can be enabled by end users
> rather than via the code?
>
> This definitely doesn't block other digester releases...it's the way digester
> has behaved for many releases.
A properties file lookup would be ideal. The problem is not so much with
digester itself. It's with the numerous consumers of digester who accept the
default digester behavior and the inability to effect digester's choice of
classloader when digester is an indirect dependency. An optional properties
file would definitely maintain the existing behavior yet allow sufficient
configurability when needed. Thanks.