Knowledge Base
Tech

Challenges in File Upload, synchronization repositories

November 12, 2017 by JRC

File sharing is an essential ever since Computers are in its being. Earlier days they were shared...

Continue reading
Card image cap
Tech

Linux desktop not openning after latest debian upgrade

May 01, 2018 by JB

That was a bad evening, I upgraded my debian box and X failed to start throwing below errors...

Continue reading
Card image cap
Tech

Jasper report integration with java

October 12, 2018 by TM

The JRXML templates (or JRXML files) in JasperReport are standard XML files, having an extension of .jrxml. All the JRXML files contain tag <jasperReport>, as root element...

Continue reading
Card image cap
Challenges in File Upload, synchronization repositories

File sharing is an essential ever since Computers are in its being. Earlier days they were shared through media e.g. cartridges, floppies or CDs. This partially exists through pen-drive today, however sharing over network is a common practice. WWW era started, more and more web applications evolved - each (or nearly each) of them has file upload/download need one way or other. These are achieved over browser and HTTP. It worked reliably for small and medium sized files and particularly with good connection. Now in 2018 the connection issues is majorly solved over most part of the world, web applications are working mostly reliably around this area. However there are still challenges when it comes to reliability and large files. And a repository with a huge number of files. We were engaged with a client who are offering solution to their user base all over the world solving their engineering design need. The design and analysis relies upon huge amount of data, often presented using a "project" - that is essentially a collection of directories and sub-directories containing number of large and small files. One thing to keep in mind, here "large" means >100GB often times. On a particular occasion it was needed to transfer entire VM of size 500GB - eventually that didn't happen as

  • There is no electronic way to achieve it over corporate web application and network.
  • Though client agreed to physically Fedex a DVD, but corporate IT policy and approval was a blockade.

Hence come the challenge

  • Can we do a file upload incrementally - tolerant to network failure?
  • can we sync a project that will discover and work on "delta" changes?

This is to be deployed for corporate users - so employing an agent on client machine is out of question. Fortunately HTML5 standards today allow browser to read files, split files, read directories at client side, even to split into pieces and send in many smaller chunks. Ajax is available for long and stable - so it comes to a matter of working on a algorithm. All modern browsers (FF, Chrome, Edge, bar IE) support HTML5 file/folder operations those are needed to make this work. We worked rigorously on this on designing efficient algorithm and implementation. Huge challenges were on its way, obviously, to make it work on all browsers through efficient file operation calls that will not slow down on client side. It was achieved. Once it worked, we stripped it out so that it is a pluggable component for other applications to use. No client installation, just drop the file on browser and it will track its own progress, guaranteed to complete over time bypassing any network failure or slowness. Keep project in sync is even faster, as that will discover delta (only the changed files) over subsequent sync operations.

X broken as drmSetMaster failed

That was a bad evening, I upgraded my debian box and X failed to start throwing below errors.

6017.269] (EE) modeset(0): drmSetMaster failed: Permission denied
[ 6017.269] (EE)
Fatal server error:
[ 6017.269] (EE) AddScreen/ScreenInit failed for driver 0

After spending hours I came to know latest X can’t run without root privilege now. We need to have legacy package of xserver to run X as non root user

sudo apt-get install xserver-xorg-legacy

then the wrapper config, so edit/create /etc/X11/Xwrapper.config to have the below two lines only.

allowed_users=console
needs_root_rights=yes

X is back, What a relief.

Jasper report integration with java

Design phase
JRXML templates(.jrxml file)
The JRXML templates (or JRXML files) in JasperReport are standard XML files, having an extension of .jrxml. All the JRXML files contain tag <jasperReport>, as root element.

Tools Use
iReport Designer
Eclipse Plugins(jaspersoft studio,jasper assistant)

Key fields/tags in jrxml report template
<queryString>
Usually contains the SQL statement, which retrieves the report result. Leave empty when we are passing data through java bean)
<field name>
This element is used to map data from data sources or queries, into report templates. name is re-used in the report body and is case-sensitive.
<fieldDescription>
This element maps the field name with the appropriate element in the XML file
<staticText>
This defines the static text that does not depend on any datasources, variables, parameters, or report expressions.
<textFieldExpression>
This defines the appearance of the result field.
$F{country}
This is a variable that contains the value of the result, a predefined field in the tag <field name>.
<band>
Bands contain the data, which is displayed in the report.

Compile Report
In this phase JasperReport template (JRXML file) compiled to JasperReport native binary format, called Jasper File. It will transform JasperDesign object into a JasperReport object.
Class used for compilation
JasperCompileManager
A static method called compileReportToFile responsible for compile the template to the jasper file.
e.g.
String sourceFileName="Payslip.jrxml";
JasperCompileManager.compileReportToFile(sourceFileName);
A file will be created with the name Payslip.jasper after compilation of Payslip.jrxml(template )

Execution Phase
In this phase the JASPER(.jasper) file fill with data and generate a print object(.jrprint) file.