geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yoel Spotts (JIRA)" <>
Subject [jira] Created: (GERONIMO-2856) Placing a gbean and/or EJB in a signed jar causes a SecurityException during deployment and/or runtime
Date Tue, 20 Feb 2007 17:23:05 GMT
Placing a gbean and/or EJB in a signed jar causes a SecurityException during deployment and/or

                 Key: GERONIMO-2856
             Project: Geronimo
          Issue Type: Bug
      Security Level: public (Regular issues)
          Components: deployment
    Affects Versions: 1.1.1
         Environment: Geronimo version 1.1.1. I don't believe the OS and hardware are relevant,
but this is running under Windows (both XP and server have been tried)
            Reporter: Yoel Spotts
            Priority: Minor

The issue surrounds Geronimo's usage of proxies and how it relates to signed jars. Thus far,
I have encountered two issues in this regard:

a) If an EJB is deployed as part of an ear, and the EJB classes are contained in a signed
jar within the EAR, the EAR will fail to deploy at all (I have tried to deploy offline, but
I doubt deploying online would make a difference). I hope to attach a sample of this (named
example-full.ear) which highlights this issue. You will note the EJB classes are located in
the signed jar example.jar and the ejb's manifest places example.jar in the classpath, so
that the classes are found, but the proxies created for the EJB classes are located out of
the signed package, just causing the SecurityException.

b) If a Gbean loaded by an EAR (defined in geronimo-application.xml) is placed in a signed
jar in the EAR, the EAR will be deployed, but will fail to startup, due to a SecurityException,
again b/c of the proxy class created for the gbean. I hope to attach an ear highlighting this
issue (named example-partial.ear). Again, the signed example.jar contains a gbean (and again,
the ejb's manifest places the example.jar on the classpath)

Besides the obvious solution of not signing the jar, it was suggested to try the experimental
property: -DXorg.apache.geronimo.gbean.NoProxy=true. I did try that, and it does seem to solve
manifestation b) of this issue. However, it won't address part a) above and is still experimental;
It does not seem clear what functionality is lost by using this option.

A possible resolution might be to create the proxies in a different package than the target
classes, which might not cause a SecurityException in that case. Another possible avenue came
from Dain Sundstrom on the mailing list: "Alternatively, just change the code that complains
about the signature.  We could add a flag to the Geronimo class loader to hide all signing

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message