[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