Jakarta Faces 4.0 introduced a new #ClientWindowScoped annotation. However, searching the specification and implementations, I haven't found any example of its practical use in applications.
Maybe it's not only the case to annotate a bean with this annotation, but also to manipulate the jfwid request parameter through some provided API. If that's the case, can anyone provide a simple example of how it can be used or point to an article that does?
Related
I was trying to find a non-XML (Java Annotation/DSL) example of using timeout as a release strategy, but was unable to do so. (Such as TimeoutCountSequenceSizeReleaseStrategy...)
My goal is to release after some delay since the last correlated entry was added.
What you are looking for is called groupTimeout. See AbstractCorrelatingMessageHandler.setGroupTimeoutExpression().
If you are looking for the solution via annotation, you should consider to use AggregatorFactoryBean with the #ServiceActivator and #Bean annotations.
When we talk about Java DSL, there are groupTimeout()/groupTimeoutExpression() options on the CorrelationHandlerSpec when you configure an .aggregate(a -> ...) in the IntegrationFlow.
See Reference Manual for more information.
JSF provides the #ResourceDependency annotation that can be used with instances of javax.faces.component.UIComponent or javax.faces.render.Renderer.
My question now is: when and where are these annotations processed? I'm particularly interested in how Oracle's JSF implementation handles these.
I'm particularly interested in how Oracle's JSF implementation handles these.
They are processed via com.sun.faces.application.annotation.ResourceDependencyHandler when the component/renderer is being instantiated. The annotation metadata is however parsed once and cached applicationwide in com.sun.faces.application.annotation.AnnotationManager. This is called by a.o. com.sun.faces.application.ApplicationImpl#createComponentApplyAnnotations() implementation which is called by a.o. Application#createComponent() interface.
I don't know If this is the right place to ask this question.
How do I make some non technical person to understand "Facelets as View technology"?
I try it.
If you use JSF as presentation layer you can use the advantages of input validation for forms, have a direct data binding to one or more ManagedBeans also known as PoJos with annotation #ManagedBean or #Model/#Named...
JSF components also support the usage of Ajax, so you can update tableviews asynchronous after adding new entries for example.
summarizing in my opinion it is easier to built a modern feeling site by using JSF, there are many different implementations e.g. primefaces, richfaces, etc. so you have the choice which framework you'll use.
Hope this helps, maybe the community can add more.
Patrick
Part of my problem here is using the proper vocabulary, so I apologize in advance for what might be a simple matter of terminology.
Suppose I have a Person interface, and a PersonBean class that implements that interface.
Suppose further I have a producer method somewhere (annotated #Produces) that returns a Person. Internally it returns a new PersonBean, but that's neither here nor there.
Finally, suppose I have another CDI bean somewhere with an injection point defined like this:
#Inject
private Person person;
Assuming I have all my beans.xml files in place etc. and have bootstrapped Weld or another CDI-1.0-compliant environment, as this all stands I will get an ambiguous definition error. This makes sense: Weld will find my PersonBean as a candidate for injection (it could just call the constructor) and will find the output of my producer method as a candidate for injection.
What I'd like to do is somehow force the production of Person instances in this application to always route through the producer method.
I understand I could invent some qualifier somewhere and make the producer method produce Person instances that are qualified by that qualifier. If I do that, and change my injection point to include the qualifier, then obviously there's only one source of these qualified injectables (namely my producer method), so voila, problem solved.
But suppose I don't want to invent some bogus qualifier. (I'm not saying this is the case; just trying to more deeply understand the issues.) What are my options? Do I have any? I suppose I could put #Typed(Object.class) on the PersonBean to make it so that it was not seen as a Person by CDI....
Any ideas welcomed, including pointers to documentation, or better ways to understand this. Thanks.
Annotate you PersonBean as #Alternative then it will use the producer method.
From digesting several different answers here and elsewhere, the solution I've adopted is to use the #Typed annotation with a value of Object.class on my bean. This means that it will only be eligible to be injected into fields that are declared like this:
#Inject
private Object something;
...which thankfully prove to be pretty much nonexistent. :-)
What I'd like to do is somehow force the production of Person
instances in this application to always route through the producer
method.
Seam solder has a solution for this.
I'm not 100% sure how this will develop with the merge of Seam 3 and Deltaspike (the page is so 90s, but the content rocks :-), but putting Solder in your classpath is certainly a safe bet.
Oh, and as far as I know a comparable mechanism made it into the CDI 1.1 spec.
So Meta Programming -- the idea that you can modify classes/objects at runtime, injecting new methods and properties. I know its good for framework development; been working with Grails, and that framework adds a bunch of methods to your classes at runtime. You have a name property on a User object, and bamm, you get a findByName method injected at runtime.
Has my description completely described the concept?
What else is it good for (specific examples) other than framework development?
To me, meta-programming is "a program that writes programs".
Meta-programming is especially good for reuse, because it supports generalization: you can define a family of concepts that belong to a particular pattern. Then, through variability you can apply that concept in similar, but different scenarios.
The simplest example is Java's getters and setters as mentioned by #Sjoerd:
Both getter and setter follow a well-defined pattern: A getter returns a class member, and a setter sets a class member's value. Usually you build what it's called a template to allow application and reuse of that particular pattern. How a template works depends on the meta-programming/code generation approach being used.
If you want a getter or setter to behave in a slightly different way, you may add some parameters to your template. This is variability. For instance, if you want to add additional processing code when getting/setting, you may add a block of code as a variability parameter. Mixing custom code and generated code can be tricky. ABSE is currently the only MDSD approach that I know that natively supports custom code directly as a template parameter.
Meta programming is not only adding methods at runtime, it can also be automatically creating code at compile time. I.e. code generating code.
Web services (i.e. the methods are defined in the WSDL, and you want to use them as if they were real methods on an object)
Avoiding boilerplate code. For example, in Java you should use getters and setters, but these can be made automatically for most properties.