Is there a way to configure the MVC3 *DependencyResolver* to stop caching the resolved IControllerActivator. I have several containers and multiple implementations of IControllerActivator registered.
Unfortunately the DependencyResolver is not always called to resolve the correct IControllerActivator. I suspect caching.
Any idea ?
There is no way to do that. You would have to write your own implementation of IControllerFactory (perhaps deriving from DefaultControllerFactory) or write a delegating IControllerActivator that dynamically looks up your desired activator and invokes it.
Related
I was exploring #RequestScoped and was wondering if there's way to use it without installing ServletModule. I am using Guice 3.0 + Jersey 1.17 and probably don't want to use GuiceContainer & GuiceServletContextListener.
I want object creation(injections) per request depending on some user input in the Jersey request. Is it possible? What can be performance & security considerations of using GuiceContainer if I had to replace my existing ServletContextListener with that of Guice?
If there's a way of using RequestScope as per my needs, can you give me some references for the same?
It is possible to bind a custom Scope implementation to a predefined scoping annotation like #RequestScoped. It does mean that then you cannot use ServletModule, since you can't bind two different implementations to the same scoping annotation.
See the documentation on Custom Scopes for details. You will need to write code to determine what constitutes a "request" for purposes of scoping, and trigger entering and exiting the scope as necessary.
For example, in the normal Guice implementation, ServletScopes.RequestScope uses a ThreadLocal initialized in GuiceFilter to keep track of what the current request is.
I always got problems with the private variable declaration.
For example FlatFileItemWrite. I would like to extend these class and overwrite the 'doRead' method. This would not work because some of the used variables are declared private. This leads to copying the complete code in an own class for overwriting one method.
Sometime even this does not work because the class extends an other class which has variables declared visible only for the same package. Then you need to copy this class also.
Then I will miss updates in the original classes with new versions. So would it not be better to use protected instead?
I can imaging only a very few reasons to use private instead of protected. For my own programs this is not an issue, I could change it on demand. But for a framework it is a pain.
with kind regards
Torsten
If something is declared private within the Spring framework (or any framework for that matter), it's not considered part of the public API. Because of that, you really shouldn't be looking to work with it directly. Doing so really means you're forking the framework and risking not being able to upgrade seamlessly.
As the project lead for Spring Batch, I'd be interested in hearing what you had to do with the FlatFileItemWriter that required you to change things that are marked private.
If the idea behind the framework was to override or extend these methods, they should have been written as being public. (be careful if a framework does not provide these methods or properties as public, since it might depend on them working in a specific way. this would be the primary reason for them being private i can think of. the secondary being that they don't matter outside that class.)
In some cases, you might not need to copy the entire class, but simply inheriting or extending it might be enough.
I'm also looking to extend certain ItemReaders/ItemWriters to support decryption/encryption on i/o. For example, I'd like to extend StaxEventItemReaderStaxEventItemReader in order to read an encrypted stream from the resource, but the FragmentEventReader is private, so I'm unable to wrap its XMLEventReader's InputStream in a decrypter.
I faced the same issue with FlatFileItemWriter.
I'm refactoring one of my controller to make it a service and I want to know if there is a performance impact to not inject whole service container into my controller.
Is this is more efficient :
innova.path.controller:
class: %innova.controller.path.class%
arguments:
entityManager: #doctrine.orm.entity_manager
session: #session
securityContext: #security.context
router: #router
translator: #translator
pathManager: #innova.manager.path_manager
calls:
- [setRequest, ["#?request="]]
scope: request
than this, for example ?
innova.path.controller:
class: %innova.controller.path.class%
arguments: [#service_container]
Official documentation explicitly tell to not inject whole DIC into a Controller (thanks #NHG for link).
Section How to work with scopes :
Injecting the whole container into a service is generally not a good
idea (only inject what you need).
But in section Service container :
When you ask for the my_mailer service from the container, the
container constructs the object and returns it. This is another major
advantage of using the service container. Namely, a service is never
constructed until it's needed. If you define a service and never use
it on a request, the service is never created. This saves memory and
increases the speed of your application. This also means that there's
very little or no performance hit for defining lots of services.
Services that are never used are never constructed.
So injecting the whole DIC to controller will not have performances impact because only the services used in controller are instanciated.
The idea of using controllers as service is injecting only necessery services. Standard controller extends Symfony\Bundle\FrameworkBundle\Controller\Controller which extending Symfony\Component\DependencyInjection\ContainerAware. So, injecting whole container is makes no sense...
Generally, injecting less service is more efficient than injecting whole container.
Additionally you should familiarize with base Symfony2 Controller class.
I provide a highly customisable application to my clients which is working totally by itself. But If one my client wants to overwrite any Controller, I want to replace my implementation by theirs. However just overwriting the controller causes an ambiguous definition of mappings.
I have been using Component Scanning to load beans.
The potential solutions came to my mind are:
Using component scanner with excluding by a custom filter? (This seems not so easy)
Using a xxxxPostProcessor to remove some beans? (How?)
Any help?
If I got your Question properly,
You can differ implementation by changing URL to particular Implementation name
Say Telecom is interface and AirtelImpl and RelianceImpl are Controllers then
Your request mapping
#RequestMapping(value= "/airtel/doBilling")
#RequestMapping(value= "/reliance/doBilling")
In this way, Implementation flow will differ.
I have followed these steps:
Created a custom annotation: #Devoted
Created a custom ImportBeanDefinitionRegistrar. Iterated already registered bean definitions to find out `#Devoted #Controller's and removed them.
Based on a request I will provide implementation details.
I have an WebApi application that contains some controllers (they are registered using the extension method RegisterApiControllers). This application references another assembly that contains other controllers that I don't want to expose(I have checked that they are not registered in the container). It happens that both have an OrderController, and when I try to access the /api/Order url, I get an exception "Multiple types were found that match the controller named 'order'." and the stack trace shows that I was in DefaultHttpControllerSelector.
I have seen that AutofacControllerFactory used to exist and there was even a ConfigureWebApi that registered it, but it is not anymore present in the default branch.(you can see it here http://alexmg.com/post/2012/03/09/Autofac-ASPNET-Web-API-(Beta)-Integration.aspx)
It seems also that we can not filter the namespace of the route definition in WebApi (it is possible to MVC).
So any idea on how I can use only the Controller registered in my Autofac container and not use the DefaultHttpControllerSelector that seems to scan all referenced assemblies to discover controller?
Thanks
The problem is that registering the controller with autofac is not really related to the routing process. Only once the routing process has identified which controller to dispatch to will Autofac be called to resolve the type.
It looks like, from digging around in the source, that you would need to write a replacement IHttpControllerSelector in order to handle two controllers with the same name. (which really sucks BTW).
You might be able replace the DefaultHttpControllerTypeResolver with an instance that is passed a predicate that filters out the controllers from the assembly that you want to ignore. It's a bit of a kludgy solution but might work.
Actually, you might be able to replace the DefaultHttpControllerTypeResolver completely with one that is based on registrations in your Autofac container. It is a very simple interface, so as long as Autofac have a some kind of discovery mechanism, you should be golden.
public interface IHttpControllerTypeResolver
{
ICollection<Type> GetControllerTypes(IAssembliesResolver assembliesResolver);
}