Bugzilla – Bug 3774
Missing dep in wsmds target?
Last modified: 2008-01-11 17:52:48
You need to
before you can comment on or make changes to this bug.
A user is reporting that after using the binary installer, and running
[globus@coal bin]$ ./globus-start-container
2005-09-22 16:39:42,757 ERROR wsdd.WSDDDeployment [main,deployMapping:324]
Unable to deploy typemapping:
Sounds like a missing dep in the pkg data.
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
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
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
# 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
# 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
# There's one java.lang.String entry that comes from native java classes, not
# 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
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.
for more information on using the command-line tool.