I hesitate to ask yet another question on the same topic, but at least now I'm reading, I think, the right docs.
So, this class:
class FacesContextProducer {
#Produces #RequestScoped FacesContext getFacesContext() {
return FacesContext.getCurrentInstance();
}
}
From the weld docs this method does, in fact, apply to Glassfish through: GlassFish is using WELD as the reference implementation for JSR-299: Java Contexts and Dependency Injection for the Java EE platform (CDI).
For the above class, where would it be used? Why do you need a separate class which #Produces a FacesContext?
For the above class, where would it be used? Why is he trying to inject FacesContext?
I think it is done either for
consistency; or
testing.
ad 1. If one tries to do pure CDI, it looks nice when you're not using other dependency lookup mechanisms (as getCurrentInstace() static method). Note that it is really not needed to define a producer and use injection. It is just convenient and consistent with usage of CDI.
ad 2. is explained by blog McDowell links to, just imagine the injection is done with CDI.
Why do you need a separate class which #Produces a FacesContext?
This does not need to be a separate class, you can have single class producing multiple beans. It just helps the clarity of the code to have it separate.
You might want to inject the FacesContext to avoid direct reliance on the static getCurrentInstance() method to make mocking and unit testing simpler.
I've written a bit about that for JSF's own dependency injection mechanisms here.
Related
I tried to follow this instruction https://rpestano.wordpress.com/2013/06/30/cdi-custom-scope/
, but it's not working, because the methods of my custom Context are not fired.
You can declare custom scopes in Quarkus. However, Quarkus does not use a full CDI implementation, instead it has a lighter implementation that does not support everything you know from CDI the way you are used to. Reasons are multiple but mostly it is done in order to make it build time friendly.
CDI extensions are one of the things that are inherently runtime based and as such are a bad fit for Quarkus stuff. Instead, you will have to use a Quarkus extension to declare your scope/context. Let me give you some materials for that...
Here is a link to Quarkus CDI guide in general, it lists its limitations and how it compensates for it.
This bit in particular shows how to register a custom scope within extension. The method is as simple as:
#BuildStep
ContextRegistrarBuildItem customContext() {
return new ContextRegistrarBuildItem(new ContextRegistrar() {
public void register(RegistrationContext registrationContext) {
registrationContext.configure(CustomScoped.class).normal().contextClass(MyCustomContext.class).done();
}
});
}
And here is a link to how Narayana Quarkus extension uses this exact same API to register #Transactional. The underlying context class is very similar to what you would use in CDI (or in Weld), take a look at this class that Narayana uses for inspiration.
I'm wondering if changing the EL resolver so a bean can use public fields in jsf could cause issues with the proxies? [That's why it isn't a duplicate.] Aall managed bean fields have to be private in the framework, because that's how the EL resolver does things. However it's a bit cumbersome and looks useless most of the time.
#Named
#RequestScoped
public class myBean{
public int age;
}
So would it cause issue with proxies trying to intercept things or whatnot?
This guy in this question apparently changed the el resolver so it's doable
Unfortunately yes, it will mess with CDI.
Why? Because public field access is impossible when bean is proxied. With Weld during startup you will get a definition error:
WELD-000075: Normal scoped managed bean implementation class has a public field ...
It's going to work fine only for non-proxied scopes (#Singleton and #Dependant).
I agree it's a bit cumbersome and looks useless sometimes, so you have two solutions:
Use IDE to generate them automatically.
Use lombok project.
But none of them is perfect.
I am using SpringFramework for web server.
Sometimes I need to do asynchronous task to implement certain function.
Usually, I prefer to use
#Inject #Component(which is implements Runnable) in #Service.
But I am not sure is it OK or not.
So I got a question just like the title.
'#Inject thread bean in #Service'
OR
'#Inject service bean in #Component'
I want to know which way is more frequently uses.
Thanks in advance:D
Have a good Day!
EDIT:
Based on edited question and commentary the answer has been changed.
#Component is generic
#Service is specific
#Inject is replaced by #Autowired
You always want to use #Autowired #Service instead of other combinations.
For architectural differences you will only get information from the API documents themselves.
for further detail check this out:
What's the difference between #Component, #Repository & #Service annotations in Spring?
I am developing webapp where my MVC controller is JSF 2.1. I have several methods that are based on
FacesContext.getCurrentInstance()
I use this to
put/retrieve values from Flash scope
add messages on view
get request params map
examples:
public void addInfoMessage(String title, String description){
FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO,title, description));
}
and
public void putFlashMessage(String code, String value){
FacesContext.getCurrentInstance().getExternalContext().getFlash().put(code, value);
}
etc.
I'm just wondering where is proper place to put this methods if I use this on every single managed bean? I consider two options:
a) create class "JSFUtils", where all method are public and static
b) create super class "ManagedBean" with no declared scope and no declared #ManagedBean annotation, but with these public methods. Every managed bean should be child of these class so it will have inherited these methods.
An utility class is the recommended approach. Instead of reinventing your own, you can use an existing JSF utility library, such as OmniFaces which has Faces and Messages utility classes for the purpose.
String foo = Faces.getRequestParameter("foo");
Messages.create(summary).detail(detail).add();
Messages.addGlobalInfo(summary); // Without detail.
Faces.setFlashAttribute(key, value);
You can indeed also abstract it away as a "super bean", but this is not reusable and you would keep repeating yourself in every JSF project. Also, a class can extend from only one class. So if your bean happen to need to extend from another super class, then you're lost.
I would recommend a utility class for the purpose simply because you allow the flexibility to extend other useful classes, such as those that have some common logic that you'd like to share across other beans.
Having said that, a JSFUtils class can grow quite cluttered with time with many many methods and can become very unmanageable. It would be better to categorize the util methods and put them in separate static utility classes.
I can't find any guidance on this question. I am writing a composite component that needs its own backing bean because it interacts with a data base.
The new component also needs to be able to set a value in some other backing bean as the result of some user action.
To do this, the question is do I have to write a #FacesComponent java class or a regular #Model/#Named (I use CDI annotations) type of bean? If you can use either, what is the advantage of one or the other?
Secondary question: will I be able to use CDI #Inject into a #FacesComponent to get my DAOs and such?
Update: I discovered that I can access cc.attr objects with the following code in a regular backing bean:
FacesContext fc = FacesContext.getCurrentInstance();
Object obj = fc.getApplication().evaluateExpressionGet(fc,
"#{cc.attrs.model.location}", Location.class);
So this allows me to obtain attributes. I haven't found out how I can write them yet.
So it seems that the only real reason to do a #FacesComponent is if you want to write rendering code that will output something the normal Facelets tags won't render. Is this correct?
I think BalusC responded to this basic question in this thread.
The main advantage is the ability of a #FacesComponent to access attributes that a UIComponent normally has access to, rather than trying to tie in with EL expressions executed in the bean.