I'm developing a tool for atomicity violation detection and I think it have found a few atomicity violations in catalina.  These are issues are due to non-atomic compositions of calls to a certain object.

In org.apache.catalina.core.ContainerBase, method getChildren(), lines 1526-1534:

>     public ObjectName[] getChildren() {
> 1526:   ObjectName result[]=new ObjectName[children.size()];
>         Iterator it=children.values().iterator();
>         int i=0;
>         while( it.hasNext() ) {
>             Object next=it.next();
>             if( next instanceof ContainerBase ) {
> 1531:            result[i++]=((ContainerBase)next).getJmxName();
>             }
>         }
>         return result;
>     }

Here "result" is alloced with size "children.size()".  A concurrent thread may add more objects to "children" possibly causing an invalid access to array "result" in line 1531.

__

In org.apache.catalina.core.StandardEngine, method start(), lines 438-439:

>     public void start() throws LifecycleException {
>         ...
> 438:            if( mserver.isRegistered(realmName ) ) {
> 439:                mserver.invoke(realmName, "init", 
>                             new Object[] {},
>                             new String[] {}
>                     );            
>                 }
>         ...
>     }

Can the "init" method be unregistered between lines 438 and 439?

__

In org.apache.catalina.core.StandardContext, method addParameter(), lines 2659-2672:

>     public void addParameter(String name, String value) {
>         ...
> 2664:   if (parameters.get(name) != null)
>             throw new IllegalArgumentException
>                 (sm.getString("standardContext.parameter.duplicate", name));
> 
>         // Add this parameter to our defined set
>         synchronized (parameters) {
> 2670:       parameters.put(name, value);
>         }
>         fireContainerEvent("addParameter", name);
>     }

A concurrent thread may add the same parameter between the execution of line 2664 and 2670.  In that case both threads will think they succeeded, when the expected behavior is for one of them to receive the exception thrown in line 2665.

Thank you