I'm using Serilog currently and I would like to be able to pass a class to the logger and have it log in a custom format before it outputs to a textfile. Somewhat similar to IFormatProvider. I have also found ITextFormatter but I am not sure if that would be the right thing to implement. Would I want a custom sink?
For primitive types, Serilog supports IFormatProvider directly.
Most user-defined reference types however won't be passed directly to the sink by Serilog. This is because sinks often operate asynchronously, and Serilog can't assume that arbitrary user-defined types are thread-safe.
You can circumvent this, in order to use an IFormatProvider, by capturing values of the type as "scalars":
.Destructure.AsScalar<SomeClass>()
Or, alternatively, you can "destructure" the class into whatever secondary representation you want at the time of logging:
.Destructure.ByTransforming<SomeClass>(sc => Display(sc))
For this (ByTransforming()) to work, you need to opt-in with # when the object is logged:
Log.Information("Hello {#Something}", new SomeClass());
Simplest of all, you could also just override ToString() in the class itself.
Related
I am trying to call a method of a class that I only know by name as a String. Now therefore I would need a ClassMirror of that class that allowes me to instantiate an instance. However, creating ClassMirrors seems to be only possible by entering a type using reflectClass(Type) or by passing an already existing instance of that class into reflect(dynamic). So these aren`t helping if I only have a String.
In Java you can do this pretty easily, by calling Class.forName(String). Then you would get a Constructor instance, make it accessibly and call it.
Does anyone know if this is even possible in dart? What seems weird is that once you have a ClassMirror you can access fields and methods by passing symbols, which can be created by Strings.
You can put a specific list of strings to map to a specific list of closures to create a new object with specific parameters.
But you can't get a reflection without using dart:mirrors, which is being deprecated, and also had a negative impact on tree shaking to get the payload size down.
In general, you're invited to look at the package:reflectable to achieve most of what you'd want out of dart:mirrors, using source-to-source builders.
I am working on some logging in log4j2, as one of the arguments I pass in pojo. I would like to intercept this and create a custom string from the pojo. The pojo is a collection of keyValue pairs. I have implemented this in logback using ClassicConverter. I have debugged but it doesn't look like I have access to the argArray
LOGGER.info("custom data in log {}", eventFields);
Is this doable in log4j2 converter or maybe I need to use a diff type of plugin.
Any thoughts?
You have a few options:
Wrap your collection in a MapMessage and log the message. If using the PatternLayout you can then use %K to select what you want.
Same as item one but implement a custom PatternConverter to format the Map.
Extend MapMessage and override one of the formatting methods.
Implement a custom pattern converter that can handle the Message types your application is using (see http://logging.apache.org/log4j/2.x/manual/messages.html).
From your description it sounds like you are trying to write a custom PatternConverter. I suspect the problem you are having is that the object you are looking for is attached to the Message object in the log event, not in the log event itself. You should be able to get access to it via the Message.getParameters() method.
It happens that there are sometimes lines of code or methods that can't produce mutants that are going to be killed by any relevant test. (For instance I may be using a null pattern object, and some of the implemented methods are not relevant in prod, so any implementation (even throwing) would be correct).
It would be nice to be able to tell pit to avoid them (so that the mutation coverage is more relevant), but I couldn't find a way to do it in the documentation.
Is there a way to do it?
PIT currently has five mechanisms by which code can be filtered out.
By class, using the excludedClasses parameter
By method, using excludedMethods
Using a custom mutation filter
By adding an annotation named Generated, CoverageIgnore, or DoNotMutate with at least class level retention. (N.B javax.annotation.Generated has only source retention and will not work)
The arcmutate base extensions allow mutation to be filtered using code comments or external text files
For your use case it sounds like options 1, 4 or 5 would fit.
Option 2 only allows for a method to be filtered in all classes (this is most commonly used to prevent mutations in toString or hashcode methods).
Option 3 is a little involved, but would allow you to (for example) to filter out methods with a certain annotation.
An aside.
I don't I follow your example of the null object pattern.
A null object needs to implement all methods of an interface and it is expected that they will be called. If they were to throw this would break the pattern.
In the most common version of the pattern the methods would be empty, so there would be nothing to mutate apart from return values.
This behaviour would be worth describing with tests. If your null object fails to return whatever values are considered neutral this would cause a problem.
I'm working on the verification of an interface formalised in the OMG's IDL, and am having problems finding a definitive answer on the semantics of getting an attribute value. In an interface, I have an entry...
interface MyInterface {
readonly attribute SomeType someName;
};
I need to know if it is acceptable for someObj.someName != someObj.someName to be true (where someObj is an instance of an object implementing MyInterface).
All I can find in OMG documentation in regards to attributes is...
(5.14) An attribute definition is logically equivalent to declaring a
pair of accessor functions; one to retrieve the value of the attribute
and one to set the value of the attribute.
...
The optional readonly keyword indicates that there is only a single
accessor function—the retrieve value function.
Ergo, I'm forced to conclude that IDL attributes need not be backed by a data member, and are free to return basically any value the interface deems appropriate. Can anyone with more experience in IDL confirm that this is indeed the case?
As we know, IDL interface always will be represented by a remote object. An attribute is no more then a syntatic sugar for getAttributeName() and setAttributeName(). Personally, i don't like to use attribute because it is hardly to understand than a simply get/set method.
CORBA also has valuetypes, object by value structure - better explaned here. They are very usefull because, different from struct, allow us inherit from other valuetypes, abstract interface or abstract valuetype. Usualy, when i'm modeling objects with alot of
get/set methods i prefer to use valuetypes instead of interfaces.
Going back to your question, the best way to understand 'attribute' is looking for C#. IIOP.NET maps 'attribute' to properties. A property simulates a public member but they are a get/set method.
Answering your question, i can't know if someObj.someName != someObj.someName will return true or false without see the someObj implementation. I will add two examples to give an ideia about what we can see.
Example 1) This implementation will always return false for the expression above:
private static i;
public string getSomeName() {
return "myName" i;
}
Example 2) This implementation bellow can return true or false, depending of concurrency or 'race condition' between clients.
public string getSomeName() {
return this.someName;
}
public setSomeName(string name) {
this.someName = name;
}
First client can try to access someObj.someName() != someObj.someName(). A second client could call setSomeName() before de second call from the first client.
It is perfectly acceptable for someObj.someName != someObj.someName to be true, oddly as it may seem.
The reason (as others alluded to) is because attributes map to real RPC functions. In the case of readonly attributes they just map to a setter, and for non-readonly attributes there's a setter and a getter implicitly created for you when the IDL gets compiled. But the important thing to know is that an IDL attribute has a dynamic, server-dictated, RPC-driven value.
IDL specifies a contract for distributed interactions which can be made at runtime between independent, decoupled entities. Almost every interaction with an IDL-based type will lead to an RPC call and any return value will be dependent on what the server decides to return.
If the attribute is, say, currentTime then you'll perhaps get the server's current clock time with each retrieval of the value. In this case, someObj.currentTime != someObj.currentTime will very likely always be true (assuming the time granularity used is smaller than the combined roundtrip time for two RPC calls).
If the attribute is instead currentBankBalance then you can still have someObj.currentBankBalance != someObj.currentBankBalance be true, because there may be other clients running elsewhere who are constantly modifying the attribute via the setter function, so you're dealing with a race condition too.
All that being said, if you take a very formal look at the IDL spec, it contains no language that actually requires that the setting/accessing of an attribute should result in an RPC call to the server. It could be served by the client-side ORB. In fact, that's something which some ORB vendors took advantage of back in the CORBA heyday. I used to work on the Orbix ORB, and we had a feature called Smart Proxies - something which would allow an application developer to overload the ORB-provided default client proxies (which would always forward all attribute calls to the server hosting the target object) with custom functionality (say, to cache the attribute values and return a local copy without incurring network or server overhead).
In summary, you need to be very clear and precise about what you are trying to verify formally. Given the dynamic and non-deterministic nature of the values they can return (and the fact that client ORBs might behave differently from each other and still remain compliant to the CORBA spec) you can only reliably expect IDL attributes to map to getters and setters that can be used to retrieve or set a value. There is simply no predictability surrounding the actual values returned.
Generally, attribute does not need to be backed by any data member on the server, although some language mapping might impose such convention.
So in general case it could happen that someObj.someName != someObj.someName. For instance attribute might be last access time.
I'm writing a Groovy script (as part of a Grails plugin) and I want to get a list of properties for a GrailsDomainClass that a user of my plugin might define. I can do this using domainClass.properties (where domainClass is a GrailsDomainClass).
However, suppose a user has the grails domain class:
class Example {
String name
static constraints = {
}
def getSomeNonExistingProperty(){
return "Not-a-real-property"
}
}
In this case, domainClass.properties returns a list with both name and someNoneExistingProperty
I understand that this is because of Grails is generating a read-only property on-the-fly for use where someone has a getBlah() method. That's great, but in my script I want to perform some actions with the "real" properties only (or at least non read-only properties).
That is, I would like some way of distinguishing or identifying someNonExistingProperty as a read-only property, or, alternatively, as a property generated by Grails and not entered explicitly as a field in the domainClass by the user of my plugin.
I've looked at the GrailsDomainClassProperty Class and it has a range of methods providing information about the property. However, none of them appear to tell me whether a property is read-only or not, or to allow me to distinguish between a field defined in the domainClass and a field created on-the-fly by Grails as a result of a "getSomeNonExistingProperty()" method.
Am I missing something obvious here? Is there a way of getting a list of just the explicitly user-defined fields (eg name, in the above example)?
I believe transient properties are what you are trying to exclude
I've run into this problem a few times, and instead of trying to work around it I typically just end up renaming my getX() method. It's probably the easiest option.
Edit:
Alternatively, I wonder if you could use reflection to see which methods are defined on the class, and while iterating over your properties see if the property has an explicit getter defined, and omit it. I'm not very familiar with reflection when it comes to Groovy and Grails, especially with the dynamic methods, but it's a possible route of investigation.