[kepler-dev] [kepler-cvs] kepler/lib/jar/jwsdp xalan.jar xercesImpl.jar
Dan Higgins
higgins at nceas.ucsb.edu
Tue Nov 8 13:25:57 PST 2005
Kevin,
I am not sure that your comment about it being OK to add the jswdp
xercesImpl.jar and xalan.jar to lib/jar is correct. Your note on Sun's
repackaging of xalan, etc. is useful, but I think there is a version
conflict with the version of xalan.jar that is in the
$Kepler/lib/jar/apache/ directory.
Note that some time ago we had to use the trick of making that
directory an endorsed directory to force java to use the classes there
prior to system classes (see the ' -Djava.endorsed.dirs=./lib/jar/apache
' added to all the java commands in the ant build file) If we don't do
this, errors appear in the apache.axis package (see below).[I must
admit, I don't understand why this happens.]
In addition, I think that Jagan had put the jswdp jars into Kepler
before and it did indeed 'break' some other code.
Dan
---- errors when -Djava.endorsed.dirs=./lib/jar/apache omitted
[java] EcogridUtils: The time to create factory is ============= 1
[java] - Logging is working
[java] - Date: Tue Nov 08 12:56:57 PST 2005
[java] - Version: Apache-XML-Security-J 1.0.4
[java] java.lang.IllegalAccessError: tried to access field
org.apache.xpath
.compiler.FunctionTable.m_functions from class org.apache.xml.security.Init
[java] at org.apache.xml.security.Init.init(Unknown Source)
[java] at
org.globus.ogsa.impl.security.authentication.wssec.WSSecurity
Engine.<clinit>(WSSecurityEngine.java:55)
[java] at
org.globus.ogsa.impl.security.authentication.wssec.WSSecurity
ClientHandler.handleResponse(WSSecurityClientHandler.java:51)
[java] at
org.apache.axis.handlers.HandlerChainImpl.handleResponse(Hand
lerChainImpl.java:153)
[java] at
org.apache.axis.handlers.JAXRPCHandler.invoke(JAXRPCHandler.j
ava:84)
[java] at
org.globus.ogsa.utils.JAXRPCHandler.invoke(JAXRPCHandler.java
:16)
[java] at
org.apache.axis.strategies.InvocationStrategy.visit(Invocatio
nStrategy.java:71)
[java] at
org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:150)
[java] at org.apache.axis.SimpleChain.invoke(SimpleChain.java:120)
[java] at
org.apache.axis.client.AxisClient.invoke(AxisClient.java:193)
[java] at org.apache.axis.client.Call.invokeEngine(Call.java:2564)
[java] at org.apache.axis.client.Call.invoke(Call.java:2553)
[java] at org.apache.axis.client.Call.invoke(Call.java:2248)
[java] at org.apache.axis.client.Call.invoke(Call.java:2171)
[java] at org.apache.axis.client.Call.invoke(Call.java:1691)
[java] at
org.gridforum.ogsi.bindings.FactorySOAPBindingStub.createServ
ice(FactorySOAPBindingStub.java:773)
[java] at
org.globus.ogsa.utils.GridServiceFactory.createService(GridSe
rviceFactory.java:136)
[java] at
org.globus.ogsa.utils.GridServiceFactory.createService(GridSe
rviceFactory.java:49)
[java] at
org.ecoinformatics.ecogrid.client.EcogridFactoryQueryClient.<
init>(EcogridFactoryQueryClient.java:81)
[java] at
org.ecoinformatics.seek.datasource.EcogridQueryDataCacheItem.
doWork(EcogridQueryDataCacheItem.java:108)
[java] at
org.kepler.objectmanager.cache.DataCacheObject.run(DataCacheO
bject.java:782)
[java] at java.lang.Thread.run(Thread.java:534)
Kevin Ruland wrote:
>Jagan,
>
>The jwsdp xercesImpl.jar and xalan.jar have been repackaged by sun.
>Every class is packaged in com.sun.org.apache.*. This means that those
>classes cannot conflict with standard distributions of xercesImpl.jar
>and xalan.jar. This is both good and bad. It's good (for us) because
>it means they can be included with standard versions of these jars
>without conflict. It's bad because it ends up causing code bloat. For
>the life of me I don't understand why sun insists on doing this.
>
>You can commit them to the lib/jar/jwsdp and rest assured that these
>copies do not conflict with the three other versions of xercesImpl.jar
>or the other version of xalan.jar which are already in the repository.
>
>Chad,
>
>I have put the build system changes on hold until we can figure out a
>way out of this mess. The current kar system does not provide any
>mechanism to provide for multiple implementations of the same
>package/class. There are not changes we can make to the build system to
>provide this without corresponding changes to the Kepler classloading
>dilemma. About all we can do, right now, is remove the duplicated jars,
>build/test/test/test, and be very strict about changing jars in the
>repository.
>
>Kevin
>
>Chad Berkley wrote:
>
>
>
>>Hi Jagan,
>>
>>I don't know if i can tell you that because I'm not sure we know.
>>There's an ongoing discussion about what to do with conflicting jars.
>>One option is using the dynamic class loading that we've been talking
>>about with kar files, but it doesn't look like that's going to get
>>implemented at this point. Kevin has also been working on redesigning
>>the build system. I'm not sure where he is on that.
>>
>>Sorry I'm not more help.
>>
>>chad
>>
>>jagan wrote:
>>
>>
>>
>>
>>>Hello Chad and Matt,
>>>
>>>Some of the GriddLeS actors are using Sun's jar files released with
>>>jwsdp-1.6 which I need to add to cvs repository.
>>>But I am bit concern that it may affect other actors. Could you mind to
>>>tell me how to add jar files specific to GriddLeS actors?
>>>
>>>with regards,
>>>
>>>Jagan Kommineni
>>>
>>>
>>>Matt Jones wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Jagan,
>>>>
>>>>We are in the process of trying to reduce the central jars stored in
>>>>Kepler because it is such a huge mess. The KAR file format now allows
>>>>you to include jar files required by an actor in a .kar file for that
>>>>actor and list it in the actor's dependencies. I think there are still
>>>>a few issues to work out about how to handle the build with the KAR
>>>>system, but the basic infrastructure should work. So I would recommend
>>>>that you work with Chad to get your Griddles actors built as a .kar with
>>>>their own specific jar dependencies.
>>>>
>>>>Over the next short while I will be pushing for us to clean out the jar
>>>>files from the central kepler lib dir and start including there only
>>>>things that are part of the core kepler framework. Actor-specific
>>>>dependencies would be resolved via the KAR system.
>>>>
>>>>Your thoughts on this approach would be appareciated.
>>>>
>>>>Matt
>>>>
>>>>jagan wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Dan,
>>>>>
>>>>>My code is using sun's latest jwsdp which includes certificate based
>>>>>security module.
>>>>>If I add those two jar files in kepler/lib/jar/jwsdp directory griddles
>>>>>actors are able to pickup the right jar.
>>>>>I have looked at the directory structure of the xalan.jar and
>>>>>xercesImpl.jar of jwsdp and was different to
>>>>>the directory structure of the old ones. Is there any possibility if I
>>>>>add these jar files at the end so that
>>>>>it won't affect other peoples code and griddles actors can get the
>>>>>access to these jar files.
>>>>>
>>>>>with regards,
>>>>>
>>>>>Jagan Kommineni
>>>>>
>>>>>
>>>>>Dan Higgins wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Jagan,
>>>>>> I suspect that we have some sort of versioning problem.
>>>>>>
>>>>>> Kepler does include the xercesImpl.jar and xalan.jar files.
>>>>>>xercesImpl.jar is in kepler\lib\jar\sms and xalan.jar is in
>>>>>>kepler\lib\jar\apache. And these jars are showing up in the kepler
>>>>>>class path.
>>>>>>
>>>>>> The class DocumentBuilderFactoryImpl is in the xercesImpl.jar file,
>>>>>>but its path is "org/apache/xerces/jaxp/". Note that the first 2
>>>>>>elements of the path in your error message (I.e. "com/sun/") are
>>>>>>missing! That is apparently why you are getting the error. But I don't
>>>>>>know why your code is looking for a sun specific version of this
>>>>>>class! (Something about the SecurityPluginUtil class?)
>>>>>>
>>>>>> The versions of xercesImpl.jar and xalan.jar files that are
>>>>>>included with kepler were needed for some other parts of kepler and
>>>>>>(if I remember correctly) are version-dependent, so we may have a
>>>>>>problem with replacing the current versions.
>>>>>>
>>>>>>Dan Higgins
>>>>>>
>>>>>>jagan wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hello Matt,
>>>>>>>
>>>>>>>I have removed xalan.jar and xercesImpl.jar files from the cvs
>>>>>>>repository.
>>>>>>>You are correct these files are already there but kepler runtime
>>>>>>>environment is complaining when I try to run griddles actors from
>>>>>>>kepler which needs some of the classes from these jar files.
>>>>>>>The error message is as follows, I suspect the kepler runtime is not
>>>>>>>able to load
>>>>>>>xalan and xerces from other directory. Could you mind to advise?
>>>>>>>-------------------------------------------------------------------------------------------------------------
>>>>>>>
>>>>>>>java.lang.NoClassDefFoundError:
>>>>>>>com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl
>>>>>>> at
>>>>>>>com.sun.xml.rpc.security.SecurityPluginUtil.<init>(SecurityPluginUtil.java:128)
>>>>>>>
>>>>>>> at
>>>>>>>org.monash.griddles.jobrun.JobrunIF_Stub.<clinit>(JobrunIF_Stub.java:41)
>>>>>>> at
>>>>>>>org.monash.griddles.jobrun.MyJobrun_Impl.getJobrunIFPort(MyJobrun_Impl.java:59)
>>>>>>>
>>>>>>> at
>>>>>>>org.monash.griddles.GriddlesRemoteExec.createProxy(GriddlesRemoteExec.java:132)
>>>>>>>
>>>>>>> at
>>>>>>>org.monash.griddles.GriddlesRemoteExec.fire(GriddlesRemoteExec.java:148)
>>>>>>> at ptolemy.actor.process.ProcessThread.run(ProcessThread.java:178)
>>>>>>>--------------------------------------------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>with regards,
>>>>>>>
>>>>>>>Jagan Kommineni
>>>>>>>
>>>>>>>
>>>>>>>Matt Jones wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Jagan,
>>>>>>>>
>>>>>>>>
>>>>>>>>These jar files are incredibly basic. I am positive there are already
>>>>>>>>copies of both xalan and xerces in the classpath of Kepler -- I have
>>>>>>>>used both in some of my actors. Adding your new copies will
>>>>>>>>undoubtedly
>>>>>>>>break something. Could you please remove them? Thanks.
>>>>>>>>
>>>>>>>>Matt
>>>>>>>>
>>>>>>>>Jagan Kommineni wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>kommineni 05/10/04 16:47:35
>>>>>>>>>
>>>>>>>>>Added: lib/jar/jwsdp xalan.jar xercesImpl.jar
>>>>>>>>>Log:
>>>>>>>>>Two jars files are added as jwsdp needs these jar files for
>>>>>>>>>executing Griddles actors .....
>>>>>>>>>
>>>>>>>>>Revision Changes Path
>>>>>>>>>1.3 +0 -0 kepler/lib/jar/jwsdp/xalan.jar
>>>>>>>>>
>>>>>>>>> <<Binary file>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>1.3 +0 -0 kepler/lib/jar/jwsdp/xercesImpl.jar
>>>>>>>>>
>>>>>>>>> <<Binary file>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>Kepler-cvs mailing list
>>>>>>>>>Kepler-cvs at ecoinformatics.org
>>>>>>>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-cvs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>------------------------------------------------------------------------
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Kepler-dev mailing list
>>>>>>>Kepler-dev at ecoinformatics.org
>>>>>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>>
>>
>>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
--
*******************************************************************
Dan Higgins higgins at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Ph: 805-893-5127
National Center for Ecological Analysis and Synthesis (NCEAS) Marine Science Building - Room 3405
Santa Barbara, CA 93195
*******************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20051108/a14dd45f/attachment.htm
More information about the Kepler-dev
mailing list