[kepler-dev] [kepler-cvs] kepler/lib/jar/jwsdp xalan.jar xercesImpl.jar
Kevin Ruland
kruland at ku.edu
Tue Nov 8 14:04:07 PST 2005
Dan,
Those jars need to be put in lib/jar/jwsdp-1.6/ directory (or whatever
it's called) only so they don't physically overwrite the others.
There will be no conflict between the apache/xalan.jar and the
jwsdp/xalan.jar because the former uses /org/apache/xalan/* packaging
and the latter uses /com/sun/org/apache/xalan/* packaging. No classes
looking for the One True xalan will ever accidentially find the classes
defined in the jwsdp/xalan.jar. Similarly, sun changed all the source
in their version of xalan.jar to only look for their copies of these
classes. Given these changes, I don't believe that these jars can ever
conflict with any other jars. Of course the best thing to do is test.
If indeed there ends up being a problem with the jwsdp/xercesImpl.jar
and the other xercesImpl.jars, then the only thing we are left with is
to have somebody make an Executive Decision to which actors will be
included in Kepler because there is no acceptable solution at this time
to support multiple classloaders.
I'm surprised you need to endorse xalan on the client side because that
is usually only used in more controlled deployment settings (such as
servlet, ejb and applet containers). I do not endorse any jars in my
client side executions and it runs just fine. If indeed the
jwsdp/xalan.jar needs to be endorsed, then that directory too would need
to be added to the java.endorsed.dirs list.
Kevin
Dan Higgins wrote:
> 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
>*******************************************************************
>
More information about the Kepler-dev
mailing list