Saturday, December 30, 2006

Knowledge vs. Experience

Knowledge is power but IMHO Experience is almightiness...

I'm preparing to Sun Certified Enterprise Architect exam and read Sun Certified Enterprise Architect for J2EE Technology Study Guide book. Of course this short book does not explain anything - it is just short remainder. I read (remind) simultaneously other good (baseline for each developer) books:

... and some other stuff e.g. about UML, RMI, CORBA and things like that, and many many more (yes, I read almost all (almost means that I started all of them but finished not all of them) enumerated books - I have them all :)...

OK, that's knowledge - I read many books and maybe have good knowledge of many technologies, frameworks, etc. I also have experience in many mentioned technologies but... Knowledge is nothing without Experience (it reminds me great advertisement of Pirelli tires Power is nothing without Control ;) - reality is more cruel than books and tutorials say. I encountered many problems that in books were referred as rare - in my cases they were normal :)

During exam preparation I have to remind myself all those technologies, protocols, design patterns, UML diagrams, etc. - the subject is quite vast (it's certificate for an architect). I must say that without experience (with plain-old-book-knowledge - POBK ;) it's almost impossible to pass this exam. More so, it is rather impossible to be a good architect (Java/JEE) without such knowledge and solid experience.

If you have knowledge without experience you may easily fall into dangerous pitfalls. Read books of good and well known authors but don't trust them too much - use your own brain and common sense - authors are not the wisest architects, the best developers, the greatest engineers. We are all the best - trust in your own knowledge, experience, ideas and ambition - and, of course, use these assets as often as you can.

Friday, December 29, 2006

XBean list of Strings

If you use XBean you probably encounter common (in my opinion) problem - XBean documentation sucks. I like short and concrete documentation but XBean exaggerates this idea ;) For example it is not explained how to fill collection of primitives e.g. String. If your bean consists of such construct:

private Collection<String> strings;

public Collection<String> getStrings() {
return strings;

public void setStrings(Collection<String> strings) {
this.strings = strings;

you will have problems in writing appropriate XML file with this bean definition.

In bare Spring you will do simple thing:

<property name="strings">

In XBean you cannot use <list> tag because it is unknown... What you can do is to add following entry to your schema definition (META-INF/services/org/apache/xbean/spring/$namespace):

string = java.lang.String
java.lang.String(java.lang.String).propertyNames = value

and then you will be able to use such notation in your bean defining XML:

<string value="Bob" />
<string value="Julia" />
<string value="steve" />

Please refer to this document spring-forward-2006-xbean-spring.pdf in order to find out more about XBean capabilities (note that this document does not explain my problem also).

Thursday, December 28, 2006

Spring ApplicationContext within Servlet

If you want to use Spring-managed beans within you web application, especially Servlet controller and you don't know which implementation of ApplicationContext to use I recommend you to use XmlWebApplicationcontext. This is pretty straightforward as all you have to do is write 4 lines of code (I love Spring ;) - the following lines of code:

XmlWebApplicationContext ctx = new XmlWebApplicationContext();
ctx.setConfigLocations(new String[] { beans definition locations });

Beans definition locations are paths relative to the web root i.e. if you store your bean definitions in WEB-INF/META-INF/services/descriptor.xml you should provide exactly the same string as a config location.

Don't forget to invoke refresh() method.

That's all - isn't Spring beautiful?

Wednesday, December 27, 2006

Hard life of the Architect

I read sometime ago that Developer is someone who knows how tree leafs work, how they cooperate, what they like, what not... Designer is someone who knows how the whole tree works, what roots like, what bark need, how to feed leafs, etc. Architect is someone who knows how the whole forest works.

I think that such metaphor tells other guys that Architect (good one) is really invaluable person in the project team. Architect has to be well educated engineer with many years of experience and couple of projects ahead. Architect has to be a guy from the bright side of the force ;) i.e. someone who has been working as a Developer and Designer for couple of years. Architect has to have wide knowledge of state-of-the-art technologies, libraries, frameworks, standards, protocols, security mechanisms, methodologies, etc. Architect has to be decisive, charismatic and influential.

Good and experienced Architect has really hard life. It's his/her decision what technologies, frameworks, etc. will be used to implement project. It is not easy to choose but it is even more hard to convince other people involved in this project that chosen ones are good and will do for the project.

If you think that it is easy try to choose technology, language, framework in order to implement web based, distributed, system that has to have access to relational database(s). System's operations will require transactions and appropriate security mechanisms.

Even after the decision is made it may turn out that some decisions were wrong... It's not Architect's fault (not always) because requirements change very often, customers change their mind, systems change, etc. All such factors make Architect's dreams shallow and short :)

Tuesday, December 05, 2006

Here comes Santa Claus...

But what he has in common with Java developers...? ;)

I see long stagnation in my posts but this is caused by huge amount of work I committed to finish by EOY. I am actually preparing Java 5 training for my team and some external guys. The subjects are: multithreading, collections, security and JMX. The main objective is to show live examples how it works and why and this takes a lot of time. Not to mention some reasonable foils which I have no idea what to put in there...

At any rate, I will probably put some stuff from this training here soon...