Sorry, I think I messed up the installation version. I was using older jars.
Here's an updated trace:

Container failed to initialize. Caused by java.lang.Exception: Secure container
requires valid credentials
	at
org.globus.wsrf.container.GSIServiceDispatcher.setupThreadPool(GSIServiceContainer.java:68)
	at org.globus.wsrf.container.ServiceDispatcher.init(ServiceDispatcher.java:112)
	at org.globus.wsrf.container.ServiceContainer.start(ServiceContainer.java:240)
	at org.globus.wsrf.container.ServiceContainer.<init>(ServiceContainer.java:198)
	at
org.globus.wsrf.container.GSIServiceContainer.<init>(GSIServiceContainer.java:44)
	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:274)
	at
org.globus.wsrf.container.ServiceContainer.createContainer(ServiceContainer.java:135)
	at
org.globus.wsrf.impl.notification.ClientNotificationConsumerManager.startListening(ClientNotificationConsumerManager.java:61)
	at org.globus.exec.client.GramJob.createJobEndpoint(GramJob.java:897)
	at org.globus.exec.client.GramJob.submit(GramJob.java:449)
	at org.globus.exec.client.GramJob.submit(GramJob.java:340)
	at Test.main(Test.java:42)

I think you just need to set the proxy location using
etc/globus_wsrf_core/global_security_descriptor.xml.  Details on security
descriptors is here:

http://www-unix.globus.org/toolkit/docs/4.0/security/authzframe/security_descriptor.html#s-authzframe-server-secdesc-descFile

In a portal scenario, there is no proxy location. Multiple users should be able
to submit jobs at the same time.

I don't understand what you mean by "there is no proxy location".  If the
container does not have access to host credentials, then you do need a proxy.  

Also, WS-GRAM can indeed run jobs as multiple users as long as the container
owner can run sudo as is described in the documentation.

It looks to me from your second comment that you are missing the
containerkey.pem and containercert.pem files in /etc/grid-security.  These are
the default credential locations that the container tries to use.  You either
need to get host credentials and copy them to those files (owned by the
container owner), specify a different location for host credentials you may
already have, or specify a user proxy location.

Basically, the container needs valid credentials to operate in secure mode. 
Whatever credentials you are using for this purpose need to be configured in
global_security_descriptor.xml.

> I don't understand what you mean by "there is no proxy location".  If the
> container does not have access to host credentials, then you do need a proxy. 

This container is the container that the client starts in order to receive
notification. The proxy should be inherited from the job proxy. 

> Also, WS-GRAM can indeed run jobs as multiple users as long as the container
> owner can run sudo as is described in the documentation.

This is on the client side. I'm not sure why I should set up sudo on my laptop
just to submit a job.

> It looks to me from your second comment that you are missing the
> containerkey.pem and containercert.pem files in /etc/grid-security.
> ...

On the client side?

> Basically, the container needs valid credentials to operate in secure mode. 
> Whatever credentials you are using for this purpose need to be configured in
> global_security_descriptor.xml.

Sorry, I got confused because the original stack trace looks like it's comming
from the service container.  The second one indeed is comming from the client
container.  I looked at the ResourceSecurityDescriptor API, and there doesn't
appear to be a way of setting the actual credential object like the
ClientSecurityDescriptor class (just the credential file paths).  The GramJob
code indeed doesn't attempt to do anything with the credentials specified with
setCredentials() with respect to the notification consumer.  I'm reassigning
this bug as I'm not sure how to remedy the situation.

Setting credentials on resource security descriptor can be done using
setSubject
(), after converting credentials to a Subject object. But that is not going to 
solve this issue, since the credentials set will be used only for security when 
a notification comes in. To start up the consumer container, we need to 
configure in credentials. The code as is, allows you to place a container 
security descriptor file name as a part of a Map object used for creating 
NotificationConsumerManager. i.e


Map properties = new HashMap();
              properties.put(ServiceContainer.SERVICE_DESCRIPTOR_FILE,
                             "path to container sec desc file");
              properties.put(ServiceContainer.CLASS,
                         "org.globus.wsrf.container.GSIServiceContainer");
                consumer = NotificationConsumerManager.getInstance(properties)

Requiring file does not work elegantly for this scenario. I will add another 
property such that a ContainerSecurityDescriptor object can be set (so non-
default credentials can be passed in programatically rather than using file 
names).

I have committed a fix for this to trunk and waiting for Jarek to review the 
fix before propagating it to branch. But the following can be done to specify 
credentials now:

                Map properties = new HashMap();
                properties
                    .put(ServiceContainer.CLASS,
                         "org.globus.wsrf.container.GSIServiceContainer");
                ContainerSecurityDescriptor desc = 
                    new ContainerSecurityDescriptor();
                GlobusCredential cred = new GlobusCredential("path to proxy");
                SecurityManager manager = 
                    SecurityManager.getManager();
                desc.setSubject(manager.credentialToSubject(cred));      
                properties
                    .put(ServiceContainer.CONTAINER_DESCRIPTOR,
                         desc);
                consumer = NotificationConsumerManager.getInstance(properties);

I think to solve the issue, GRAM needs to add this code, if non-default 
credentials are set. 

Would this work if I have two jobs submitted at the same time, using two
different credentials, and inside the same JVM instance?

can a test case be developed so we include this in the standard tests just to
make sure?

Yes, it ought to work.  Notice the following line in Rachana's code example:

consumer = NotificationConsumerManager.getInstance(properties);

This should get a brand new instance using the properties set up with different
credentials.

I'll try to get code changes in by tomorrow morning and attach the new client
jar for you to try out. If the new jar solves your problem then I will commit
the fixes to the trunk.  I'll need to wait for Rachana's changes to be committed
to the 4.0.1 branch before doing the same.

Gregor,

I admit it would be nice, but I think it will be difficult and dangerous to move
around the default proxy file when someone runs the test just to make sure the
embedded container is actually picking up the right cred.  I think as long as
Mihael can verify the fix works then we should be ok.  I doubt the code that
will hopefully fix this will change much.

Rachana,

I think your changes broke something.

First of all, I'm getting "if subject is null" when I start up the container.

Secondly, without modifying the client code as you suggested, it seems the
container is picking up my proxy credentials instead of the container
credentials.  I say this because now the client is complaining because it
expected host credentials but got my proxy subject instead.  I verified that I
did not change the globus_security_descriptor.xml file from the default content. 

Nevermind on #2. Rebuilding core with Ant wiped out my containerSecDesc entry
in
server-config.wsdd.  Those System.out.prinln() calls should be removed, though.

Ok, I lied.  It's stupid for me to put a new jar up since it relies on
Rachana's
commits.  So I'm not going to do that.  I comitted the GramJob changes to the
trunk, so you should be able to just update the globus_java_ws_core and
globus_wsrf_gram_client_java GPT packages, I think.

Removed System.outs lines.

Works fine with the test case I had.

Rachana,

Any idea when those security updates will make it to the 4.0 branch?

Changes merged with branch.

I forgot to close this bug out.  The GramJob.java changes were added to the 4.0
branch, so nothing more is needed to be done.