Re: [Orekit Users] Help with ZipJarCrawler

Dear Luc,

sorry but I can't check whether the patch works since I deleted my working copy of Orekit when I moved to the 6.0 release. I'm on the final stage in the project and I don't think I'll have the time to download, build and test a development version of Orekit. What I did is I replaced the EOP xml files with the text files. Now I don't get any exception, so that has to be the problem.

After the project is finished (2-3 weeks), I'll have the time to play around with it. I guess by then you'll already have the clean solution and my tests won't be so much appreciated...but I don't want to risk messing up with the project now. I hope you understand.

Thank you again for your fast answer and for providing an alternative way of making my project advance. It's really appreciated.

Best regards,
Carlos.

On 3 June 2013 21:48, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:

"Carlos M. Casas Cuadrado" <carlos.marce@gmail.com> a écrit :

Hi Luc,

Hi Carlos,

Thank you very much for your support. Here's the trace you asked for:

Caused by: java.io.IOException: Stream closed
at java.util.zip.ZipInputStream.ensureOpen(Unknown Source)
at java.util.zip.ZipInputStream.closeEntry(Unknown Source)
at org.orekit.data.ZipJarCrawler.feed(ZipJarCrawler.java:239)
at org.orekit.data.ZipJarCrawler.feed(ZipJarCrawler.java:156)
... 12 more

The jar file has read permissions. Looking at the trace, it seems that the
input file is read up to a certain point. The problem happens when closing
an entry: at that some point in the past the ZipInputStream zip was closed
and that entry closing operation fails. I wonder why and when the stream is
closed. Could it be that, at line 205, the zip stream is closed when the
new ZipInputStream object is destroyed?

I think I have found the problem.
Could you apply the following ugly patch and see if it works?

The problem is that the SAX parser (or the underlying InputSource, I did not check) automatically closes the InputStream provided to it, and we don't want that. The patch simply ignores the call to close.

Anyway, I would suggest you to not use the xml version of the EOP files, it is really not efficient to parse it. IERS provides the same data as simple text files and Orekit knows how to read them.

Tell us if the workaround patch solves the problem, I'll try to set up something cleaner.

best regards,
Luc

Regards,
Carlos.

On 2 June 2013 20:21, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:

"Carlos M. Casas Cuadrado" <carlos.marce@gmail.com> a écrit :

Hi all,

Hi Carlos,

I'm having problems with the ZipJarCrawler data provider. I have the

following code:

DataProvidersManager.**getInstance().clearProviders()**;
DataProvidersManager.**getInstance().addProvider(new
DirectoryCrawler(myDirectory))**;

where myDirectory is a File object to my data folder, and the program
works
perfectly fine. I now insert my data folder into the project JAR file and
replace those two lines with:

DataProvidersManager.**getInstance().clearProviders()**;
DataProvidersManager.**getInstance().addProvider(new

ZipJarCrawler(myJar));

where myJar is a File object with the path to the JAR file. In this case
the program throws an IO exception with the message "Stream closed", which
is captured by an Orekit exception with the following stack trace:

org.orekit.data.ZipJarCrawler.**feed(ZipJarCrawler.java:167)
org.orekit.data.**DataProvidersManager.feed(**
DataProvidersManager.java:332)
org.orekit.frames.**RapidDataAndPredictionXMLLoade**r.fillHistory1980(**
RapidDataAndPredictionXMLLoade**r.java:110)
org.orekit.frames.**FramesFactory.**getEOP1980History(**
FramesFactory.java:284)
org.orekit.frames.**GTODProvider.<init>(**GTODProvider.java:72)
org.orekit.frames.**FramesFactory.getGTOD(**FramesFactory.java:916)

and my project files from here on.

The data files are definitely in the JAR file, under a subdirectory called
data/orekit. Since the documentation says that the search is recursive the
data provider should be able to find the data files. I'm using the Orekit
6.0 release. What am I doing wrong?

Do you also have the stacktrace for the initial IOExcetion -it should
appear after a "caused by ..." line. What I would like to know is if the
exception was thrown while executing line 147 of ZipJarCrawler (i.e. when
opening the jar itself), or at some deeper level from the list of
recursuive calls starting at line 156 of ZipJarCrawler (i.e. when parsing
the jar and reading the contained files). Also did you check the read
access properties of the jar file?

best regards,
Luc

Best regards,
Carlos.

------------------------------**------------------------------**----

This message was sent using IMP, the Internet Messaging Program.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.