Kevin Thorley wrote: > It seems that we are still not yet in the clear regarding Jasper > Reports. When I reviewed and tested the patch a couple weeks ago, I did > so on a new development environment that had been set up following the > wiki instructions. However, when I did one last sanity check on Friday > on my regular development environment, I got an exception when > generating reports. The exception was due to a java bad version number. > Somewhere, we had code compiled by Java 1.6, and I am running Java 1.5 > (which is what all sipXconfig code is supposed to work with). Anyways, > after much searching, it turns out that the offending code was not in a > Jasper dependency, but rather in the generated classes created from the > jasper reports themselves. It turns out that jasper was using the 1.6 > compiler on my machine to dynamically compile the reports, and this was > causing the issue. When I switched to the 1.5 compiler the problem went > away. Of course, if that was the end of the problem, I wouldn't be > writing this email :) > > The issue at hand is that Jasper's use of javac at runtime is not > acceptable, as we do not require target systems to be running a JDK > (Java SDK, or whatever else you'd like to call it). There are a few > ways around this, which I'll explain here, but the short story is that > in its current form, we can't take the Jasper patch. > > Option 1) Jasper can make use of several compilers. The situation that > I saw was that Jasper was invoking javac directly, by creating a new > process to handle the compilation of the reports (.jrxml). Jasper also > supports using the Eclipse JDT, which we could include as a dependency. > Eclipse JDT is available as an RPM (in Fedora repo, at least) and is > installable via yum. However, this is a 26MB package and, IMO, is far > too large and bloated to justify including it just to get at a Java > compiler. >
Alternatively we could add dependency on java-devel packages. We publish them on sipfpoundry.org already (sun version is around 17 MB). It's just that until now nothing in sipx required java compiler to be installed. What jasperreports is doing (searching for javac on system paths) is quite troubling: we cannot guarantee that what happened to you is not going to happen again on some non-standard configured system. > Option 2) We can precompile our pre-writtern jasper reports at build > time, eliminating the need for run-time compilation. This does have the > undesired side effect that admins will not be able to upload their own > reports, which we would need to compile at run time. There are ways > around this, such as providing a way for them to precompile the reports > and then upload them. If it was up to me, I would go with this option. I do not think that there is a big benefit in admins uploading the templates anyway. Current jasper patch doesn't provide any UI that would allow people to set reports parameter (right?), so uploading the templates is has a very limited application anyway. > > Option 3) Maybe a future version of Jasper will provide a more friendly > way to handle compilation. I have not checked into more recent versions > that the one we are currently using. > > So, there it is. Thoughts and/or suggestions? > > Kevin > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
