I got a microservice .NET Core that receives a Serilog.Events.LogEvent though a external source. The Microservice implements the UseSerilog whitch mean that the injected Microsoft ILogger will be a disguised Serilog.
The question is how I log my LogEvent from within this class that only got a Microsoft ILogger?
I tried to cast the Microsoft ILogger to a Serilog ILogger but that was not possible.
MS Ilogger is supposed to make it easy to switch logging systems, all a class needs to know about should be the MS Ilogger. But in this case, I took a shortcut, I simple injected a Serilog ILogger and then used this to log the LogEvent.
This is a very small standalone project so it should not be a problem. Besides, to get Serilog structure logging working one must use a specific syntax, this might not be the same if the log system is changed.
Related
I have a Dropwizard application that uses Dropwizard metrics and uses BigTable for persistence. I am already reporting metrics to graphite from my application and would like to report client side BigTable metrics too. I see that there is an existing class BigtableClientMetrics that supports reporting client-side metrics. DropwizardMetricRegistry is also provided which wraps the dropwizard MetricRegistry and creates an instance of the class. Considering an instance of the MetricRegistry is already created as part of bootstrap of my application, is there any way I can use the same instance for reporting Bigtable client metrics too?
Would be great if the DropwizardMetricRegistry class would have a constructor that takes a dropwizard MetricRegistry object as a parameter.
That sounds like a Cloud Bigtable HBase client feature request. Please submit an issue here: https://github.com/googleapis/cloud-bigtable-client
I am working on a greenfield project and I want to integrate serilog with ninject.
The use case is as follows:
There are a number of common libraries
These libraries are used in a number of modules i.e plugins. These plugins each receive a GUID at run time which is unique. This
is a base property on an abstract plugin class which every
implementation of a plugin inherits
We want to append this unique name to every log message that a plugin makes
as well as any calls to the common libraries from that plugin so that a log
message can be traced to the unique instance of a plugin that made it
We would prefer not to modify each class in the common libraries to take in a logger to use to log
My thoughts were to :
Create a singleton logger provider. This will be called by anything needing to log.
Use postsharp and CallContext.LogicalSetData to set the GUID prior to any call to the logging provider
Use CallContext.LogicalGetData to get the GUID in the singleton logger provider. This will either retrieve an existing logger for that GUID using Logger.ContextFor or create a new one to add to a dictionary.
Use Ninject to resolve the ILoggerProvider to the singleton provider always when requested
Before I down this circuitious route, is there a better way to do this, maybe with ninject?
Thanks for reading.
I went with the solution as described but due to it being a singleton there was no need for ninject in the end.
The solution is working and doesnt seem to have any performance issues logging at high volumes
I implemented Serilog for a ASP.NET MVC project which will be hosted in Azure and Serilog provides sinks to log to Azure storage.
I then wanted a better way to handle exceptions and ran into this very informative article on integrating ASP.NET MVC with Elmah - http://www.hanselman.com/blog/ELMAHErrorLoggingModulesAndHandlersForASPNETAndMVCToo.aspx
I like it that Elmah lets you view exceptions and has ways to notify admins when exceptions occur. Given that I already have Serilog, should I replace it with Elmah or use it in conjunction with it?
Elmah is only used to log unhandled exceptions. That is, exceptions that would otherwise result in a yellow screen of death. It has a very nice log viewer as well, but ultimately, it's only used for exception logging.
Serilog can do everything that Elmah can do, with the exception (no pun intended) of the built-in viewer. However, there are lots of ways to view your exceptions.
Serilog will also do tracing or "event logging", which Elmah won't do (by default, there are ways to use Elmah's infrastructure to do this).
Finally, you don't get the structure of Serilog's logging with Elmah. You just get flat logfiles.
You can use both if you want, but I'd rather just configure an Exception handler to log to Serilog.
FYI, Serilog can log to Elmah.
http://blog.elmah.io/logging-to-elmah-io-from-serilog/
There's a good blog entry on the Elmah website about the difference between Elmah and Log4net. Many of the same reasons apply with Serilog, although obviously there is also Serilog's structured logging which you wouldn't get with either of those.
http://blog.elmah.io/elmah-vs-log4net/
Also, despite the fact I've linked to elmah.io, don't be confused. There are two versions of Elmah. One of them is free (and open source), the other is not (although it is partially open source). Elmah.io is cloud based, and not free. Elmah is still open source and free.
http://code.google.com/p/elmah/
I'm looking for an example to expose the methods already exposed via MBean server with SNMP.
I read that since Java6 this is already supported in the JDK, but I also found snmp4j as a library. But I couldn't find any example that fits my scenario, or would be helpful.
I already have MBeans registered to the MBeanServer, and I'm looking for a way to enhance the classes I already have in order to make them suitable for SNMP. I can't use mibgen, as it would be the other way around.
Maybe someone can give me an example on what I need to do in order to be able to monitor my application via some SNMP manager.
An example MBean would be
public interface ExporterMXBean {
public static String BEANNAME = "exporter:type=Exporter,name=Exporter";
String getOutputDirectory();
void setOutputDirectory(String outputDirectory);
void startExport();
int getNumberOfThreadsWorking();
}
What would I need to add to the implementation of the interface, how would I register this to a MIB, and how would it be exposed/viewable to a Manager?
Thanks in advance.
I would recommend using SNMP4J-AgentJMX on top of SNMP4J-Agent and SNMP4J like the in the example of SNMP4J-AgentJMX called JvmManagementMibInst.java.
With this approach you do not modify your existing classes (MBeans). Instead your programm or generate a mapping which makes use of the above APIs.
A basic How-To on the necessary steps to create a SNMP agent based on some MBeans of a MBean server is described in the SNMP4J-AgentJMX HowTo
I'm working on a large legacy application using stateless session beans that has recently been migrated from EJB2 to EJB3, and I'd like to use dependency injection. Unfortunately, in a (IMO misguided) attempt to achieve decoupling, all actual business logic lies in "manager" classes to which the session beans forward their calls. Those manager classes then often use other EJBs.
Can I somehow make these manager classes capable of being injected into the EJBs via #Resource and then having the other EJBs injected into them via #EJB?
The application has to run on glassfish 2.1.
(...) all actual business logic lies in "manager" classes to which the session beans forward their calls.
That was a very common pattern with EJB 2.x allowing to unit test the "manager" classes easily, outside the container, without any adherence to the EJB API.
Can I somehow make these manager classes capable of being injected into the EJBs via #Resource and then having the other EJBs injected into them via #EJB?
Not out-of-the-box with Java EE 5. Injection is limited only to first class constructs defined in the Java EE platform, including:
SessionContext object
DataSources object
UserTransaction
EntityManager interface
TimerService interface
Other enterprise beans
Web services
Message queues and topics
Connection factories for resource adaptes
Environment entries limited to String, Character, Byte, Short, Integer, Long, Boolean, Double, and Float.
In Java EE 6, this would be possible using CDI (JSR-199) and the #Inject annotation in EJBs to inject your managers and also in you managers to get EJBs injected.
Maybe you could try to deploy Weld (the RI of JSR-199) as part of your application on GlassFish v2.1. I didn't experiment this myself, so I can't confirm anything. Just in case, maybe have a look at the Chapter 18. Application servers and environments supported by Weld (GlassFish v2.1 hasn't been tested, but it doesn't mean it doesn't work).
Pascal's suggestion about upgrading to GlassFish 3 sounds probably like the most elegant approach ;)
I'd be curious to hear what prevents moving to a more recent version (not saying there can't be a reason, just wondering what the issue is here).