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.

More TIKA changes: http://www.apache.org/dist/lucene/tika/CHANGES-0.4.txt

After some small googling, I figured out that the most cool feature of the SVN properties is to ensure that if you check out something from repository, you’ll get the line endings you need.

“In other words, if a user on a Windows machine checks out a working copy that contains a file with an svn:eol-style property set to native, that file will contain CRLF EOL markers. A Unix user checking out a working copy which contains the same file will see LF EOL markers in his copy of the file.”

Quote from: http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5

So, this is client config. That means YOU have to make sure that you add your files with the correct properties. Let’s assume you want to add a file named test.txt. You would do:

svn add test.txt

After adding you need to perform:

svn propset -R svn:eol-style native test.txt

to set the properties correctly.

Having that beeing said. most people will complain now that this is a difficult task and very error proven. Well it is. But you don’t have to take care if you are sure that only one operating systems (means: one development enviroment)  is set up. This is true for most projects I guess.

If it is NOT the case, you can force your developers to create a default config setup. On windows it just some entries in the registry (please try this, I am not using windows for open source stuff anymore), on Mac OS X and Linux the file ~/.subversion/config must be edited.

In my case, this did do the trick:

[miscellany]
enable-auto-props = yes

[auto-props]
*.java = svn:mime-type=text/plain;svn:eol-style=native
*.css = svn:mime-type=text/plain;svn:eol-style=native

or at least mostly.  SVN told me, after I wanted to change properties to native, that my css files were binary, which this wasn’t the case, of course! I couldn’t change it, until Sebastian Bazley came up with the following:

svn pl -v

showed:

Properties on 'maven.css':

  svn:mime-type

    application/octet-stream

He further told me to do:

svn pd svn:mime-type maven.css

And that was it – SVN is forced to use mime type I want.

Last but not least, here is the link to the apache recommendation or SVN config.

However, if you read the article: please enjoy. If there are any further questions about the usage of Commons Compress, consider to add yourself to the mailinglists.

All the worlds speaks about testdriven development and unit testing. But most people finishing there exams don’t have a clue about what this means. To be honest, I was surprised that people could get out of a university just with one or two Junit tests implemented. Well, here are some words about testing.

What is a unit test?

A unit test is nothing else than some lines of test code which tries to check out if the lines of business logic you wrote actually works. To help you with this, tools like JUnit and PHPUnit (or SimpleTest in PHP enviroment) have been written. They are frameworks which give you some methods to work with. To be clear: a unit test is some kind of class which instantiates another class and checks if the parameters you put in bring the correct results.

What does testdriven development mean?

Hardcore people say, before you write the business logic, you’ll have to write a test case. This is test driven development: write your test, then write the actual business logic. For me it works usually like this: I write my business logic and as soon as I have something cool working, I write a testcase. Sometimes it behaves a bit different. Depends on. But thats a matter of taste. As usual I recommend not to be to extreme about everything and just try out what is best for you.

What and how much to test?

Everything. Well, not really. A good testing ratio is at 70%. More does mean that you even test your exceptions, less means you have forgotten some classes. There are tools available which help you with checking out how much you have tested. In Javaworld its Cobertura, in PHP its Spike PHP Testcoverage, for example.

How does a testcase look like?

Usually you have to extend your tester class from a class called TestCase or similar. In PHPUnit its PHPUnit_Framework_TestCase. They make your classes executable in the testing enviroment. Then implement methods – all methods which implement an actual test is prefixed with test.

An example from Log4PHP:

class LoggerLayoutHtmlTest extends PHPUnit_Framework_TestCase {
    public function testErrorLayout() {

The testing frameworks usually look for methods like this and execute them one by one. In newer JUnit Versions you have to annotate testing methods. OK, and this is a valid PHP testcase:

public function testErrorLayout() {
        $event = new LoggerLoggingEvent("LoggerLayoutHtmlTest", new Logger("TEST"), LoggerLevel::getLevelError(), "testmessage");
        $layout = new LoggerLayoutHtml();
        $v = $layout->format($event);
        $e = "blub";
        self::assertEquals($v, $e);
    }

Again, its Log4PHP. I instantiate a class which I am intending to test and call a method on it. The result is stored in $v. What I expect is stored in $e. All testing frameworks provide you so called assert methods, which enable you to compare or check otherwise if the expectation meets the actual result. In my case, “blub” is expected. If this assertion fails, my tool shows me that error.

Why is it necessary to keep old tests?

If you change business logic or refactor something you can simply execute old tests and recognize if something goes wrong. People say, before putting an echo or System.out.prinln somewhere, write an test. I agree here. A good testing ratio makes your software stable and you take care of side effects, even when software grows. And before you deliver you run all your tests. This way you make sure that everything is fine.

Test Data and dependend Tests

To make it short, test methods should never depend on the success of  test methods. Each test method can be executed stand alone. Otherwise your life will be hell – think on thousand methods depending on each other. Same goes to test data. A testcase must not depend on data another test method created. This will cause you hell.

I know that this is very difficult  with databases. Testframeworks usually give you “tearUp” or “tearDown” methods which are called before a test method starts. You can create your testdata in the databases in these methods. But this is very time consuming. Test executions of this kind can easily take hours. Best is, keep your tables short, make a SQL file for each package or even each test case. There are no best practices which fits on each project.

In my last project we have used Excel (=Manager aware) to take care of the data and then generated SQL files out of it. Time consuming, complex, but it worked. The relations in this tables where to strong, we couldn’t keep the data care up otherwise.

Testing helps coding

Having said the above, you can imagine that you should think about testability BEFORE you code. Spaghetthi code isn’t testable. Make short methods. Keep in mind what “Separation of Concerns” means. Same goes to databases. Make them plugable. Not at all time foreign keys are good. Think about it twice – they are mighty but can be evil too. I have worked in projects where it was very heavy duty or even impossible to delete any data. If you write your application testable, its going to be good designed in much cases.

This doesn’t mean you should put all methods to public scope! Test cases should be in the same package as their Test classes are, so you can try to work with package scoped methods aswell. However, whatever you do, testable code is good, but it never should break encapsulation just for beeing testable.

In most cases private methods can be tested with the test of public methods. Test coverage tools help to identify test lacks.

What to test? Again!

Try to test all public methods! If you need to create files, use the tempfolder. Set up databases for the test. Use Jetty and HSQL if need it embedded – in PHP its PDO and SQLite. Don’t waste your time with testing exceptions which usually never happen. Just use 20% of your time to make 80% of tests! Try to test business logic – if that means the creation of complex objects, so be it. Maybe you can share the logic. But don’t get bored with testing getter and setters. Those are called thousand of times within normal tests or procedures, no need to do that.

How much time can test development need??

Calculate the same time as implemeting the testcase. Too much? Not really! Imagine you are writing business code for 5 hours. Thousands of outputs on the console you read manually. You delete it, check it in and later want to fix again. Put those outputs in again? Have commented it out? Code is ugly? Put all your stuff in a testcase. Nobody claims if you need 5 hours for it, if its done properly. Sometimes testcases need 3 days but the fix just 1 hour. This can happen in EAI enviroments, where multiple systems communicate. No problem here – these is business critical, automatic tests are the best you can do.

Commons Compress is a component that contains Ar, Cpio, Jar, Tar, Zip and BZip2 packages

Source and binary distributions are available for download from the Apache Commons download site:

http://commons.apache.org/compress/download_compress.cgi

When downloading, please verify signatures using the KEYS file available at the above location when downloading the release.

For more information on Apache Commons Compress, visit the Commons Compress home page:

http://commons.apache.org/compress/

Changes in this version include:

New features:
o Initial release

Have fun!
-Commons Compress team

In fact, I strongly believe that every concept (ok, most ) have benefits and drawbacks. The case of the singleton for me is easy: it depends.

So what’s wrong with that pattern?

Some people claim that the Singleton pattern is a sign of bad software design. They say the Singleton can be used as some kind of global variable. Well, that’s true, sometimes. But the Singleton can be used otherwise than a global variable holder. Actually you have to differ between your programming language before thinking about a good or bad usage of the Singleton Pattern.

How to implement the Singleton pattern in PHP

PHP is a scripting language, it’s actions are performed by an interpreter. It doesn’t support multiple threads like Java or Ruby does. This is very important later. But first, lets create a singleton in PHP.

class MySingleton {

    private static $instance;

    private function __construct() {}

    public static function getInstance() {

        if(self::instance == null) {

            self::instance = new MySingleton();

        }

        return self::instance;

    }

}

How does this work? You create a static variable in a class. If one calls getInstance() for the first time, a new object is created and stored in the static variable. If you call the method again, you’ll get exactly the same instance you created with the first call. This object – since it is static – will stay until your script has ended and the complete request is processed. You see, why the singleton has it’s name. It’s only one object created and used for all the time.

And to keep this behaviour, you just have to put your constructor private – nobody else than your getInstance method should be allowed to create this object.

How to implement a Singleton with Java

Now you have to think about some more issues. Since Java supports multithreading you have to think about more than just creating the object and returning it. First, we’ll see how a pure PHP programmer would create the singleton with Java syntax.

public class MySingleton {

    private static MySingleton instance;

    // Again - just MySingleton is allowed to construct this object

    private MySingleton() {}

    public static getInstance() {

        if(instance == null) {

            instance = new MySingleton();

        }

        return instance;

    }

}

OK, now think about two threads which call getInstance() at the same time, and imagine nobody has done so before. Both threads would enter getInstance(). Chances are good that Java helps you even with multiple processors (it should do, cause Suns Sales Managers sell Java as a simple to use language ). In that case, one thread would go on to create the MySingleton object, while the other one will jump over it and return the instance.

You have to ask the question, does this really work? Cause at which point of time is instance not longer null? The answer is, if you create the object headers, the instance variable is not longer null. That means, that a second thread could overtake thread one and work on an instance which is not really created (just the have of it)! Something unexpected will occure and even if your customer will claim about an error, you probably will never have the chance to find it.

So what now? We have to make sure that:

a) two threads are not creating a MySingleton object at the same time
b) one thread doesn’t work on the object while it is still under construction

Some programmers start something like this:

public class MySingleton {

    private static MySingleton instance;

    public static getInstance() {

        if(instance == null) {

            synchronized(this) {

                if(instance == null) {

                    instance = new MySingleton();

                }

            }

        }

        return instance;

    }

}

Please note the synchronized block above. It keeps care that only one thread can execute the code for creation at one time.

Is this the solution? No. Even in that case it can happen that Thread 1 locks everything correctly for creating the object. But if Thread 2 comes at a bad time, it will ask the outer instance == null check and again it could return an unfinished object. The synchronized block just helps with one problem.

Actually there is only one 100% solution. Create the necessary object while class loading.

public class MySingleton {

    private static MySingleton instance = new MySingleton();

    public static getInstance() {

        return instance;

    }

}

This is a solution PHP programmers cannot have since PHP doesn’t support to create objects like this. But for the Java programmer it’s the only way to make object creation work. And yes, sometimes it’s not possible to go this way. But that’s another story.

Singleton Lifetime

You should know about another difference between Java and PHP Singletons. In Java, the static keywords makes the variable available at a class level, not at object level. This means it follows you as long as the JVM is alive – from programm start to programm end, and in case of an enterprise or an eai server, this can take a long, long time.

For a PHP programm it’s the same – from programm start to programm end. But in PHP words this means the time when an HTTP request arrives and script execution begins till the end of the script has been reached. After a request, the singleton is gone, dead, and you’ll have to create it again, with the next request.

In human words, this means that a Java singleton probably lives for days, weeks or even months and the PHP singleton just for less milliseconds.

The Benefits of Singleton

Well, benefit is: you have to create only one object of an class and can use it over and over again. This is cool, since creating an object takes usually a long time in the interpreter or in the virtual machine. Cause of this, old programmers often say object orientation is slow. Meanwhile everything is faster and in most cases you don’t have to care bout this anymore.
And this is where critic starts: people say, you could misuse the Singleton as some kind of global variable store. This comes often from PHP programmers, who think about that code:

class MySingleton {

    ...

    public $bla = "blubber";

    public static function getInstance() {

        ...

    }

}

In this case, you can have the variable $bla available all over your code. Just do a:

MySingleton::getInstance()->$bla;

Is this good? No. Of course not. If you just want to store something, go ahead, use $GLOBALS or a similar global available variable. Same goes to Java. There are no global fields, but you can create some similar with System properties.

But Singleton will have more the worth if the singleton object has some methods you can operate on. Imagine that singleton object trys to reload a configuration.

class MySingleton {

    ...

    public $bla = "blubber";

    public function loadConfiguration() {

        // code to load xml file

        $this->bla = getValueFromXML();

    }

    ...

}

This would make it possible to reload the config at runtime. Even date formatting etc. would be possible at runtime.

Basically said, an object which provides methods is worth something. It’s not to bad to do so. But a more cool benefit is if you have a stateless singleton.

class MySingleton {

    ...

    public function doSomething($bla) {

        $bla = $bla / 2;

        return $bla;

    }

    ...

}

Imagine doSomething() does some complex things with $bla. You don’t need to store the result in the MySingleton object. It will returned. Since there are no object variables available, this object is stateless. And there is really no need to create multiple objects just to perform some operations on $bla.

But why should one consider to create an object if he can do this in a static way, you ask. Static access to methods is not very flexible. Think on AOP, where objects wrap other objects and prevent you from calling a method directly. This wouldn’t work. That’s just one example. There are others: maybe you want to choose at runtime, which implementation you use to create this task. In a static context you would have to change your implementation, in an object context you could use a factory and a strategy pattern to switch. This is way more flexible.

Drawbacks of the Singleton pattern

Yes, of course there are several. Think on the global variable thing. It’s true, imagine you have one thousand of Singletons, all keeping care of their own little states, read within the application from a million of places. Not very good. Esspecially with PHP you cannot easily find out where those variables are called. In Java you have some good shortcuts in your IDE.

But we know now, that a Singleton is meant for reducing object creation time and not for state sharing. Next drawback is more significant, since the first one is a mistake just inexperienced programmers do.

Problem is, if you create a Singleton it will stay one forever. If you need to make multiple objects of your class, you have to write code for this. In small projects this is not such a big issue, but in a 100.000 lines of code project it is. There are other patterns like Prototype or Factory which could be useful suddenly and we would have to write code. This is a risk.

The solution is to create this Singleton not by code like we did above. Use a framework for creating your objects. In PHP you PIWI and the BeanFactory at your side, which helps you with constructing singletons (and injects the objects in other objects – Dependency Injection, see the previous article).
In Java you can use Spring for this. Spring is the big inspiration source for PIWI (regarding object creation and dependency injection) and widely used. Besides Spring there is Google Guice and PicoContainer too, which provide similar stuff.

Finally

There is no need to say Singleton is good or bad. It’s neither. It’s just a pattern. A Singleton is just as evil as you misuse it, and just as glorious as you identify it as fitting pattern to a specific problem.

In my projects I use a Singletons sometimes for configuration. I don’t think it’s bad behaviour. If I don’t have one thousand of this object in my System, it’s OK. More often Singletons are used as some kind of worker classes, just here for doing complex stuff with storing a state. They help me not to waste memory. And due Singletons are objects I easily can extends them via aspect oriented programming – perfect!

Design Patterns – all just theory?

If students make their exams and come as junior programmers to my projects, they often believe a design pattern is something to eat. Or something theoretical. Or simply a joke. I usually start with explaining how to use it and such, but at the first glance it seems to abstract to them. Later, with the expierence, comes the joy.

This is true for patterns like Singleton or Factory or maybe Model-View-Controller. Coming to Dependency Injection – which is not read very often in Books about good software design – most people NEVER have joy. In this kind it behaves like the Proxy pattern. One really cannot use this out of the box. I mean, a singleton can be implemented within minutes, and it does what it does. But Dependency Injection? It’s more a concept of software design than a design pattern. Can you implement a singleton? Yes. Can you implement Dependency Injection? No, of course not. Having that said, the joy and the power comes when you are using a fitting framework which supports the design pattern. Like Spring. Or PIWI, in the latest trunk version. Cause we PIWI-folks simply have stolen much of the ideas of Spring and now use it not only in Java, but in PHP5 too.

What’s all about it?

Basically Dependency Injection simply says: don’t make a class dependent from another, inject the dependency. So what? some will say. But it’s simple. Imagine the following PHP lines:

class Car {
   private $driver = null;

   public crash() {
      $this->driver->saySomething();
   }
}

You see, there is a private member called driver in the car class. If your use case is that each car is a driver, it’s quite easy in most cases. Just fill the member in the constructor. This is, what most people do. This makes $driver nullsafe.

class Car {
   private $driver = null;

   public __construct() {
      $this->driver = new Driver();
   }

   public crash() {
      $this->driver->saySomething();
   }
}

OK. From this point on the class Car depends on the class Driver, cause you need the Driver class to instanciate Car. After you did that and all works well, your boss looks round the corner and tells you that we need to distinguish between female drivers and male drivers. He is sorry for saying that so late, but it’s like this. Cause if you call the new method crash(), a female driver would simply say:”you crashed me!” and a male driver would say something like:”guy i have a gun!”. And, that’s the point, your client A just wants male drivers in their systems, while client B just needs female drivers.

People start doing:

class Car {
   private $driver = null;

   public __construct($client) {
      if($client == "A") {
         $this->driver = new MaleDriver();
      } else if($client == "B") {
         $this->driver = new FemaleDriver();
      }
}

   public crash() {
      $this->driver->saySomething();
   }
}

All is good. But what if you need to port the system for somebody who just let childs drive? Or people with glasses upon their noses? In fact, we had the requirement to create several modules for several clients – customization. Yes, the example above with male and female drivers is not the best, but I am sitting in a car while typing this.

Problem on the approach above is that you need a new if else if you ever have more Driver types than above. And you have to put this in class where such dependencies exist. Maybe it’s not pretty much, but in our case we had about 20 modules – without customizations. I really was afraid before such a switch.

Dependency Injection for the solution

As I allready told you, we had Spring and Java 6 in our system. But we ported dependency injection to PIWI. And if you are using one of these frameworks, you know that both heavily use XML. Imagine you could say in an XML which driver you want to use. More better: you really would define an interface for all the driver classes and would make sure that you operate on that interface only.

See this:

interface Driver {
   public saySomething();
}

class FemaleDriver implements Driver {
   public saySomething() {
      echo "You crashed me!";
   }
}

(imagine something similar for MaleDriver).

You could do something like that:

class Car {
   private $driver = null;

   public __construct($driver) {
      $this->driver = $driver;
   }

   public crash() {
      $this->driver->saySomething();
   }
}

Isn’t your code much cleaner now? You know, if else means death to object orientation! This way your Car class doesn’t depend to MaleDriver or FemaleDriver. In case of PHP5 it just depends on an untyped object. In case of Java it depends on the Interface Driver.

By the way: you can force types in PHP5 (in some level of course). You could write the constructor like this:

public __construct(Driver $driver) {
   $this->driver = $driver;
}

This forces the caller to put an object inside which implements the interface Driver. And this in fact is the way you should go! And this is all about the Dependency Injection pattern. It says, make your classes dependend on interfaces, not on classes.

So, isn’t it nice? But how do you decide to bring your dependency in? This is another point, and this is why I said you have to check out Spring or PIWI for this. The example above is working gorgeous, but if you don’t find a mechanism to bring your dependencies into the game, all is lost. I promised XML like Spring does, and here it is: PIWIs XML file for Dependency Injection in PHP.

<bean id="xmlPage" class="XMLPage" scope="request">
   <property name="contentPath" php="$GLOBALS['PIWI_ROOT'].CONTENT_PATH" />
   <property name="siteFilename" value="site.xml" />
</bean>

<bean id="siteSelector" class="SiteSelector" scope="request">
   <property name="page" ref="xmlPage" />
</bean>

We call our objects beans, like Spring does. It’s Spring-Beans in Spring, but PIWI-Beans in PIWI. We are shameless. First, look at the bean definition with the id xmlPage. You give it a class and a scope, and some properties.

Basically, PIWI (and Spring too) creates the objects for you. That has many benefits. I will write an blog article why instanciating objects yourself is sometimes a bad idea some day. However, PIWI makes an object and stores it in our context, the BeanFactory. It’s stored under the id xmlPage, and you can get the object manually if you call:

$xmlPage = BeanFactory::getBeanById('xmlPage');

This brings you the ready bean. Additionally you tell the BeanFactory that it should set the property “siteFilename” to “site.xml”. And one line above you even give it an PHP expression. After PIWi made the object from the class XMLPage, it checks if a member variable is accessible named siteFilename. If it isn’t it looks if there is a method called setSiteFilename($o); or siteFileName($o). If PIWI found that method, it calls it with the value.

This is all done by reflection, which has been shipped with PHP5. No dependencies to other libs, no problem. Just plain PHP5. Same goes to Java. Plain Java. No Magic. Just some reflection.

If you would have called this line instead of the one above:

$siteSelector = BeanFactory::getBeanById('siteSelector');

the BeanFactory would have created the siteSelector bean. If you look into it, you see this:

<property name="page" ref="xmlPage" />

If the BeanFactory gets aware of this (and it does!), it will look in the context for a PIWI Bean with the ID xmlPage. If there isn’t one, it will try to create such a bean. Same rules as above. After creation of xmlPage it will be set into SiteSelector’s setPage($xmlPage) method.

And now imagine how your boss would love it, if you tell him that such a customization is just a matter of some XML?

<bean id="maleDriver" class="MaleDriver" scope="request" />
<bean id="femaleDriver" class="FemaleDriver" scope="request" />

<bean id="car" class="Car" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

Everthing done!

For the sake of completness – what do we mean with scope? Well, scope is in which scope your object lives. Defining request means, the we create maleDriver only once while the whole request. If you define another class which needs maleDriver, it would get – exactly the same -. This is, what some people call a Singleton in PHP. But Singletons are worth an own Blog entry, since some people – esspecially who have just written code with PHP and not for Java Enterprise Systems – say, Singletons are evil. Well, they are not. If developers are not thinking while coding, that is evil You can misuse everything, if you want to.

Here is another example for using the driver more than once:

<bean id="maleDriver" class="MaleDriver" scope="request" />
<bean id="femaleDriver" class="FemaleDriver" scope="request" />

<bean id="car" class="Car" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

<bean id="truck" class="Truck" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

In this case, only the same instance of maleDriver makes it to the truck and to the car. Decide yourself if this is your usecase. In the MaleDriver class are no states defined – so one object is enough.

OK – Dependencies are out. Instanciation is out of the code too. But is this the whole benefit? Not really. This stuff makes it possible to create dynamic proxies and use aspect orientation, even with PHP. And be sure, PIWI will have features some day. And Spring still got this cool stuff. But that’s another story.

Motivated by the 100 downloads I started to create the Annotation encoder yesterday night. Its very basic and doesn’t contain good testcases at the moment, but at first glance it works You can serialize Java Objects into a JSon string with that stuff. Supported are the usual json types, except double (sorry, forgot that). List and Maps can be serialized too, aswell as annotated pojos.

I will add the double and some more testcases in future, then try to aim to the next release. Additionally I want to release a zip file next time, containing license stuff and maybe some docs. If you are willing to help, shout!

Background info:

JJSon is a small API for working with the Json format. There are several libs out there, but I don’t know any which are well encoded AND have no dependencies. JJSon doesn’t provide all features the other libs have, but aims to be easily extendable and definitly comes without any necessary dependencies.