Hi Pascal, The problem is that something needs to be added to the design here to actually catch an error in the background thread.
Any error must be caught by someone with a try/catch. IIRC, before java.util.concurrent convenience classes existed, writers of background tasks had to specifically remember to try/catch, otherwise the thread just terminated silently when an error occurred. With java.util.concurrent ExecutorService, typically the Future.get() or Future.get(…,…) method is used to get the result of a background task that was submitted to an ExecutorService. If the background task had an error, that call to Future.get will throw an error (which may wrap the original error), @see : http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html Right now, in the utility stuff in Wonder, the CCAjaxLongResponsePage does that call to Future.get and handles an error appropriately. In the ERRest scenario, you are using the database to manage the status since the REST request is a direct action that could hit any instance. So a transient single-instance instance of a Future object is not so useful there. Suggested approaches to error handling for the ERRest case where the task state is kept in the db might be (1) possibly have the TaskInfo implement the Future interface (elegant solution?) or (2) just have an errorMessage attribute field and a FAILED_WITH_EXCEPTION status as another status option for the TaskInfo entity. Then wrap the call/run task logic in a try/catch block and in the case of an error log the error, put the error.getMessage into the database TaskInfo.errorMessage and when the rest request for status comes in, return the error response. HTH, Kieran On Sep 1, 2011, at 7:29 AM, Pascal Robert wrote: > Nope, it's in a ERRest context (a bit like the example I added to > BackgroundTasks). > >> Is the Callable task being executed by a CCAjaxLongResponsePage? >> >> Regards, Kieran. >> (Sent from my iPhone) >> >> >> On Aug 31, 2011, at 9:21 PM, Pascal Robert <[email protected]> wrote: >> >>> FYI, problem #1 was that the parameters have to be >>> "isForPrompting="false"". But after that, it was still failing, and this >>> time without any errors but neither with a PDF. Added some breakpoints, and >>> I found out that it was failing when filling up the report (which have >>> multiple sub-reports) but no exception was raised. So I did the same calls >>> but in a non-Callable context, and I got the following error: >>> >>> java.lang.ClassNotFoundException: >>> org.codehaus.groovy.control.CompilationFailedException >>> >>> So the problem is that 3 sub-reports had Groovy as the language for >>> expressions instead of Java. Changed that, and now it works. I just have to >>> find why I don't get the exceptions when in a background task context. >>> >>> PS: to enable lo4j for JasperReports: >>> >>> log4j.logger.net.sf.jasperreports=DEBUG >>> >>>> Hi, >>>> >>>> I have to run some Jasper Reports where the data will come out by a SQL >>>> query embedded in the report instead of a JRDatasource. The report I'm >>>> working works fine in iReport (well, except the fact that iReport is one >>>> of the worst app I ever used) and that report have parameters to change >>>> the SQL query. I was under the impression that when you build the >>>> parameters map, you can just include the parameter from the report into >>>> the map, like this: >>>> >>>> HashMap<String, Object> params = new HashMap<String, Object>(); >>>> ... >>>> params.put("studentID", "102449"); >>>> params.put("showAssessmentHistory", false); >>>> ... >>>> JRReportTask reportTask = new JRReportTask(location.id(), fs, >>>> report.__globalID(), params); >>>> >>>> But where "studentID" and "showAssessmentHistory" are parameters inside >>>> the report. But when I execute the report, I get a blank page, even if I >>>> do have data for that studentID (using the same values in iReport results >>>> with data). Is this the correct way to supply report parameters to the >>>> engine? >>>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com >>> >>> This email sent to [email protected] > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
