wsrf-get-property client with
OGSA-DAI services?Exception in thread "main"
java.lang.IllegalAccessError: tried to access field..."?
This can be done as follows:
$ export GLOBUS_LOCATION=/PATH/TO/GT
$ cd $GLOBUS_LOCATION
$ ./bin/wsrf-get-property -s URL \
-k {http://ogsadai.org.uk}ResourceID RESOURCE-ID \
PROPERTY-NAME
For example:
$ ./bin/wsrf-get-property
-s http://localhost:9060/wsrf/services/dai/DataResourceInformationService \
-k {http://ogsadai.org.uk}ResourceID MySQLDataResource \
{http://uk.org.ogsadai.resource.activities}SupportedActivities
Alternatively you can use a WS-EPR in a file as follows:
$ ./bin/wsrf-get-property -e WS-EPR-FILE PROPERTY-NAME
For example:
$ ./bin/wsrf-get-property -e dai-epr.xml \
{http://uk.org.ogsadai.resource.activities}SupportedActivities
The OGSA-DAI example server client (see Chapter 70, Example server client) is one way of getting WS-EPRs for OGSA-DAI services and resources.
OGSA-DAI property names map to Globus property names as follows:
{...}. e.g. for
prefix.Name you would use
{prefix}Name and for
longer.prefix.Name you would use
{longer.prefix}Name etc.
For example in the above we used:
{http://uk.org.ogsadai.resource.activities}SupportedActivities
for
http://uk.org.ogsadai.resource.activities.SupportedActivities
Running the QueryResourceProperties operation on a resource exposed
by an OGSA-DAI GT service with a query
//* will return the resource
properties document for the resource.
If a resource has been configured incorrectly then clients may be informed by the OGSA-DAI server that the resource is unknown. The OGSA-DAI server logs will provide information about why the configuration is incorrect.
Alternatively errors in resource configuration may only be realised when a request is submitted that contains activities that use the resource. e.g.
A problem has occured... [1185804665299:2] uk.org.ogsadai.client.toolkit.REQUEST_COMPLETED_WITH_ERROR : ogsadai-114177657b5
The actual request execution status will contain more information in the entry for the activity that tried to use the resource.
Problems with activity configurations are manifested at the client-side as follows. For example:
[1185805382056:3] uk.org.ogsadai.client.toolkit.REQUEST_ERROR : ogsadai-11417822efa [1185805382057:4] uk.org.ogsadai.GENERAL_REQUEST_USER_EXCEPTION [1185805382057:5] uk.org.ogsadai.GENERAL_ACTIVITY_USER_EXCEPTION [1185805382057:6] uk.org.ogsadai.UNSUPPORTED_ACTIVITY : uk.org.ogsadai.ListDirectoryX, FileResource
Either the client has specified an activity unknown to the resource or the activity is not known to the server.
These are caused when one or more activities in the request encounter or raise an error. These are manifested client-side as follows:
[1195650926263:4] uk.org.ogsadai.client.toolkit.REQUEST_COMPLETED_WITH_ERROR : ogsadai-116616aa6d9 ...
Such problems can be caused by:
This may be manifested client-side as follows:
[1185805813092:1] uk.org.ogsadai.client.toolkit.REQUEST_ERROR : ogsadai-1141788c349 [1185805813092:2] uk.org.ogsadai.SERVER_ERROR_WITH_HOST : 1185805812851:2, coal.epcc.ed.ac.uk
This means there is a problem on the OGSA-DAI server and you (or the OGSA-DAI server administrator) should check the OGSA-DAI server logs for the error with the given ID.
This might be evidenced as follows when when invoking operations on OGSA-DAI-specific operations on OGSA-DAI GT services:
{http://ogsadai.org.uk/namespaces/2007/04/service/execution}resourceUnknownFault:
<ns2:id xmlns:ns2="http://ogsadai.org.uk/namespaces/2007/04/service/faults">
uk.org.ogsadai.RESOURCE_UNKNOWN_ERROR
</ns2:id>
<ns3:msg xmlns:ns3="http://ogsadai.org.uk/namespaces/2007/04/service/faults">
[1179491427865:0] uk.org.ogsadai.RESOURCE_UNKNOWN_ERROR : null
</ns3:msg>
<ns4:parameter xmlns:ns4="http://ogsadai.org.uk/namespaces/2007/04/service/faults">
null
</ns4:parameter>
This might be evidenced as follows when when invoking OGSA-DAI GT WS-ResourceProperties or WS-ResourceLifetime operations:
{http://xml.apache.org/axis/}stackTrace:java.rmi.RemoteException: Failed to acquire resource; nested exception is: org.globus.wsrf.InvalidResourceKeyException
The most common cause of this is not having the file
client-config.wsdd in a directory
that is in your client's CLASSPATH
If a synchronous request takes a long time then the client connection to the OGSA-DAI server (via the data request execution service) may time out. In such circumstances, the OGSA-DAI server will continue to execute the workflow submitted by the client. There is however no way for the client to access their data since there is no means of getting the ID of the request (as known to the server) back to the client. This is a further argument in favour of the use of asynchronous requests for workflows that may have long execution times.
If you get an error from your client or in your logs:
Exception in thread "main" java.lang.IllegalAccessError: tried to access field org.apache.xpath.compiler.FunctionTable.m_functions from class org.apache.xml.security.Init at ...
then this is probably due to an incompatibility between the version of
the xalan.jar shipped with the Globus
Toolkit and the particular version of Java you are using.
To find out the version of Java you are using, run:
$ java -version
ensuiring that you run the same Java version as referenced by your
JAVA_HOME environment variable.
Some builds of Java version 1.4.2_05 are known to cause this error. Versions of the Java 1.4 up to and including 1.4.2_04 are known to be okay. It is believed that a change of a variable from public to private in Java versions since 1.4.2_05 has caused this problem.
To fix this problem, you can use a newer version of
xalan.jar. See the information on the
"Endorsed Standards Override Mechanism" explained in the Xalan FAQ: http://xml.apache.org/xalan-j/faq.html#faq-N100CC.
Essentially, you need to download the latest version of
Xalan and copy the xalan.jar,
xercesImpl.jar
and xml-apis.jar
files to a directory called
JRE_HOME/lib/endorsed where
JRE_HOME is the base directory of
your JRE installation.
Alternatively, switching to an earlier Java version (1.4.2_05 and previous) should solve this problem.
For more information on this bug take a look at:
If using a Macintosh that has a built-in Java 1.4.2_09 release then you should use Xalan 2.6.0.
Ideally, OGSA-DAI deployers would register their OGSA-DAI servers and
meta-data on the resources they expose (e.g. supported activities,
associated databases) in some registry (e.g. a Globus Toolkit Service
Group). A user or client could then, for example, search for a DRER
that supports the activities they are interested in executing and
select one based on the results of the search. We haven't really
looked at registries however so generally rely upon a manual approach
by which the OGSA-DAI deployer would just tell actual and potential
clients which DRER to use. Also in most cases OGSA-DAI deployers
typically will support just one DRER with the default name of
DataRequestExecutionResource.