I have a java web application running on Spring Web FLow,Spring Faces. I would like to ask as to how to properly manage error messages display. Should I do the usual storing of error messages on the session? Or is there a better handling by Spring regarding the matter.
The flashScope is intended for just this type of "display a once-off message to the user" usage. You can use it in combination with a resource bundle and the or tags to retrieve the localized error string from a key stored in the flashScope.
Spring Web Flow offers a level of automation for error messages if you make use of the validation framework so you may not even need to do the above manually. However not knowing your exact use case, it's hard to recommend a specific approach.
Related
When an exception occurs during execution of a Web.Api controller method in our system, the request is sent to Application Insights as a failure and we send the exception to Application Insights with telemetry.TrackException(actionExecutedContext.Exception);
Behavior:
request is shown as a failure with URL and some other data in the details
exception is shown under Server exceptions with the stack trace shown in the details.
However, when looking at the details of a failed request (due to a server exception), the Exception part does not show the correlated exception - just the default Learn how to track exceptions for failed requests.
When looking at what is sent to Application Insights inside Visual Studio 2017, I see that the exception and request are correlated (same Operation Id).
But it seams that this gets lost on the way to the detail page.
We use ASP.NET WebApi with OWIN, default Application Insights installation (of nuget packages) and applicationinsights-owinextensions (including the steps described there to setup the OWIN extension).
I think How to link exceptions to requests in Application Insights on Azure? does not apply because the data is shown as correlated in the Visual Studio AppInsights Viewer and when clicking Show telemetry for: this operation inside the details view of the exception inside AppInsights.
Maybe related:
Application Insights shows 2 requests for a failure. The first one shows the HTTP Method (e.g. GET) the second one misses the HTTP Method and has a duration that is slightly longer.
Thanks for hints :-)
As you are using applicationinsights-owinextensions, I checked the code for OperationIdTelemetryInitializer that is used to initialize operation id. I believe the reason you're not seeing telemetry linked correctly on detail blades is that this code is not setting operation.parentId field. To verify whether this is correct you can examine the payload sent to check whether parent.id field is set. The initializer that we are shipping in the officially supported .NET SDK sets operation.id, as well as operation.parentId.
So my recommendation is, once you confirm, that parentId is indeed not set, would be to to either fix the OperationIdTelemetryInitializer used in owin-extensions so it starts setting parentId, or replace it in ApplicationInsights.config with your custom one. The latter approach would make it easy to confirm this theory.
The solution was to remove the Microsoft.ApplicationInsights.Web.OperationCorrelationTelemetryInitializer from the application insights config file.
This initializer gets in the way of the initializer from applicationinsights-owinextensions nuget package.
I'm receiving an error when I'm attempting to consume a web service:
Cannot read the token from the 'Timestamp' element with the 'http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' namespace for BinarySecretSecurityToken, with a '' ValueType.
Not quite sure
The client is an asp.net web application, making a call. From Wireshark, one can see the post going in, and the response coming back, but then it errors out like this.
To give some background, this is a WCF calling on a java served web service.
You may need to add a security timestamp soap header to the message. Look at this SO question where they had the opposite problem but it may be helpful to look at their configuration. Also, you may save yourself some grief if you can use one of the WCF Interop Express bindings for accessing a java service implementing WS-Security.
I'm working on a web service that uses ASP.NET security model (i.e. with AspNetCompatibilityRequirements set to allowed). Like many others, I got an error saying the Anonymous access is required because the mexHttpBinding requires it and the only way to get around it is to remove the mex endpoint from each service as described here:
WCF - Windows authentication - Security settings require Anonymous
I thought by removing mex endpoint I will no longer able to generate WSDL or add a reference to the service from Visual Studio but to my surprise everything still works. I quickly googled the "mex binding" but most web sites just say it's for "Metadata Exchange" without going into too much detail on what it actually does.
Can anyone tell me what's the side effect of removing the mex binding?
If your WCF service does not expose service metadata, you cannot add a service reference to it, neither from within Visual Studio (Add Service Reference), nor will another client be able to interrogate your service for its methods and the data it needs.
Removing Metadata Exchange (mex) basically renders the service "invisible", almost - a potential caller must find out some other way (e.g. by being supplied with a WSDL file, or by getting a class library assembly with a client he can use) about what the service can do, and how.
This might be okay for high risk environment, but most of the time, being able to interrogate the service and have it describe itself via metadata is something you want to have enabled. That's really one of the main advantages of a SOAP based service - by virtue of metadata, it can describe itself, its operations, all the data structures needed. That feature is used to make it really easy to call that service - you just point to the mex endpoint, and you can find out all you need to know about that service.
Without the metadata exchange, you won't be able to use svcutil.exe to automatically generate the proxy classes.
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.
I'm looking for the best way to log errors in an ASP.NET application.
I want to be able to receive emails when errors occurs in my application, with detailed information about the Exception and the current Request.
In my company we used to have our own ErrorMailer, catching everything in the Global.asax Application_Error. It was "Ok" but not very flexible nor configurable.
We switched recently to NLog. It's much more configurable, we can define different targets for the errors, filter them, buffer them (not tried yet). It's a very good improvement.
But I discovered lately that there's a whole Namespace in the .Net framework for this purpose : System.Web.Management and it can be configured in the healthMonitoring section of web.config.
Have you ever worked with .Net health monitoring? What is your solution for error logging?
I use elmah. It has some really nice features and here is a CodeProject article on it. I think the StackOverflow team uses elmah also!
I've been using Log4net, configured to email details of fatal errors. It's also set up to log everything to a log file, which is invaluable when trying to debug problems. The other benefit is that if that standard functionality doesn't do what you want it to, it's fairly easy to write a custom appender which can process the logging information as required.
Having said that, I'm using this in tandem with a custom error handler which sends out a html email with a bit more information than is included in the standard log4net emails - page, session variables, cookies, http server variables, etc.
These are both wired up in the Application_OnError event, where the exception is logged as a fatal exception in log4net (which then causes it to be emailed to a specified email address), and also handled using the custom error handler.
First heard about Elmah from the Coding Horror blog entry, Crash Responsibly, and although it looks promising I'm yet to implement it any projects.
I've been using the Enterprise Library's Logging objects. It allows you to have different types of logging (flat file, e-mail, and/or database). It's pretty customizable and has a pretty good interface for updating your web.config for the configuration of the logging. Usually I call my logging from the On Error in the Global.asax.
Here's a link to the MSDN
I use log4net and where ever I expect an exception I log it to the appropriate level. I tend not to re-throw the exception because it doesn't really allow for as-nice user experience, there is less info you can provide at the current state.
I'll have Application_Error also configured to catch any exception which was not expected and the error is logged as a Fatal priority through log4net (well, 404's are detected and logged as Info as they aren't that high severity).
My team uses log4net from Apache. It's pretty lightweight and easy to setup. Best of all, it's completely configurable from the web.config file, so once you've got the hooks in your code setup, you can completely change the way logging is done just by changing the web.config file.
log4net supports logging to a wide variety of locations - database, email, text file, Windows event log, etc. My team has it configured to send detailed error information to a database, and also send an email to the entire team with enough information for us to determine in which part of the code the error originated. Then we know who is responsible for that piece of code, and they can go to the database to get more detailed information.
I recently built an asp.net webservice with NLog, which I use for all my desktop apps. The logging works fine when I'm debugging in Visual Studio, but as soon as I switch to IIS the log file isn't created; I've not yet determined why, but it the fact that I need to look for a solution makes me want to try something else for my asp.net needs!
We use EnterpriseLibrary.ExceptionHandling.Logging. I like it a bit better than log4net because not only do we control the logging completely, but we can control the Throw/NoThrow decision within config as well.
We use a custom homegrown logging util we wrote. It requires you to implement logging on your own everywhere you need it. But, it also allows you to capture a lot more than just the exception.
For example our code would look like this:
Try
Dim p as New Person()
p.Name = "Joe"
p.Age = 30
Catch ex as Exception
Log.LogException(ex,"Err creating person and assigning name/age")
Throw ex
End Try
This way our logger will write all the info we need to a SQL database. We have email alerts set up at the DB level to look for certain errors or frequently occurring errors. It helps us identify exactly where the errors are coming from.
This might not be exactly what you're looking for. Another approach similar to using Global.asax is to us a code injection technique like AOP with PostSharp. This allows you to inject custom code at the beginning and end of every method or on every exception. It's an interesting approach but I believe it may have a heavy performance overhead.