Subject: Re: incompatible xalan version - msg#00062

Previous Message by Date:

incompatible xalan version

Hi everybody, I am developing a portlet web service client and I have come across the following well-known exception: java.lang.IllegalAccessError: tried to access field org.apache.xpath.compiler.FunctionTable.m_functions from class org.apache.xml.security.Init         at org.apache.xml.security.Init.init(Unknown Source)         at org.globus.ogsa.impl.security.authentication.wssec.WSSecurityEngine.<clinit>(WSSecurityEngine.java:55)         at org.globus.ogsa.impl.security.authentication.wssec.WSSecurityClientHandler.handleResponse(WSSecurityClientHandler.java:51)         at org.apache.axis.handlers.HandlerChainImpl.handleResponse(HandlerChainImpl.java:167)         at org.apache.axis.handlers.JAXRPCHandler.invoke(JAXRPCHandler.java:53)         at org.globus.ogsa.utils.JAXRPCHandler.invoke(JAXRPCHandler.java:16)         at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)         at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)         at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)         at org.apache.axis.client.AxisClient.invoke(AxisClient.java:190)         at org.apache.axis.client.Call.invokeEngine(Call.java:2765)         at org.apache.axis.client.Call.invoke(Call.java:2748)         at org.apache.axis.client.Call.invoke(Call.java:2424)         at org.apache.axis.client.Call.invoke(Call.java:2347)         at org.apache.axis.client.Call.invoke(Call.java:1804)         at it.trieste.elettra.services.CalcStub.add(CalcStub.java:175)         at it.trieste.elettra.services.TestWs.testConnection(TestWs.java:47)         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)         at it.trieste.elettra.services.TestWs.main(TestWs.java:67) As I have found in http://www.ogsadai.org.uk/releases/ogsadai.php, this can be due to an incompatibility between the version of the xalan.jar shipped with the Globus Toolkit 3.2.x distribution and particular versions of the Java JDK. To overcome this problem I have updated to JDK 1.4.2_04 which is said to work fine and as a result my WS portlet worked properly. After this I have installed gridportlets and now nothing works, neither the WS portlet nor gridportlets. I have discovered that gridportlets installs gridportlets-ogsa-3.2.1-* libraries in $CATALINA_HOME/common/lib and gridportlets-ogsa-3.2.1-xalan.jar in $CATALINA_HOME/common/endorsed and I have two questions to ask: First, why are these libraries installed under common and not under shared as advised in the Tomcat classloader how-to? I supposed that these libraries are related to the xalan incompatibility problem mentioned above, so, what can I do to make both gridportlets and my WS portlet work under the same gridsphere installation? If the scenario is not clear enough, I can explain better. thanks in advance for your help, Laura

Next Message by Date:

Re: incompatible xalan version

Hi, At one point I asked the globus mailing list why the jars were not placed in shared/lib instead of common, but never got a response. The xalan should go in endorsed/lib as it does (which still won't help if you were using jdk 1.4.1 where the xalan it shipped with had problems). In the end as Mike suggests, try various combinations always making sure no duplicate jars are found in common/lib, shared/lib, or server/lib and please report any findings you have. Thanks, Jason Michael Russell wrote: Hi Laura, In the past, I and some others were using Grid Portlets to write clients to OGSA services using the "httpg" protocol. This protocol is no longer officially supported, but some services in the GridSphere's old parent project, GridLab, are still using this protocol. Using it requires modifying Tomcat's setclasspath.sh/bat files to bootstrap _all_ jars that pertained to the use of the httpg protocol. It was a very confusing and difficult problem to overcome, so I added support for modifying Tomcat automatically. NOTE that this feature is NO LONGER enabled by default. That is, Grid Portlets will only touch Tomcat files if httpgservice.resource.support=true in config/build/build-globus.properties. I suppose I can change the install location of the jars to shared, from common (and not put the xalan.jar in endorsed). It was left that way more or less for historical reasons (basically, because the above problem was so confusing and it wasn't clear why it wasn't enough just to put the jars in shared/lib as documented). I'll get this into CVS and in a release soon. For now, please try one of these options below. Grid Portlets supports the ability to do a clean uninstall / undeploy from Tomcat. Just run "ant uninstall" (or "ant undeploy-jars" if you want to save your deployed database) and any jars GP deploys to Tomcat will be removed. Then edit things as described here and try redeploying. 1) If you want to install OGSA (or WSRF) separately, you can disable Grid Portlets from installing Globus jars altogether by setting globus.install=false in config/build/build-globus.properties. Install OGSA/WSRF separately and make sure you have CoG 1.X and related jars available somewhere in Tomcat before you build Grid Portlets. 2) If you want to let Grid Portlets install support for OGSA for you still, edit the locations GP deploys Gloubs jars to from common/lib to shared/lib in config/build/build-globus.xml (line 79). Note that GP can act as a web service container, so that installing OGSA separately is not required. This was a feature we are using for various reasons (to allow GP to host its own services, developed in separate GridSphere web applications ("gridlab", "gt3portlets", "gt4portlets"). I haven't had the chance to test OGSA and WSRF in the same container, so if you want to use both... well, please let me know what your experiences are. We are in the process of adding support for WSRF to GP. This is still experimental, but you can set globus.version=wsrf-4.0 in config/build/build-globus.properties. This will GP install the jars from lib/wsrf-4.0... but still in the common locations. Again, I will fix that. Michael On Jun 20, 2005, at 4:54 PM, laura elettra wrote: Hi everybody, I am developing a portlet web service client and I have come across the following well-known exception: java.lang.IllegalAccessError: tried to access field org.apache.xpath.compiler.FunctionTable.m_functions from class org.apache.xml.security.Init at org.apache.xml.security.Init.init(Unknown Source) at org.globus.ogsa.impl.security.authentication.wssec.WSSecurityEngine.<clinit>(WSSecurityEngine.java:55) at org.globus.ogsa.impl.security.authentication.wssec.WSSecurityClientHandler.handleResponse(WSSecurityClientHandler.java:51) at org.apache.axis.handlers.HandlerChainImpl.handleResponse(HandlerChainImpl.java:167) at org.apache.axis.handlers.JAXRPCHandler.invoke(JAXRPCHandler.java:53) at org.globus.ogsa.utils.JAXRPCHandler.invoke(JAXRPCHandler.java:16) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:190) at org.apache.axis.client.Call.invokeEngine(Call.java:2765) at org.apache.axis.client.Call.invoke(Call.java:2748) at org.apache.axis.client.Call.invoke(Call.java:2424) at org.apache.axis.client.Call.invoke(Call.java:2347) at org.apache.axis.client.Call.invoke(Call.java:1804) at it.trieste.elettra.services.CalcStub.add(CalcStub.java:175) at it.trieste.elettra.services.TestWs.testConnection(TestWs.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at it.trieste.elettra.services.TestWs.main(TestWs.java:67) As I have found in http://www.ogsadai.org.uk/releases/ogsadai.php, this can be due to an incompatibility between the version of the xalan.jar shipped with the Globus Toolkit 3.2.x distribution and particular versions of the Java JDK. To overcome this problem I have updated to JDK 1.4.2_04 which is said to work fine and as a result my WS portlet worked properly. After this I have installed gridportlets and now nothing works, neither the WS portlet nor gridportlets. I have discovered that gridportlets installs *gridportlets-ogsa-3.2.1-** libraries in $CATALINA_HOME/common/lib and *gridportlets-ogsa-3.2.1-xalan.jar* in $CATALINA_HOME/common/endorsed and I have two questions to ask: First, why are these libraries installed under *common* and not under *shared* as advised in the Tomcat classloader how-to? I supposed that these libraries are related to the xalan incompatibility problem mentioned above, so, what can I do to make both gridportlets and my WS portlet work under the same gridsphere installation? If the scenario is not clear enough, I can explain better. thanks in advance for your help, Laura

Previous Message by Thread:

incompatible xalan version

Hi everybody, I am developing a portlet web service client and I have come across the following well-known exception: java.lang.IllegalAccessError: tried to access field org.apache.xpath.compiler.FunctionTable.m_functions from class org.apache.xml.security.Init         at org.apache.xml.security.Init.init(Unknown Source)         at org.globus.ogsa.impl.security.authentication.wssec.WSSecurityEngine.<clinit>(WSSecurityEngine.java:55)         at org.globus.ogsa.impl.security.authentication.wssec.WSSecurityClientHandler.handleResponse(WSSecurityClientHandler.java:51)         at org.apache.axis.handlers.HandlerChainImpl.handleResponse(HandlerChainImpl.java:167)         at org.apache.axis.handlers.JAXRPCHandler.invoke(JAXRPCHandler.java:53)         at org.globus.ogsa.utils.JAXRPCHandler.invoke(JAXRPCHandler.java:16)         at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)         at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)         at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)         at org.apache.axis.client.AxisClient.invoke(AxisClient.java:190)         at org.apache.axis.client.Call.invokeEngine(Call.java:2765)         at org.apache.axis.client.Call.invoke(Call.java:2748)         at org.apache.axis.client.Call.invoke(Call.java:2424)         at org.apache.axis.client.Call.invoke(Call.java:2347)         at org.apache.axis.client.Call.invoke(Call.java:1804)         at it.trieste.elettra.services.CalcStub.add(CalcStub.java:175)         at it.trieste.elettra.services.TestWs.testConnection(TestWs.java:47)         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)         at it.trieste.elettra.services.TestWs.main(TestWs.java:67) As I have found in http://www.ogsadai.org.uk/releases/ogsadai.php, this can be due to an incompatibility between the version of the xalan.jar shipped with the Globus Toolkit 3.2.x distribution and particular versions of the Java JDK. To overcome this problem I have updated to JDK 1.4.2_04 which is said to work fine and as a result my WS portlet worked properly. After this I have installed gridportlets and now nothing works, neither the WS portlet nor gridportlets. I have discovered that gridportlets installs gridportlets-ogsa-3.2.1-* libraries in $CATALINA_HOME/common/lib and gridportlets-ogsa-3.2.1-xalan.jar in $CATALINA_HOME/common/endorsed and I have two questions to ask: First, why are these libraries installed under common and not under shared as advised in the Tomcat classloader how-to? I supposed that these libraries are related to the xalan incompatibility problem mentioned above, so, what can I do to make both gridportlets and my WS portlet work under the same gridsphere installation? If the scenario is not clear enough, I can explain better. thanks in advance for your help, Laura

Next Message by Thread:

Re: incompatible xalan version

Hi, At one point I asked the globus mailing list why the jars were not placed in shared/lib instead of common, but never got a response. The xalan should go in endorsed/lib as it does (which still won't help if you were using jdk 1.4.1 where the xalan it shipped with had problems). In the end as Mike suggests, try various combinations always making sure no duplicate jars are found in common/lib, shared/lib, or server/lib and please report any findings you have. Thanks, Jason Michael Russell wrote: Hi Laura, In the past, I and some others were using Grid Portlets to write clients to OGSA services using the "httpg" protocol. This protocol is no longer officially supported, but some services in the GridSphere's old parent project, GridLab, are still using this protocol. Using it requires modifying Tomcat's setclasspath.sh/bat files to bootstrap _all_ jars that pertained to the use of the httpg protocol. It was a very confusing and difficult problem to overcome, so I added support for modifying Tomcat automatically. NOTE that this feature is NO LONGER enabled by default. That is, Grid Portlets will only touch Tomcat files if httpgservice.resource.support=true in config/build/build-globus.properties. I suppose I can change the install location of the jars to shared, from common (and not put the xalan.jar in endorsed). It was left that way more or less for historical reasons (basically, because the above problem was so confusing and it wasn't clear why it wasn't enough just to put the jars in shared/lib as documented). I'll get this into CVS and in a release soon. For now, please try one of these options below. Grid Portlets supports the ability to do a clean uninstall / undeploy from Tomcat. Just run "ant uninstall" (or "ant undeploy-jars" if you want to save your deployed database) and any jars GP deploys to Tomcat will be removed. Then edit things as described here and try redeploying. 1) If you want to install OGSA (or WSRF) separately, you can disable Grid Portlets from installing Globus jars altogether by setting globus.install=false in config/build/build-globus.properties. Install OGSA/WSRF separately and make sure you have CoG 1.X and related jars available somewhere in Tomcat before you build Grid Portlets. 2) If you want to let Grid Portlets install support for OGSA for you still, edit the locations GP deploys Gloubs jars to from common/lib to shared/lib in config/build/build-globus.xml (line 79). Note that GP can act as a web service container, so that installing OGSA separately is not required. This was a feature we are using for various reasons (to allow GP to host its own services, developed in separate GridSphere web applications ("gridlab", "gt3portlets", "gt4portlets"). I haven't had the chance to test OGSA and WSRF in the same container, so if you want to use both... well, please let me know what your experiences are. We are in the process of adding support for WSRF to GP. This is still experimental, but you can set globus.version=wsrf-4.0 in config/build/build-globus.properties. This will GP install the jars from lib/wsrf-4.0... but still in the common locations. Again, I will fix that. Michael On Jun 20, 2005, at 4:54 PM, laura elettra wrote: Hi everybody, I am developing a portlet web service client and I have come across the following well-known exception: java.lang.IllegalAccessError: tried to access field org.apache.xpath.compiler.FunctionTable.m_functions from class org.apache.xml.security.Init at org.apache.xml.security.Init.init(Unknown Source) at org.globus.ogsa.impl.security.authentication.wssec.WSSecurityEngine.<clinit>(WSSecurityEngine.java:55) at org.globus.ogsa.impl.security.authentication.wssec.WSSecurityClientHandler.handleResponse(WSSecurityClientHandler.java:51) at org.apache.axis.handlers.HandlerChainImpl.handleResponse(HandlerChainImpl.java:167) at org.apache.axis.handlers.JAXRPCHandler.invoke(JAXRPCHandler.java:53) at org.globus.ogsa.utils.JAXRPCHandler.invoke(JAXRPCHandler.java:16) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:190) at org.apache.axis.client.Call.invokeEngine(Call.java:2765) at org.apache.axis.client.Call.invoke(Call.java:2748) at org.apache.axis.client.Call.invoke(Call.java:2424) at org.apache.axis.client.Call.invoke(Call.java:2347) at org.apache.axis.client.Call.invoke(Call.java:1804) at it.trieste.elettra.services.CalcStub.add(CalcStub.java:175) at it.trieste.elettra.services.TestWs.testConnection(TestWs.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at it.trieste.elettra.services.TestWs.main(TestWs.java:67) As I have found in http://www.ogsadai.org.uk/releases/ogsadai.php, this can be due to an incompatibility between the version of the xalan.jar shipped with the Globus Toolkit 3.2.x distribution and particular versions of the Java JDK. To overcome this problem I have updated to JDK 1.4.2_04 which is said to work fine and as a result my WS portlet worked properly. After this I have installed gridportlets and now nothing works, neither the WS portlet nor gridportlets. I have discovered that gridportlets installs *gridportlets-ogsa-3.2.1-** libraries in $CATALINA_HOME/common/lib and *gridportlets-ogsa-3.2.1-xalan.jar* in $CATALINA_HOME/common/endorsed and I have two questions to ask: First, why are these libraries installed under *common* and not under *shared* as advised in the Tomcat classloader how-to? I supposed that these libraries are related to the xalan incompatibility problem mentioned above, so, what can I do to make both gridportlets and my WS portlet work under the same gridsphere installation? If the scenario is not clear enough, I can explain better. thanks in advance for your help, Laura