iReport – Plain Text Passwords

iReport — Jeff Eske on October 29, 2012 at 3:06 pm

Everyone already (should) know that iReport will save your connection passwords in plain-text.  Depending on your level of paranoia, this may or may not be an issue.  If you’re not paranoid and you save the connection passwords, it can come in handy.  I needed to setup connections on a second computer and didn’t have the connection passwords.  Everything was already setup on my other machine, so I was able to actually just go in and find the password that I couldn’t remember and just copy/paste it into my connection on the other machine.  Voila! Problem solved.

If you need to find the connection password(s), they’re saved in a file named ireport.properties in each user’s own .iReport folder.  In Windows 7, my ireport.properties file was at: C:\Users\my user profile\.ireport\4.x.x\config\Preferences\com\jaspersoft\ireport.properties.  I simply opened it in a text editor and searched for password.  I then copied and pasted it in to my new connection.

Jeff Eske

iReport – Classpath and Importing Settings

iReport — Jeff Eske on October 22, 2012 at 2:47 pm

I found that you need to be careful when updating iReport.  When you install, it picks a new folder by default.  This is kind of nice in that you can have multiple copies of iReport on your machine.  When you open iReport, it will even let you know that if found previous installs and volunteers to import the setting for you.

Well, importing settings sounds good, but you need to be careful.  I went ahead and gave it a try, just out of curiosity.  I have a few extra .jar files that I’ve added, to enable access to various databases.  I covered how to get the jtdc jar file added to the classpath in a previous post.  I wanted to see how importing settings affected those .jar files.  I was curious if importing settings only imported settings, or if it would actually copy over the jar files, etc.  Well, it simply copies over the classpath information, not the resources that are pointed to in the classpath.

I assume that if you create a generic iReport directory and always install new version there, overwriting the previous install, you won’t encounter any issues.  If instead, you create a new folder for each version, you need to be careful about your classpath references.  You can end up with classpath references to previous iReport folders and if you rename/remove those iReport folders, you then break your current install.

Something to think about.

Jeff Eske

iReport – Adding jdkhome reference on a Windows machine

General — Jeff Eske on October 22, 2012 at 2:10 pm

I was running into problems while trying to install plugins in iReport.  Some of the plugins were complaining that they needed the Java JDK.

Here’s the error screen I got:

Basically, it says, “Some of the selected plugins require the JDK in order to function.  Currently, NetBeans IDE appears to be running with the JRE instead of the full JDK.  To use these plugins, start IDE with the –jdkhome command line option set to the location of a JDK installation”.

OK, that made sense; I had gone out and downloaded and installed the Java JRE only.  I went back out and downloaded and re-installed Java with the JDK.  Back I go to iReport to try downloading and installing the the iReport Plugins again.  Same thing happens.  Well, first I spent some time trying to figure out how to add the jdkhome parameter to my shortcut.  No luck.

After some searching, I found that the solution was pretty simple.   There’s already a commented spot to add the jdkhome reference in the ireport.conf file.  By simply updating that with the path to where my JDK ended up, I was able to solve the problem.

In my Windows 7 installation, the ireport.conf file is located at: C:\Program Files\Jaspersoft\iReport-x.x.x\etc\ireport.conf,  where x.x.x is the installed version number.  So in the ireport.conf file, I simply uncommented the jdkhome reference and added my path (see below).

The actual path to JDK on my machine – C:\glassfish3\jdk7\

[ireport.conf]
# default location of JDK/JRE, can be overridden by using –jdkhome <dir> switch
jdkhome=”c:/glassfish3/jdk7″
[/ireport.conf]

After that, iReport started fine and I was able to add the plugins with no problem.

I also learned, when I went to do this entry, that if you have installed plugins that require the JDK, then lose the JDK reference (by commenting it back out, in my instance) you will get a very similar error message when starting iReport.  You can see the error below:

Basically, it says, “The JDK is missing and is required to run some of the the NetBeans modules.  Please use the –jdkhome command line option to specify a JDK installation”.  It’s basically the same error as above, except that it lets you disable the plugins/modules and still start iReport.  Chances are, if you get this message something has happened to your JDK installation.

Jeff Eske

 

OTRS – “EOF – End of data in parsing input stream” Error When Importing to CMDB

OTRS — Jeff Eske on October 2, 2012 at 2:30 pm

I’ve started into the process of automatically importing a data dump of CI information from LANDesk.  In the near future,  I’ll create a step-by-step tutorial on how to set all of that up, but for now I want to address the “EOF – End of data in parsing input stream” error.  It appears that the error is related to how the Text::CSV_XS perl module handles reading data from at least SOME text files.  That module isn’t necessary for the .csv importing to work; it evidently just speeds up processing.  I solved the issue by simply deleting the Text::CSV_XS module.

What turned me on to that as the possible culprit was a post that I found somewhere on the Internets that indicated that Text::CSV_XS can have problems seeing the end of files.  There’s also a note on the TEXT::CSV_XS cpan page (http://search.cpan.org/~hmbrand/Text-CSV_XS-0.91/CSV_XS.pm) that indicates that there can be a problem.  I’ve also seen indications that it may be related to file encoding also, so I’ll test that and see.

UPDATE:  I re-installed Text::CSV_XS and tried various different document encodings with the same “EOF” error.

Jeff Eske

 

 

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. | Jeff's Blog