Cannot open iReports 6 - jasper-reports

i tried installing the latest version of iReport. installation was successful but now while opening it is giving me error. the Slash screen opens and closes.
error :
my config file :
# ${HOME} will be replaced by user home directory according to platform
default_userdir="${HOME}/.${APPNAME}/5.6.0"
default_mac_userdir="${HOME}/Library/Application Support/${APPNAME}/5.6.0"
# options used by the launcher by default, can be overridden by explicit
# command line switches
default_options="-J-Xms256m -J-Xmx512m -J-Dorg.netbeans.ProxyClassLoader.level=1000 -J-XX:MaxPermSize=512m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dnetbeans.exception.report.min.level=99999 "
# for development purposes you may wish to append: -J-Dnetbeans.logger.console=true -J-ea
# default location of JDK/JRE, can be overridden by using --jdkhome <dir> switch
#jdkhome="C:\Program Files (x86)\Java"
jdkhome="\jdk1.6.0_45"
# clusters' paths separated by path.separator (semicolon on Windows, colon on Unices)
#extra_clusters=
please help me

Look at this line
# default location of JDK/JRE, can be overridden by using --jdkhome <dir> switch
#jdkhome="C:\Program Files (x86)\Java"
jdkhome="\jdk1.6.0_45"
# clusters' paths separated by path.separator (semicolon on Windows, colon on Unices)
#extra_clusters=
What you need is to set an environement varialble JDK_HOME that points to the path of your JDK installation , or update your config file to point to the path where JDK installed

a) Once installed, go to its \etc folder, e.g., C:\Program Files (x86)\Jaspersoft\iReport-5.6.0\etc and add write permissions (for yourself) to the readonly file ireport.conf, of which you show an example output.
b) Open ireport.conf w/ an editor like Notepad++ , and add the line for your jdk home, e.g., jdkhome="C:\\Program Files\\Java\\jdk1.7.0_71" (instead of just jdkhome="\jdk1.6.0_45"). Note: on Win OS you might need to use the escaped backslash.

Related

Command "docker" not recognized in windows powershell

I am using Windows Powershell (on windows 10). I am also using the latest version 2.3.0.5 of docker desktop. When I type "docker version" in powershell the command is not recognized. The error message reads "Der angegebenen Datei ist keine Anwendung zugeordnet." (English: No application is assigned to the specified file). When I instead include the file extension and type "docker.exe version" the command can be executed. The interesting thing is that "docker version" works in a cmd window, but for some reason not in powershell. The extension ".exe" is contained in the windows environment variable PATHEXT.
What could be the reason that it doesn't work in powershell?
PS: I had an old version of docker installed before. There everything worked fine. Then I updated to the newest version. After that I couldn't use my existing docker containers anymore. So I uninstalled the old version and installed version 2.3.0.5. Since then I have this issue.
tl;dr:
Run Get-Command -All docker | ForEach-Object Path
Among the file paths returned, remove those that do not end in *.exe (use Remove-Item).
The likeliest explanation is that, in one of the directories in your system's path ($env:PATH) that comes before the one in which docker.exe is located, contains another file whose base name is docker:
Either: It is an extension-less file literally and fully named docker [This is what it the problem turned out to be] .
PowerShell unexpectedly tries to execute this extension-less file, because it considers it executable, despite - by definition - not having an extension designated as executable via the PATHEXT environment variable ($env:PATHEXT).[1]
This would explain cmd.exe's different behavior, because it sensibly never considers an extension-less file executable.
Presumably, the uninstallation of the old Docker version removed the original docker.exe, but left an extension-less docker file in the same directory behind (possibly a Unix shell script).
Or: It does have an extension (other than *.exe), which:
refers to a file that isn't directly executable and needs an interpreter - a separate executable - in order to be executed
and that extension is listed in the PATHEXT environment variable
and the association between the filename extension (e.g., .py) and the (information about the) associated interpreter is (now) missing, possibly as a result of having uninstalled the older Docker version.
[1] In fact, PowerShell unexpectedly considers any filename extension executable - see GitHub issue #12632.
However, for those extensions not listed in PATHEXT, execution via the path only works if you include the filename extension in a file-name-only call (e.g., executing file.txt opens a file by that name located in the first folder in the path that has such a file in the associated editor). With an extension-less file, there is obviously no extension to include, which is why confusion with an *.exe file of the same base name is possible (unless you invoke with .exe); if both such files reside in the same directory in the path, the *.exe file takes precedence, but if the extension-less file is in a different directory listed earlier in the path, it takes precedence.

Windows Powershell Basic Questions - new user

When trying to open a file with text editor VIM, I am unable to open the file unless VIM (shortcut) is in my current working directory. As an example, I am able to write start firefox to open a firefox window. However, start vim C:\filepath\filename.txt does not work unless a vim shortcut is in my current directory. How do I get around this?
Also, is there a way to have a program execute a file in the current working directory without having to reference the entire file path? For example instead of Start-Process vim C:\Users\User\Desktop\File\file.txt is there an available path shortcut like Start-Process vim ~\file.txt with ~ representing the current working directory?
The OS need to determine the full path of the exe, no matter what.
There's 2 ways that it will happen.
You're calling the executable from it's working directory
The executable location is in the Windows environment variable.
You can view the PATH variable content through this simple statement
$env:Path -split ';' | sort
You sill see that the Firefox path is listed there, but not the one from VIM.
That's why the former can be started by it's executable name and the latter require the full path.
You need to add VIM directory to your PATH variable if you want to be able to call it just by typing vim
Otherwise, if you have restricted access or don't want to edit that variable, you can also set a $vim variable, then invoke it whenever you want to call the executable.
Regarding the second part of your question
Powershell use the dot as a reference to the current directory .\file.txt.
You can also just specify the filename without anything else file.txt.
Both backslash \ & slash / work for filepath so .\file.txt and ./file.txt are both valid ways to reference the file.
Use ..\ to reference the parent directory (e.g. ..\file.txt)
$Vim = "c:\Path\To\Vim.exe"
& $vim "file.txt"
& $vim ".\file.txt"
#Forward slash also work for paths
& $vim "./file.txt"

Netbeans.conf: what is the variable for the user home?

When starting Netbeans, I need to add a system property named mEnvironment and set it as a sub-directory of the user's home. Example: In the netbeans.conf, I would like to add:
netbeans_default_options="-J-XX:+UseStringDeduplication -J-Xss2m -J-DmEnvironment=${USER_HOME}/mySubDirectory ......
USER_HOME is given as example of course.
Does someone know how Netbeans get the user home directory in the netbeans.conf file?
Thank you
Paul
Does someone know how Netbeans get the user home directory in the
netbeans.conf file?
The process is convoluted, and varies by operating system, but is described in great detail within netbeans.conf itself. This is the relevant content for my Apache NetBeans 11.1 installation:
# On Windows ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "<AppData>\NetBeans" where <AppData> is user's
# value of "AppData" key in Windows Registry under
# "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
# and ${DEFAULT_CACHEDIR_ROOT} will be replaced by the launcher
# with "<Local AppData>\NetBeans\Cache" where <Local AppData> is user's
# value of "Local AppData" key in Windows Registry under
# "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
#
# On Mac ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "~/Library/Application Support/NetBeans" and
# ${DEFAULT_CACHEDIR_ROOT} with "~/Library/Caches/NetBeans"
#
# On other systems ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "~/.netbeans" and ${DEFAULT_CACHEDIR_ROOT} with "~/.cache/netbeans"
....
netbeans_default_userdir="${DEFAULT_USERDIR_ROOT}/11.1"
However, none of that really helps you, because you cannot access the values of netbeans_default_userdir or DEFAULT_USERDIR_ROOT; they are used internally by NetBeans itself, and are not System properties. You can verify this by displaying the values returned by System.getProperties(); none of the entries in netbeans.conf are shown.
Also, you can't meaningfully add new name/value pairs in netbeans.conf; you can only modify the values of the names used by NetBeans. That file is for NetBeans configuration, not user configuration. So if you add a line containing (say) MyConfSetting="ABC" then NetBeans will simply ignore that, and it won't be accessible to you either.
However, you can use an alternative approach to set a System Property for your directory in your application:
The read-only environment variable APPDATA points to your (operating system's) user directory. On my Windows 10 machine it has the value C:\Users\johndoe\AppData\Roaming.
The default user directory for NetBeans is the value of APPDATA + a sub-directory named NetBeans + a sub-directory named the NetBeans version. On my machine it is C:\Users\johndoe\AppData\Roaming\NetBeans\11.1. See the value of User directory in the Help > About screen for confirmation.
I don't know how to dynamically determine the version of NetBeans, but if that isn't important you can programmatically create a system property specifying your directory path:
String dir = System.getenv("APPDATA") + "\\NetBeans\\mySubDirectory";
System.setProperty("myDir", dir);
System.out.println("myDir=" + System.getProperty("myDir"));
On my machine that println() call displays myDir=C:\Users\johndoe\AppData\Roaming\NetBeans\mySubDirectory. I don't know if that approach meets your requirements, but I don't know of any other simple way to dynamically set your directory name.
Notes:
I checked this on Windows 10. Details may vary on other operating systems, but the overall approach should still work.
You can also specify parameters at run time using {project} > Properties > Run > Arguments (e.g. arg1=%APPDATA%\NetBeans\MyDir) and {project} > Properties > Run > VM Options (e.g. -Dvmopt1=%APPDATA%\NetBeans\MyDir), but that approach won't work because the %APPDATA% is simply treated as the literal "%APPDATA%" rather than evaluated as an environment variable.

How to create mask in winrar to archive folders by name?

I have folders C:\testA01, C:\testA02 and C:\testB01, C:\testB02.
How to create a command to archive only folders with testA in their name?
"C:\Program Files\WinRAR\WinRAR.exe" a -r -u -rr8 -y C:\BACKUP\backup.rar C:\testA ?? \*.*
Windows command line interpreter does not support wildcards in folder paths. It is only possible to search for folders matching a pattern with DIR or FOR.
But take a look on text file WhatsNew.txt in program files directory of WinRAR version 5.30 or any later version. There can be read:
Folder wildcards are allowed in RAR command line in file names to
archive. For example:
rar a backup c:\backup\2015*\*
will archive all '2015*' folders in c:\backup. Use -r switch to search
for '2015*' also in c:\backup subfolders.
WinRAR v5.30 can be used on Windows XP and later Windows.
A command line for your backup task is for example:
"%ProgramFiles%\WinRAR\Rar.exe" u -cfg- -ep1 -idq -r -rr8 -y C:\BACKUP\backup.rar C:\testA*\*
For details on the used command u which is like command a with switch -u and the used switches see text file Rar.txt being the manual for the console version Rar.exe of WinRAR.
Of course you can also run from command line the GUI version, but one switch must be changed:
"%ProgramFiles%\WinRAR\WinRAR.exe" u -cfg- -ep1 -ibck -r -rr8 -y C:\BACKUP\backup.rar C:\testA*\*
The switch -ibck for running GUI version in background (minimized to system tray) is used instead of -idq which means for console version to run in quiet mode with only error messages printed into console window.
The commands and switches for the GUI version with some differences to console version are explained in help of WinRAR. Start WinRAR, click in menu Help on menu item Help topics, select tab Contents, open item Command line mode and read the pages listed below this list item.

'findstr' is not recognized as an internal or external command,

I got the following error while starting JBoss from a command line prompt today:
'findstr' is not recognized as an internal or external command
Please google it, you can find a lot of answers. But do as below to fix it. Add the following value to Right Click My Compuer -> Advanced -> Environment Variables -> System Variables -> Select Path variable -> append the below value.
C:\WINDOWS\system32
It should work with that change.
As others pointed, issue is in wrong settings of PATH variable in Windows.
According to article this is most probably because some stupid installer wrongly modified PATH variable in Windows registry. Registry has 2 different string value types - REG_SZ and REG_EXPAND_SZ. Only the second one allows for expansion of %SystemRoot%.
So check your path by typing set path in command prompt. If you see unexpanded %SystemRoot% and other variables in Path, you are affected (PATH should show only plain directory names, not variables).
You need to edit Path variable in registry: HKEY_CURRENT_USER\Environment and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. As it is not possible to change the type of key, save the path value somewhere, delete the key and re-create it with type REG_EXPAND_SZ. You need to logout for changes to take effect.
for me it works when I've coped findstr(from windows/system32) to wildfly/bin
Please go throught the simplest steps:-
go to C:\Windows\system32\ and copy findstr.exe file.
paste this file into the location C:\Program Files\Java\jdk1.6.0_24\bin
Run your jboss again you will get out of this.....
Check to see if you %SystemRoot% is evaluating (type set path into a command prompt, you should not see %SystemRoot%, but instead that actual path). If your path variable's (user, or systems) first entry begins with an %(an environment variable) this can cause an issue.
To resolve this, simply swap this first entry with anything else in your path that does not lead with an environment variable.
You can also hard code the directory by replacing 'findstr' with 'C:\Windows\system32\findstr'. This is useful when using systems with restricted user permissions.
I have try to work with play framework but stuck with to run activator.bat file but solution is the same just copy file from windows/system32/findsr and past it to under stuck folder then run the respective file again.
thanks to andrewsiand Suryaprakash
Please beware that current Windows systems use a Capital "S" for the System directory, so:
C:\WINDOWS\System32
%SystemRoot%\System32
Omitting the capital S will result in a neglect of the line in the %PATH%
In my case (not JBoss related) the following helped to fixed this error.
Instead of:
SET path="%path%;C:\some\additional\path"
I used:
SET "path=%path%;C:\some\additional\path"
For IBM ACE solution for
'findstr' is not recognized as an internal or external command,
Go to the path C:\Windows\System32
Find the findstr.exe, copy it and then find the path where you bin file of your application is found. eg C:\Program Files\IBM\ACE\11.0.0.12\server\bin then past it inside the bin file
cancel the console of ace and re-open it.
Then run ACE toolkit command on ace console.
Then press enter, now it can open.