Bug 5995 - globusrun-ws problems with extensions element in job description
: globusrun-ws problems with extensions element in job description
Status: RESOLVED FIXED
: GRAM
wsrf gram clients
: alpha
: Macintosh All
: P3 blocker
: 4.2
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-04-08 17:10 by
Modified: 2008-04-17 10:34 (History)


Attachments


Note

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


Description From 2008-04-08 17:10:08
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

<job>
    <executable>/bin/true</executable>
    <extensions>
      <logfile>/tmp/perlLog</logfile>
    </extensions>
</job>

and got:

[martin@osg-test1 ~]$ globusrun-ws -submit -f job.xml 
globusrun-ws: globus_i_submit.c::204:
Error loading rsl
globus_soap_message_deserialize.c:globus_soap_message_deserialize_element_end:194:
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.
------- Comment #1 From 2008-04-09 08:21:13 -------
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.
------- Comment #2 From 2008-04-09 11:40:04 -------
I verified that it works fine if the sub-elements of the extensions
element contain a namespace different from the target namespace
"http://www.globus.org/namespaces/2008/03/gram/job/description"

The following works fine

  <extensions xmlns:my="http://www.globus.org/whatever">
    <my:logfile>/tmp/logFeller</my:logfile>
  </extensions>

for submission of globusrun-ws, however, no logfile is written on the
server-side.

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 
logfile element.

Possible solution: let a client define whatever namespace it wants and
strip the namespaces in ExtensionsHandler.pm. Is this a good solution?
------- Comment #3 From 2008-04-11 09:45:33 -------
How about this:

<job>
    <executable>/bin/true</executable>
    <extensions xmlns="http://www.globus.org/some/namespace">
      <logfile>/tmp/myPerlModuleLog</logfile>
    </extensions>
</job>

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.
------- Comment #4 From 2008-04-11 09:53:41 -------
To make that doc correct:

<job xmlns="http://www.globus.org/namespaces/2004/10/gram/job/description">
    <executable>/bin/true</executable>
    <extensions>
      <logfile 
xmlns="http://www.globus.org/some/namespace">/tmp/myPerlModuleLog</logfile>
    </extensions>
</job>

The extensions element is in the gram/job/description namespace

Joe
------- Comment #5 From 2008-04-11 09:58:17 -------
oh yeah, right.
------- Comment #6 From 2008-04-11 10:05:32 -------
Would it help to fix the bad namespace checking that's allowing you to get away
with gram elements without a namespace?
------- Comment #7 From 2008-04-17 10:34:31 -------
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.