It looks to me that the client-config.wsdd that gets used in the binary
installer contains type-mappings for the GRAM faults, and not the smaller
subset that would be implied by the using "wsmds" target.  As a result, the
container tries to load all of these bean classes at startup, and since GRAM is
not installed (as it not a dependency of ws-mds) the classes are not found and
the 
errors result.

Removing all type-mapping references to gram faults in the client-config.wsdd
allowed the container to startup normally, so there is a workaround.

I am not sure at this point if this is a bug with MDS dependency metadata, so I
am copying it to Charles to see if he has any ideas :)

This is the same problem as was eventually reported in 4849 also.  We need core
to give us the ability to have services to split up the client-config.wsdd the
same way we already split up server-config.wsdd.

I'll accept this and see if we can come up with something for wsrf-core for 4.2

*** Bug 5082 has been marked as a duplicate of this bug. ***

Re-assigning to the correct category

This issue prevents installation of binaries in any configuration other than
installing the whole toolkit at once.  We need something like the handling of
server-config.wsdd for the client-config also.  Upgrading to blocker, cc:ing
jwscore-dev.

Do we have a plan for this for 4.2 yet?  It's key to our ability to deploy
subsets of the toolkit in binary format.

I cooked up a script that will remove offending typeMappings from a 4.0.x
installation:

cd $GLOBUS_LOCATION/lib

# Create the list of all classes contained in $GL jar files.
# unzip -l outputs filenames in columns 29-
# Classes are listed as org/globus/.../foo.class
# In the typemappings, though, the / are replaced by .
for f in *.jar; do
   unzip -l $f | cut -c29- | grep class | tr / . >> ../jarlist
done

cd ..

# Type mappings in client-config.wsdd start with <typeMapping
# They have a number of quote-delimited fields.  The classname appears
# in the 10th field, and are listed as java:org.globus..., so strip off the
java:
# There's one java.lang.String entry that comes from native java classes, not
our
# jar files, so exclude it.
grep typeMapping client-config.wsdd | cut -d\" -f10 | cut -d: -f2 | grep -v
java.lang.String > typemappinglist

# Iterate over the classes listed in the typemappings and search for them
# in the list of classes we own.  Output offending classes.
while read typemap; do
   grep $typemap jarlist > /dev/null;
   if [ $? -ne 0 ]; then
     echo $typemap >> missingtypes
   fi
done < typemappinglist

#make a backup
cp client-config.wsdd client-config.wsdd.orig
cp client-config.wsdd client-config.temp

#remove all lines that reference uninstalled classes
while read badmap; do
   grep -v $badmap client-config.temp > client2
   mv client2 client-config.temp
done < badmap;

mv client-config.temp client-config.wsdd

I'll let Mike add details on the solution, but in a nutshell a client has been
created that updates the the client config in $GLOBUS_LOCATION to have
information from the components installed in $G_L. The effective change needed
from services is for them to list their client config.wsdd file in filelist, so
that GPT includes it in a binary deploy. So this solution can and should be
applied to branch also.

Code has been committed to CVS trunk to address this issue for the 4.2 release. 

A command-line utility called "globus-update-client-config" has been added that
will allow build automation or an administrator to scan for client-config.wsdd
files located in $GLOBUS_LOCATION/etc/<module-name> and merge each file's
contents into $GLOBUS_LOCATION/client-config.wsdd.

The primary impact of this change is that component developers who currently
provide a "deploy-client.wsdd" file will now find that in addition to having
that deploy-client.wsdd file merged into client-config.wsdd at deploy time,
will also have this file copied to
$GLOBUS_LOCATION/etc/<module-name>/client-config.wsdd, so that it can be
rescanned when the globus-update-client-config tool is run.

This means that component developers who do provide a "deploy-client.wsdd" file
must now add an entry into the GPT packaging filelist for the file
"etc/client-config.wsdd".  If this change is not made, then any type-mappings
or other client-side configuration modifications from this file will not be
reflected in the global $G_L/client-config.wsdd. Note that this caveat applies
to BINARY PACKAGED INSTALLATIONS ONLY.  The procedure for building and
deploying from source remains unchanged.

See
http://www.globus.org/toolkit/docs/development/4.2-drafts/common/javawscore/developer/globus-update-client-config.html
for more information on using the command-line tool.