Hello, thanks for FreeRapid!

I want to share a script that makes FreeRapid work with PortableJava, and report two issues I found with version 0.83.

The batch script allows you to run FreeRapid using portableapps.com's portable Java, so FRD becomes fully portable even on computers where Java isn't normally installed. The script is at the end of this message. Instructions are included inside the script. I have been running this script with version 0.82 for months with no significant issues.

However, as I upgraded to version 0.83 I found two new issues, and I wonder if it is the script causing those issues, of if they are inherent in FRD 0.83 and can be fixed or worked-around. So those are my questions, if anyone could answer them or point me in the right direction. Now the issues.

Reminder, I run FRD 0.83 through the script below, it needs portable Java, which is harmless and can be used even on a PC where non-portable Java is installed.
Issue 1 - when option save description to txt file is enabled, FRD does not save the description file at all.
Issue 2 - downloads terminate correctly - however the downloaded file is named FILENAME.ext.CRC.part, that is as if FRD failed to remove the CRC.part suffix at the end of the download. File contents are correct, but the file needs to be renamed manually.

----------- CMD.exe batch script -----------

@echo off
rem script runs FreeRapid jar file using portableapps.com portable JVM
rem credits JavaPortableLauncher.nsi

rem (*) = change the version number string to reflect the installed FRD version
rem 1. download portable Java from portableapps.com and install it in your portable
rem    application folder, say x:\port. So java ends up in x:\port\Common Files\Java
rem 2. unzip FRD in x:\port, so frd.exe ends up in x:\port\FreeRapid-0.83\ (*)
rem 3. create folder x:\port\FreeRapid-0.83\tools\portablejava (*)
rem 4. Copy the batch file below in x:\port\FreeRapid-0.83\tools\portablejava\runportable.cmd (*)
rem 5. Double-click runportable.cmd to start FRD.
rem The download save path is saved relative to folder portablejava.
rem In other words, if you tell FRD to save into X:\downloads, you will find
rem the bits in X:\port\FreeRapid-0.83\tools\portablejava\downloads.

setlocal

pushd "%~dp0"

set jarpath=%CD%\..\..\frd.jar
if not exist "%jarpath%" echo FRD not found && pause && goto ERROR

rem portableapps.com app folder structure assumed, change below if needed
set portableappspath=..\..\..
set JAVAHOME=%portableappspath%\CommonFiles\Java
if not exist "%JAVAHOME%" echo JVM not found && pause && goto ERROR

pushd "%JAVAHOME%"
set JAVAHOME=%CD%
popd

set CLASSPATH=.
if not exist Data mkdir Data
if not exist Data\AppData mkdir Data\AppData
set APPDATA=%CD%\Data\AppData
cd %APPDATA%
start "" "%JAVAHOME%\bin\javaw.exe" -Duser.home="%APPDATA%" -jar "%jarpath%" --portable %*

echo =================================================================
echo REMINDER: do not let FreeRider auto-restart after plugin updates.
echo Just close it and restart it again with %~n0.
echo =================================================================
pause
goto OK

:ERROR
set status=1

:OK
popd

quit %status%
endlocal & rem NOTREACHED

Thanks for sharing. I will check the issues ASAP, probably during weekend. Although I don't think that the script is related to your issues you described.

-------------------------------------





Edited 1 time(s). Last edit at 10/21/2009 09:08PM by Vity.

Thanks Vity, I will wait for your feedback.

Meanwhile you can test this - check app.log file when file is finished for error.
Do you have enough free disk space on target drive/disk?

-------------------------------------

Yes, I have enough disk space. Here is app.log
The folder path exists, checked.
Is it correct that it starts with file:/C instead of file://C ...

Keep in mind that the destination folder path was entered in FRD as C:\downloads, not as shown.
The longer path file://C... below is the result of the portable script. FRD 0.82 handled that path without issues. FRD 0.83 does not.
Once downloaded with 0.82, the files did end up in that folder path, and not in C:\downloads. That was a minor bother for me, as long as I got the files. However, if you think the script or FRD can be improved to deliver the files in C:\downloads - as entered in the GUI - I would like to know how.

cz.vity.freerapid.utilities.LogUtils processException
SEVERE:
java.io.IOException: Failed to open file:/C:/apps/port/FreeRapid-0.83/tools/portablejava/Data/AppData/../../../downloads/R/XIP1099.rar. Error message: The system cannot find the path specified.

at sun.awt.windows.WDesktopPeer.ShellExecute(Unknown Source)
at sun.awt.windows.WDesktopPeer.open(Unknown Source)
at java.awt.Desktop.open(Unknown Source)
at cz.vity.freerapid.utilities.OSDesktop.openFile(Unknown Source)
at cz.vity.freerapid.gui.content.ContentPanel.openFileAction(Unknown Source)
at cz.vity.freerapid.gui.content.ContentPanel.smartEnterAction(Unknown Source)
at cz.vity.freerapid.gui.content.ContentPanel$8.mouseClicked(Unknown Source)
at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

I don't understand why you setup -Duser.home= to launch path.
--portable means that all configuration files are stored in the FRD's directory, user.home is ignored then.
Relative paths are counted from FRD's directory. Example:
FRD's directory: x:\FreeRapid-0.83\
if you want to save your files into x:\FreeRapid-0.83\downloads - then choose same path in the dialog
the store path (internally) will be ./downloads
if you want to save your files into x:\downloads - then choose same path in the dialog
the store path will be (internally) ../downloads whenever you move to any other system.

-------------------------------------





Edited 1 time(s). Last edit at 10/24/2009 06:44AM by Vity.

Vity Wrote:
-------------------------------------------------------
> I don't understand why you setup -Duser.home= to
> launch path.

I don't recall if I had any reason for setting -Duser.home, probably not since I didn't know that it would be ignored, as you're saying below. I will update my script to not set user.home, but it won't matter as regards my open issues, because you say that --portable makes -Duser.home ignored:

> --portable means that all configuration files are
> stored in the FRD's directory, user.home is
> ignored then.

As regards relative paths, I'm not sure I explained myself. With the above script, I never enter a relative path.
I enter c:\downloads\R. That's absolute. But the files are then stored (unrenamed - issue still pending) in a sub-folder of FRD's. Your description below confirms that FRD turns absolute paths into relative paths (x:\downloads case), so I'm not surprised that C:\downloads\R - with my script active - becomes a sub-folder of FRD's. I was hoping there would be a way to avoid it.

> Relative paths are counted from FRD's directory.
> Example:
> FRD's directory: x:\FreeRapid-0.83\
> if you want to save your files into
> x:\FreeRapid-0.83\downloads - then choose same
> path in the dialog
> the store path (internally) will be ./downloads
> if you want to save your files into x:\downloads -
> then choose same path in the dialog
> the store path will be (internally) ../downloads
> whenever you move to any other system.

Anyway, the most pressing issue for me is to get downloaded files renamed correctly, and their .txt description files written.
Thanks.



Edited 3 time(s). Last edit at 10/25/2009 12:10PM by ra.

Hi, I tested without -Duser.home and entering a relative folder path. Again FRD did not rename the downloaded file, nor did it create a txt file for comments (corresponding option enabled). As download folder I simply entered R (as in Relative). Since R did not exist, FRD asked for permission to create it, which I OKed. This way we know FRD's starting idea of folder R's location. When the file was downloaded FRD saved it elsewhere (unrenamed), in another NEW folder "R". For whatever reason FRD ending idea of R's location changed. Here is a list of relevant files and folders. The number before each line is a timestamp mmss, so we can sequence file/folder creation.

C:\FreeRapid-0.83\tools\portablejava\runportable.cmd
2207 C:\FreeRapid-0.83\tools\portablejava\Data\AppData
2131 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\R
2526 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\tools
2207 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\app.log
2207 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\app.log.lck
2526 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\tools\portablejava
2526 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\tools\portablejava\Data
2526 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\tools\portablejava\Data\AppData
2526 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\tools\portablejava\Data\AppData\R
2819 C:\FreeRapid-0.83\tools\portablejava\Data\AppData\tools\portablejava\Data\AppData\R\WF52.rar.6546390411820692819.part

text in app.log

Oct 24, 2009 8:22:07 PM org.apache.commons.httpclient.SimpleHttpConnectionManager getConnectionWithTimeout
WARNING: SimpleHttpConnectionManager being used incorrectly.  Be sure that HttpMethod.releaseConnection() is always called and that only one thread and/or method is using this connection manager at a time.

Well. I spent an evening on this. I think I found the line which is causing it. Unfortunately I am not sure with this change, because I can easily influence some other stuff I am not aware of at this time. This playing with relative paths is pretty tricky and it's problematic (there is different behavior on different systems).
I will add this change into some early /alfa/ versions of FRD 0.84. Not for planned 0.83 update 1 (this weekend).

-------------------------------------

Thanks Vity, I'm looking forward to the early /alpha/ build with this change.
Where do you announce alpha builds?