JASPER_STARTER_CLASS is hard coded in ProcessUtil
Description
Environment
Attachments
relates to
Activity
Diego Ruiz July 30, 2020 at 8:02 AM
Closing due to lack of interaction from the community in 5 years. The workaround still works.
Diego Ruiz June 18, 2015 at 6:43 AM
HI, thanks for replying.
I see a problem here and it's that in the AbstractProcessCtl class, when the classname of the report is different to the hard coded one, the report is run twice if it is successful, once by the line 234 "if (!startProcess())" which calls the new process class using the method you described above. And a second one by
if (isJasper)
{
m_pi.setReportingProcess(true);
m_pi.setClassName(ProcessUtil.JASPER_STARTER_CLASS);
startProcess();
.....
That second one it's always called through the standard because of the hard coded class name as you can see. It doesn't happen when you use the normal one because in line 219 the classname is set to null when is the standard Jasper class the one being used.
We managed to trick this behavior in two ways.
1 - In a different Jasper plugin, do everything what you say before using the name of the standard jasper class (org.adempiere.report.jasper.ReportStarter).
I tried to avoid that because my goal was to be able to use both plugins, and choose which one to use in which cases, not breaking any retro compatibility with previous Jaspers reports configured.
2 - Returning false in our own ReportStarter class when everything success, so I can trick the AbstractProcessCtl to not duplicate the call by entering into the if (!startProcess()) { unlock(); return; } segment. It works like that but it is really strange to return false when everything works, and I don't think that's a clean code to share with a lot of people.
In any case I still think that the hard coded classes are not a good way to let idempiere to be "plugable" as it is intended to be, and it can be useful not only for our particular case scenario (as we already managed it to work without it).
Regards,
Diego Ruiz
Bx Service GmbH
Carlos Ruiz June 17, 2015 at 10:07 PM
Hi, tested this issue found that maybe is not needed - you just need to implement your own ProcessFactory and return your own custom ReportStarter.
Just like the org.adempiere.report.jasper.ProcessFactory is returning the ReportStarter if the class is set like org.adempiere.report.jasper.ReportStarter or org.compiere.report.ReportStarter.
Can you please check on your plugin if that approach works? Your process factory requires also a service.ranking to be taken into account before the default which has service.ranking=1
JASPER_STARTER_CLASS is hard coded and its used across idempiere, that makes it hard to use a different plugin than the default one.
The solution was to leave the JASPER_STARTER_CLASS as a Sysconfig