FWIW, I can replicate this error in JWS Core 4.0.6 on Windows.

(In reply to comment #0)
> Obviously there is a bug with the PDP

Well, no, that's not obvious.  If I replace line

<authz value="global:org.globus.gridshib.GridShibPDP"/>

with

<authz value="global:org.globus.gridshib.SAMLAssertionPushPIP"/>

in the security descriptor, I get the following similar stacktrace when I try
to start the container:

Container failed to initialize. Caused by java.lang.NullPointerException
        at
org.globus.wsrf.impl.security.authorization.ContainerPDPConfig.getProperty(ContainerPDPConfig.java:41)
        at org.globus.gridshib.BasePIP.initialize(BasePIP.java:70)
        at
org.globus.wsrf.impl.security.authorization.ServiceAuthorizationChain.initialize(ServiceAuthorizationChain.java:108)
        at
org.globus.wsrf.impl.security.util.PDPUtils.getServiceAuthzChain(PDPUtils.java:114)
        at
org.globus.wsrf.impl.security.util.PDPUtils.getContainerAuthzChain(PDPUtils.java:148)
        at
org.globus.wsrf.impl.security.descriptor.ContainerSecurityConfig.loadAuthorization(ContainerSecurityConfig.java:143)
        at
org.globus.wsrf.impl.security.descriptor.SecurityConfig.initSecurityDescriptor(SecurityConfig.java:193)
        at
org.globus.wsrf.impl.security.descriptor.SecurityConfig.initialize(SecurityConfig.java:171)
        at
org.globus.wsrf.impl.security.descriptor.ContainerSecurityConfig.initialize(ContainerSecurityConfig.java:101)
        at
org.globus.wsrf.impl.security.descriptor.ContainerSecurityConfig.getConfig(ContainerSecurityConfig.java:89)
        at
org.globus.wsrf.impl.security.descriptor.ContainerSecurityConfig.getConfig(ContainerSecurityConfig.java:78)
        at
org.globus.wsrf.container.GSIServiceDispatcher.init(GSIServiceContainer.java:75)
        at
org.globus.wsrf.container.ServiceContainer.start(ServiceContainer.java:242)
        at
org.globus.wsrf.container.ServiceContainer.<init>(ServiceContainer.java:197)
        at
org.globus.wsrf.container.GSIServiceContainer.<init>(GSIServiceContainer.java:45)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)

        at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
        at
org.globus.wsrf.container.ServiceContainer.createContainer(ServiceContainer.java:138)
        at
org.globus.wsrf.container.ServiceContainer.startSecurityContainer(ServiceContainer.java:452)
        at
org.globus.wsrf.container.ServiceContainer.main(ServiceContainer.java:408)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:95)
        at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:37)

In both cases (BasePDP and BasePIP), initialization is failing at the following
line of code:

Object o = config.getProperty(name, keys[i]);

where config is an instance of

org.globus.wsrf.security.authorization.PDPConfig

I thought the Authz Framework guaranteed that the PDPConfig instance is not
null.

By the way, BasePDP and BasePIP are located here:

http://viewcvs.globus.org/viewcvs.cgi/gridshib/gt/interceptors/java/source/src-proxies/4.0/org/globus/gridshib/?pathrev=gridshib_gt_0_6_0_branch

Hmmm, from my reading of the stack trace, the problem is from
ContainerPDPConfig.java:41. Looking at ContainerPDPConfig.java line 41, which
is the line starting with 'return' below, it would seem that either
this.msgCtx, name or property is null. I've working back property, which comes
from keys[i] in the GS code, which should always be initialized. So I suspect
one of the other two elements. The name element flows through the GS code (it's
an argument to the initiatize() method in the interceptor), so we could check
it.

    public Object getProperty(String name, String property) {
        return ContainerConfig.getConfig(this.msgCtx.getAxisEngine())
            .getOption(name + "-" + property);
    }

It doesn't matter if name or property are null, it's most likely because 'this'
(a PDPConfig instance) is null and therefore this.msgCtx throws a NPE.

I don't think this is a problem in the GridShib code...

I just verified there is no such problem in GT4.0.4 or GT4.0.5.  Evidently this
is new in GT4.0.6.

(In reply to comment #3)
> It doesn't matter if name or property are null, it's most likely because 'this'
> (a PDPConfig instance) is null and therefore this.msgCtx throws a NPE.

Both Tim and Von have pointed out to me that it's this.msgCtx that is null. 
Thanks.

From briefly looking at some core code, it looks like there might be a chicken
and egg situation, the ContainerPDPConfig is being set up at the moment and
it's also needed by the gridship base PDP to get configurations from.

gridmap doesn't seem to suffer this because of these lines in SecurityConfig
class:

    protected void initSecurityDescriptor() throws ConfigException {
        // desc is never null for container, so default creds shld get loaded
        if (this.desc == null) {
            return;
        }
        initCredentials();
        loadGridMap();
        loadAuthorization();
    }


GridMap gets treated specially. This problem is however happening during
loadAuthorization()

(In reply to comment #6)
> From briefly looking at some core code, it looks like there might be a chicken
> and egg situation, the ContainerPDPConfig is being set up at the moment and
> it's also needed by the gridship base PDP to get configurations from.

But what changed in GT4.0.6 that caused this problem to surface?

My patch for bug 5608 broke this. Sorry about that, shouldn't have changed the
container descriptor initialization with out testing message context
ramifications. I will commit fix and publish an update package for this.
Meanwhile, if you would like to try out the patch, I am pasting it below.

Thanks,
Rachana

Index: java/core/source/src/org/globus/wsrf/container/GSIServiceContainer.java
===================================================================
RCS file:
/home/globdev/CVS/globus-packages/wsrf/java/core/source/src/org/globus/wsrf/container/GSIServiceContainer.java,v
retrieving revision 1.13.2.5
diff -u -r1.13.2.5 GSIServiceContainer.java
--- java/core/source/src/org/globus/wsrf/container/GSIServiceContainer.java   
24 Oct 2007 18:35:00 -0000    1.13.2.5
+++ java/core/source/src/org/globus/wsrf/container/GSIServiceContainer.java   
8 Apr 2008 17:02:26 -0000
@@ -63,7 +63,7 @@
         super(properties);
     }

-    protected void init() throws Exception {
+    protected void setupThreadPool() throws Exception {

         Subject subject = null;        
         if (this.containerDescriptor != null) {
@@ -77,7 +77,7 @@
             config.refresh();
             subject = config.getSubject();
         }
-        
+
         if (subject == null) {
             String err="";
             String descFile = ContainerSecurityConfig.getConfig()
@@ -89,24 +89,11 @@
             }
             throw new Exception(i18n.getMessage("noValidCreds") + err);
         }
-
-        super.init();
-
-    }
-
-    protected void setupThreadPool() throws Exception {
-
-        ContainerSecurityConfig config =
-            ContainerSecurityConfig.getConfig();
-        config.refresh();
-        Subject subject = config.getSubject();
-
         this.credentials = JaasGssUtil.getCredential(subject);
         this.threadPool = new GSIServiceThreadPool(this);
     }
 }

-
 class GSIServiceThreadPool extends ServiceThreadPool {

     public GSIServiceThreadPool(ServiceDispatcher dispatcher) {

So in the end, will the problem be confined to GT4.0.6 and GT4.0.7?  Will the
patch be rolled out in GT4.0.8 (assuming 4.0.8 is even released).

Yes.

Committed to branch and advisory has been published:
http://www-unix.globus.org/toolkit/advisories.html.