Is it thread safe if i want to create an instance of some type via Prism container resolve method that was previously registered as singleton? Unfortunately i couldn't find any info on this.
It depends on what you mean by thread-safe, and depending on the answer to that, what implementation of ServiceLocator you are using.
Both MEF and Unity containers are thread-safe in the sense that Resolve can be called independently from multiple threads for the same type. Theoretically you could have some other kind of ServiceLocator which was not thread-safe in this respect, but I would be surprised to find one, because it would make thread synchronization across a Prism app a real chore.
What may not be thread-safe is the actual object that is returned from the container. For instance, if you registered a Dictionary object and asked for that back, there is nothing magical about ServiceLocator that would make the Dictionary's operations thread safe.
Related
I deal with a framework "X" which starts multiple threads and from each of them calls methods from a self-written JAR library. I wanted to get benefits from both of frameworks "X" and Spring, so i've designed the method which is being called from "X" in a way that it initializes Spring Context. In such way I have a Spring Context in each Thread. I can't show the code, so that's the brief description of the case. Everything is fine, just I'm just wondered about some circumstances:
Does that situation mean that every singleton scoped bean is becoming automatically Thread-safe (framework X handles threads itself) so I don't have to bother about ThreadLocals, local variables and can I do everything without synchronization with instance variables.
Do class variables still shared among all threads/spring context or bean class variables in this case become local to context?
I have some other question if you don't mind I'll edit this question later yet. And maybe I'll write some resume of conclusions if get answers here.
Thank You all in advance.
I'm trying to create a service such that once it is created it only allows itself to be held by a single consumer/bundle at any one time. (If this is against the philosophy/specification of OSGi then that obviously provides a quick answer but reference to the OSGi specs. stating this would be appreciated.)
To implement such a requirement I implemented the ServiceFactory interface thinking that whenever there was a requirement for the service the getService(Bundle bundle, ServiceRegistration<S> registration) method would be called and it would be where I could determine if the Bundle was a new consumer or not and act accordingly.
It appears that this is not the case in the scenario I have tested this in.
Using a Apache Karaf and instantiating a consumer of the Service via Blueprint it would seem that the getService method is never called. Instead the consumer's binding method for the service is called directly but injecting a proxy service object.
While I understand that Blueprint uses proxies surely there is still the obligation of the ServiceFactory contract to fulfil even if it's a proxy object consuming the service?
Why do I want to do this?
I am attempting to wrap JavaFX and the Stage class and because JavaFX isn't OSGi friendly I am attempting to co-ordinate access to the Stage object. I'm aware that there are frameworks such as Drombler but a brief look at them made me think that it doesn't suit my use case. They appear too restrictive for my needs e.g. I don't necessarily wish to layout an application in the manner Drombler uses.
It depends what you mean by a consumer. ServiceFactory does give you the chance to create a separate instance of a service per bundle that calls getService on your service. It's not clear from your question but I suspect you weren't seeing the getService invoked multiple times because you were fetching the service from the same consumer bundle. In this case, ServiceFactory simply returns the same object repeatedly.
As for your general question about restricting access to a single consumer, no that really goes against the OSGi philosophy. I'm sorry I don't have a spec reference for you but the clue is in the name: it's a service that is available to all.
I'm aware that there are frameworks such as Drombler but a brief look at them made me think that it doesn't suit my use case. They appear too restrictive for my needs e.g. I don't necessarily wish to layout an application in the manner Drombler uses.
Please note that the layout of Drombler FX applications is pluggable so you can provide your own implementation tailored to your needs. This allows you to get the most out of Drombler FX and JavaFX.
While this feature is available for some time, there is now a new tutorial trail explaining it in more detail.
Is HTTPBuilder in Grails thread safe?
If HTTPBuilder is wired to a Grails service class, will it be safe to use? Or should it be instantiated on every invocation?
There doesn't seem to be any concrete answer as to whether HTTPBuilder in Grails is thread safe or not. I'm inclined to go with non thread safe due to the lack of documentation regarding that particular aspect, but I'd like a definitive answer.
The code seem to indicate it should be ok to handle multiple requests from multiple threads so long as they will go through to the same URL with the same context (headers, authenticators etc.).
Do you mean groovyx.net.http.HTTPBuilder? It has several fields that are modified by calling methods, and there's no synchronization or locking, and no use of thread-safe collections or other classes, so no, it's very much non-thread-safe. Most builders are similarly stateful and should be assumed to not be thread-safe.
I updated Ninject.MVC3 package from 2.2.1.0 to 2.2.2.0. Before I had access to the Kernel object through BootStrapper.Kernel property but in the new version Kernel property is marked as obsolete. I get a warning saying
'Public ReadOnly Property Kernel As Ninject.IKernel' is obsolete: 'Do not use Ninject as Service Locator'.
Is there a different way to access the kernel in the new version?
If you have a class that (for some reason) needs to retrieve objects from the Ninject kernel, you can include the kernel as one of the injected properties/constructor parameters on the class. This pattern is better in the sense that you're explicitly declaring that a particular class is using the kernel, rather than always having it available as the service locator pattern does.
This assumes that Ninject automatically adds an instance binding of the kernel to itself. I know that it used to do this, but if it doesn't you can add the binding manually.
The reason why this has been marked Obsolete and will be changed to internal in future is that people tend to use Ninject as a service locator if it is possible to do so. But Service Locator is an antipattern that should not be used. And as we don't want to provide functionality that helps building badly designed software it will be removed in future.
If this needs a lot of changes in your code this is sign that your code is suffering from this malaise Dependency Injection wise and you really should change it to a better design.
Limit your access to the kernel to a mimimum. There is almost no situation in MVC where you need something other than plain constructor injection. Therefore my first advice is to refactor to constructor injection where possible.
For these very rare cases where you need access to the kernel to create other objects you should inject a factory to the class that needs the new instance and inject the kernel into this factory (if the Constructor has a Kernel parameter, it'll receive the instance doing the injecting).
If you really want to stay with service locator even if almost everyone will tell you not to, you will have to keep a static reference yourself.
In ASP.NET MVC 3, I think DepedencyResolver is a clean way to get a service locator.
You could use the Common Service Locator as a service location hook into Ninject. The Common Service Locator only allows you to retrieve objects though, not inject objects that you already have. Of course you could hack around this restriction, but you could just as easily create a static class that exposes the Ninject kernel and reference that rather than the BootStrapper.
Is there any reflection performance considerations when repeatedly calling container.Resolve<T>() when a resolution has already been established?
I'm using it in an MVC controller to resolve my data service, so it will be called on every HTTP request. I'm storing the container instance in Application state, and I'm using container controlled lifetime so it maintains a singleton instance of my resolved class. My assumption is that while the container is alive and has created a new instance of the service, it will not need to use reflection on subsequent calls to resolve it.
I'm considering keeping a reference to the resolved class instead if performance of Resolve<T>() is an issue. But with the singleton lifetime setup, it seems like I would be duplicating something that's already built-in.
While not directly answering your question, Torkel Ödegaard's IoC container benchmarks suggest that you'll not be seeing a major performance hit related to resolving dependecies.