Best way to store JRPrint in DataBase

[ktrinad]

By: C-Box - c-box

Best way to store JRPrint in DataBase

2004-09-03 05:43

Hi,

 

I've a problem (again) :-)

 

I want to save the filled reports for future "recall" ... as a kind of "evidence/reprint-archive". I can't use the save-method that saves the files directly to filesystem as PDF or any other format because I work on JBoss and I have to realign it a bit, if it doesn't fit on preprinted business-paper. (therefore I posted already a FeatureRequest see here http://sourceforge.net/tracker/index.php?func=detail&aid=949111&group_id=36382&atid=416706).

 

So I do now save the JasperPrint-Object that is filled with the fill-method to an outputstream. That stream is stored in my database.

 

Now the problem. Is it for sure, that any later release of JasperReports (now I still use 0.5.3 because of the stable version of IReport 0.3.2) can open that stream again into a JasperPrint-Object?

 

So it must be sure that for instance JasperReports 1.5 in two years still can open the reports I filled today with version 0.5.3.

 

It's more a question to Teodor I guess, but perhaps any other as also an idea if there is another solution for my purpose.

 

And again, PDF-Stream is just an "emergency-solution" - because there I can't change the global OffSetX and OffSetY like I posted in RFE (http://sourceforge.net/tracker/index.php?func=detail&aid=949111&group_id=36382&atid=416706).

 

tia

C-Box

 

 

By: Daren O - rckrll106

RE: Best way to store JRPrint in DataBase

2004-09-07 08:45

I was thinking about saving JasperPrint objects to file for later reference. Therefore, I'm also curious how this would work.

 

I assuming since JasperPrint has a serialVersionUID that you could not open older jasper files.

 

I would definately prefer storing JasperPrint objects compared to pdf's. There are many benefits on using the object compared to pdf.

 

- Pdf's are not exact and can distort reports which is a problem when your printing on mail labels or preprinted forms etc... (exact reports)

- Viewing pdf's in an application becomes a little more difficult than using the JasperViewer (easy of viewing)

- You also have the option to export to different formats if you have the JasperPrint object (flexability).

- etc...

 

This is a limitation of Jasper I didn't think of. C-box I'm glad you brought this point up.

 

I'm curious if there is a work around or fix (besides using pdf's)?

 

 

 

By: Ethan Kayes - ebkayes

RE: Best way to store JRPrint in DataBase

2004-09-23 08:02

If I understand your problem corectly you wish to save the byte array output of Jasper (PDF) to a RDMS. In addition you wish to retrieve this information back to a browser using the correct MIME type.

 

We accomplish this by inserting the byte array output in a BLOB on our RDMS.

We then use a JSP to retieve this infromation back to the end user on request.

 

Security constrants in our enviornment pervent our firm from stroring personal information outside an RDMS.

 

I can supply a sample of this code on request.

 

 

By: Daren O - rckrll106

RE: Best way to store JRPrint in DataBase

2004-09-23 09:11

Well I think what you(ebkayes) meantioned in your message might have been part of c-box's question but not the main question.

 

The question he raised and I'm concerned with as well is that if you saved the JRPrint object to the db (or to file) then when future version changes occur how can you read the old JRPrint objects.

 

Now, pdf's is a way to get around the JRPrint object (storing, version)issue. However there are many draw backs to using pdf's compared to JRPrint objects (see my old post). Also, what use is the viewer(to the many of us that use it) on the client side if you don't have JRPrint objects.

 

The way I see it is you either go with pdf's and loose jasper functionality or you stick with JRPrint objects and have version issues.

 

I'd like to hear some feedback if there is a solution. Also, would like to hear from Teodord and hear his thoughts.

 

This has kinda been haunting me and how we handle reports.

 

 

By: Edgar Dollin - edollin

RE: Best way to store JRPrint in DataBase

2004-09-23 10:22

While this is not the same issue, there is a version sensitivity problem in the compilation process as well. If there are slight build differences in customer java libraries referenced in the jasper xml, the file will not compile.

 

In my opinion, the system would be better off issuing warnings for version variances, rather than failures. If the features used in a version still function, let the report run with a warning. If it actually fails due to changed signatures, etc, then it fails and you would get the appropriate java error.

 

Edgar

 

 

By: Daren O - rckrll106

RE: Best way to store JRPrint in DataBase

2004-09-23 11:10

I believe that there is some tools that help with the compiling version issue. IReport has the masive compiler. Will this help with all versioning issues? NO!!!

 

I see the compiling issue more as an annoyance but something that can be worked around.

 

However, I agree that would be handy to be able to compile with warnings instead of errors.

 

Although with jasper constantly changing (for the good I might say) I'm not sure allowing warnings would be a good idea. More complex logic would have to be introduced (I believe) to code for missing tags (to be processed at run time). I wouldn't want to hold back jasper's progress with new features to be bogged down with more complexities.

 

I agree that there needs to be some kind of solution with the version issues, but what would be the best solution.

 

It would be nice to have a converter of some type that would help in all of these areas. It this possible?? Just an idea??!!

 

 

By: Chuck Deal - cdeal

RE: Best way to store JRPrint in DataBase

2004-09-23 11:47

Since the first time I read this message, I have been trying to think of a good solution. Here is what I have come up with:

 

Consider any popular Word Processing application. It is capable of opening any of its previous file formats as well as its current format. Most are restricted to writing only in their current format.

 

Following this idea, Jasper should be able to open previous versions of the files that it reads (*.jrxml, *.jasper, *.jrprint, etc). To ease things a bit, I would say that it only has to write the files in the latest format.

 

But how? Mind you, I have zero experience with this, it is just a brainstorm...

(I will be using only the object JRPrint for the purposes of discussion, but the concept would need to be applied to the JRDesign object as well)

 

Instead of modifying the JRPrint object with each release of Jasper, it would have a different JRPrint class with every release (every release that changes the object's structure). The class would have the variables and methods necessary for that version of the JRPrint object.

 

The XML would probably need a new attribute on the Report tag that specifies the JasperReports version used to generate it. When the XML is read, it would use that attribute to determine which of the JRPrint classes to instantiate.

 

Now, if you are storing a JRPrint object in a database, then I imagine that you are serializing it. This means that the version of Jasper used to produce that object would be preserved as well. Therefore, when you read your bytestream back into an object, even a newer version of Jasper would be able to read (and understand) it.

 

Now, I imagine a problem may come in when processing the objects. Since at this time we only have one filler, viewer, etc which is coded for the latest version.

 

One solution would be to have a generic fill process which at key points would call a helper class that is specific to a particular version of Jasper. So, we would have one MasterFiller class and a number of FillerHelper classes.

 

A second solution might be to have a JasperReportInfo Interface that had properties on it to describe features that can be used. For example, one method could be:

boolean supportsLastPageFooter();

Then each version of Jasper would need to include a new implementation of this interface with the appropriate values. The fill process or viewer could then use this interface to help it make critical decisions.

 

I know that there is a lot here, but I felt it was about time to get my ideas out there. I haven't had the time to work out any real scenarios, but this might at least be a starting point. Please comment/critique my ideas at your leisure.

 

 

By: Doug Berkland - berkland

RE: Best way to store JRPrint in DataBase

2004-09-23 12:56

Has anyone tried using java.bean.XMLEncoder/XMLDecoder with JasperPrint objects?

 

From the javadoc:

<quote>

Portable and version resilient: they have no dependencies on the private implementation of any class and so, like Java source files, they may be exchanged between environments which may have different versions of some of the classes and between VMs from different vendors.

</quote>

 

If JasperPrint object makes a good round trip, this may be an option that avoids loosing all of the old reports in the database if you upgrade to a new version of JasperReports.

 

 

By: Daren O - rckrll106

RE: Best way to store JRPrint in DataBase

2004-09-23 14:10

I agree that storing the object that way would recreate it the exact same. However, wouldn't any kind of exporting, viewing, etc... be an issue if a version change occured. Meaning if a new tag is required in the JasperPrint object then you'd still have a problem working with it because the old restored object is missing that tag.

 

 

 

 

By: Doug Berkland - berkland

RE: Best way to store JRPrint in DataBase

2004-09-23 15:14

I think any properties that are new in a new version will end up having value a default value. In most cases this will be null. If the object contructor initializes any new fields with valid values that give the same behaviour as the previous version, I don't think will be any problem. I haven't tried it though, so this is purely conjecture.

 

 

By: Daren O - rckrll106

RE: Best way to store JRPrint in DataBase

2004-09-24 07:15

Doug when you think about the fact that when you upgrade Jasper each time you need recompile the xml files. If you don't then you get version errors when filling. From what I've seen many of the classes have a serial id which is compared.

 

private static final long serialVersionUID = 503;

 

I think we've all seen the errors when we use old compiled versions.

 

I'm pretty sure that this would be the same issue.

 

I think Chuck has some pretty good ideas (posted above) but I really don't have the experience to what needs to be done. I believe I'm on the same page. However, instead of creating many interfaces maybe having the fillers, exporters, etc... be able to handle older versions by checking the serialVersionUID?? So still have one class but have it flexible?

 

If that was possible, then you could still use older versions. Older reports would still work, print, export but just not be able to use the newer features.

 

Any thoughts?

 

 

By: Chuck Deal - cdeal

RE: Best way to store JRPrint in DataBase

2004-09-24 09:07

My reasoning behind having muliple classes was for modularity and maintainability. I HATE to see one class littered with if statements to handle changes such as this. This leads to spaghetti code.

 

On that same note, I would hate to have a specific filler for each report type. That would lead

 

The combination of a master filler object that delegates custom functionality to a helper class minimizes code duplication while still allowing for custom implemenation (or no implementation) of certain features.

 

 

By: Doug Berkland - berkland

RE: Best way to store JRPrint in DataBase

2004-09-24 15:18

Implementing Chuck's idea would require all future versions to use the same serialVersionID. I think it may also require custom readObject in some cases. This would allow versions on and after the serialVersionID freeze to be read in with future versions. This won't help with going from a previous version to the current one. I think we will probably run an upgrade process on our serialized reports using java.bean.XMLEncoder when we upgrade to the next version of JasperReports. From a quick look at the JasperPrint object heirarchy, it seems to expose all of its properties with public getters and setters. If this holds true throughout the heirarchy, this is the ideal scenario for the XMLBeanEncoder/Decoder.

 

(For JasperReport objects, I would still recompile after an upgrade. Actually we rebuild the .jasper files on every build, treating them like .class files.)

 

 

By: Teodor Danciu - teodord

RE: Best way to store JRPrint in DataBase

2004-09-25 06:37

 

Hi all,

 

One possible solution I'm considering is to freeze

the serialVersionUID in future releases.

 

Since XMLEncoder has been mentioned for storage

and upgrade, I want to point out that JasperReports

itslef has the capability of producing XML through

JRXmlWriter of report design objects and JRXmlExporter

for generated documents.

 

Thank you.

Teodor