Check this app: https://play.google.com/store/apps/details?id=pt.joaobrito.wcb
Now with auto refresh every 30 seconds! Try it today!
Posted from WordPress for Android
Category Archives: web
Why don’t you give it a try? The World Cup 2014 is here!
https://play.google.com/store/apps/details?id=pt.joaobrito.wcb
A simple but objective android app that allows you to follow the world cup championship of Brazil in real time no matter where you are…
Posted from WordPress for Android
New Android APP
The new version of the World Cup 2014 Brazil it’s here. Now with a different name and new look.
Check this app: https://play.google.com/store/apps/details?id=pt.joaobrito.wcb
Posted from WordPress for Android
World Cup Brazil 2014 – new version available
New version is now available in google play store with a lot of new features. Check it out!
Logger CDI Injection
In this post I will show you how to inject an instance of Logger class using CDI (Context Dependency Injection) and SLF4J (Simple Logging Facade for Java).
To keep it simple, we only have a xhtml page (index), a managed bean (Controller.java) and the producer (LoggerProducer.java). The project configuration is as follows:
As we are using JSF with facelets, the index page looks like:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<?xml version='1.0' encoding='UTF-8' ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://xmlns.jcp.org/jsf/html"> <h:head> <title>CDI Producer</title> </h:head> <h:body> <h2>The name is: #{controller.name}</h2> </h:body> </html> |
In this file we simply display the name that is setted in the controller (line 10).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
package pt.joaobrito.controller; import javax.annotation.PostConstruct; import javax.enterprise.context.RequestScoped; import javax.inject.Inject; import javax.inject.Named; import org.slf4j.Logger; @Named @RequestScoped public class Controller { @Inject private Logger logger; private String name; public Controller() { } @PostConstruct public void init() { logger.info("before setting the name: name = " + name); this.name = "John Doe"; logger.info("the name was setted to: name = " + name); } public String getName() { return name; } public void setName(String name) { this.name = name; } } |
In the controller we inject (@Inject) an instance of the Logger class and print to the console the name before and after the name is setted (lines 23 and 25). CDI knows which Logger to inject because we have a class that works as a factory of Loggers (LoggerProducer) with some special annotations.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
package pt.joaobrito.producer; import javax.enterprise.context.Dependent; import javax.enterprise.inject.Produces; import javax.enterprise.inject.spi.InjectionPoint; import org.slf4j.Logger; import org.slf4j.LoggerFactory; @Dependent public class LoggerProducer { @Produces public Logger newLoggerInstance(InjectionPoint ip) { return LoggerFactory.getLogger(ip.getMember().getClass()); } } |
In the LoggerProducer class we have an annotation (@Produces) in a method that returns a Logger instance. This is enough to CDI inject a Logger when needed. Notice that in line 13 we pass as a parameter the injection point (ip) in order to get the class where the logger is being injected (in this specific case ‘Controller.class’). This is only necessary beacuse the getLogger method needs it.
Finally, here are the results (the log and the web page):
log
As you can see here, we have two lines displaying the information that we expected: first the name is null and after the set of the variable name, name = John Doe.
That’s it. It’s just that simple!
Conclusion
First we create a factory of loggers, then we inject them whenever we need them:
@Produces to indicate CDI what we are producing and
@Inject to inject the instance ready to use.
Notice that this methodology works with other types rather than Logger. You may inject whatever you want by simply following the above technic.
Feel free to comment.
Java EE7: Creating HTML5 Pages Using JSF 2.2
Developer tools updated
Developer tools
Update: Easy Parameters
This is a tool for queries taken from logs, where we have queries and parameters unbinded. Take a look at the example.
You can also insert the parameters into the query text area instead, with the following text:
bind => [param1, param2, etc].
Feel free to use and comment.
Seven JavaScript Quirks I Wish I’d Known About | Telerik Developer Network
JSF 2.2 Flash Scope Example
JSF 2.2 Flash Scope Example
In this article I will try to explain you how to use the flash scope in Java EE.
Introduced in JSF 2.0, the flash scope provides a short-lived conversation (flash session). It is a way to pass temporary objects (not only strings) that are propagated across a single view transition and cleaned up before moving on to another view. The flash scope can only be used programmatically as there is no annotation.
In some cases we need to redirect from one view to another view in JSF. But when we do a redirect we lost everything that is stored in the url with a GET request. One solution is to use an EL expression of the abstract class Flash #{flash.foo}. So, this is a pretty simple solution to redirect without lost anything:
Source files:
index.xhtml
The special thing here is the use of #{flash.foo}, where foo is the name of the variable in the flash scope.
ExampleController.java
The goal of this controller is just to do a redirect from the index.xhtml to the target.xhtml.
target.xhtml
Here we fetch the value of the foo variable by doing again #{flash.foo} to display the data.
The results:
This is the first page with the message Hello World.
And finally this is the second page (target.xhtml) wich displays the message from the previous page.
Final Considerations
We’ve learned how to pass values with the help of flash from one view to another with redirects.
Notice that if you refresh the second page after it shows up, all the data has gone. That’s because the flash scope was destroyed immediately when the rendering of the second page occurs. This is the goal of the flash scope. It just holds some values (in a flash session) between one HTTP request and the subsequent HTTP response.
This type of scope must be done programmatically. There is no annotation, like there is, for example, to the request scope (@RequestScoped).