[izpack-devel] Issues while reading data from packs

[Bartz, Klaus]

Hi Michael,
see
Unpacker line 418ff

  if (!overwritefile)
  {
      if (!pf.isBackReference() && !((Pack) packs.get(i)).loose)
          objIn.skip(pf.length());
      continue;
  }

and then the real ugly thing
line 431
   InputStream pis = objIn;
and line 457
    int bytesInBuffer = pis.read(buffer, 0, maxBytes);
                        
The pack contains 

Number of files to be installed	as an 32 bit int
for(int i = 0; i < files; ++i)
{
    Informations of one file        as PackFile object
    file data                       as "normal byte stream		                     
}
Number of files to be parsed		as an 32 bit int
for(int i = 0; i < files; ++i)
{
    Informations of one file        as ParseableFile object
}
Number of files to be executed	as an 32 bit int
for(int i = 0; i < files; ++i)
{
    Informations of one file        as ExecutableFile object
}
Number of update checks			as an 32 bit int
for(int i = 0; i < files; ++i)
{
    Informations of one check        as UpdateCheck object
}


I think the switch between an ObjectInputStream and a "normal"
InputStream has confused you.

>-----Original Message-----
>From: izpack-devel-bounces at lists.berlios.de
>[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Michael
>Scherer
>Sent: Friday, August 04, 2006 12:36 PM
>To: izpack-devel at lists.berlios.de
>Subject: Re: [izpack-devel] Issues while reading data from packs
>
>
>Hi Klaus, thanks for the quick answer.
>Though I have a few points to discuss, see below.
>
>Bartz, Klaus schrieb:
>
>>> While doing this I'm trying to find all filenames by reading them
>>>from the packs like the InstallPanel does ...
>> 
>> ?? The Unpacker reads the pack "files" (entries in the jar file).
>Exactly, thats what I "copied".
>
>>> Now when doing "PackFile packFile = 
>>> (PackFile)packStream.readObject();" I get
>>> java.io.OptionalDataException
>>>         at java.io.ObjectInputStream.readObject0(Unknown Source)
>>>         at java.io.ObjectInputStream.readObject(Unknown Source)
>>>         at 
>> 
>> The structure of a pack is really specific. There are ints, packs
>> and the data in a well (not documented) order. If you would read the
>> hole pack file you have to skip the "to be installed part". 
>> That's what you NOT DO. 
>> Seems so, you think that the pack file only
>> contains the information of a pack. No, it contains the hole pack.
>Ok, if you say so. :)
>Though I still wonder why my source breaks.
>
>Unpacker.java:
>for (int i = 0; i < npacks; i++)
>{
>	// We get the pack stream
>	int n = idata.allPacks.indexOf(packs.get(i));
>
>	// Custom action listener stuff --- beforePack ----
>	informListeners(customActions, 
>InstallerListener.BEFORE_PACK, packs.get(i),
>		new Integer(npacks), handler);
>	ObjectInputStream objIn = new 
>ObjectInputStream(getPackAsStream(n));
>
>	// We unpack the files
>	int nfiles = objIn.readInt();  // <<<< FIRST ACCESS to stream
>
>	// We get the internationalized name of the pack
>	final Pack pack = ((Pack) packs.get(i));
>	String stepname = pack.name;// the message to be passed to the
>	// installpanel
>
>	[...] Skips langpack stuff [...]
>
>	for (int j = 0; j < nfiles; j++)
>	{
>		// We read the header
>		PackFile pf = (PackFile) objIn.readObject(); // 
><<<< SECOND ACCESS to stream
>	[...]
>}
>
>OpenBackupPanel.java
>for(int i = 0; i < packs.size(); i++)
>{
>	// get the pack for later usage
>	final Pack p = (Pack)packs.get(i);
>	System.err.println(">>> PackName: " + p.name);
>
>	// position of pack in packs
>	int n = idata.allPacks.indexOf(packs.get(i));
>
>	ObjectInputStream packStream =
>		new ObjectInputStream(getPackAsStream(idata, 	
>	// get the number of files in the pack
>	int nfiles = packStream.readInt(); // <<<< FIRST ACCESS, works
>
>	// iterate over file entries
>	for(int j = 0; j < nfiles; j++)
>	{
>		PackFile packFile = 
>(PackFile)packStream.readObject(); <<<< SECOND ACCESS, 
>same as in the Unpacker.java, though borks with an Exception
>	[...]
>}
>
>Now if I'm right the Unpacker doesn't skip anything as well.

not the ObjectInputStream, but after the cast to an InputStream...
>
>You are for sure right about the performance stuff but to be 
>honest, I'd 
>prefer a backup instead of a faster installer.
>
>> If I have to implement something like this, I think I will implement
>> an InstallListener which implements isFileListener and
>> beforeFile.
>> isFileListener returns true,
>> beforeFile makes the backup.
>> See as example 
>> 
>%IZ_HOME%\sample\src\myCompany\tools\install\listener\ChmodInst
>allerListener.java
>> 
>> You conserve about the real hard job to find the files which are
>> selected for installation. That's with "selected" is not to 
>much simple,
>> the Unpacker needs over 150 lines of code to handle it.
>> beforeFile will be called from the Unpacker before a file 
>will be installed. 
>Correct, I'd save a load of work but lose the ability to 
>display the backup on a separate panel. 

Yes.
It is possible to display progress of performing a custom action in the
ExtendedInstallPanel.
Additional there are some more things todo. I have written it in a 
mail thread to the izpack-user list at 20.06.2006 named
"Messages for AntActions are not displayed"
see later ones.
But of course that is not possible for actions during "beforeFile"
because there you are in the "regular" file installation loop. You
know, there is also no display of parseable and executable (but
for the last a separate ExecutePanel exist).

>Though not everyone would need that, I'd prefer it.

If you mean... But then you have to understand the deep internals
of IzPack. 
In our inner area we are (the IzPack developers) really
able todo nice things. At some points the code is a little bit
self protecting. At the time I began with IzPack I have it accepted
as challenge. Many learned the time...



>
>
>Right, hope you can give me a hint for the above code.
>

see docu and
%IZ_HOME%\sample\src\myCompany\tools\install\listener\ChmodInstallerListener.java

>Greeetings,
>  Michael
>

Cheers

Klaus

>_______________________________________________
>izpack-devel mailing list
>izpack-devel at lists.berlios.de
>http://bat.berlios.de/mailman/listinfo/izpack-devel
>