I was wondering if there was a way using Quarkus to see how beans are being pulled in. Like a tree or graph showing the hierarchy of bean resolution. I have a few beans that I think should be considered "unused", but they are still pulled in (I know because they fail with missing config properties).
That's an interesting idea. Would you care to file a new issue here: https://github.com/quarkusio/quarkus/issues?
By the way, "unremovable" beans do not need to be injected anywhere. There are other rules that apply. For example, a #Named bean or a bean that declares an observer method is never removed. Furthermore, Quarkus extensions can add their own rules.
Added enhancement issue to github: https://github.com/quarkusio/quarkus/issues/26065
PR: https://github.com/quarkusio/quarkus/pull/26153
Will be built to 2.11
Related
I just started a quarkus proof of concept. The containers-start time is amazing!
Right now, I'm working on the Dependency Injection part. And figuring out the options.
https://quarkus.io/blog/quarkus-dependency-injection/
My preferences are:
I prefer constructor injection. (This has been going ok).
I prefer "java config" so I can follow the "Composition Root" pattern of putting all my application dependency injections in a common place. (See https://blog.ploeh.dk/2011/07/28/CompositionRoot/ )
With Spring DI, this is done with the
org.springframework.context.annotation.Configuration
and declaring the Beans there.
Aka, I prefer not to place "#ApplicationScoped" annotations all over my classes.
Does CDI/Quarkus support a "java config" model? The reason I ask about quarkus is that I read quarkus has a limited CDI implementation.
//start quote//Our primary goal was to implement a supersonic
build-time oriented DI solution compatible with CDI. This would allow
users to continue using CDI in their applications but also leverage
Quarkus build-time optimizations. However, ArC is not a full CDI
implementation verified by the TCK - see also the list of supported
features and the list of limitations.//end quote
So my question isn't a solely CDI question.
I've tried different internet search terms, but they keep showing me Spring links. :(
You should create a CDI bean that will produce your beans, this is the standard CDI approach to what Spring calls Java Configuration.
So something like this
import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.inject.Produces;
#ApplicationScoped
public class MyConfiguration {
#Produces
public MyBean myBean(){
return new MyBean();
}
}
I have a multi module maven project (a Java EE app with ear, persistence, web, ejb, api, bl and other modules), where I'd like to use Weld CDI.
When I try to inject a bean, where will Weld search for injectable beans? Will Weld search in all the modules, where a beans.xml is placed to WEB-INF or META-INF regardless from their dependencies (or dependencies matter somehow?), or will Weld be able to inject a bean from an other deployment? I tried to find a document, which describes the mechanism and boundaries of bean lookup, but I haven't found anything yet.
What you're describing is part of the overall EE spec, not the CDI spec. but yes, in general the contents of your EAR will be discovered as distinct applications (per the EE spec). This means that you may not be able to access individual beans across JARs. It is highly recommended to use WAR deployment with CDI.
I tried to convert managed Beans ManagedBeans to CDIBeans simply by including #Named and #XxxScoped from javax.entreprise.context package. Along with the two JAR files cdi-api-1.1-PRD.jar javax.inject-1.jar. But it seem to be not as simple as that.
I wanted to know why?
Why isn't the above mentioned process
working?
Shouldn't CDI beans support functionalities of managed beans? Am I totally missing something here?
At least add empty beans.xml file to META-INF/ or WEB-INF/ in your archive.
There are other things you may need to do but that depends on your runtime environment.
There's a nice config example for Tomcat
I want to use CDI beans into JSF application. I'm interested is there any possible way to avoid the bean declaration into faces-config.xml file. I want to use annotations to declare the beans similar to JSF beans. Is there any possible solution?
There is no need to declare CDI beans anywhere (except for the according annotation on the injection point). All you need is a beans.xml - it may as well be empty - either in the META-INF or in the WEB-INF folder of your war.
For web applications it is a common practice to put the beans.xml in the WEB-INF folder.
Here you can find a nice explanation of the technical background.
We are using JDeveloper 11g.
Both a Model and ViewController project that makes use of ADF fusion and what not.
My web-xml has an EJB reference for a stateful session EJB .
I have a managed bean that's declared in faces-config.
I am trying to access a EJB from inside the managed bean.
I declare
#EJB (name ="LocationServicesEJB")
private LocationServicesEJB locationServices;
When accessing this in a method, the locationServices is null.
I do not see any JNDI type problems in the console,
so I imagine that it's not even bothering to lookup.
Do I need to enable injection or something?
Or do I need to define 'locationServices' as managed property in my faces-config?
Please advise.
Thanx
You are confusing two different types of injection.
There is EJB injection that happens among EJBs by the respective annotation. This type is handled by the EJB container (your application server or OpenEJB e.t.c)
Then there is "normal" injection (ala Spring) that happens between normal Java beans
and is defined in faces-config. This type is handled by JSF.
So decide what you want to do.
My proposal would be to download the official Java EE tutorial and skim through all topics.