[kepler-dev] Kepler startup problem with cipres
Zhijie Guan
guan at sdsc.edu
Fri May 19 10:54:55 PDT 2006
Ok. Now it is fixed. Those two errors come from a third-party jar
CipresKeplerRegistry.jar in $KEPLER/lib/jar/cipres/. It prints out
the warnings if it cannot find the Cipres distribution directory in
the machine. I have commented out those warnings. Please let me know
if you find out any errors/warnings about CIPRES during the build.
Thanks for all your help! Especially for Christopher and Dan who
reported the error and Nandita who helped me testing the fix.
Zhijie
On May 19, 2006, at 10:30 AM, Zhijie Guan wrote:
> Sorry again there are still two errors for the CIPRES actors. But
> they won't stop the build. I am working on those and will let you
> know when they get fixed.
>
> Zhijie
>
> On May 19, 2006, at 10:15 AM, Zhijie Guan wrote:
>
>> Sorry about this. It's my fault. I checked in a machine-dependent
>> registry entry. I have updated that registry again. Hopefully this
>> had been fixed.
>>
>> So I broke the build from 4am to 10:13am this Firday (05/19/2006).
>>
>> Zhijie
>>
>>
>> On May 19, 2006, at 10:09 AM, Christopher Brooks wrote:
>>
>>> Kepler won't start for me on two different machines, I get:
>>>
>>> [echo] java.library.path=c:/WINDOWS/system32
>>> [java] Opening user library C:\Documents and Settings\cxh
>>> \.ptolemyII\UserLibrary.xml...
>>> [java] KAR Library directories: [C:\cxh\src\kepler\kar\actors,
>>> C:\cxh\src\kepler\kar\directors]
>>> [java] org.xml.sax.SAXException: unable to add
>>> 'default-std-err-dir' to <cipres-kepler-registry> due to the
>>> following exception:
>>> [java] >>>--- Begin Exception ---<<<
>>> [java] java.lang.Exception: Unable to locate or create
>>> defaultStdErrDir at
>>> /Users/zhijieguan/.kepler/tmp/cipres/temp/
>>> [java] at
>>> org.cipres.kepler.registry.CipresKeplerRegistry.setDefaultStd
>>> ErrDir(CipresKeplerRegistry.java:71)
>>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0
>>> (Native
>>> Method)
>>> [java] at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
>>> sorImpl.java:39)
>>> [java] at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
>>> hodAccessorImpl.java:25)
>>> [java] at java.lang.reflect.Method.invoke(Method.java:324)
>>> [java] at
>>> org.exolab.castor.mapping.loader.FieldHandlerImpl.setValue(Fi
>>> eldHandlerImpl.java:463)
>>> [java] at
>>> org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHa
>>> ndler.java:803)
>>> [java] at
>>> org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknow
>>> n Source)
>>> [java] at
>>> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEnd
>>> Element(Unknown Source)
>>>
>>> Looks like a path is hard coded in?
>>>
>>> _Christopher
>>> _______________________________________________
>>> 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
More information about the Kepler-dev
mailing list