Bug 3774 - Missing dep in wsmds target?
: Missing dep in wsmds target?
: Java WS Core
: unspecified
: All All
: P1 blocker
: 4.2.0
Assigned To:
: 4849
  Show dependency treegraph
Reported: 2005-09-22 11:25 by
Modified: 2008-01-11 17:52 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2005-09-22 11:25:56
A user is reporting that after using the binary installer, and running

   make wsmds

he gets:

[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.
------- Comment #1 From 2007-02-20 22:53:13 -------
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
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 :)
------- Comment #2 From 2007-02-22 15:42:24 -------
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.
------- Comment #3 From 2007-02-26 19:59:40 -------
I'll accept this and see if we can come up with something for wsrf-core for 4.2
------- Comment #4 From 2007-03-15 13:30:19 -------
*** Bug 5082 has been marked as a duplicate of this bug. ***
------- Comment #5 From 2007-09-11 11:23:33 -------
Re-assigning to the correct category
------- Comment #6 From 2007-09-19 11:48:04 -------
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
------- Comment #7 From 2007-11-28 14:05:24 -------
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.
------- Comment #8 From 2008-01-11 11:16:52 -------
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

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
# 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
------- Comment #9 From 2008-01-11 11:29:30 -------
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.
------- Comment #10 From 2008-01-11 17:52:48 -------
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.