Jump to content
We've recently updated our Privacy Statement, available here ×

bdmayes

Members
  • Posts

    15
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

bdmayes's Achievements

Apprentice

Apprentice (3/14)

  • Week One Done
  • One Month Later
  • One Year In
  • First Post Rare
  • Collaborator Rare

Recent Badges

0

Reputation

  1. Hi all, I'm trying to get JasperServer 5.0.1 to connect to AD for authentication. I have followed what is in the authentication cookbook and the following (really good) post: http://fcosfc.wordpress.com/2011/10/31/jasperserver-user-authentication-with-microsoft-active-directory/ After fixing a typo in applicationContext-security.xml I was finally able to get the server to start again. I can still login with the predefined roles (jasperadmin for example), but cannot login using my AD account credentials. Every time I try I get the following message: Invalid credentials supplied. Could not login to JasperReports Server. I have verified that all of the information is correct using ldapsearch (that is, the command will correctly return information for the user I search for). Is there something else I need to do on JasperServer to make this work? Do I need to create a role for myself there and somehow? That doesn't seem logical because it prompts me for a password and I shouldn't need one since it's an LDAP account and not a local account to JasperServer. Here is my ldapsearch syntax which works fine: $ ldapsearch -x -LLL -E pr=200/noprompt -h aadc02.mycompany.com -D 'cn=ssotest,ou=People,dc=mycompany,dc=com' -w 'mypassword' -b 'ou=People,dc=mycompany,dc=com' "(sAMAccountName=bmayes)" And now here are the relevant beans from applicationContext-security.xml. I have highlighted a few questionable lines with comments below. Sorry, I don't know how to get this new layout to ignore the XML tags and display it all as text so I just took a screenshot. The cookbook and the link above both use "cn=Users" in their userSearch bean but I don't think that applies to my environment. I tried setting it and restarting the app in Tomcat but I get the same invalid credentials command with that value so it's clearly not the problem. So I guess it's not supposed to be "cn=Users" for my environment, nor is it the search base that works in the ldapsearch command ("ou=People,dc=mycompany,dc=com"). Any ideas how to find out what the 2 values commented above should be? Please keep in mind I'm a Java developer and not an LDAP/AD guru so you may need to talk to me as if I were a 5 year old (and then I'll relay any questions I can't answer to our IT folks). In fact, about the only thing I know how to do with LDAP is perform the ldapsearch command to test that it's working. Thanks!
  2. I would recommend 2 things: 1. Make SURE you are using iReport to export the fonts into a jar file. I have found that even if I create the same directory structure manually that it does not work. To do this in iReport you need to : - Go to Tools > Options > iReport > Fonts - click on the "install font" button and go through the wizard - click on the "export as extension" button - include the resulting jar file into the CLASSPATH of your Java application 2. I noticed you have specified the pdfEncoding and pdfEmbedded attributes. Maybe try and remove those attributes because they are deprecated as of version 3.7.2 or maybe it was 3.7.6? In any case, they should no longer be used if you're on 4.1.2 so you might try leaving those fields blank and see if that resolves the issue.
  3. I'm having a very strange issue with some Jasper reports (library version 4.0.0) for one particular client. I'm not sure if it's a database encoding issue at the moment or what. But here is what I know: 1. We allow users to upload Jasper reports through our application. Essentially, we store the JRXML as a CLOB in a database table, and then we also invoke JasperCompileManager.compileReportToStream() and store its output (the compiled report as bytecode) into a BLOB field. 2. Some reports are working great and others are just showing empty data. Both working and broken reports are using a SQL query against the exact same database (same schema in Oracle with the same connection info). When we are constructing the report we just pull the BLOB data out of the table and load it into an InputStream object named in. Then we simply do this: jasperReport = (JasperReport) JRLoader.loadObject(in); This object named jasperReport is what we pass to the JasperFillManager (along with the arguments map and a connection to the database): JasperPrint jasperPrint; try { jasperPrint = JasperFillManager.fillReport(jasperReport, argsMap, dl.getConnection()); } So the really strange thing is that some reports return data, while others do not. Yet if I load up the JRXML in iReport and preview it then all reports work. So it seems like something we are doing wrong but I cannot determine what. I stepped through the 4.0.0 source code and here is what I can say: - Inside of JRVerticalFiller.fillReport() I can see that the call to the next() method returns false. It therefore drops us into the else section and inside of the switch statement we match on case NO_PAGES. - If I step into the creation of the datasets (specifically in JRBaseFiller.createDatasets() method) I see that jasperReport.getDatasets() returns null. This seems to be true for both a working report and a failing report, so maybe this is not important. - During the call to JRVerticalFiller.fillReport() I can inspect the mainDataset instance variable and see that the fieldsMap attribute of it is properly populated. It has 12 fields in it -- exactly the number of columns being selected by the SQL query inside of the JRXML file. This baffles me because it means that Jasper was clearly able to obtain the ResultSet metadata for this SQL query, but still there are no rows. It's almost like it ran the query with WHERE 1=2 so that no rows were returned (but it still got the metadata). - The SQL query in the JRXML has a single parameter in it (which I see is properly passed into the argsMaps object when we invoke the JasperFillManager). If I copy/paste the query into SQLDeveloper and then replace the parameter with an actual value, I get 8 rows of data back. It should absolutely returns rows -- and clearly since the report works in iReport (and we can run the query manually and get rows) we know that it does. - Several of the broken reports contain subreports but I have tested other reports that include subreports and found several that work fine...so having subreports is not the cause. If anyone has a clue what might be causing this I am all ears. I will keep stepping through code when I can but this something I need to get resolved ASAP. Thanks!
  4. Hi all, We have a Gantt chart in my software that we allow users to print. The chart itself is all div tags in HTML (which allows interaction with the object), but when the user prints the chart from our web application, we generate a Jasper report and return it to them in PDF format. Essentially, when the print option is invoked I assign a page number to each row in a table (10 rows per page), and then dynamically generate a report that includes the appropriate number of calls to subreports. The subreports are all the exact same report (with a Gantt chart in it) but it accepts a parameter that is the current page number -- thus they all display up to 10 different rows. This is working great for our scheduling functionality -- across the top (X-axis) we show dates and on the Y-axis we have it showing work order numbers. The problem comes when I attempt to modify this and use something other than dates across the X-axis, for example, mile markers on a stretch of road. I modified the code to appropriately change the SQL query used and the datatypes of the fields from java.sql.Timestamp to java.lang.String. I have tested the queries in Oracle and they run just fine. The report itself even compiles without error both in iReport and when using JasperCompileManager.compileReportToStream(). But for some reason the report blows up and throws this error at runtime (note this is jasperreports-4.0.0): java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Date at net.sf.jasperreports.engine.fill.DefaultChartTheme.setAxisBounds(DefaultChartTheme.java:2025) at net.sf.jasperreports.engine.fill.DefaultChartTheme.configureAxis(DefaultChartTheme.java:571) at net.sf.jasperreports.engine.fill.DefaultChartTheme.createGanttChart(DefaultChartTheme.java:1581) at net.sf.jasperreports.engine.fill.DefaultChartTheme.createChart(DefaultChartTheme.java:310) at net.sf.jasperreports.engine.fill.JRFillChart.evaluateChart(JRFillChart.java:1338) at net.sf.jasperreports.engine.fill.JRFillChart.evaluateRenderer(JRFillChart.java:1305) at net.sf.jasperreports.engine.fill.JRFillChart.evaluate(JRFillChart.java:1294) at net.sf.jasperreports.engine.fill.JRFillElementContainer.evaluate(JRFillElementContainer.java:258) at net.sf.jasperreports.engine.fill.JRFillBand.evaluate(JRFillBand.java:499) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillSummaryNoLastFooterSamePage(JRVerticalFiller.java:1072) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillSummary(JRVerticalFiller.java:1037) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportEnd(JRVerticalFiller.java:301) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:135) at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:946) at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:845) at net.sf.jasperreports.engine.fill.JRFillSubreport.fillSubreport(JRFillSubreport.java:609) at net.sf.jasperreports.engine.fill.JRSubreportRunnable.run(JRSubreportRunnable.java:59) at net.sf.jasperreports.engine.fill.JRThreadSubreportRunner.run(JRThreadSubreportRunner.java:205) at java.lang.Thread.run(Thread.java:662) If I look at the DefaultChartTheme.setAxisBounds() method, it appears that the axis object is an instance of DateAxis so it attempts to call setMinimumDate() -- and this is where the error occurs. My label is a String and not a Date object. I looked in the JRXML and it appears that it is pulling these values from the <startDateExpression> and <endDateExpression> tags: <startDateExpression><![CDATA[$F{START_DATE}]]></startDateExpression> <endDateExpression><![CDATA[$F{END_DATE}]]></endDateExpression> Thus, I have tried a few things that all failed: 1. I tried populating them with sysdate in my SQL query (this is Oracle): select ... sysdate AS START_DATE, sysdate AS END_DATE, ... 2. I noticed in iReport that the fields appeared to be optional when defining a Gantt chart so I tried leaving the expressions out. 3. I tried putting the tags back but not defining any value: <startDateExpression></startDateExpression> <endDateExpression></endDateExpression> Is there any way to render a Gantt chart without defining the value axis in terms of dates? It appears that the DefaultChartTheme.setAxisBounds() method can accept an Axis that is NOT an instance of DateAxis (in which case it assumes they are numbers and I could just wrap the columns with a call to TO_NUMBER() in my query). How do I force the Gantt chart to interpret my data this way instead of thinking the value axis is using Date objects? Is it even possible? Post Edited by bdmayes at 02/23/2012 15:41
  5. Thanks for the reply -- unfortunately it is not quite what I am looking for. What you suggested will change the default font used when the .jrxml files are written by iReport. This affects the fonts that appear in the reports themselves (as seen in the "Preview" functionality, or as seen in a report rendered by the JasperReports engine itself). I am looking to change the look and feel of iReport itself. I'm pretty sure this isn't possible but I thought I would ask anyway.
  6. Hi everyone, I run Ubuntu at work and am using iReport more and more often. A while back I installed iReport on a Windows VM, but I have since download the tar.gz file on my host machine and it works great. My only complaint about it, is that the font used by iReport is quite ugly. I'm pretty certain it is pulling the Ubuntu font (since that is the default for my system) but the size is huge. See the attached fonts.png. Is there any way to control this and change it to another font, or at least change the size? Note that this is the font used by the text in iReport itself. I am *NOT* referring to font extensions (a jar file containg .ttf files that is put in the classpath of the JVM running the JasperReports engine). Thanks!
  7. uhurusurfa Wrote: Not sure what your issue was/is but possibly it is the empty string for the attribute ..... Yes, I mention that this was definitely an issue in my original post. I'm pretty confident that my two posts above thoroughly address the issue, but there is one piece of the puzzle that was missing until recently. I mentioned before that things worked at 3.7.2 but not when I created the jar file for 4.0.0. As it turns out, the jar file was never being used in the 3.7.2 release either. We always assumed it was but in reality what was happening was that it was using a font from the file system, and NOT the .ttf file packaged in the jar. I found this out month or so back while diagnosing yet another font problem. So in reality I think what was happening was that the 4.0 version was much stricter with the font, looking for it ONLY in the classpath where it was never found. It seemed like the 3.7.2 version was using the jar file in the class path but it turns out that it was actually finding the font on the local filesystem. So here is the bottom line: USE IREPORT TO GENERATE YOUR FONT EXTENSIONS! If I create the directory structure and package it up with the jar command manually it fails, regardless of which format/tutorial I follow (which includes the tutorial in the ultimate guide -- as I mentioned before even Jaspersoft support/dev couldn't explain why it didn't work). Generating the jar file using iReport seems to be the only way that the JVM can locate the font definitions in the classpath. I have now generated 2 different jar files this way and both of them have worked on every system in every scenario I have thrown at them. The only time it doesn't work is when it fails to find a font like Garamond or Calibri, but those are fonts that are not supported by default (like the DejaVu fonts), and are not packaged up in our font extension. So I expect them to fail. After running into these issues I simply added to our product documentation a list of supported fonts. If any user strays from that list and has problems we can simply direct them to the documention that says you shouldn't have used that font, and if you insist on using it then you will have to create your own font extension in iReport and add it to the classpath yourself. Thanks to lawyers and so on, we don't have the rights to redistribute anything except for open source fonts. ;)
  8. Awesome!! Thank you very much...that explains a lot! It's almost like both topics and domains are the same but topics have to be created in iReport (and are therefore a canned query in the form of a jrxml file) while domains are created in Jasper Server directly and can include joins and so forth. I guess you could technically do a join in the jrxml file as well, and then expose those values as fields but then you're doing it all manually. In any case, hooray I finally get it! :)
  9. Thank you for the reply -- it definitely helps. I am still a little confused about what you refer to as jrxml topics however. You said that "An iReport user creates this Topic as an empty JRXML file." ... How empty of a file are we talking about here? You mean empty in the sense that there are no queries (SELECT statements), or do you mean truly empty? It can't be entirely empty because then it would be completely pointless and unnecessary. So I guess I'm just wondering if you can clarify what you mean by empty. If I define some fields inside of the bands and add some variables and/or parameters, is that considered empty? Perhaps as soon as I tie it to a data source and define queries it is no longer empty?
  10. Hi everyone, I have taken the Jaspersoft technical training (4 day course) but one thing I am curious about is how to create topics and domains. In the training course, we could easily create ad-hoc reports and dashboards by selecting a topic/domain that already existed in the training environment. Of course on my own server, these topics and domains do not exist. I see where to create domains (from the main menu it's just create > domain) but I don't know that I fully understand it. A domain is basically just a data source? So let's say I create a domain and connect it to a database then the "domain" is just essentially a JDBC connection...is that correct? Also, how do I create topics? I obviously found it once before because I have a topic saved, but if I remember correctly it just basically allows me to select a report to connect to the topic. So I guess my questions are: 1. What is a topic? 2. How do I create a topic? 3. Is it the case that a topic is always controlled by/connected to a jrxml file? 4. Do I have the correct idea about domains? I'm sorry but I have tried looking through documentation, the ultimate guide, and my training materials but I cannot figure out the answers to these questions. Thanks!
  11. Yeah I had to contact Jaspersoft support about this issue. I did exactly the same thing you did (change the empty strings to a valid font name). Unfortunately, then it complained that those fonts (Arial, Times New Roman, etc.) didn't exist. After 2 different tickets and weeks of digging we basically discovered the following: 1. The jasperreports-fonts.jar we had previously created wasn't being parsed for some reason. Jaspersoft support looked at it and claimed that it was syntactically valid and should work, but suggested that I follow a second format for the jar file as described in the JasperReports ultimate guide (specifically the "Simple Font Extension Tutorial"). 2. I followed the tutorial in the ultimate guide (and had to add a few jars from the Spring framework to my classpath) and things still didn't work. I sent them the jar and they said that it was syntactically valid and should work, but must not be in my classpath (even though it was in the same WEB-INF/lib directory with all of the other jars). I went back and forth with support about whether or not my jar file was in the classpath (sending them Tomcat documention, and eventually putting Java classes in there that were found and run) before they finally accepted that my jar file was in the classpath. 3. Support finally suggested that I add the fonts in iReport and use iReport to generate the font extension jar file. This finally worked, even though it is almost syntatically identical to the original jar file we had (see item 1 above). So I can't say why things didn't work with valid jar files, but generating the extension through iReport resolved the issue. It looks exactly the same as the one I created and packaged up manually (except instead of calling the file fonts.xml they call it fonts.xmlNNNNNNN where NNNNNNN is some random number), but for whatever reason it works and the manual jar files do not. Once I finally got that resolved with support I just wrote some code to pull out each jrxml file from our database, parse it line by line and fix any invalid font issues, compile it, and then save the new jrxml file along with the compiled bytecode back to our database. Now I don't have any more font issues (unless someone uses a font that isn't inside the jar file -- which is their problem not mine). Ridiculous but it finally all works and we have migrated to the 4.0.0 version of JasperReports. Post Edited by bdmayes at 05/24/2011 18:19
  12. Hi everyone, I'm having a problem with some reports after upgrading the JasperReports engine from 3.7.2 to 4.0.0. On several reports I encounter the following error: Font '' is not available to the JVM. See the Javadoc for more details. I have tried recompiling these with the 4.0.0 version of the engine (as well as iReport) but it doesn't seem to do any good. I don't really want to use the net.sf.jasperreports.awt.ignore.missing.font parameter if I don't have to (and found one post cached on google that suggests setting it didn't help). The issue really seems to be malformed XML. After digging through the jrxml files for the report, I found that some of the subreports defined blank fonts like this: <font fontName="" size="10" isBold="true" pdfFontName="Arial"/> If I define a name there and change it to something like: <font fontName="Arial" size="10" isBold="true" pdfFontName="Arial"/> then everything works just fine. The problem is that I have to change every reference in every file...which when including subreports can hundreds of files per client (of which we have many)!! I'm not going to manually go and edit thousands of files. Furthermore, it seems like the jasperreports-4.0.0.jar does not work unless you explicitly define the fontName item somewhere in the <font> tag. If the tags just define something like the following: <font size="11"/> or <font pdfFontName="Helvetica-Bold" isBold="true"/> Then the 4.0.0 engine cannot render them properly (complains about missing font '') while the 3.7.2 engine renders the reports just fine. This is odd and seems quite backwards to me since the pdf font and other font properties in the latest version of iReport show that these font properties are deprecated. Even iReport 3.7.2 lists them as deprecated yet they still render fine in the 3.7.2 engine. So far the only way that I have found to fix these issues is to manually go and edit each and every font tag and add something like fontName="Arial" to the tag. It seems like the 4.0.0 is looking for an explicit font definition and if it doesn't find it then it return empty string as the font, which ultimately throws the exception since there is no such font named empty string. Is this a bug with the 4.0.0 version of the engine? Seems like a regression since the 3.7.2 jar file render the reports just fine but the 4.0.0 version fails. Any thoughts? Post Edited by bdmayes at 03/23/2011 18:53 Post Edited by bdmayes at 03/23/2011 18:55
  13. Ok I have made some progress. I wrote a simple test class and finally sorted through all of the jar files that needed to be in CLASSPATH to execute...after calling compileReportToStream() I found that the 3.7.2 version of the jar and 4.0.0 version of the jar did indeed generate different bytecode. So that answers that question. I am 99% certain that the jrxml files do not change format via the compilation button in iReport. In fact, that makes sense -- the xml *shouldn't* change unless the user explicitly add a new variable/parameter/field, changes the properties of something, adds a band, etc. So I think I'm good to go here unless anyone has anything further to add. I still have problems with the font stuff not working correctly but the JasperReports forum seems like a better place for that.
  14. Ok so I guess the problem isn't necessarily when JasperServer is upgraded, but the actual Jasper engine itself (which I assume is included in JasperServer). Specifically, we are upgrading the jasperreports-3.7.2.jar to jasperreports-4.0.0.jar. We recently purchased a professional license but at the moment have not integrated JasperServer... I'm not sure that my question was really answered, though I think it was. You said that the .jrxml files have "fantastic compatibility with later releases of JasperReports" but that doesn't seem to be the case, unless it's actually our bytecode that is the problem. So right now we do this: 1. upgrade the Jasper engine in our app 2. login and notice that many Jasper reports are not working 3. download the newer version of iReport (which matches the upgraded version of the engine from step 1) 4. download the .jrxml file from our server and then compile it with the latest version of iReport 5. upload the .jrxml file back to the server (throwing away the .jasper file as we compile the code anyway when the .jrxml file is uploaded) If what you're saying is correct, then recompiling in iReport (step 4) is essentially pointless -- all we really need to do is to call JasperCompileManager.compileReportToStream() and save away that new bytecode (e.g. the .jrxml file isn't really changing format at any time). If so then it seems that given the exact same input file (.jrxml) the 3.7.2 engine can/may generate different bytecode inside of compileReportToStream() than the 4.0.0 version will. Is that correct? If so it makes my life easy since the only thing we would have to do is loop through each row in the table, pull out the XML code, compile it with the JasperCompileManager class, and then save it back into the BLOB in the same row. Any additional thoughts?
  15. I am working on Jasper reports for my company's application and am in the process of upgrading the engine from 3.7.2 to 4.0.0. I swapped out the jar files and re-built everything and several reports worked fine. Others threw NullPointerExceptions and some of them even gave me errors such as "Font '' is not available to the JVM. See the Javadoc for more details." The NullPointerExceptions seem to be resolved by downloading the .jrxml file, compiling it the newer version of iReport, and then uploading the .jrxml file again (I can only assume that this process somehow modifies the .jrxml file to conform to the specs for the latest version of Jasper). The second issue was more complex and involved some malformed XML inside of the .jrxml files themselves, even after recompiling the reports. Specifically, the lines would specify a font with the empty string like this: <font fontName="" pdfFontName="Arial" size="10" isBold="true"/> I had to manually edit all the problematic files and change them such that some font was specified. For example: <font fontName="Arial" pdfFontName="Arial" size="10" isBold="true"/> Problems with malformed XML aside, it seems that reports compiled in an older version of iReport do not always play nicely when using the latest Jasper engine (I found numerous forum posts where people were instructed to recompile the .jrxml file in the latest version of iReport). Apparently recompiling is a fairly common task, and my understanding is that when this process is done, the XML file is updated to the format that this new version of iReport uses (and ultimately what the new version of the engine requires). This process is fine if you only have a few reports, but we have hundreds of reports, and most of them have several subreports. It's a pain to recompile all of these manually. As I mentioned before, the fix when we upgrade the Jasper engine is generally to download the .jrxml file from our server, recompile it in the new iReport (in this case I'm using 4.0.1 and the jasperreports-4.0.0.jar file), and then overwrite the existing file on the server with the new .jrxml. Oddly enough the bytecode (.jasper file) can be ignored -- uploading the .jrxml file is sufficient. After doing some research it turns out that the reason that uploading the .jrxml file alone is sufficient is because we actually store the uploaded XML in our database as well as call the JasperCompileManager.compileReportToStream() method inside of the Jasper engine. The resulting bytecode is then stored in a BLOB column in our database. My questions are therefore: 1. When are the .jrxml files updated? Clearly something in them changes just by opening them in iReport and recompiling and I don't even have to click save. So is it the compilation process that updates the .jrxml files or does it happen when the report is first opened by iReport? 2. If changes to the .jrxml file do NOT occur during compilation then is there some way to pass XML into a method and receive the newly updated version of it? Ultimately I would like to create a job that will automatically loop through all .jrxml files, update them, and then recompile them with the latest version. I can then write the updated XML and updated bytecode back to the table in our DB. I know that they can be recompiled by calling JasperCompileManager.compileReportToStream() but I don't know if that process also updates the .jrxml file or if there is some other method that can be called to perform that process. If anybody knows I would greatly appreciate the answer! :) Post Edited by bdmayes at 03/22/2011 21:08
×
×
  • Create New...