Bugzilla – Bug 5995
globusrun-ws problems with extensions element in job description
Last modified: 2008-04-17 10:34:31
You need to
before you can comment on or make changes to this bug.
globusrun-ws in trunk doesn't seem to be able to handle the
extensions element of a job description properly. Tried to
submit the following job
[martin@osg-test1 ~]$ globusrun-ws -submit -f job.xml
Error loading rsl
Unexpected logfile element in message while looking for an end tag
I verified that it works fine in 4.0. The inofficial Java client GlobusRun
can handle this job, and the Perl modules log into the specified file then.
The namespace constraint of the wildcard in the Extension element is
not(http://www.globus.org/namespaces/2004/10/gram/job/description) because of
the ##other namespace attribute on the wildcard in the schema. That means that
extensions there must have a namespace (See
http://www.w3.org/2001/05/xmlschema-rec-comments.html#pfiother). I think the C
code is correct to reject that document.
I verified that it works fine if the sub-elements of the extensions
element contain a namespace different from the target namespace
The following works fine
for submission of globusrun-ws, however, no logfile is written on the
Reason seems that ExtensionsHandler.pm does not strip the namespace prefix
from the tag names, so they are named differently than expected
(my:logfile vs logfile) and thus not found.
If i strip the prefixes things seem to work fine, at least for the
Possible solution: let a client define whatever namespace it wants and
strip the namespaces in ExtensionsHandler.pm. Is this a good solution?
How about this:
The default namespace would probably be the most convenient solution
for a client, because it must be specified only once and no ns-prefixes
for all sub-elements would have to be provided.
I'm getting the deserialization exception from globusrun-ws when i try
to submit that job.
To make that doc correct:
The extensions element is in the gram/job/description namespace
oh yeah, right.
Would it help to fix the bad namespace checking that's allowing you to get away
with gram elements without a namespace?
I set the namespace element to ##any for now. By this all ugly and dirty
things as we do now work fine, no changes at all required, neither on the
client-side (no explicit namespace settings) nor on the server-side (no
fixing in ExtensionsHandler.pm, no discussion about elements we want to
support or not).
A client can put whatever it wants into the extensions element and has
to adapt the perl modules to handle elements that we don't handle in the
custom perl modules.
As Joe said this is not a particular nice solution, but it looks like a
reasonable tradeoff to me with respect to convenience for users and the
effort it would take on the server-side to have a more elaborate solution.