Friday, November 28, 2008
Where is Spring 3.0M1?
Well, Thanksgiving came and went by but no Milestone 1 release of Spring 3.0 available, yet. But it looks like all open issues for M1 have been resolved. Oh well...
Wednesday, November 26, 2008
Configure Logback from your Web Application at Runtime
As mentioned in one of my earlier blog posts, I migrated my OSS project from Apache Commons Logging and Log4j to Simple Logging Facade for Java and Logback. One piece however that was left open was my web logging component. It gives you access to your log files from within the administrative area of your web application. Not only can you download the current logfile, but you can also change the log levels at runtime. Just in case some of your app's users hit an issue and you can't SSH into the server that very moment but have web access - at least you can gain an overview of the situation quickly.
Here is a screen-shot of my application's logging component:
The tables are rendered using the JMesa data grid, which works very nicely. The tables are paginated and the columns are sortable as well as filterable. Furthermore, the table is refreshed via AJAX using the jQuery JavaScript library.
On this page you can:
Although I originally used Log4j to retrieve the required logging data, the conversion over to Logback has been fairly straightforward. Here is one of the methods that interacts with logback and returns a collection of loggers:
Here is a screen-shot of my application's logging component:
The tables are rendered using the JMesa data grid, which works very nicely. The tables are paginated and the columns are sortable as well as filterable. Furthermore, the table is refreshed via AJAX using the jQuery JavaScript library.
On this page you can:
- View your log files
- Download the logfile as text file
- View the configured loggers
- View all available logger
- Set logging levels for any of the available loggers
Although I originally used Log4j to retrieve the required logging data, the conversion over to Logback has been fairly straightforward. Here is one of the methods that interacts with logback and returns a collection of loggers:
public static List <ch.qos.logback.classic.logger> getLoggers(boolean showAll) {Anyway if you look for something similar for your own application, you can download all the relevant source code here. Please be aware that the archive is not a full demo application but rather a couple of source files cobbled together. If you rather like to see an entire buildable demo application, just let me know.
final LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
final Listloggers = CollectionUtils.getArrayList();
for (ch.qos.logback.classic.Logger log : lc.getLoggerList()) {
if(showAll == false) {
if(log.getLevel() != null || LoggingUtil.hasAppenders(log)) {
loggers.add(log);
}
} else {
loggers.add(log);
}
}
return loggers;
}
Thursday, November 20, 2008
Book Review: jQuery in Action
jQuery in Action by Bear Bibeault and Yehuda Katz is an excellent book for learning the jQuery JavaScript library. In my opinion the book is suitable for beginners as well as advanced developers that like to explore jQuery. It is also a good reference book as it describes all the essential functionality offered by jQuery in a nicely structured manner.
I belong to the category of developers that used Prototype in the past. The funny thing is though that both libraries offer almost identical sets of functionality. You may ask why did I decide to go with jQuery?
I like its innovative way of querying for page elements and to iterated over them, allowing you to often accomplish multiple tasks with just one line of code. jQuery in Action starts out explaining those core concepts of jQuery in the first 3 chapters of the book - allowing to query for page elements using the CSS syntax, how to manipulate page elements as well as how to work with collections of elements. The book does a very good job explaining those aspects of jQuery combined with many useful examples.
What also drove me to jQuery was the fact that it has a plug-in mechanism that allows you to either use additional third party add-ons or to write your own plug-ins by still adhering to the spirit of jQuery.
In that regard it is also worth mentioning that the jQuery website is "really nice" with a ton of documentation and also providing a plugin-repository, something Prototype is lacking. Thus, for the majority of your JavaScript needs, there is now a one-stop place to get it all.
Unfortunately, the authors do not provide a comparison between both wildly popular javascript libraries Prototype and jQuery even though Bear Bibeault has been a coauthor of Prototype and Scriptaculous in Action. It would have been nice if chapter 1.1 Why jQuery detailed some pros and cons in that respect.
Generally, throughout the book, the authors encourage certain valuable patterns you should follow to write good unobtrusive JavaScript code using jQuery. I particularly like that aspect of the book as it shows you efficiently how to separate page markup from JavaScript code.
In that regard it would have been nice, though, if the authors had mentioned YSlow as another tool to analyze you page markup, which includes the recommendation to place JavaScript at the bottom of your page rather then on the top, if possible.
Anyway, there shouldn't be any need to declared the onclick attributed on page elements directly any longer. It all can be separated using JavaScript events which is well described in the book.
Speaking of handling JavaScript events, I think the authors should have further mentioned the concept of event delegation. Instead, they describe how to use the Live Query plugin in order to solve a similar issue. After reading the respective chapter, I was going to further dive into Live Query but a fellow blogger pointed out NOT to use Live Query as "it is very performance heavy" but rather to use event delegation.
I guess this is a drawback writing a book about a subject that is evolving with the speed of light.
Nevertheless, despite all my critical remarks, I think that jQuery in Action is an excellent book that will help you learn and understand jQuery. I certainly enjoyed reading the book.
I belong to the category of developers that used Prototype in the past. The funny thing is though that both libraries offer almost identical sets of functionality. You may ask why did I decide to go with jQuery?
I like its innovative way of querying for page elements and to iterated over them, allowing you to often accomplish multiple tasks with just one line of code. jQuery in Action starts out explaining those core concepts of jQuery in the first 3 chapters of the book - allowing to query for page elements using the CSS syntax, how to manipulate page elements as well as how to work with collections of elements. The book does a very good job explaining those aspects of jQuery combined with many useful examples.
What also drove me to jQuery was the fact that it has a plug-in mechanism that allows you to either use additional third party add-ons or to write your own plug-ins by still adhering to the spirit of jQuery.
In that regard it is also worth mentioning that the jQuery website is "really nice" with a ton of documentation and also providing a plugin-repository, something Prototype is lacking. Thus, for the majority of your JavaScript needs, there is now a one-stop place to get it all.
Unfortunately, the authors do not provide a comparison between both wildly popular javascript libraries Prototype and jQuery even though Bear Bibeault has been a coauthor of Prototype and Scriptaculous in Action. It would have been nice if chapter 1.1 Why jQuery detailed some pros and cons in that respect.
Generally, throughout the book, the authors encourage certain valuable patterns you should follow to write good unobtrusive JavaScript code using jQuery. I particularly like that aspect of the book as it shows you efficiently how to separate page markup from JavaScript code.
In that regard it would have been nice, though, if the authors had mentioned YSlow as another tool to analyze you page markup, which includes the recommendation to place JavaScript at the bottom of your page rather then on the top, if possible.
Anyway, there shouldn't be any need to declared the onclick attributed on page elements directly any longer. It all can be separated using JavaScript events which is well described in the book.
Speaking of handling JavaScript events, I think the authors should have further mentioned the concept of event delegation. Instead, they describe how to use the Live Query plugin in order to solve a similar issue. After reading the respective chapter, I was going to further dive into Live Query but a fellow blogger pointed out NOT to use Live Query as "it is very performance heavy" but rather to use event delegation.
I guess this is a drawback writing a book about a subject that is evolving with the speed of light.
Nevertheless, despite all my critical remarks, I think that jQuery in Action is an excellent book that will help you learn and understand jQuery. I certainly enjoyed reading the book.
Wednesday, November 19, 2008
Spring Presentation @ AJUG
Today Keith Donald gave a presentation about Spring web application development at the Atlanta Java Users Group. It has been a great presentation. The room at the Holiday Inn was packed and people were actually standing in the back (At least 100+ attendees).
The talk covered mostly the following area:
I have not actively developed using Spring MVC since version 2.0 and therefore the annotation support in 2.5 is realy quite nice compared to the old style. Keith showed some examples of how far you can go with annotating your action controllers as well using conventions over configuration. They way you write your controllers in 2.5 reminds me of Struts 2 actions - just better (plus the current stable release Struts 2.0.x does not have annotations support, yet.)
I wonder, especially with the 3.0 release, whether there is still any reason left to use Struts 2...but that's just my personal opinion.
Spring Javascript was another component Keith talked about. Currently part of Spring Webflow 2.0 it will eventualy become its own top level project.
It is a "lightweight abstraction over common JavaScript toolkits such as Dojo". Personally, I don't like DOJO for my typical web application development needs - it's too heavy. I rather use jQuery and DWR instead to add common AJAX functionality to my pages.
But, Spring Javascript has some interesting aspects such as gaceful degradation in case Javascript is disabled.
As Keith was getting close to the end, he only briefly talked about Spring Webflow 2.0 and Spring Faces. I wish Keith had mentioned a little bit more about the conversational state support that is supposed to be included in Spring MVC 3.0. In my current project we have the requirement to support multiple tab browsing for the same application. Thus, it would be nice to see how Spring is solving this requirement.
Nevertheless, it has been a nice informative talk and also, Keith will be back in Atlanta March 10 and 11 for the AJUG sponsored developer conference at the Cobb Galleria.
The talk covered mostly the following area:
- Spring MVC
- Spring Javascript
- Spring Webflow
- Spring Faces
I have not actively developed using Spring MVC since version 2.0 and therefore the annotation support in 2.5 is realy quite nice compared to the old style. Keith showed some examples of how far you can go with annotating your action controllers as well using conventions over configuration. They way you write your controllers in 2.5 reminds me of Struts 2 actions - just better (plus the current stable release Struts 2.0.x does not have annotations support, yet.)
I wonder, especially with the 3.0 release, whether there is still any reason left to use Struts 2...but that's just my personal opinion.
Spring Javascript was another component Keith talked about. Currently part of Spring Webflow 2.0 it will eventualy become its own top level project.
It is a "lightweight abstraction over common JavaScript toolkits such as Dojo". Personally, I don't like DOJO for my typical web application development needs - it's too heavy. I rather use jQuery and DWR instead to add common AJAX functionality to my pages.
But, Spring Javascript has some interesting aspects such as gaceful degradation in case Javascript is disabled.
As Keith was getting close to the end, he only briefly talked about Spring Webflow 2.0 and Spring Faces. I wish Keith had mentioned a little bit more about the conversational state support that is supposed to be included in Spring MVC 3.0. In my current project we have the requirement to support multiple tab browsing for the same application. Thus, it would be nice to see how Spring is solving this requirement.
Nevertheless, it has been a nice informative talk and also, Keith will be back in Atlanta March 10 and 11 for the AJUG sponsored developer conference at the Cobb Galleria.
Friday, November 14, 2008
Some links regarding Spring 3.0
Can't wait to get my hands on Spring 3.0. The improvements for Spring MVC look very cool.
http://juliensimon.blogspot.com/2008/11/spring-conference-in-paris-part-3_13.html
http://raibledesigns.com/rd/entry/what_s_coming_in_spring
Plus Keith Donald presenting at the Atlanta Java Users Group next Tuesday. Stay tuned for more information from that event.
http://juliensimon.blogspot.com/2008/11/spring-conference-in-paris-part-3_13.html
http://raibledesigns.com/rd/entry/what_s_coming_in_spring
Plus Keith Donald presenting at the Atlanta Java Users Group next Tuesday. Stay tuned for more information from that event.
Tuesday, November 11, 2008
Migrating from JCL+Log4j to SLF4J+Logback
For my OSS project I went through the exercise of migrating from Apache Commons Logging (JCL) and Log4J to the Simple Logging Facade for Java (SLF4J) and Logback.
Logback is considered to be the successor of Log4J and is being developed by the same developer that originally developed Log4J. In return SL4J serves as a replacement for JCL.
There are already quite a few projects that use SL4J including Hibernate, Mule and Jetty to name just a few.
The migration process has been quite easy. The necessary code changes are minimal. They are virtually the same as before and the new way of declaring your loggers is:
The nice thing about SLF4J is that it provides various components that help you bridge older logging libraries such as JCL and Log4J. Therefore, even your third-party libraries that don't support SLF4J and Logback directly will ultimately use them when using those bridging components. The result: No need to have Log4J of JCL in your classpath. Nice.
The only potential headache is that if you are using Maven for your dependency management, then your direct dependencies often have transitive dependencies that include JCL.
Well, you could manually exclude the JCL depency for each of your dependencies but what a pain, even when dealing with a moderately sized project. Luckily there is a workaround available: "commons-logging version 99.0-does-not-exist". It basically downloads a fake 0 byte JCL jar. Not necessarily pretty, but hey, it works as promised.
Furthermore, I hit one more minor issue with the Jawr library: the current version is using Log4J directly. The developer of Jawr promised that in the near future they will migrate to....well...unfortunately not SL4J but rather JCL. Anyway, by using the log4j-over-slf4j bridge I was able to work around that issue, too.
Well there is one task left for my project's logging framework conversion: I have a section in my web application that allows you accessing your loggers dynamically, which also permits you to adjust log levels dynamically at run-time. So far I was using Log4J directly to implement the necessary functionality...but that is worth another blog entry another time.
Logback is considered to be the successor of Log4J and is being developed by the same developer that originally developed Log4J. In return SL4J serves as a replacement for JCL.
There are already quite a few projects that use SL4J including Hibernate, Mule and Jetty to name just a few.
The migration process has been quite easy. The necessary code changes are minimal. They are virtually the same as before and the new way of declaring your loggers is:
/**
* Logger Declaration.
*/
private final static Logger LOGGER = LoggerFactory.getLogger(MyClass.class);
For converting your old log4j.properties file to logback's logback.xml equivalent, there is an online converter available. It worked quiet well, I had to do only one minor tweak for my config file.The nice thing about SLF4J is that it provides various components that help you bridge older logging libraries such as JCL and Log4J. Therefore, even your third-party libraries that don't support SLF4J and Logback directly will ultimately use them when using those bridging components. The result: No need to have Log4J of JCL in your classpath. Nice.
The only potential headache is that if you are using Maven for your dependency management, then your direct dependencies often have transitive dependencies that include JCL.
Well, you could manually exclude the JCL depency for each of your dependencies but what a pain, even when dealing with a moderately sized project. Luckily there is a workaround available: "commons-logging version 99.0-does-not-exist". It basically downloads a fake 0 byte JCL jar. Not necessarily pretty, but hey, it works as promised.
Furthermore, I hit one more minor issue with the Jawr library: the current version is using Log4J directly. The developer of Jawr promised that in the near future they will migrate to....well...unfortunately not SL4J but rather JCL. Anyway, by using the log4j-over-slf4j bridge I was able to work around that issue, too.
Well there is one task left for my project's logging framework conversion: I have a section in my web application that allows you accessing your loggers dynamically, which also permits you to adjust log levels dynamically at run-time. So far I was using Log4J directly to implement the necessary functionality...but that is worth another blog entry another time.
Subscribe to:
Posts (Atom)