Since I am still working hard on getting more documentation in place it is the right time to start also building an example application. However building a blog application seems to be the "hello world" for webapplications lately. There is even a war going in which language you can implement it with less code. Certain people obviously think that this is a sign of quality. But for me it is not a matter how to easily build such a simple application but rather how easy it is to extend with more sophisticated features.
Anyway I am currently building the application and in parallel writing it down what I am doing. The result will be a nice PDF showing the reader step by step how to build an application with jZonic.
It also helps me at the moment to find weak parts where I need to improve and add certain features.
So if anyone is reading this then stay tuned for the upcoming release.
Donnerstag, 2. April 2009
Donnerstag, 19. März 2009
Writing and writing and writing
Seems like I have a real good week when it comes to write some documentation. Although not my favourite kind of work it needs to get done. There are more and more people using jZonic I have to do it. So tonight I spent a fair amount of time and wrote a few more pages. Still soo much to write down.
I made a list of topics I need to cover and this list and really long. Next time I start an open source project I will keep the features to a bare minimum. Just to be sure I can document it by a single page.
Anyway back to work. Or maybe play a bit of quakelive in the meantime....
I made a list of topics I need to cover and this list and really long. Next time I start an open source project I will keep the features to a bare minimum. Just to be sure I can document it by a single page.
Anyway back to work. Or maybe play a bit of quakelive in the meantime....
Dienstag, 17. März 2009
Too much security can kill your server
Sometimes you have to learn the hard way and that is what I did a few days ago.
But let me start at the beginning. At the company I am working for we have one golden rule
that says that every public website that we launch needs to be tested. I am talking about a pentest here.
A pentest bascially checks your website for any kind of vulnerability like XSS (cross site scripting),
SQL injection and all these nasty kind of attacks. These test are performed by an external company
pentest.co.uk. They are doing a great job.
So a few weeks ago we launched a new website that I am responsible for and of course a pentest
was executed last week. The results are pretty impressive (thanks to jZonic) and no vulnerabilities were found.
Anyway of course they usually also complain if your servers are too noisy. For example if they show up
their name and version in the HTTP header or on a 404 page. Also they firgured out that the HTTP TRACE
method was still available. Nothing serious but it usually reveals too much internal information.
Our livesystem usually combines an apache2.2 running upfront and then resin3.2 for the webapplication
itself and both working together using mod_proxy.
Now I tried to fix the issues but changing the server header in apache is not that simple. But there was
mod_security to the rescue. I installed it and simply used the default configuration. In case you do not
know mod_proxy you can check it out here. There is a huge ruleset available that you can use.
The installation is pretty simple and you can for example change the server header. After the installation
I was pretty happy since I solved the open issues and went back to my regular work.
During the day I saw that all of the sudden the performance of the website went nuts. A "htop" revealed that all of a sudden the machine was really busy. But traffic did not went up as well. Even a restart of resin did not solved the problem. After some digging I figured out that it probably was a problem with mod_security. It was the only thing that I changed that day so it had to be it. First step was to disable it and the server went
back to stable conditions immediately.
Now it was the time to probably take a deeper look at the configuration of the mod_security.
That was actually my problem. You can download a HUGE set of rules for mod_security and that is what I did and I enabled ALL of them. So it was time to take a closer look at these rules. I was able to get rid of 70% of the rules. After enabling the mod again the server is still in stable conditions.
The conclusion is that mod_security is great. It should be part of any apache installation. BUT take a closer look before you use it.
That is the story how too much security killed my poor server.
But let me start at the beginning. At the company I am working for we have one golden rule
that says that every public website that we launch needs to be tested. I am talking about a pentest here.
A pentest bascially checks your website for any kind of vulnerability like XSS (cross site scripting),
SQL injection and all these nasty kind of attacks. These test are performed by an external company
pentest.co.uk. They are doing a great job.
So a few weeks ago we launched a new website that I am responsible for and of course a pentest
was executed last week. The results are pretty impressive (thanks to jZonic) and no vulnerabilities were found.
Anyway of course they usually also complain if your servers are too noisy. For example if they show up
their name and version in the HTTP header or on a 404 page. Also they firgured out that the HTTP TRACE
method was still available. Nothing serious but it usually reveals too much internal information.
Our livesystem usually combines an apache2.2 running upfront and then resin3.2 for the webapplication
itself and both working together using mod_proxy.
Now I tried to fix the issues but changing the server header in apache is not that simple. But there was
mod_security to the rescue. I installed it and simply used the default configuration. In case you do not
know mod_proxy you can check it out here. There is a huge ruleset available that you can use.
The installation is pretty simple and you can for example change the server header. After the installation
I was pretty happy since I solved the open issues and went back to my regular work.
During the day I saw that all of the sudden the performance of the website went nuts. A "htop" revealed that all of a sudden the machine was really busy. But traffic did not went up as well. Even a restart of resin did not solved the problem. After some digging I figured out that it probably was a problem with mod_security. It was the only thing that I changed that day so it had to be it. First step was to disable it and the server went
back to stable conditions immediately.
Now it was the time to probably take a deeper look at the configuration of the mod_security.
That was actually my problem. You can download a HUGE set of rules for mod_security and that is what I did and I enabled ALL of them. So it was time to take a closer look at these rules. I was able to get rid of 70% of the rules. After enabling the mod again the server is still in stable conditions.
The conclusion is that mod_security is great. It should be part of any apache installation. BUT take a closer look before you use it.
That is the story how too much security killed my poor server.
Montag, 16. März 2009
Some updates on jZonic
I was a bit scared when I saw that my last post is actually 6 month old. So I thought I just take the time and write something that I would like to get anounced.
This time I thought I just write something about jZonic. Guess nobody has ever heard of it before. Anyway this is a web application framework that I am working on for several years. Cannot even remember when Terry Dye and myself started with it.
Over the years it has grown up to a mature framework which we use for all our web applications of course. You have to eat your own dogfoot. Anything else would be ridiculous.
Way back in 2002 or 2003 there was a huge gap and nearly no sensible frameworks available. The world has chaned ever since and there are now many frameworks available. At that time there was Struts and one called expresso. None of them were even close to be a usuable framework at all. So we started our own.
The name jZonic has some weird history as well. At that time we were listening a lot to music /MP3s during the day. One of our favourite records was "Sonic temple" from "The cult". That actually gave the name to our work. The "j" was added because it is a java framework. Also at that time it has hip to spell words slightly different. So the name "jZonic" was taken. Maybe not the best choice.
However beside all the nice features we have implemented over the time we did one very poor job. The documentation up to day is still close to non existing. I hate writing documentation. The others hate it as well.
But finally we have a new website running and whenever I feel like I start documenting one of the features.
If you like to follow me here read the website. Again there is not much yet to find.
Like many times before I have said to me myself that I really have to change my attitude and write more.
At least for this week I am doing it. Probably next week it will change again and I will get back to me writing-hibernate.
This time I thought I just write something about jZonic. Guess nobody has ever heard of it before. Anyway this is a web application framework that I am working on for several years. Cannot even remember when Terry Dye and myself started with it.
Over the years it has grown up to a mature framework which we use for all our web applications of course. You have to eat your own dogfoot. Anything else would be ridiculous.
Way back in 2002 or 2003 there was a huge gap and nearly no sensible frameworks available. The world has chaned ever since and there are now many frameworks available. At that time there was Struts and one called expresso. None of them were even close to be a usuable framework at all. So we started our own.
The name jZonic has some weird history as well. At that time we were listening a lot to music /MP3s during the day. One of our favourite records was "Sonic temple" from "The cult". That actually gave the name to our work. The "j" was added because it is a java framework. Also at that time it has hip to spell words slightly different. So the name "jZonic" was taken. Maybe not the best choice.
However beside all the nice features we have implemented over the time we did one very poor job. The documentation up to day is still close to non existing. I hate writing documentation. The others hate it as well.
But finally we have a new website running and whenever I feel like I start documenting one of the features.
If you like to follow me here read the website. Again there is not much yet to find.
Like many times before I have said to me myself that I really have to change my attitude and write more.
At least for this week I am doing it. Probably next week it will change again and I will get back to me writing-hibernate.
Mittwoch, 1. Oktober 2008
Getting rid of Spring IoC
After reading all the posts about the new Springsource license I was thinking if choosing Spring IoC is the best idea. So I started looking for a replacement and started to check out Picocontainer. Actually I am aware of this project for a long time. But so far I never had any interest mainly of the developers whom attitude I really do not like. Is it really necessary to get religious about something so freaking simple? If using an IoC container really means a change of life for you then I feel sorry for you.
Anyway after looking at PicoContainer I was not impressed at all. Mainly because they have build something complex out of something so simple. If you are actually familiar with java reflection slightly then this looks like very much overengineered.
About 2 hours and six classes later I had build my own IoC container. Yet another lightweight (6 classes and no dependencies IS lightweight) IoC container. It supports getting the beans injected either by constructor or by setter method or both. Of course there is no XML involved! How do I hate the beans.xml from Spring.
It is not yet perfect but it does the job perfect. Right now I have removed the Spring stuff in jzwiki to mainly test my own implementation. jzwiki is making heavy use of IoC so it was the best proof of concept (better to say proof of code).
The move was quite painfull since it involved a lot of monkey work but when I was done it just felt good.
The main reason why I did it is because it was fun. Writing code that is simple and does the job is wonderful and makes my day (my developer day of course).
So, bye bye Spring. It was fun while it lasted but there is a point where it is over.
Probably we will meet again later.
Anyway after looking at PicoContainer I was not impressed at all. Mainly because they have build something complex out of something so simple. If you are actually familiar with java reflection slightly then this looks like very much overengineered.
About 2 hours and six classes later I had build my own IoC container. Yet another lightweight (6 classes and no dependencies IS lightweight) IoC container. It supports getting the beans injected either by constructor or by setter method or both. Of course there is no XML involved! How do I hate the beans.xml from Spring.
It is not yet perfect but it does the job perfect. Right now I have removed the Spring stuff in jzwiki to mainly test my own implementation. jzwiki is making heavy use of IoC so it was the best proof of concept (better to say proof of code).
The move was quite painfull since it involved a lot of monkey work but when I was done it just felt good.
The main reason why I did it is because it was fun. Writing code that is simple and does the job is wonderful and makes my day (my developer day of course).
So, bye bye Spring. It was fun while it lasted but there is a point where it is over.
Probably we will meet again later.
Donnerstag, 14. August 2008
Running resin 3.2.0
Today I came across the news that Resin3.2 was released. Probably these are old news but I just heard it today. Since I am a heavy user of resin for long time now I directly grabbed me a copy.
Installation was easy and I just copied the stuff from my old_resin/webapps directory to the new one. It started directly and there was not even one minor issue.
Then after some reading in the docs I figured out how easy it is to use the jmx remote support.
Only a few minutes later I was already monitoring my new resin with VisualVM.
Unfortunately the free version does not support heap dumps from remote machines. You need to buy the pro version for this.
Right now we are testing the new resin in our test environment to see if we should upgrade our livesite. Running a website that gets 2.5 million hits every month needs some extra caution.
First step was to upgrade my personal server and my open source projects that are hosted on it to see how it works.
Again I have to say that the resin server really rocks! Especially the hot deployment during development is the best.
Installation was easy and I just copied the stuff from my old_resin/webapps directory to the new one. It started directly and there was not even one minor issue.
Then after some reading in the docs I figured out how easy it is to use the jmx remote support.
Only a few minutes later I was already monitoring my new resin with VisualVM.
Unfortunately the free version does not support heap dumps from remote machines. You need to buy the pro version for this.
Right now we are testing the new resin in our test environment to see if we should upgrade our livesite. Running a website that gets 2.5 million hits every month needs some extra caution.
First step was to upgrade my personal server and my open source projects that are hosted on it to see how it works.
Again I have to say that the resin server really rocks! Especially the hot deployment during development is the best.
Mittwoch, 2. Juli 2008
Why another web framework? - Because!
From time to time you see the same questions raising up over and over again.
It seems to be difficult for people to understand why there are so many web frameworks
available. Sometimes there is also the question why all these developers of the different
framework do not share their knowledge and build ONE common framework.
The answer is not that easy.
First of all developing such a framework is fun. If you are a passionate developer then this is a perfect weekend project. You can build something on a weekend that will get you started.
Second of course is that you learn something. Basically you learn how servlets/webapps work and you get a chance to dig deeper into it. If you are just a user of such a framework you will definitely miss this oportunity.
Third of course is a matter of personal taste. This only applies if you are also passionate about what you are doing. Most of the developers are just doing their job. They want to get the tasks done and get the projects finished and be home at 7pm. These kind of persons do not really care about special aspects.
If you do then you probably can answer the question above yourself.
Fourth there are always minor things that tickels you. One framework might be great but since it is using annotations and you hate annotations then this might be a "no go". Or they integrate hibernate you are in love with iBatis. Or they use JSF and you think this is complete crap. Or your framework emphasizes the use of callback methods and you just hate this approach.
There are so many things that might disturb you.
So why not start up your computer and start working on your own framework? Take all the pieces that you and leave out the things you hate.
The basic question still is if you really want to release it as open source and then read all this boring "Oh, yet another web framework" kind of crap when you anounce it on javalobby or whereever.
Just wait for "I love Spring! We ALL should use Spring" and then "NO Struts2! The best one". "I use wicket and I am happy. We ALL should use this one". "I spent 1,5 years learning Tapestry and know I understand why it rocks! By far the best one". Blablabla.....
It seems to be difficult for people to understand why there are so many web frameworks
available. Sometimes there is also the question why all these developers of the different
framework do not share their knowledge and build ONE common framework.
The answer is not that easy.
First of all developing such a framework is fun. If you are a passionate developer then this is a perfect weekend project. You can build something on a weekend that will get you started.
Second of course is that you learn something. Basically you learn how servlets/webapps work and you get a chance to dig deeper into it. If you are just a user of such a framework you will definitely miss this oportunity.
Third of course is a matter of personal taste. This only applies if you are also passionate about what you are doing. Most of the developers are just doing their job. They want to get the tasks done and get the projects finished and be home at 7pm. These kind of persons do not really care about special aspects.
If you do then you probably can answer the question above yourself.
Fourth there are always minor things that tickels you. One framework might be great but since it is using annotations and you hate annotations then this might be a "no go". Or they integrate hibernate you are in love with iBatis. Or they use JSF and you think this is complete crap. Or your framework emphasizes the use of callback methods and you just hate this approach.
There are so many things that might disturb you.
So why not start up your computer and start working on your own framework? Take all the pieces that you and leave out the things you hate.
The basic question still is if you really want to release it as open source and then read all this boring "Oh, yet another web framework" kind of crap when you anounce it on javalobby or whereever.
Just wait for "I love Spring! We ALL should use Spring" and then "NO Struts2! The best one". "I use wicket and I am happy. We ALL should use this one". "I spent 1,5 years learning Tapestry and know I understand why it rocks! By far the best one". Blablabla.....
Abonnieren
Kommentare (Atom)