Commons Digester
  1. Commons Digester
  2. DIGESTER-28

[digester] Default ClassLoader policy unusable in EAR archive

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6
    • Fix Version/s: 3.0
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

      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

        Hide
        Simon Kitching added a comment -

        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.

        Show
        Simon Kitching added a comment - 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.
        Hide
        Craig Miller added a comment -

        (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.

        Show
        Craig Miller added a comment - (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.
        Hide
        Simone Tripodi added a comment -

        Issue fixed on Digester3 /trunk, see r1135201
        Thanks for contributing!

        Show
        Simone Tripodi added a comment - Issue fixed on Digester3 /trunk, see r1135201 Thanks for contributing!
        Hide
        Simone Tripodi added a comment -

        included in Apache Commons Digester 3.0 release

        Show
        Simone Tripodi added a comment - included in Apache Commons Digester 3.0 release

          People

          • Assignee:
            Simone Tripodi
            Reporter:
            Craig Miller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development