Sources has comment that TryAdd version do not adds service if it is already registered in IServiceCollection. But docs doesn't mention this method.
When it should be used?
Typically if you have a library with dependencies you would create an extension method of IServiceCollection that the consumer of you library would call from startup to wire up the default dependencies.
.TryAdd is useful inside your extension method when only one implementation of an interface should be used. Then if someone wants to override a default implementation they can register it before calling your extension method and since their implementation is registered first the TryAdd won't add anything.
If .Add is used in your extension method, one can still override the default implementation by registering their implementation after the call to your extension method. But in this case there are still multiple implementations registered so one could take a dependency on IEnumerable of IFoo and get all the implementations that have been registered. But if they take a dependency on IFoo they get just the default one ie the last one added.
Related
what is difference between Serilog.Sinks.File and Serilog.Extensions.Logging.File packages in asp.net core?
When I tried to implement logging in asp.net core project with Serilog I found a quick example here which used Serilog.Sinks.File.
When I tried to implement the same in my project,the logger factory didnt have the extension AddFile().
But when I added another extension Serilog.Extensions.Logging.File I got the extension.
Are both extensions needed? or just Logging.File extension is enough?
What is the basic difference Sinks.File and Logging.File ?
In the link you provided, the example explicitly use Serilog.Extensions.Logging.File.
It is this extension that provide the AddFile method to ILoggerFactory (via Extension Methods mecanisms in DotNet) :
Extension of Microsoft.Extensions.Logging.IloggerFactory
A quick look at the Nuget package definition of Serilog.Extensions.Logging.File indicates that it has a dependency on
Serilog.Sinks.RollingFile.
The latter extension itself has a dependency on Serilog.Sinks.File.
So, Serilog.Extensions.Logging.File extends ILoggerFactory, providing the AddFile() method. That method uses the RollingFile class (as seen in the source code).
I am using AspectJ and Load-time weaving to trace methods calls in an arbitrary java program. I can trace all calls using the standard:
call(* *.*(..))
But what I now trying to do is separate out calls to the native java libraries and any application code:
nativeCalls(): !within(MethodTracer) && call(* java..*.*(..));
appCalls(): !within(MethodTracer) && call(* *.*(..)) && !call(* java..*.*(..));
The issue is that the nativeCalls() pointcut is picking out calls to application classes that inherit from native java classes, even though the signatures do not start with java.lang. or java.util, etc.
For example:
If I have a class tetris.GameComponent that inherits from java.awt.Component, my nativeCalls() pointcut will pick out tetris.GameComponent.getBackground() when the method is actually implemented in java.awt.Component.getBackground().
Is there a way to have my nativeCalls() pointcut ignore the calls to inherited methods?
I hope this is clear. I can provide additional info if necessary. Thanks for any help that can be provided.
Actually I have no idea why you want to exclude those inherited method calls from your trace because IMO it is important or at least interesting to know if a method was called on one of your classes, even if that method was defined in a JDK super class.
But anyway, the answer is no, you cannot exclude calls to JDK methods from your nativeCalls() pointcut if those calls are actually made upon target objects typed to one of your application classes. At the time the call is made, AspectJ does not know how the JVM will resolve the polymorphism. There can be several cases:
Call to Foo.aaa(), existing method Foo.aaa() is executed. This is the simple case where a called method actually exists.
Call to Foo.bbb(), inherited method Base.bbb() is executed (polymorphism). This is the case you want to exclude, but you cannot because the fact that a base method is called will only be known when the method is executed. Furthermore, if Base is a JDK class, you cannot even intercept its method executions with AspectJ.
Call to Base.ccc(), non-overridden method Base.ccc() is executed. This can happen if you directly create an instance of Base or also if you assign/cast a Foo instance to a variable typed Base, e.g. Base obj = new Foo(), and call obj.ccc() which has not been overridden by Foo.
Call to Base.ddd(), overridden method Foo.ddd() is executed (polmorphism). This also happens if you assign/cast a Foo instance to a variable typed Base, e.g. Base obj = new Foo(), and call obj.ddd() which has been overridden by Foo.
So much for not being able to easily exclude the polymorphism stuff when calling inherited JDK method.
Now the other way around: You can easily intercept execution() instead of call() upon your application classes and take advantage of the fact that JDK method executions cannot be intercepted anyway: pointcut appMethod() : execution(* *(..));
Context:
I have a dependency injection container - www.typhoonframework.org
It allows using the interface for defining components to resolve them at runtime - using resolveInstanceMethod and implentationWithBlock to trampoline the request to DI container.
Users have been asking for some parameters to be provided at runtime. For example:
[assembly dangerousEnemyWithWeapon:id<BigGun>]
. . where the enemy is assembled from collaborating classes in the DI container, but the gun is provided at runtime. . .
The Question:
Is it possible to use resolveInstanceMethod to define an implementation where the number of arguments is not known up front?
I would like to package up these arguments, and forward them on to another responder.
The arguments could be packed in order or added to a dictionary with the matching selector part as key.
You can't use +resolveInstanceMethod: for that, but you can use traditional forwarding. +resolveInstanceMethod: just installs a new instance method on the class using the Objective-C runtime. You don't get to affect how it is called. It will be called just like any other method with the arguments in the registers and on the stack as the caller supplied them. You don't get an opportunity to package or marshal the arguments.
If you implement -forwardInvocation: and -methodSignatureForSelector:, then you get an NSInvocation object. That's already a packaging of the arguments (and return value). You can use that as it is or interrogate it to unpack the arguments and repack them how you want.
I am learning to use dependency injection with ninject. Most of the properties and methods are fairly intuitive, one that has me though is Kernel.Inject(instance);
What does the Inject method actually do as it doesn't return anything. I've looked around but search for a method called inject on a dependency injection container is a nightmare, I can't find any references to the method specifically.
Kernel.Inject(instance) will inject dependencies into an already existing object.
That's why it returns void because it takes the parameter object instance and starts to investigate it's methods and property setters looking for the [Inject] attribute. Then it will call them with the resolved instances of their parameter types. (this is called Method or Property injection)
So when contructor injection is not enoughpossible you can Kernel.Inject to fill in your dependencies for a given instance.
You can read more about this here: Ninject Injection Patterns
I have been trying to implement a solution similar to what Ayende posts in his MSDN article, Building a Desktop To-Do Application with NHibernate. Fortunately, Skooletz wrote a similar article that follows up what I am trying to accomplish with his 3 part blog post on NHibernate interceptor magic tricks (1, 2, 3). I am having trouble getting my POCO object's parametered constructor to be called by NHibernate when instantiating the object.
When I remove the protected parameterless constructor, NHibernate complains with an InvalidProxyTypeException: "The following types may not be used as proxies:
YourNamespace.YourClass: type should have a visible (public or protected) no-argument constructor". If I then add in the protected default constructor, NHibernate no longer complains, but the dependency (in the overloaded constructor) is never called causing the application to barf with a NullReferenceException at runtime when the dependency is not satisfied.
public MyClass
{
IRequiredDependency dependency;
public MyClass(IRequiredDependency dependency)
{
this.dependency = dependency;
}
protected MyClass() {}
}
I just can't seem to get NHibernate to call the overloaded constructor. Any thoughts?
In the configuration of the IoC container, you have to declare your type with the dependency in addition to the dependency itself.
container.RegisterType<IRequiredDependency, RequiredDependency>();
container.RegisterType<MyClass, MyClass>();
I missed that little tidbit from Pablo's post (where he registers the Invoice class in addition to its dependency, IInvoiceTotalCalculator) as I am using Unity instead of Windsor.
One additional note: I found is that if you would like to have any other overloaded constructors, make them internal, leave the default constructor as protected and have only a single public constructor that contains your dependencies. This tidbit helped tighten up some of my API design for the classes.