I have some filters implementing javax.ws.rs.container.ContainerRequestFilter and registering this filter through implementing javax.ws.rs.container.DynamicFeature.configure(ResourceInfo, FeatureContext) as below:
context.register(filter);
Now there is some cleanup worked to be performed through that filter implementaion on shutdown, I have tried that through org.glassfish.jersey.server.spi.ContainerLifecycleListener.onShutdown(Container) as well as org.glassfish.jersey.server.monitoring.ApplicationEventListener.onEvent(ApplicationEvent)
But somehow I am not able to get the reference of this filter to call its destroy method inside of these above both listener methods.
Below of some compulsion:
Cannot make filer class as Singleton.
Cannot mark this filer class with Provider annotation. As there may be different type of filters need to be register on basis of different use-case.
Related
when I use a #RepositoryEventHandler then its methods are only invoked when the call into the repository comes in via HTTP.
Any reason why? OK, it is called Spring Data REST, but wouldn't it be VERY useful to invoke the handler too, when I call my Repo directly, not via HTTP?
Any way to invoke the handler when called directly (some magic AOP-stuff)?
Thank you
The reason for that is that the different persistence mechanisms covered by the different Spring Data modules already ship with event mechanisms. Depending on the one you use you now get a different mechanism to use.
Unfortunately this can't be unified as e.g. with JPA not all persistence operations need to go through the repository in the first place, as JPA automatically flushes all changes that were made to an attached instance on EntityManager flush. In this case even AOP on the repository instance doesn't help.
So you're basically left with two choices:
The events exposed by Spring Data REST for all repositories (as we basically don't make use of the automatic change tracking in JPA).
The store specific event mechanisms that will make sure that the persistence mechanism exposes events as documented.
I don't know if the solution I put below from other stackoverflow questions would seen as acceptable by #Olivier-drotbohm, but from:
SpringDataRest #RepositoryEventHandler not running when Controller is added
and
#RepositoryEventHandler events stop with #RepositoryRestController
you could inject/autowire the "ApplicationEventPublisher" and fire the BeforeCreateEvent/AfterCreateEvent manually to trigger the RepositoryEventHandler.
This is not a perfect solution, but I hope it is good enough for you (and we tested it: it works).
So, I have a viewmodel class in a xamarin project that I inject some dependencies into via ninject binding on app start. One of these is an IDialogService.
When my MainPage in my application changes it raises a property changed event and I rebind the implementation of the dialog service since it is tied to the MainPage.
If my viewmodel has already been created with lets say DialogServiceA and then when MainPage changes we rebind to DialogServiceB, will my viewmodel be using service A or B? I think it is using A and therefore does not display in the UI because it is tied to a MainPage that no longer exists.
So, if this is the case how can I dynamically change my dialog service but then update classes that have already been instantiated without changing everything to get the current dialog service from the container every time its used (therefore not injecting it at all really, and doing more of a servicelocator)
Also, if this approach is completely wrong, set me straight.
You're right. Re-configuration of the container does not affect already instanciated objects.
If you want to change dependencies without re-instanciating the dependent (parent ViewModel) there's a few possibilities for you:
use a factory to instanciate the service every time. Implement an Abstract Factory (Site by Mark Seeman) or use Ninject.Extensions.Factory to do so
instead of injecting a service directly, inject an adapter. The adapter then redirects the request to the currently appropriate service. To do so, either all service can be injected into the adapter, or you can use a factory as with the possibility above.
instead of inject a service directly, inject a proxy. The proxy is quite similar to the adapter, but instead of coding every method / property redirection specifically, you code a generic redirect by an interceptor. Here's a tutorial on castle dynamic proxy
At the end of the day, however, i believe you'll also need a way to manage when to change the service / which it should be. There's probably a design alternative which doesn't rely on exchanging objects in such a manner.. which would make it an easier (and thus better?) design.
Edit: i just saw that you also tagged the question as xamarin-forms. In that case it most likely won't be an option to use either a dynamic proxy nor ninject.extensions.factory (it relies on dynamic proxies, too). Why? dynamic proxy / IL emitting is not supported on all platforms, AFAIR specifically on Apple devices this can't be done.
I am using the NamedScoped Ninject extension in an attempt to create object graphs that are constructed everytime a command handler is constructed by the container. In other words, I want a fresh object graph for every command that might get processed by its corresponding handler.
I have used the .DefinesNamedScope("TopLevelOrhcestrator") binding when registering my "command handlers" as they are the top level for command processing.
A type in this named scope needs to be injected with the result of a method call on a type already registered in this named scope. I thought the best way to do this would be with a ninject provider.
Inside the provider I attempt to resolve the type in hopes I can call a method on it to pass into another object I am creating within this named scope. The problem I'm having is that when I ask the IContext for the instance inside the customer provider I get an exception that says "No matching scopes are available, and the type is declared InNamedScope(TopLevelOrchestrator).
context.Kernel.Get<TypeAlreadyRegisteredInScope>().MethodThatGetsAnotherDependency()
Is it possible to get types from the container inside a Ninject provider when they are registered inside a named scope?
EDIT
I apologize if the use case seems a bit odd, I am experimenting with some ideas about how to manage my units of work and other services/managers that may need a handle to the uow to complete a business usecase. I know its common for the unit of work to be "started" and then passed into all dependencies that may need to take part in a larger process. I was thinking I'd rather let my orchestrator take a unit of work factory so that it could deterministically destroy the UOW and it would be clear who the owner of a usecase is. What would get supplied to the managers/services would be a proxy to the unit of work that would be null until a real unit of work was started by the orchestrator. That's why I was attempting to link the proxy from the already registered type in my provider. This is all very experimental at this point and was testing some ideas.
I'd be happy to hear any further thoughts.
For MethodThatGetsAnotherDependency() to be able to .Get<>() an instance that is bound .InNamedScope(...) you will need to add the Context Preservation Extension.
This is because NamedScope is adding a parameter to the request context of the binding that has .DefinesNamedScope(...). As soon as that request is over, that context and it's parameters are forgotten. Now with the ContextPreservation extension the context is kept and reused for late / factory creations (Func<>, interface factory with .ToFactory() binding...). It think it should also work with providers.
If not, just switch to a factory instead of a provider.
However i have to admit that i don't fully understand why/what you are trying to achieve. There might be simpler ways.
I am trying to run some code on objects that are loaded from RavenDB, and I need to do it just after the object has been loaded with its property values.
I've tried intercepting the deserialization process using a CustomCreationConverter and overriding ReadJson, but the object I can access at that point has all the properties set, except the one I need : the Id. Is there somewhere else I can slot into the pipeline in order to do this?
The reason you don't see the Id is because it's not part of the document, it's in the metadata as #id.
If you want to intercept client side, you can register a custom Conversion Listener. Create a class that implements IDocumentConversionListener and register it with documentStore.RegisterListener(). In the DocumentToEntity method, you can run your custom logic. The documentation is lacking on Listeners in general, but there is another topic that also uses them:
http://ravendb.net/kb/16/using-optimistic-concurrency-in-real-world-scenarios
The other option would be to add a bundle that intercepts on the server side. For that, you would use a Read Trigger.
In structuremap you can control the lifeCycle of an object you register, normally some interface to a concrete type as follows:
x.For<IMyInterface>().Transient().Use<MyObject>();
So I can control the life cycle. However when resolving objects (Concrete) types that are not registered the life cycle defaults to what seems to be Transient().
This is obviously a convenient feature of structuremap as I surely dont want to register each concrete type.
However is there a way to override this life cycle without registration?
Furthermore it would be great if you can specify the life cycle of an object as an override much like:
ObjectFactory.With<SomeUnregisteredConcreteObject>().LifeCycleIs(...)
In such a case the life cycle would be modified for the next resolution to GetInstance
Any idea how any of this can be done?
You could create a child container & register the component:
var child = ObjectFactory.Container.CreateChildContainer();
child.Configure(config => config.For<SomeUnregisteredConcreteType>().Singleton());
var #object = child.GetInstance<...>();
I assume that the reason why you didn't want to register was because you didn't want the registration to hang around. I think this solves that problem.
I also don't know of built-in a way to specify a default lifecycle. However, I think it's probably possible using the IAutoMocker interface. You could probably browse through the code in that whole folder to figure out how to do it. The AutoMocking hooks into the container so that a component is requested that isn't registered, it calls into the IAutoMocker and gives it a chance to register a component. I imagine that you could use IAutoMocker to register components with a different default lifecycle.
If you succeed in this, I hope you send a pull request or write a blog post to share with the rest of us.