Json.net allows to provide custom ContractResolver when deserializing objects from json:
Deserialize with dependency injection and Json.NET 6.0 Release 4
In order to resolve dependencies root container has to be passed to AutofacContractResolver object when Autofac is configured.
However it makes impossible to resolve InstancePerRequest dependencies because of not matching scope (DependencyResolutionException: No scope with a Tag matching
'AutofacWebRequest' is visible from the scope in which the instance
was requested... Is thrown)
Is there any way of configuring this custom resolver which allows resolving InstancePerRequest dependencies?
Related
First, no grails and no spring.
I just use groovy servlet (http://docs.groovy-lang.org/latest/html/api/groovy/servlet/GroovyServlet.html)
if I have a servlet named user_action.groovy, and I have UserDao.groovy, UserService.groovy, how can I inject services or daos into servlet please?
If you're using a servlet container that supports JNDI, such as Tomcat, you could potentially configure your UserDao class as a JNDI resource, and then access it via the JNDI directory lookup. That would provide a level of indirection, but relies on external configuration.
Another option is to include a DI framework such as Tiger or Guice if you're not interested in Spring based DI.
But injection by nature requires some form of Dependency Injection framework to support it. Otherwise you just go:
def dao = new UserDao()
Questions about ejb session bean behavior when used as injected bean instances.
I'm not 100% sure how this works. I guess it from practice and from reading documents on the subject.
I want to know how #EJB annotation is processed by container in detail.
Session bean have interfaces, impl class, deployment descriptor. We package them in ejb jar.
What is putted in global JNDI by container? Static references to
business interfaces ?
How and when global JNDI is read from ?
When component JNDI ENC is populated with ejb reference ?
Is this reference in JNDI ENC (java:comp/env/beanB) is reference to
session bean component interface, session bean instance proxy or
session bean instance ? Is there difference for SLSB and SFSB ?
With #EJB annotation on field does every new ejb session bean
instance get new instance of injected ejb in the annotated field or
all ejb instances share the same injected ejb session bean instance
?
Does ejb injection by lookup (on session context) provide always new
injected ejb instance, example: calling ctx.lookup(ejbReference) in
loop ?
In EJB 3.0, the JNDI names are vendor-specific (if available at all; in theory, a container could support EJB references only), but vendors typically return an EJB reference/proxy. In EJB 3.1, the specification requires the EJB container to make specific java:global, java:app, and java:module names available, and the object returned from these lookups must be an EJB reference/proxy.
The global JNDI is accessed when you perform a JNDI lookup. The container might access the global JNDI names in other cases (e.g., when resolving #EJB(lookup="java:app/...")).
It's undefined when the container populates java:, but the contents must be available before lifecycle callback or business methods are invoked on the component instance.
#EJB/<ejb-ref>/<ejb-local-ref> ensure lookups always return an EJB reference/proxy and never an actual bean instance. The proxy ensures that all container services are performed (security, transaction, remoting, etc.) before invoking an actual bean instance. For SLSB, an arbitrary bean instance will be invoked, and the same or different actual instance might be invoked depending on the thread, concurrency, timing, vendor-specific configuration, etc. For SFSB, a bean instance with a specific identity will be invoked; you are likely to get the same bean instance, but you might not if the EJB container has passivated the actual bean instance, but reactivation should result in an instance with equivalent state. For singleton session bean in EJB 3.1, you are guaranteed the singleton bean instance will be invoked.
It's undefined whether you get the same proxy instance. For SLSB and singleton beans, injection or lookup could return a single proxy that delegates to the actual bean instance as mentioned above. For SFSB, the proxy is basically required to be a separate instance per injection or lookup since the proxy must store some state with the identity so it can invoke the specific actual bean instance.
It's undefined what the container does, but injection is typically implemented by containers using Context.lookup followed by Field.set (or Method.invoke for setter method injection). Regardless, the instance handling is as described above.
I need to declare a Spring bean using Annotation-based config, which will be available throughout the runtime of the Application Server (in my case, JBoss). I should be able to write and read the data to/from the bean across multiple requests. I have read about the global session scoped bean, but couldn't find any concrete examples. Is there a way to implement this and what are the thread-safety concerns with this kind of bean?
Best Regards,
Chandra.
I've gotten the basics done with resolving controller dependencies with Autofac + MVC5. However, I'm wondering how to inject dependencies into services.
Given a sample definition as such, how can I create/get an instantiated copy of the class with Autofac resolving the necessary dependencies?
Bar : IBar
{
Public Bar(IFoo foo, IPanda panda)
{}
}
Ultimately it just comes down to registering the type in the Container. Such as:
var builder = new ContainerBuilder();
builder.RegisterType<Bar>().As<IBar>();
var container = builder.Build();
I'm assuming you have similar code using the Builder somewhere during your initialization.
There are several different ways to register and configure dependencies, lifetimes, interceptors etc, more info here:
http://docs.autofac.org/en/latest/register/registration.html
Once everything is registered, whenever Autofac tries to instantiate your controller, it'll inspect your controller's constructor, and when it finds an IBar as dependency, it'll look for it's container registration and instantiate accordingly.
The same applies when it tries to instantiate IBar, it'll notice IFoo and IPanda and repeat the same process.
The main difference is that Autofac supports automatic registration of your controllers, just to spare you the hassle of registering each one manually.
So in the end, it'll all be chained in that manner, dependencies created as needed.
I tend to avoid using ServiceLocator style of instantiation by requesting a dependency directly, and just let Autofac provide the dependencies during construction.
I am trying to understand the usage of making the http request context available through dependency injection in global.asax application start event like this.This is ASP.NET MVP application and the code is
Container.Register(Component.For()
.LifeStyle.PerWebRequest
.UsingFactoryMethod(() => new HttpRequestWrapper
(HttpContext.Current.Request)));
Can anybody expalin me this code.
what it does?
I won't say that this is an absolutely recommended approach, but it helps to resolve HttpContextBase dependencies in constructors or properties while building up the object graph. It can be particularly useful when you have classes that depend on HttpContextBase so they can unit tested using mocks.