I register in container services implementing IMyService.
Do I have any guarantees about their order in
container.Resolve<IEnumerable<IMyService>>
?
Just as extra help for people like me landing on this page... Here is an example how one could do it.
public static class AutofacExtensions
{
private const string OrderString = "WithOrderTag";
private static int OrderCounter;
public static IRegistrationBuilder<TLimit, TActivatorData, TRegistrationStyle>
WithOrder<TLimit, TActivatorData, TRegistrationStyle>(
this IRegistrationBuilder<TLimit, TActivatorData, TRegistrationStyle> registrationBuilder)
{
return registrationBuilder.WithMetadata(OrderString, Interlocked.Increment(ref OrderCounter));
}
public static IEnumerable<TComponent> ResolveOrdered<TComponent>(this IComponentContext context)
{
return from m in context.Resolve<IEnumerable<Meta<TComponent>>>()
orderby m.Metadata[OrderString]
select m.Value;
}
}
No, there's no ordering guaranteed here. We've considered extensions to enable it but for now it's something to handle manually.
I don't mean to self-promote, but I have also created a package to solve this problem because I had a similar need: https://github.com/mthamil/Autofac.Extras.Ordering
It uses the IOrderedEnumerable<T> interface to declare the need for ordering.
I know this is an old post but to maintain the order of registration, can't we just use PreserveExistingDefaults() during registration?
builder.RegisterInstance(serviceInstance1).As<IService>().PreserveExistingDefaults();
builder.RegisterInstance(serviceInstance2).As<IService>().PreserveExistingDefaults();
// services should be in the same order of registration
var services = builder.Resolve<IEnumberable<IService>>();
I didn't find any fresh information on topic and wrote a test which is as simple as (you'd better write your own):
var cb = new ContainerBuilder();
cb.RegisterType<MyClass1>().As<IInterface>();
// ...
using (var c = cb.Build())
{
using (var l = c.BeginLifetimeScope())
{
var e = l.Resolve<IEnumerable<IInterface>>().ToArray();
var c = l.Resolve<IReadOnlyCollection<IInterface>>();
var l = l.Resolve<IReadOnlyList<IInterface>>();
// check here, ordering is ok
}
}
Ordering was kept for all cases I've come up with. I know it is not reliable, but I think that in the current version of Autofac (4.6.0) ordering is wisely kept.
Related
I am new to Autofac and IOC concept. I have following code which I am not getting or understanding what it is doing.
`
public void AddComponentInstance<TService>(object instance, string key = "", ComponentLifeStyle lifeStyle = ComponentLifeStyle.Singleton)
{
AddComponentInstance(typeof(TService), instance, key, lifeStyle);
}
public void AddComponentInstance(Type service, object instance, string key = "",ComponentLifeStyle lifeStyle = ComponentLifeStyle.Singleton)
{
UpdateContainer(x =>
{
var registration = x.RegisterInstance(instance).Keyed(key, service).As(service).PerLifeStyle(lifeStyle);
});
}
public void UpdateContainer(Action<ContainerBuilder> action)
{
var builder = new ContainerBuilder();
action.Invoke(builder);
builder.Update(_container);
}
public static class ContainerManagerExtensions
{
public static Autofac.Builder.IRegistrationBuilder<TLimit, TActivatorData, TRegistrationStyle> PerLifeStyle<TLimit, TActivatorData, TRegistrationStyle>(this Autofac.Builder.IRegistrationBuilder<TLimit, TActivatorData, TRegistrationStyle> builder, ComponentLifeStyle lifeStyle)
{
switch (lifeStyle)
{
case ComponentLifeStyle.LifetimeScope:
return HttpContext.Current != null ? builder.InstancePerHttpRequest() : builder.InstancePerLifetimeScope();
case ComponentLifeStyle.Transient:
return builder.InstancePerDependency();
case ComponentLifeStyle.Singleton:
return builder.SingleInstance();
default:
return builder.SingleInstance();
}
}
}
`
From above code what I understood is that, We are registering the Singleton Instance in Container and we are updating the container. I searched online For IRegistrationBuilder interface example but I could not get any satisfying answer.
Can anyone please help me to understand the concept of IRegistrationBuilder.
I am referring this code from NopCommerce application.
Thanks in Advance.
IRegistrationBuilder is application of builder design pattern within autofac. Look at the line:
x.RegisterInstance(instance).Keyed(key, service).As(service).PerLifeStyle(lifeStyle);
this chain of methods defines registration of istance of certain object. Each of the methods used sets properties used for proper registration. Each of the methods returns builder object which implements IRegistrationBuilder - it holds all those properties. Because PerLifeStyle accepts as first parameter IRegistrationBuilder you can use it in chain above to change builder properties - in case of PerLifeStyle to affect instantiation of the object. Because PerLifeStyle returns IRegistrationBuilder you may use it in the middle of methods invokation chain like:
x.RegisterInstance(instance).PerLifeStyle(lifeStyle).Keyed(key, service).As(service)
Using StatefulKnowledgeSession I'm able to define a filter which describes the rules I want to execute:
session.fireAllRules(new RuleNameEqualsAgendaFilter(ruleName));
But I couldn't find a way to do same thing using StatelessKnowledgeSession:
cmds.add(CommandFactory.newFireAllRules());
ExecutionResults results = session.execute(CommandFactory.newBatchExecution(cmds));
CommandFactory.newFireAllRules() can take int max and String outIdentifier or no parameter at all.
Excessive(!) documentation of JBoss Drools doesn't help me either:
Documentation
My question is whether this is possible or not.
Thanks.
The CommandFactory doesn't have methods for creating a FireAllRulesCommand using filters, but you can just create one yourself:
List<Command> cmds = new ArrayList<Command>();
cmds.add(CommandFactory.newInsert(new MyFact()));
cmds.add(new FireAllRulesCommand(new RuleNameEqualsAgendaFilter("MyRule")));
ExecutionResults results = ksession.execute(CommandFactory.newBatchExecution(cmds));
private static class RuleNameEqualsAgendaFilter implements AgendaFilter {
private final String ruleName;
public RuleNameEqualsAgendaFilter(final String ruleName) {
this.ruleName = ruleName;
}
public boolean accept(final Activation activation) {
return activation.getRule().getName().equals(this.ruleName);
}
}
I have to implement a Chat module to enable privacy chatting b/w users. I have to do this in Play framework using Scala, Akka and java.net.*
I had got several examples over the net which are demonstrating the use of WebSockets but I didn't got any which can help me implementing Chat module using WebSockets. I have the idea of what i have to do but i am totally confused about what should be the structure of the objects, classes and how Should I start.
Please, if anyone can help me for this or refer me a good article, paper which can help me all the way through the implementation. Thankyou.
I did it in Java. This is what I modified from the exemple :
public class ChatRoom extends UntypedActor {
//Added hashmap to keep references to actors (rooms).
// (might be put in another class)
public static HashMap<String,ActorRef> openedChats=new HashMap<String,ActorRef>();
//Added unique identifier to know which room join
final String chatId;
public ChatRoom(String chatId) {
this.chatId = chatId;
}
public static void join(final User user, final String chatId , WebSocket.In<JsonNode> in, WebSocket.Out<JsonNode> out) throws Exception{
final ActorRef chatRoom;
//Find the good room to bind to in the hashmap
if(openedChats.containsKey(chatId)){
chatRoom = openedChats.get(chatId);
//Or create it and add it to the hashmap
}else{
chatRoom = Akka.system().actorOf(new Props().withCreator(new UntypedActorFactory() {
public UntypedActor create() {
return new ChatRoom(chatId);
}
})
);
openedChats.put(chatId,chatRoom);
}
// Send the Join message to the room
String result = (String)Await.result(ask(chatRoom,new Join(user.getId()+"", out), 10000), Duration.create(10, SECONDS));
// ..... Nothing to do in the rest
It's only the main modifications, you also have to adapt javascript and route file
Feel free to ask questions.
Have a look at the official sample in playframework
https://github.com/playframework/playframework/tree/master/samples/scala/websocket-chat
I'm trying to build a command processor that can take any command that implements a marker interface (or maybe descends from a base class). The processor will handle the command that it is asked to process. However I'm struggling with resolving the true generic type as Resolve(Type) returns an object.
I'm not sure is how to cast this if at all possible?
public void Process(ICommand command)
{
var c = command.GetType();
var t = typeof(ICommandHandler<>).MakeGenericType(new[] { c });
var o = container.Resolve(t);
//((ICommandHandler)o).Handle(command); *** This doesn't work
}
The calling code would be something like this -
Dispatcher.Process(new SomeCommand(Guid.NewGuid(),"Param1",12345));
If you absolutely have to call the ICommandHandler<T>.Handle method and you have no other control over the design of the system, then reflection may be your only choice. There's no great way to deal with the switch from generic to non-generic.
Otherwise, you may have a couple of options.
First, if your Dispatcher.Process can be made generic, you can save all the casting.
public static class Dispatcher
{
public static void Process<T>(T command) where T : ICommand
{
var handler = container.Resolve<ICommandHandler<T>>();
handler.Handle(command);
}
}
This is a pretty common solution to a problem like this that I've seen out in the wild.
If you can't do that, then you may be able to make your ICommandHandler<T> interface implement a non-generic ICommandHandler base interface.
public interface ICommandHandler
{
void Handle(ICommand command);
}
public interface ICommandHandler<T> : ICommandHandler
{
void Handle(T command);
}
In this latter case you'd have to switch your strongly-typed command handler implementations to call the same internal logic for generic or basic handling or you'll get different handling based on the call, which would be bad:
public class SomeCommandHandler : ICommandHandler<SomeCommand>
{
public void Handle(ICommand command)
{
var castCommand = command as SomeCommand;
if(castCommand == null)
{
throw new NotSupportedException("Wrong command type.");
}
// Hand off to the strongly-typed version.
this.Handle(castCommand);
}
public void Handle(SomeCommand command)
{
// Here's the actual handling logic.
}
}
Then when you resolve the strongly-typed ICommandHandler<T> your cast down to ICommandHandler (as shown in your question's sample code) will work.
This is also a pretty common solution, but I've seen it more in systems that existed before generics were available where an updated API was being added.
However, in all cases here, the problem really isn't that Autofac is returning an object; it's a class/type design problem that affects any generic-to-non-generic conversion scenario.
Using Reflection - but is this the best way to approach this?
public void Process(Command command)
{
var c = command.GetType();
var ot = typeof(ICommandHandler<>);
var type = ot.MakeGenericType(new[] { c });
var mi = type.GetMethod("Handle");
var o = container.Resolve(type);
mi.Invoke(o, new object[] { command });
}
I have a rather complex bit of resolving going on in Autofac. Basically I want all the objects in the container which implement a specifically named method with a specific argument type. I have implemented some somewhat insane code to get it for me
var services = (from registrations in _componentContext.ComponentRegistry.Registrations
from service in registrations.Services
select service).Distinct();
foreach (var service in services.OfType<Autofac.Core.TypedService>())
{
foreach (var method in service.ServiceType.GetMethods().Where(m => m.Name == "Handle"
&& m.GetParameters().Where(p => p.ParameterType.IsAssignableFrom(implementedInterface)).Count() > 0))
{
var handler = _componentContext.Resolve(service.ServiceType);
method.Invoke(handler, new Object[] { convertedMessage });
}
}
My problem arises in that the handler returned the the resolution step is always the same handler and I cannot see a way to resolve a collection of the the registrations which are tied to the service as one might normally do with container.Resolve>().
I feel like I'm pushing pretty hard against what AutoFac was designed to do and might do better with a MEF based solution. Is there an easy AutoFac based solution to this issue or should I hop over to a more composition based approach?
G'day,
In MEF you could use 'Method Exports' for this (http://mef.codeplex.com/wikipage?title=Declaring%20Exports) but that might be a bit drastic. There are a couple of ways to achieve what you want in Autofac.
You can make the above code work by searching for registrations rather than services:
var implementorMethods = _componentContext.ComponentRegistry.Registrations
.Select(r => new {
Registration = r,
HandlerMethod = r.Services.OfType<TypedService>()
.SelectMany(ts => ts.ServiceType.GetMethods()
.Where(m => m.Name == "Handle" && ...))
.FirstOrDefault()
})
.Where(im => im.HandlerMethod != null);
foreach (var im in implementorMethods)
{
var handler = _componentContext.ResolveComponent(im.Registration, new List<Parameter>());
im.HandlerMethod.Invoke(handler, new object[] { convertedMessage });
}
I.e. implementorMethods is a list of the components implementing a handler method, along with the method itself. ResolveComponent() doesn't rely on a service to identify the implementation, so there's no problem with the service not uniquely identifying a particular implementor.
This technique in general will probably perform poorly (if perf is a concern here) but also as you suspect will work against the design goals of Autofac (and MEF,) eliminating some of the benefits.
Ideally you need to define a contract for handlers that will let you look up all handlers for a message type in a single operation.
The typical recipe looks like:
interface IHandler<TMessage>
{
void Handle(TMessage message);
}
Handlers then implement the appropriate interface:
class FooHandler : IHandler<Foo> { ... }
...and get registered at build-time like so:
var builder = new ContainerBuilder();
builder.RegisterAssemblyTypes(typeof(FooHandler).Assembly)
.AsClosedTypesOf(typeof(IHandler<>));
To invoke the handlers, define a message dispatcher contract:
interface IMessageDispatcher
{
void Dispatch(object message);
}
...and then its implementation:
class AutofacMessageDispatcher : IMessageDispatcher
{
static readonly MethodInfo GenericDispatchMethod =
typeof(AutofacMessageDispatcher).GetMethod(
"GenericDispatch", BindingFlags.NonPublic | BindingFlags.Instance);
IComponentContext _cc;
public AutofacMessageDispatcher(IComponentContext cc)
{
_cc = cc;
}
public void Dispatch(object message)
{
var dispatchMethod = GenericDispatchMethod
.MakeGenericMethod(message.GetType());
dispatchMethod.Invoke(this, new[] { message });
}
void GenericDispatch<TMessage>(TMessage message)
{
var handlers = _cc.Resolve<IEnumerable<IHandler<TMessage>>>();
foreach (var handler in handlers)
handler.Handle(message);
}
}
...which is registered like so:
builder.RegisterType<AutofacMessageDispatcher>()
.As<IMessageDispatcher>();
The component that feeds in the messages will then resolve/use IMessageDispatcher to get the messages to the handlers.
var dispatcher = _cc.Resolve<IMessageDispatcher>();
dispatcher.Dispatch(message);
There are still ways to do this without the interface, but all rely on creating some kind of contract that uniquely defines handlers for a particular message (e.g. a delegate.)
In the long run the generic handler pattern will be the easiest to maintain.
Hope this helps, Nick.