So after being confronted with the dreaded javax.faces.application.ViewExpiredException, I had to go look around the internet to find the proper solution. Fortunately, the solutions are readily available and I went ahead and adopted the OmniFaces FullAjaxExceptionHandler.
Enough said, as with pretty much everything from OmniFaces, it worked wonders. But, every time I have a view expiring I am getting :
SEVERE: WebModule[/myModule]FullAjaxExceptionHandler: An exception occurred during processing JSF ajax request. Error page '/WEB-INF/errorpages/test.xhtml' will be shown.
javax.faces.application.ViewExpiredException: viewId:/my/page.xhtml - View /my/page.xhtml could not be restored.
...
This is fine as it is handled as expected, but is there anyway to silence this exception from being printed to the server.log? This would crowd the log pretty quickly.
I am running :
Mojarra 2.1.23
PrimeFaces 4.0-SNAPSHOT
OmniFaces 1.6-SNAPSHOT-2013-07-01
on
Glassfish 3.1.2.2
As per OmniFaces 1.6, you can extend it and override the method logException() as below to skip the stack trace for ViewExpiredException.
public class YourAjaxExceptionHandler extends FullAjaxExceptionHandler {
public YourAjaxExceptionHandler(ExceptionHandler wrapped) {
super(wrapped);
}
#Override
protected void logException(FacesContext context, Throwable exception, String location, String message, Object... parameters) {
if (exception instanceof ViewExpiredException) {
// With exception==null, no trace will be logged.
super.logException(context, null, location, message, parameters);
}
else {
super.logException(context, exception, location, message, parameters);
}
}
}
Create a factory around it:
public class YourAjaxExceptionHandlerFactory extends ExceptionHandlerFactory {
private ExceptionHandlerFactory wrapped;
public YourAjaxExceptionHandlerFactory(ExceptionHandlerFactory wrapped) {
this.wrapped = wrapped;
}
#Override
public ExceptionHandler getExceptionHandler() {
return new YourAjaxExceptionHandler(getWrapped().getExceptionHandler());
}
#Override
public ExceptionHandlerFactory getWrapped() {
return wrapped;
}
}
In order to get this to run, register it as factory in faces-config.xml the usual way (don't forget to remove the original registration for FullAjaxExceptionHandlerFactory):
<factory>
<exception-handler-factory>com.example.YourExceptionHandlerFactory</exception-handler-factory>
</factory>
Related
When a DataProvider fetch or count method throws an exception, e.g. because the user is not authorized, how could I handle these exceptions centrally? I know there is HasErrorParameter interface to show error views when there is an exception thrown when routing. But these error views are not triggered when DataProvider throws the exception.
Example:
new AbstractBackEndDataProvider<String, Void>() {
#Override
protected Stream<String> fetchFromBackEnd(Query<String, Void> query) {
...
}
#Override
protected int sizeInBackEnd(Query<String, Void> query) {
throw new UnsupportedOperationException("test");
}
}
#Route("failed")
public class FailView extends VerticalLayout
implements HasErrorParameter<UnsupportedOperationException> {...}
Even if I do a try catch within the DataProvider methods, I don't see how I could navigate to the appropriate error view just by using the caught exception and not the view component class (this wouldn't trigger setErrorParameter method).
BTW: I miss the router exception handling topic in Vaadin Flow 13 documentation. I wonder why they removed it.
I believe all Exceptions that don't occur while routing will be given to the ErrorHandler of the VaadinSession the error occured in.
The best way to set the ErrorHandler seems to be to override the sessionInit method in a custom SessionInitListener
You can add a custom SessionInitListener inside the servletInitialized method of a custom VaadinServlet.
class CustomServlet extends VaadinServlet{
#Override
protected void servletInitialized() throws ServletException {
super.servletInitialized();
getService().addSessionInitListener(new CustomSessionInitListener());
}
}
And that SessionInitListener (in this example CustomSessionInitListener) has to set the errorHandler of the sessions that get initialized.
class CustomSessionInitListener implements SessionInitListener{
#Override
public void sessionInit(SessionInitEvent event) throws ServiceException {
event.getSession().setErrorHandler(new CustomErrorHandler());
}
}
For further information on how to create your own Servlet take a look at Vaadin's tutorial page(you need to scroll down to "Customizing Vaadin Servlet")
Edit:
To show the error page you need to get Vaadin to reroute to an error. To achieve that we can use an BeforeEnterEvent, BeforeEnterEvents have a rerouteToError method which we can use to let Vaadin show our ErrorView.
But we also want to pass along the Exception instance, so we have to store that as well. I did exactly that with the following class:
#Route("error-view") // Route shown in the user's browser
public class ErrorViewShower extends Div implements BeforeEnterObserver {
// Class to store the current Exception of each UI in
private static class UIExceptionContainer extends HashMap<UI, Exception> {
}
// Method to call when we want to show an error
public static void showError(Exception exception) {
UIExceptionContainer exceptionContainer = VaadinSession.getCurrent().getAttribute(UIExceptionContainer.class);
// Creating and setting the exceptionContainer in case it hasn't been set yet.
if (exceptionContainer == null) {
exceptionContainer = new UIExceptionContainer();
VaadinSession.getCurrent().setAttribute(UIExceptionContainer.class, exceptionContainer);
}
// Storing the exception for the beforeEnter method
exceptionContainer.put(UI.getCurrent(), exception);
// Now we navigate to an Instance of this class, to use the BeforeEnterEvent to reroute to the actual error view
UI.getCurrent().navigate(ErrorViewShower.class);// If this call doesn't work you might want to wrap into UI.access
}
#Override
public void beforeEnter(BeforeEnterEvent event) {
UIExceptionContainer exceptionContainer = VaadinSession.getCurrent().getAttribute(UIExceptionContainer.class);
// Retrieving the previously stored exception. You might want to handle if this has been called without setting any Exception.
Exception exception = exceptionContainer.get(UI.getCurrent());
//Clearing out the now handled Exception
exceptionContainer.remove(UI.getCurrent());
// Using the BeforeEnterEvent to show the error
event.rerouteToError(exception, "Possible custom message for the ErrorHandler here");
}
}
Usage of it in combination with the error handler looks like this:
public class CustomErrorHandler implements ErrorHandler {
#Override
public void error(ErrorEvent event) {
// This can easily throw an exception itself, you need to add additional checking before casting.
// And it's possible that this method is called outside the context of an UI(when a dynamic resource throws an exception for example)
Exception exception = (Exception) event.getThrowable();
ErrorViewShower.showError(exception);
}
}
Edit2:
As it turns out that Exceptions occuring inside internal method calls don't get handled by the UI's ErrorHandler or the VaadinSession's ErrorHandler but instead by another error handler which causes the client side to terminate and show the Error Notification,
a solution is to catch the Exceptions inside the methods of the DataProvider and pass them to ErrorViewShower.showError() and still return without any Exception flying the stacktrace upwards. (Or don't throw any Exception yourself and instead simply pass a new to the ErrorViewShower.showError() method).
By returning normally Vaadin doesn't even know something went wrong.
ErrorViewShower.showError() calls ui.navigate, that navigation command seems to get "queued" behind the calls to the DataProvider, meaning the view of the user will change in the same request.
Dataprovider with such an implementation:
new AbstractBackEndDataProvider<String, Void>() {
#Override
protected Stream<String> fetchFromBackEnd(Query<String, Void> query) {
try{
//Code that can throw an Exception here
}catch(Exception e){
ErrorViewShower.showError(e);
//We have to make sure that query.getLimit and query.getOffset gets called, otherwise Vaadin throws an Exception with the message "the data provider hasn't ever called getLimit() method on the provided query. It means that the the data provider breaks the contract and the returned stream contains unxpected data."
query.getLimit();
query.getOffset();
return Stream.of(); //Stream of empty Array to return without error
}
}
#Override
protected int sizeInBackEnd(Query<String, Void> query) {
//Second way i mentioned, but this will not catch any Exception you didn't create, where as the try...catch has no way to let any Exception reach Vaadin.
if(badThingsHappened){
ErrorViewShower.showError(new UnsupportedOperationException("Bad things..."));
return 0;//Exiting without error
}
}
}
I have created a Mobile App Service and hosted that on Azure.
Sometime specific line of code throws exception and I'm not handling those. Instead I'm logging those in ExceptionFilterAttribute.
The problem I'm facing is, those exceptions are reported as unhandled by Azure App Service which I think is true. My question is, how can I improve the below line of code such that it will not be considered unhandled exception?
public async Task<SingleResult<DTO.Responses.User>> GetUser(string id, OS os = OS.iOS, string openUrl = null)
{
/* some code written here that sometimes throws exception */
}
if I add try...catch block how will this be handled by Mobile App sync framework?
Below is code for exception filter
public class UnhandledExceptionFilter : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
/* Log exception here*/
}
}
Based on my knowledge, we could use global error handing.
We could get the following demo code from this tutorial.
public class TraceSourceExceptionLogger : ExceptionLogger
{
private readonly TraceSource _traceSource;
public TraceSourceExceptionLogger(TraceSource traceSource)
{
_traceSource = traceSource;
}
public override void Log(ExceptionLoggerContext context)
{
_traceSource.TraceEvent(TraceEventType.Error, 1,
"Unhandled exception processing {0} for {1}: {2}",
context.Request.Method,
context.Request.RequestUri,
context.Exception);
}
}
config.Services.Add(typeof(IExceptionLogger),
new TraceSourceExceptionLogger(new
TraceSource("MyTraceSource", SourceLevels.All)));
Then we could config it in the ConfigureMobileApp method
Public static void ConfigureMobileApp(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
config.Services.Add(typeof(IExceptionLogger),
new TraceSourceExceptionLogger(new
TraceSource("MyTraceSource", SourceLevels.All)));
new MobileAppConfiguration()
.UseDefaultConfiguration()
.ApplyTo(config);
...
app.UseWebApi(config);
}
For a custom monitoring tool I need an API (REST) to fetch the console log of a Jenkins build in chunks.
I know about the /consoleText and /logText/progressive{Text|HTML} APIs, but the problem with this is that sometimes, our build logs get really huge (up to a few GB). I have not found any way using those existing APIs that avoids fetching and transferring the whole log in one piece. This then normally drives the Jenkins master out of memory.
I already have the Java code to efficiently fetch chunks from a file, and I have a basic Jenkins plugin that gets loaded correctly.
What I'm missing is the correct extension point so that I could call my plugin via REST, for example like
http://.../jenkins/job/<jobname>/<buildnr>/myPlugin/logChunk?start=1000&size=1000
Or also, if that is easier
http://.../jenkins/myPlugin/logChunk?start=1000&size=1000&job=<jobName>&build=<buildNr>
I tried to register my plugin with something like (that code below does not work!!)
#Extension
public class JobLogReaderAPI extends TransientActionFactory<T> implements Action {
public void doLogChunk(StaplerRequest req, StaplerResponse rsp) throws IOException {
LOGGER.log(Level.INFO, "## doLogFragment req: {}", req);
LOGGER.log(Level.INFO, "## doLogFragment rsp: {}", rsp);
}
But I failed to find the right encantation to register my plugin action.
Any tips or pointers to existing plugins where I can check how to register this?
This was indeed more simple than I expected :-) It as always: once one understands the plugin system, it just needs a few lines of code.
Turns out all I needed to do was write 2 very simple classes
The "action factory" that get's called by Jenkins and registers an action on the object in question (in my case a "build" or "run"
public class ActionFactory extends TransientBuildActionFactory {
public Collection<? extends Action> createFor(Run target) {
ArrayList<Action> actions = new ArrayList<Action>();
if (target.getLogFile().exists()) {
LogChunkReader newAction = new LogChunkReader(target);
actions.add(newAction);
}
return actions;
}
The class the implements the logic
public class LogChunkReader implements Action {
private Run build;
public LogChunkReader(Run build) {
this.build = build;
}
public String getIconFileName() {
return null;
}
public String getDisplayName() {
return null;
}
public String getUrlName() {
return "logChunk";
}
public Run getBuild() {
return build;
}
public void doReadChunk(StaplerRequest req, StaplerResponse rsp) throws IOException, ServletException {
Currently I log exceptions as follows-
public ActionResult Login()
{
try
{
throw new Exception("test");
}
catch (Exception ex)
{
LogException(ex);
}
return View();
}
I can get a clear & detail information about the exception from LogException() method here. See below-
Created on: 27-Dec-2016, 06.34.33 PM
Type: System.Exception
Error Description: test
Source File: ...\Controllers\LoginController.cs
Method: Login
Line: 20
Column: 17
I tried the same method in -
public class MyCustomAttribute : FilterAttribute, IExceptionFilter
{
public void OnException(ExceptionContext filterContext)
{
Exception ex = filterContext.Exception;
LogException(ex)
}
}
public class MyCustomAttribute : HandleErrorAttribute
{
public override void OnException(ExceptionContext filterContext)
{
Exception ex = filterContext.Exception;
LogException(ex)
}
}
I also tried overloading OnException method-
public abstract class BaseController : Controller
{
public BaseController() {}
protected override void OnException(ExceptionContext filterContext)
{
Exception ex = filterContext.Exception;
filterContext.ExceptionHandled = true;
LogException(ex);
}
}
In all three abose cases I am getting no information about Source File, Method, Line and Column-
Created on: 27-Dec-2016, 06.44.45 PM
Type: System.Exception
Error Description: test
Source File:
Method: <BeginInvokeAction>b__1e
Line: 0
Column: 0
This is my method to log exception-
public static void Create(Exception exception, String rootDirectoryPath)
{
try
{
StackTrace st = new StackTrace(exception, true);
StackFrame frame = st.GetFrame(st.FrameCount - 1);
string fileName = frame.GetFileName();
string methodName = frame.GetMethod().Name;
int line = frame.GetFileLineNumber();
int col = frame.GetFileColumnNumber();
//Other code .....
}
catch (Exception)
{
//do nothing.
}
}
My question is, is it possible to retrieve Source File, Method, Line and Column information from those three cases?
I would not like to handle exceptions by writing try .. catch.. every time.
I have heard about ELMAH & Log4Net. But not sure whether those library able to supply my desired information from exceptions.
Sorry for the long question.
I'm the author of Coderr which also takes care of tracking exceptions for you.
the problem with your solution is that the exception filter (and the ASP.NET framework calls to invoke it) will be part of the stack trace, thus getting frames from the stack trace object wont work.
Also note that if the .PDB file is not included when you put your web site in production you wont get file numbers.
The most common approach is just to log exception.ToString() which will include line numbers in the stack trace (if there is a PDB file).
Why do you want to use your custom approach?
You are reinventing the wheel as ELMAH will do the job just fine. Did you give it a try? Just a Nuget package and some configuration to be fully set.
You can read more about it from Scot Hanselman or read the tutorial.
I am facing a problem when publishing changes to WebSphere with JSF2 (Myfaces 2.0.12).
Everytime I publish a change to my local server (WebSphere) I am getting a java.lang.VerifyError. After a full restart of the server the application runs smoothly with my changes.
java.lang.VerifyError: com/sun/faces/renderkit/html_basic/HtmlResponseWriter.startElement(Ljava/lang/String;Ljavax/faces/component/UIComponent;)V
The StackTrace indicates that something is wrong with the ResponseWriter and indeed we changed a little bit there ;-)
For accessibility-reasons I have to have full controll of the HTML so I need custom HtmlRenderers. To reduce duplicate code I decorated the ResponseWriter I get from the FacesContext with my own, and provide additional convenience-methods on top.
public class CustomResponseWriter<T extends UIInput & MyFormdataInterface> extends HtmlResponseWriter
{
public CustomResponseWriter(ReponseWriter writer){
super(writer, writer.getContentType(), writer.getCharacterEncoding());
}
public writeFancy(T component)
{
...
writeText(component.getMyFanceAttribute(), null);
...
}
}
As I said, the code runs fine after the server was restarted so I assume the code is correct. But on the other side, this error occurs only on pages where I use this CustomReponseWriter.
Is there anything wrong with the idea of decorating the ResponseWriter in a new class? Or might this just be a problem in WebSphere?
As lu4242 mentioned in his comment, I changed the implementation from decorator to a delegate and the problem disappeared. It would be nice to understand why this happens but for now here is the changed code (I dont like the verbose code from the delegate in this case but as long as it works).
public class CustomResponseWriter<T extends UIInput & MyFormdataInterface> extends ResponseWriter
{
private ResponseWriter delegateWriter;
public CustomResponseWriter(ReponseWriter writer){
this.delegateWriter = writer;
}
public writeFancy(T component)
{
...
writeText(component.getMyFanceAttribute(), null);
...
}
public String getContentType()
{
this.delegateWriter.getContentType();
}
//... and so on for all methods from ResponseWriter...
}
}