The project I'm working on already has a "custom" error handler but I have a task to make another one which handles only one exception. My question is can the two handlers co-exist and if yes - where do I set mine to be used by the project?
According to Documentation page about handling errors:
You can customize the default error handling by implementing a custom ErrorHandler and enabling it with setErrorHandler() in any of the components in the component hierarchy, including the UI, or in the VaadinSession object.
That means that what you need to do is most likely doable, and exception will be handled by first error handler it arrives at - unless you want to have two error handlers on the same component (i.e. UI) which is impossible.
Related
I'm using the Off-screen rendering component TChromiumOSR in the dcef3 package - the Delphi wrapper for Chromium-embedded library.
Situation
FormA contains a TChromiumOSR and paints the output.
Modal FormB modifies the web page by executing some js code against FormA.TChromiumOSR.
Issue
The TChromiumOSR.OnPaint event (in FormA) is not triggered until FormB.ShowModal returns.
Notes
There is no such issue in the above described situation (under a modal form) with the standard TChromium control.
I assume the `TForm.ShowModal' method only blocks the input of the background forms, but not the painting?
Or does it caused by the internal working of cef3?
Anyway, how to solve it? Thanks.
dcef3 master branch is here
I've succeeded updating an HTML element by using the ExecuteJavaScript method called from a modal form. But you might have use CEF V8 as well (that's what I haven't tested). For cases when you need to invalidate the current view manually, you can call Invalidate:
MyChromiumOSR.Browser.Host.Invalidate(PET_VIEW);
But that's workaround rather than solution. Invalidating of relevant elements should happen by the CEF engine for you. And if you come up with an MCVE, I can investigate more about your specific problem.
Ok, I found the source of the problem - it's not a bug in cef3 or dcef3 but was caused by my improper use of Delphi Event Bus, and the following are the steps to reproduce the issue:
In one the 'delphi event bus' handler, the program shows a modal form at this point the execution of the main thread is blocked.
On top of the modal form, the user doing certain actions will start a background thread, which in turn will send a message to the main thread, which in turn will calls the 'delphi event bus' to post another new event, which in turn will execute some js code to update the web page inside dcef3, which in turn will trigger some of the dcef3 events (in the main thread), and here is where the program stuck - since the TEventBus.Post() method is locked by a TCriticalSection.
Solution:
In Step #1, don't call ShowModal directly, but use a technique such as PostMessage winapi to 'delay' the execution of ShowModal.
I'm not sure if I have described it clearly...
I'm looking for ways to configure/reconfigure log4j after it may, or may not have been initialized. This should work running standalone or in a web container.
The configuration may be represented by a configuration file at a particular arbitrary URI. The knowledge of the URI comes from the application, not log4j framework. The configuration may also be done programmatically (less problematic but problematic still).
The public API is unfortunately sorely lacking so developers are forced to write brittle code using implementation classes from log4j core. From weeks of studying documentation and stepping through log4j code I see two ways to accomplish reconfiguration:
Stopping the current context and re-initializing using log4j.core.config.Configurator,
similar to the following:
((LoggerContext) LogManager.getContext(false)).stop();
Configurator.initialize(buildDefaultConfiguration()); //programmatically building a configuration
or
((LoggerContext) LogManager.getContext(false)).stop();
Configurator.initialize(null, ConfigurationSource.fromUri(loggingUri)); //passing the configuration source constructed from a known URI
The first line in both examples will stop the current context if it has already been created and started (when running in a web container for example). If log4j has not been initialized (when running as a standalone app for example) it will initialize log4j with the default configuration and start the context first (as a side effect of calling getContext()), and then stop it.
If the current context is not stopped first the call to Configurator.initialize() will have no effect. log4j will ignore your attempt to re-initialize, will not give you any indication of it, and just simply return the current context. This behavior is not mentioned in the "Reconfigure Log4j Using ConfigurationBuilder with the Configurator" section of the Manual. It simply says: "However, should any logging be attempted before Configurator.initialize() is called then the default configuration will be used for those log events." The default configuration will also be used for all subsequent log events in the provided examples because calling Configurator.initialize() will have no effect, unless the current context is stopped first.
Setting a new configuration location on the existing context thus forcing reconfiguration,
similar to the following:
((LoggerContext) LogManager.getContext(false)).setConfigLocation(loggingUri);
This works in a similar fashion: if log4j hasn't been initialized the call to getContext() will trigger initialization and creation of the default context that will then be reconfigured; and if it has been initialized then the current context, whatever it may have been, will get reconfigured. The configuration source will be created from the URI by the log4j framework.
The difference is that in the first way the context is replaced and all loggers in the old (stopped) context will be dead. If any code on the stack holds references to these dead loggers and tries to log to them it will be a no-op. In the second way the context is kept but the configuration is replaced and existing loggers are updated with the new configuration.
Both methods use core code and are therefore brittle, but both work for the sunny day scenario (using log4j-core 2.10.0 anyway). However, neither one appears to afford the user any control over handling any exceptional events, or even inform the user that something went wrong. Log4j will "eat up" any exceptions, and make its own executive decision how to handle them.
If a problem occurs after Configurator.initialize() is called log4j will create a default configuration that effectively cuts all logging off other than errors to the console and happily return the new context back not giving the calling code any clue that logging has effectively been stopped.
If a problem occurs after LoggerContext.setConfigLocation() is called log4j will do essentially the same thing except the current context will be kept. One would think that particularly in the case of a reconfiguration failure the most typical handling would be to revert back to the old configuration. There doesn't appear to be a way to accomplish this because log4j will simply stop logging (other than errors to the console) and give the calling code no indication of the failure.
Here's a typical scenario: several applications extend a common framework. The framework configures the same logging for all extending applications (to facilitate reuse and simplify post-processing of the logs). Some application has a unique logging need and attempts to reconfigure log4j from its own metadata (config file at a known URI). The XML parser throws an exception parsing this file. The exception gets handled internally by log4j, logging is quietly stopped, and no one knows. Well, there is an error log sent to the StatusLogger with the exception, but the calling code doesn't know.
So with this lengthy preamble, the question is: is there a mechanism I haven't discovered yet to modify log4j configuration in a predictable fashion and be able to handle abnormal events should they arise? That is, other than something drastic like (for the example above) extending the XML configuration class and replacing code that handles exceptions, thus running a risk of creating undesirable side effects in the current log4j implementation, not talking about an even greater risk of breaking in the future if the implementation changes.
Any help would be greatly appreciated!
I'm writing a wrapper component for WKWebView and I'd like to make sure I cover my bases for error handling.
The documentation for webView:didFailNavigation simply states Called when an error occurs during navigation. What exactly does the documentation writer mean when they say "navigation?"
I'm aware that there's also webView:didFailProvisionalNavigation, which executes whenever there's a loading error. The documentation for that hook states Called when an error occurs while the web view is loading content. I can make this trigger by calling [_webView loadRequest:request], where request contains a malformed URL.
i am validating user input in my application using Struts2 build in validation framework and its working fine.
I have to show the error message as per the application layout so need to place my inside a predefined block.
but i need to show this block only when there is validation error in my application and i am unable to figure out how i can do this.
One solution is i should override the theme for error but in that case error theme will applicable for whole application and that is not what i need.Is there any way by whihc i can check if contains any error or not?
Problem solved.after looking at free marker template i came up with solution
something like
fieldErrors.keySet().size()
I am using Delphi 6 along with the JEDI-JVCL 3.x. My project settings include creating the JDBG files and inserting them into the executable. Yet somewhere along the line I did something that defeated the appearance of the custom Exception handling form that shows the complete detailed stack dump with other information, and now I just get the standard Exception dialog box with just the singular Exception info. Can anyone tell me most likely what I did that is interfering with the appearance of the custom Exception dialog box?
-- roschler
It looks like you have deleted Jcl Exception dialog from the project. Or it just initializes later then exception occurs.