In my opinion this new project will be very important to the ASF. Apache only hosts two other PHP projects, Log4PHP and Shindig. Since PHP is becoming more and more popular for big business (think on Facebook) I think its necessary to attract more developers and bring them into the Apache community. Many PHP projects out there use the GPL license, and that is sometimes very difficult to combine with commerical work. Good that we now have a component framework under ASL! Together with Log4PHP it’s a good start for much proprietary work.

More in future, I think that even the PIWI Framework will benefit of this change. I already had some trouble with dependent GPL code in it and hopefully Zeta can address most of my wishes. PIWI built upon Log4PHP and Zeta would be charming. But as already said, this will need a while.

At the moment, Zeta Components do already have a mailinglists and status page on the incubator. Jira will follow and after finally the CLAs of the initial developers have been processed, work can begin. However, if you are interest in helping this project subscribe to the user and to the dev list mentioned in the status page.

Lucky me I have been elected into the Apache Incubator PMC and can now serve as a mentor to this project. It’s not only honour to me, it’s also a good chance to work with obviously very nice people and excellent technicians. Also it makes it easy to me to step into this project and learn all I need.

So, welcome Zeta Components!! I am glad you arrived at the Apache Software Foundation!

Localization does not work out of the box in WordPress. But the concepts in WordPress allow to use a combination of custom fields and themes to make this work. I refused to translate all my blogposts and for only pages it is very straightforward.

First I created my pages in the wordpress pages section. In the Custom fields I used a new meta key named “language” and put as value “de” or “en” for german or english.

I couldn’t use the Pages Widget, because I need to generate my navigation out of the selected language. Not to conflict with my current implementation I duplicated my current theme and used the preview function to work on it (on a live system, which is a really great feature for prime time programming). I should mention that I created two pages, one for each language, only stating that the language has been changed.

Next step was to include the language flags in my theme (header.php in my case). I linked the flags to my newly created “language switched” pages. Additionally I have added the param language=de (or en for english) to the link. My complete link for the german language is as follows:

http://www.grobmeier.de/deine-sprache-wurde-umgestellt?language=de

Ok, I am now able to link between the languages. In my header.php I wrote this:

session_start();

include(TEMPLATEPATH . '/grobmeier-session.functions.php');

I started the session myself – it seems WordPress frontend doesn’t use session at all. In the included new php grobmeier-session.functions.php I create a function for storing my language key. This function has been stolen and modified from PIWI:

function grobmeier_getUserLanguage() {
    $supported[] = 'de';
    $supported[] = 'en';

   if (isset ($_GET['language'])) {
       if (in_array($_GET['language'], $supported)) {
            $_SESSION['language'] = $_GET['language'];
       }
    }

    if (!isset ($_SESSION['language'])) {
        $_SESSION['language'] = 'en';
    }
    return $_SESSION['language'];
}

Now I just need to generate the navigation. I’ll do this with a prepared function of wordpress. On the correct place in my header.php I wrote:

$args = array(
	'meta_key' => 'language',
	'meta_value' =>  grobmeier_getUserLanguage());
wp_list_pages( $args );

As you might see, the navigation is build on the user language setting. And that’s all – you’ll deliver localized versions of your pages from now on. I should mention this works with 2.9.2 and I think earlier versions too. You just need to create pages with the correct custom field setting.

Now Log4PHP needs to succeed 3 votes. One for the Log4PHP team to vote for graduating; one for Apache Logging to accept the podling as a subproject. And finally – after the first two have succeeded – a vote on the incubator list to release the podling to its final destination.

The first two votes are already running and it looks very good so far. Votes need to be open another day then the next step can be done. For those who are interested – there is a detailed document about graduation available.

Let’s see how it works out – I think everything could be in place in quite less time, maybe the next two or three weeks.

But everything has its good sides. I decided to put my development on that plugin more into public and created a new google code project: Wavediver. You can find the original WordPress plugin there. I will try to update the API and make it more usable. At the moment it’s a little bit, well, ugly Let’s hope that it will reach the status to be included in the PIWI framework later.

Already included is a cli.php file, which enables you to send Adobe Wave message from the command line, just with: php -f cli.php. That can help testing.

If there is anybody who wants to join up – don’t hesitate.

It’s an exciting time for all involved, and is the result of a culmination of many like-minded individuals. Everyone’s worked hard and as the initial test community seem to have responded positively and in such detail they could test anything from Word to Think Bingo (http://www.thinkbingo.com/) with their eyes closed. The people behind the development had a few words on the announcement of the first Log4PHP.

Here is the original statement:

The Log4PHP community is pleased to introduce the Apache Log4PHP 2.0.0 (Incubating) release [1]. It’s the first Log4PHP release since 2004 and tons of changes have been done. Finally Log4PHP has become a well tested framework made for PHP 5. Many thanks to all the contributors who made this release possible. Please download [2] Log4PHP and enjoy

The Log4PHP team

[1] http://incubator.apache.org/log4php/changes-report.html
[2] http://incubator.apache.org/log4php/download.html

My first impression was: wow, is that really a quick reference? The book has a good format and comes with roundabout 370 pages. I hoped for a short book in these times I don’t have too much time for huge novels in the kind of “Gone with the wind”. However, I jumped through the content and figured out that this is actually a quick reference  - very good for the impatient developers like me!

In fact, this book covers all relevant topics I can imagine: it starts with an introduction and a description of Geronimos architecture, which gives an brief (sometimes a bit short) overview of how Geronimo works with its plugins and its deployment strategy. I would have loved to read a bit more about the “hot deployment” feature of Geronimo. In JBoss world, this has brought me some headache. In this book it’s only covered with roundabout one page, just saying that it exists, were you need to place your files and how you can monitor that activity. Even later it’s not mentioned in special. Well, but that’s ok for a Quick Reference.

After this, one gets in touch with the most important knowledge of JMS, Database connectivity and JPA. Then there is an extraordinary good chapter about Security. Its one of the biggest chapters in this book and one can feel quite well how expierenced these guys are. Topics are handled in some kind of How-To way, like “Creating a new keystore” or “Changing a private key password”. These guys know what they speak about, probably the best chapter in this book.

Then it comes to CORBA, which I found also interesting, but to short in general. JNDI was reduced to the most important “put your hands there” information. Then it comes to Geronimo Plugins. This one was very interesting too and I wished to read more about it, but well, again, it’s short reference.  You can find much Listings in this chapter, but I cannot say that they helped me too much without digging in the containers documentation.

In the administration chapter, the authors show the different portlets Geronimo provides for monitoring actions. It’s basically a walk through of the different pages of the Geronimo console. I think, this chapter could have been improved much more. For example, the Thread Pools Portlet is described with just one sentence: “…lists the thread pools defined in the server, and lets you monitor the thread pools.”. Ok, I don’t need a book for that information. Some other portlets are described a bit more in detail, but nothing which makes me to a Geronimo Guru.

Later you will have a How-To use the Geronimo Eclipse Plugin. It contains lots of screenshots which helps you to create a project specifically for the Geronimo. More impressive was the Cluster chapter. Clustering is a difficult topic and I would use this section for doing the job. It’s a good mix between explanation and reference.

Last chapter I was eager to see was the one with the Geronimo Internals. At some parts it reads like a smaller version of an API. It should help to develop own GBeans and it does, but not so much that I would have a huge benefit compared to the docs.

Final words: this one is really a reference and not a teaching book. If you would like to buy it, you should have some knowledge about JEE and about Containers in general. This book will not help you to understand the technologies behind. It’s more a collection of How-Tos, and that is what I expected from a Quick Reference. The authors made this point clear on the cover, were they are stating that you need to know about JEE5 concepts. At some points I would have preferred some more information. Sometimes I would have wished that they put not so much unnecessary listings (I don’t need import statements in java listing nor do I need XML-Comments in a 10 line XML file). I think, if you are developing an application, this book is a nice to have. If you are more an administrator and need to develop, package or cluster Geronimo, this book will probably give you some benefits. Especially the security chapter is well done.

However, thanks for this book, I like it, but it’s not one of my all-time faves.

I wanted to step into Geronimo before a few years, but JBoss, Weblogic and even Websphere were used on my projects. No time for playing with Geronimo. Well, but with this book I will start finally and check out whats possible with this little beast

From the table of contents, server side javascript seems not to be on the list. But thats not to bad – I think I have a new idea for a blog post.

However, I am looking forward to this book. Packt already informed that it’s on the way to me. So far a very good impression of this publisher. Polite people, quick delivery. Let’s see how good the book is.

Time for me to think about the different options to write to log files.

I figured out, that I have to compare the following options:

1) Not closing the file while the whole request is running. This is not an option in a live system, but will give me a good idea whats currently the case

$fp = fopen($file, 'a+');
while($count < $loop) {
   fwrite($fp, $text);
}
fclose($fp);

2) Closing the file directly after fwrite is called

while($count < $loop) {
   $fp = fopen($file, 'a+');
   fwrite($fp, $text);
   fclose($fp);
}

3) Use file_put_contents, which is known as an alias to fopen, fwrite and fclose

while($count < $loop) {
   file_put_contents($file, $text, FILE_APPEND);
}

4) Leave the file open while the whole request, but unlock it with flock and flock it again, when the next log event occurs

$fp = fopen($file, 'a+');
flock($fp, LOCK_UN);
while($count < $loop) {
   if (flock($fp, LOCK_EX)) {
      fwrite($fp, $text);
   }
   flock($fp, LOCK_UN);
}
fclose($fp);

5) Use a nonblocking stream for this and flock

$fp = fopen($file, 'a+');
stream_set_blocking($fp, 0);

while($count < $loop) {
   if (flock($fp, LOCK_EX)) {
       fwrite($fp, $text);
   }
   flock($fp, LOCK_UN);
}
fclose($fp);

6) Use the error_log method, which my friend Kevin Horst brought up

while($count < $loop) {
   error_log($text, 3, $file);
}

For each of this options I wrote a simple function which wrote 10000 times 100 characters in  a freshly created log file. I measured before opening and after closing. Additionally I tried out with 2 seperated threads if the write access is nonblocking. Good thing is, option 2 to 6 are actually nonblocking. And here are the timing results:

1) Execution with NOT closing the log file took 0.0668561458588 seconds
2) Execution with CLOSING the log after each write file took 30.1630220413 seconds
3) Execution with file_put_content took 30.153963089 seconds
4) Execution with leaving the file open, but LOCKING and UNLOCKING it took 0.148998975754 seconds
5) Execution with nonblocking stream took 0.149605989456 seconds
6) Execution with the error_log method took 30.069578886 seconds

Let’s see what it means.

Not closing the file until the 10000 fwrite calls are handled as actually the fastest. No surprise. It just took 0.0668 seconds but this one is not really an option, cause other threads have to wait until this request has been finished.

If you close the file after each fwrite and make it available to other threads and then reopen it, is hell. For 10000 calls of this kind I needed 30 seconds! It’s insane to have this in a productive system. The same goes with file_put_contents. Well, I allready knew (its in the php docs) that this method is nothing else then a wrapper for fopen, fwrite and fclose. Times are so similar that I say it’s exactly the same. Sometimes the one is some millis faster, sometimes the other.

If you open the file, unlock it with flock and flock it again it works very well. Just 0.14 ms for the 10000 fwrite calls. Thats the double amount of option 1, but yeah, here we do some more stuff. The interpreter cares about who is allowed to write, together with the OS. flock works that way, that a call to this function blocks until the requestor gets the actual lock. You can be sure that only one thread is actually writing.

Same goes to the nonblocking stream. This works with stream_set_blocking($fp, 0);. The file stream is nonblocking, means each thread could write at it the same time. That no mess happens, we need an flock here too. That brings us to the nearly same results as fopen, flock, fwrite, flock, fclose option above. But looking at the logfiles of this one and option 4, this one looks more nice to me. This is just subjective, but it looks like the lock is shared more nicely between both threads.

Last one is the error_log method. It didn’t had any idea what to expect, but… 30 seconds! This one behaviours like a wrapper for fopen, fwrite and fclose, like file_put_content. No guys, this is not really a method enabled for logging! If one would use this in a framework like Log4PHP, that would be hell to performance. I would think that this should better removed out. The name suggests a good logging method, but this is not the case.

Having that all said, Log4PHP will get the lock and unlock option number 4. I feel good with it, since it’s quite straightforward. I don’t have too much expierence with the non blocking stream and don’t want to have this in a framework like log4php is.

However, Logging must be used carefully at all. I thnk on a system with 10000 request a second. Enabling logging into one file could bring the system down. I think a live system should have the option to log exactly one request. Maybe triggered by an url param. Think carefully what you log and how you configure your live system.

The complete script can be found here.