I am writing an RCP application in eclipse. When I load my application my application models are loaded from a file in the disk and injected with context.
Using a profiler I noticed that the inject method slows me down...
Is this a known issue?
Thanks
The short answer is no they aren't slow.
The first injection of a class which is not already in the context may mean that the class has to be constructed but this is no slower than normal class construction.
I have nearly 800 #Inject statements in one of my RCPs and this does not cause any problems.
Related
Is it possible to use EclipseLink with QUarkus? Or is Quarkus too hardly coupled with Hibernate?
We are in the process of choosing our MP implementation and we want to stick as close to the reference impls as possible
I am not seeing much information on https://quarkus.io/guides/ or even this very forum to indicate that eclipselink too can be used with Quarkus.
Any pointers on why Quarkus is tied so tightly to a specific impl (if it is) of JPA would also be welcome
TIA
Rahul
You can use EclipseLink by adding it in your classpath as fxrobin mentioned. But it won't work for native image generation, nor will be integrated with the database connection pool, the transaction enlistment etc. Finally the startup time will be much longer.
The reason Quarkus focuses on Hibernate ORM is exactly for these reasons. Making Hibernate ORM work on native, making it do work at build time to speed startup time, smoothly integrating it with other areas takes a lot of time. Someone could make the same for EclipseLink with a few months of work ahead of them.
You can add EclipseLink in a class way as if you were in Java SE. But then you have to manage the transactional behaviour by code but not with annotations.
I am a newcomer to C# / .Net / Prism / WPF / DevExpress and started to work on a big project in my company. As I am starting a bit late in the project, a lot of code was already produced and I stumble upon code like this very often:
public class AboutWindowViewModel : BindableBase
{
public AboutWindowViewModel(IUnityContainer container)
{
...
What I find "special" here is the dependence of the view model in the container. In the codebase I am currently looking at, it seems to be the "pattern". Every class gets a dependence in the IUnityContainer and then the dependencies are resolved manually with e.g.
container.ResolveEx<...>(...);
I am used to work with DI frameworks in other languages, so that example was just a non-sense to me because it goes against the definition of a DI framework and the problems it is meant to solve. For example, I tried to make up some code to test one of those view models and it turned out to be a nightmare.
Now, I addressed that concern to the developpers of my company and they answered me the following:
Prism recommendation is to resolve services using containers as they are needed.
Therefore, they resolve them all the time with the IUnityContainer.ResolveEx method.
My question is: is that really the recommended way to build up software with Prism??? If not, do you know where I can find documentation that clearly addresses that point with examples?
is that really the recommended way to build up software with Prism???
Not at all, in it's an anti-pattern.
Prism recommendation is to resolve services using containers as they are needed.
Not really just Prism, but more generally, the recommendation is to let the container resolve the dependencies. Of course, this can be done by calling Resolve manually, but in doing that one defeats all the benefits expected from dependency injection.
Rather, you want to list the dependencies as constructor parameters and let the container fill them. Your code does not need to depend on the container, except for the very entry-point ("resolution root"). The application should only ever contain a single Resolve statement that resolves the first instance.
Here's where Prism comes into play: in your PrismApplication.RegisterTypes and IModule.RegisterTypes, you configure your container. You tell it which type should implement which interface. Later on, when view models are needed, Prism (the ViewModelLocator to be precise) uses the container to resolve the view models, thereby resolving all the dependencies. There's no reason to make any class depend on the container, in fact, Prism doesn't register anything for IContainerRegistry in the first place.
Keep in mind that the container can not only inject singleton services, but also transient instances or factories. And if you need parametrized factories, you can always manually create and register complex factories.
On a side-note, I, personally, would be hesitant to work for a client with a code-base like this, as it's an obvious proof that their developers have no idea what they're doing.
I am working on an E4 RCP application and, while our basic DI configuration is working, I have some reservations about our current implementation.
The IInjector interface and #ProcessAdditions annotation are tagged as being discouraged for external access. Currently, we are using a series of statements similar to
injector.addBinding(IInterface.class).implementedBy(Concrete.class);
from within a method marked as #ProcessAdditions. What method(s) can be used that don't violate access rules? I know I can bind classes/strings to instances via IEclipseContext, but using ContextInjectionFactory by hand seems to force order of construction to be known by configurer (as opposed to other DI frameworks).
I know Guice has the concept of child injectors, but in E4, ContextInjectionFactory is internally set to use only the default injector for manufacturing. What is the best method to manufacture a group of objects, using DI, and subsequently disposing of this group? I would like to create a fresh batch of processing objects for each processing operation.
ContextInjectionFactory is the only thing I have seen described for doing injection in e4 (in Lars Vogel's 'Eclipse 4 RCP' book for example). This is what I use in my e4 applications.
Some things, such as #ProcessAdditions are marked as discouraged because that part of the e4 API has not been finalized yet and might change, they can still be used. #ProcessAdditions is only used for the application Life Cycle class.
In some implementations, I've seen jsp's using java bean classes acting as an intermediate store/data access layer to get data from a jcr.
Why is this, since the jsp can access the jcr directly via the jcr api.
Separation of concerns? Memory cache for the data?
Just wondering why such a pattern exists when the jcr api was written in the first place.
Using scriptlet's might not be so problematic in smaller installations but is in large multi site projects.
Separating UI code and model/business logic eases maintainability and allows reusability of code upon projects. Also changing layout's gets much easier. Usually this seperation is done by using a component bean to access the JCR repo and to provide the data and by using the JSP just for the view.
Just imagine that your customer requires a large UI change propably in multiple sites. It's harder to change JSPs mixed up with scriptlets and UI code, especially if you have a lot of them.
From an OO perspective using JSPs and scriptlets prevents you from using inheritance and composition. Scriptlet's can not be made abstract.
I experienced that java beans are easier to debug then scriptlets, especially in case of an exception and java beans can be easier unit tested.
I’m using jboss and cmt and have seen strange behaviour when using requires_new on an ejb method that I loop over from another bean to insert some records.
I see that intermittently after restarting the jboss the operations in the method aren’t committed to db after the method is finished.So, I have tried to use TransactionSynchronizationRegistry and found that when the data isn’t committed I actually don’t get a new transaction each time the method is entered. Anyone who has heard of jboss acting this way? I'm using ejb, jboss, jpa, Hibernate, cmt.
So, I've finally solved this problem. I used this great blog post
http://piotrnowicki.com/2011/11/am-i-in-the-same-transaction-am-i-using-the-same-persistencecontext/
to make sure that I actually was in the same transaction after entering the method annotated REQUIRES_NEW. So then I understood that JBoss intermittently ignored the annotation and defaulted to REQUIRED instead. This was because multiple classes implemented the same interface. So I simplified it so that I now have one interface, annotated #Local, and one implementing class where the REQUIRES_NEW annotated method is.
I understand that in this case it was our code that was wrong so it's not really a bug in Jboss way of handling transactions. But it's really strange that there isn't as much as a warning in the logs that there is a race condition. I could restart the Jboss and get a different behavior than before the restart. I think that's strange. I haven't found much about that this could be a problem after googling so I hope that this answer can save some time for someone else.
Edit:
It's not about multiple implementing classes, just about declaring all the methods in the interface annotated #Local, otherwise JBoss might ignore the attributes