[kepler-dev] [Fwd: Problems with newly checked in files]

[Kevin Ruland]

Dan,

Thanks so much for dorking around with this - it is very tedious.  Your 
assessment that the ecogrid client code is doing something very 
particular is most likely correct.   It seems there are actually two 
problems:  One, why doesn't the data get loader, and two why was there 
no indication of error?

My life is pretty much in a shambles now.  I think I'll be able to 
declare victory over the digir server (again) this weekend, and be able 
to jump back over there and see if I can't figure out where it's 
hanging.  Unless of course, you end up beating me to it.

Until then, I think Jagan's changes are on hold.

Jagan, have you looked into moving from jwsdp to simple axis?  That 
would eliminate this problem too.

Kevin

Dan Higgins wrote:

> Hi Kevin, Jagan, and others,
>
>     Jing got the ecogrid stuff working again, so I got around to 
> testing Kevin's jswdp/Xerces fix. Unfortunately, we still seem to have 
> a problem.
>
>     First of all, the current head of CVS seems to be working. In 
> particular, the I can delete the cache, run 'ant clean buildkarlib 
> run-dev' and then open the 'EML2-Simple-Plot Example' workflow. The 
> Eml2 datasource will initially be red, but it turns to yellow in about 
> 30 seconds and the workflow can then be executed. (i.e. the ecogrid 
> data is downloaded).
>     If I make Kevin's suggested changes (see below), I get no errors, 
> but the EML2 Data Source icon stays red; i.e it never completes 
> downloading data! The problem seems to exist with all workflows which 
> have ecogrid data sources.
>
>     Let me descibe the configuration of changes (in case someone can 
> see something that may be missing.
> 1) xercesImpl.jar is added back to the kepler/lib/jar/jswdp/ drectory 
> along with sax.jar,jaxp-api.jar, and dom.jar
> 2) xml-apis.jar is removed from the kepler/lib/jar/apache/ drectory
> 3) In the build file all "-Djava.endorsed.dirs=./lib/jar/apache" 
> stings are changed to "-Djava.endorsed.dirs=./lib/jar/jwsdp".
>
> As I said, with these changes, everything compiles and Kepler starts 
> up with no errors. Workflows open, but ecogrid sources never finish 
> loading!
>
> So I would guess that something in the client ecogrid code is using a 
> specific version of some earlier XML class; but without some error 
> message, I don't know what! At the moment, I just don't know how to 
> get Jagan's code, which needs the newer jswdp jars, working at the 
> same time as the ecogrid data sources!
>
> Dan
>
> --------------------
>
> Kevin Ruland wrote:
>
>>Hi all.
>>
>>Let me explain my theory.  Even though jwsdp/xercesImpl.jar had
>>repackaged everything, it contained the file
>>META-INF/services/javax.xml.parsers.DocumentBuilderFactory which pointed
>>the JVM to use the com.sun.org.apache.xerces.DocumentBuilderFactory (or
>>what ever it's called, just look in that file).  This is Sun's JAXP
>>magic method #3 to change the underlying implementation of DOM.
>>
>>So my theory is the JVM saw this file, and decided it was appropriate to
>>use com.sun.org.apache...DocumentBuilderFactory instead of
>>org.apache...DocumentBuilderFactory.  The former is from
>>jwsdp/xercesImpl.jar and the latter from sms/xercesImpl.jar.  (I'm doing
>>this from memory and don't recall where this jar really is -- even
>>though it's in two palaces.)
>>
>>Now, Kepler is using the jwsdp/xercesImpl.jar for parsing the actor
>>library, moml and what not.  This really might not be all that bad,
>>after al xerces is xerces and pretty much it should work.
>>
>>The kicker is, jwsdp/xercesImpl.jar apparently implements a newer
>>version of DOM than the xercesImpl we're all used to.  Now we ended up
>>with wacky exceptions which makes you think that an interface doesn't
>>support what's expected of it.
>>
>>Ok.  The end of the story.  We also had a copy of apache/xml-apis.jar
>>which contains, org.w3c.dom, javax.xml, and org.xml.sax interface
>>packages.  These were older than what was expected from jwsdp-1.6.  So
>>after copying the dom.jar, sax.jar, and jaxp-apis.jar (sun split them up
>>nicer) from jwsdp-1.6 into lib/jars/jwsdp/, removing the
>>apache/xml-apis.jar, and changing the java.endorsed.dir to now point to
>>lib/jars/jwsdp, things seem to work.
>>
>>It all kinda makes sense to me.  And this just points out the complexity
>>of trying to have lots of independent components play nicely together
>>all in one very-small sandbox.
>>
>>Kevin
>>
>>    
>>