3774 2005-09-22 11:25 Missing dep in wsmds target? 2008-01-11 17:52:48 1 1 1 Unclassified Java WS Core globus_wsrf_core unspecified All All RESOLVED FIXED P1 blocker 4.2.0 4849 1 rynge@isi.edu mdarcy@isi.edu bacon@mcs.anl.gov jms@mcs.anl.gov jwscore-dev@globus.org laura@isi.edu mdarcy@isi.edu neillm@mcs.anl.gov roy@cs.wisc.edu tfreeman@mcs.anl.gov rynge@isi.edu 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: {http://www.globus.org/namespaces/2004/10/gram/job/faults}ExecutionFailedFa ultType java.lang.ClassNotFoundException: org.globus.exec.generated.ExecutionFailedFaultType Sounds like a missing dep in the pkg data. mdarcy@isi.edu 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 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 :) bacon@mcs.anl.gov 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. mdarcy@isi.edu 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 bacon@mcs.anl.gov 2007-03-15 13:30:19 *** Bug 5082 has been marked as a duplicate of this bug. *** bacon@mcs.anl.gov 2007-09-11 11:23:33 Re-assigning to the correct category bacon@mcs.anl.gov 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 jwscore-dev. bacon@mcs.anl.gov 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. bacon@mcs.anl.gov 2008-01-11 11:16:52 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 ranantha@mcs.anl.gov 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. mdarcy@isi.edu 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. 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.