Jeremy Thomerson

More great reasons to go to ApacheCon US 2009

Jeremy Thomerson — Wed, 14 Oct 2009 03:09:49 +0000

ApacheCon US 2009 is fast approaching. And for all you Wicket lovers out there, or anybody interested in getting started with Wicket, you know that I will be presenting a one day training as well as an Introduction to Wicket session. So if you haven’t done so already, go sign up!

More info on the Wicket training: http://www.jeremythomerson.com/blog/2009/07/wicket-training-at-apachecon-us-2009/

CLICK HERE TO REGISTER

But what about more great reasons to register? I’ve put together a list of the sessions that you might want to attend if you are interested in Wicket. Of course, there are many great sessions, and you may (like me) have a hard time choosing. You may be interested in the entire track on Lucene / Hadoop and the family. Or in the business track. But here are some that you may particularly like:

Wednesday - 11:00am - Tomcat Community Overview
Wednesday - 1:30pm - An Introduction to Apache Velocity 1.6
Wednesday - 2:30pm - Introduction to Wicket
Wednesday - 4:00pm - Securing your Tomcat installation
Wednesday - 5:00pm - mod_jk / mod_proxy and others
Thursday - 9:00am - Content Driven Portals with Jetspeed and Jackrabbit

Thursday - 10:00am - It’s a toss-up between:
Thursday - 2:00pm - Scalable Internet Architectures
Thursday - 4:30pm - Recent Developments in SSL and Browsers

Friday - 9:00am - Welcome to the Future! (httpd)
Friday - 10:00am - Deciphering mod_ssl: Using SSL with the Apache HTTP Server
Friday - 11:15am - Selling Open Source E-commerce and ERP
Friday - 2:00pm - Building Intelligent Search Applications with the Lucene Ecosystem
Friday - 3:00pm - Realtime Search

For those who are more business-focused, here are a few alternative sessions that you may be interested in:

Wednesday - 4:00pm - Open Source Business for Hackers
Wednesday - 5:00pm - Apache License as a Business Model - Challenges and Opportunities
Thursday - 9:00am - Making Sense of Open Source Licenses

So, what are you waiting for?
CLICK HERE TO REGISTER

And don’t forget to register for your Wicket training!

Wicket Training at ApacheCon US 2009

Jeremy Thomerson — Tue, 07 Jul 2009 14:38:50 +0000

I am very happy to announce that there will be a one day training course at the 2009 ApacheCon conference in Oakland, CA (USA). Before I tell you more about it, consider the following “top ten” list:

Top Ten Reasons You Should Attend ApacheCon US 2009:
10: Hacking is encouraged at the Apache Hackathon two day event.
9: Free beer! http://wiki.apache.org/apachecon/ApacheConUs2009Program
8: Meet members of your favorite projects (i.e. me last year getting Martijn to sign my copy of Wicket in Action: see Martijn signing my book)
7: Free two day BarCamp
6: Free meetups three nights of the week
5: It’s always a good time to visit California: http://oaklandcvb.com/
4: Support the tenth anniversary of the Apache Software Foundation and the many other great projects that will be there.
3: Did I mention FREE BEER?
2: Two attendees in the class will receive FREE copies of Wicket in Action
1: WICKET TRAINING! (more info)

More details will be coming soon, but if you are looking to get your feet wet with Wicket, you should certainly start making plans now to attend the 2009 US ApacheCon, and the Wicket training class that will be held. Those who register early get discounts, too!

The class will consist of fast-moving explanations of core design principles, Wicket components, and “The Wicket Way”, and each section will be followed by a coding practice where you can put into use what you just learned. We will focus on laying a foundation - how to use Wicket, create pages, organize your application, and create a Wicket application.

We will cover the following:
- The fundamentals of Wicket
- Handling data / working with objects and models
- Standard components provided by framework
- Containers / Application / Session / Page
- Effective code reuse strategies

ApacheCon site: http://www.us.apachecon.com

November 2-6, 2009 in Oakland, CA. Classes will be held on Monday and Tuesday. Wednesday through Friday will be for the conference sessions. The Wicket class will be held on Tuesday.

Follow ApacheCon on Twitter: http://twitter.com/apachecon

I’m now a Wicket core developer

Jeremy Thomerson — Sat, 07 Mar 2009 04:51:58 +0000

My intention is not to blow my own horn, but I was so excited to have been asked to join the Wicket development team (link) that I knew it was time to dust off the old blog and start trying to write some articles again. And no more than an hour after it was announced, I was asked about when 1.5 would be released! (a well-meaning joke). I have a lot of respect for all of the Wicket developers who have brought the great framework this far, and I hope that I will do well in assisting to carry the torch further.

Thank you to everyone who has contributed countless hours to making Wicket a great product! Now it’s time to roll up my sleeves and get to work!

Wicket Stuff Reorganization

Jeremy Thomerson — Mon, 01 Dec 2008 20:05:39 +0000

So last week and this weekend I was swamped spending pretty much every night trying to get the Wicket Stuff project organized. When I started, the trunk of Wicket Stuff had over 85 folders (subprojects) in it. It was a mess. Tons of these have been abandoned over time, with no work done since the 1.3 release of Wicket was cut and trunk changed to 1.4 development. The biggest problem I wanted to address (and the community overwhelmingly agreed) was that there was no standard release pattern for nearly any WicketStuff project.

What we decided

It was decided to create a “core” project for WicketStuff where other projects would reside under it (using Maven modules). We would get this core building and releasing snapshots in the wicketstuff.org maven repo so that if you were developing against Wicket 1.4-SNAPSHOT, you could also do the same for the WicketStuff projects. Then, whenever a numbered release of Wicket came out (i.e. 1.4-rc2 soon), we would cut a release with the same number for WicketStuff. This should make it much easier to use the WicketStuff projects, many of which have never had any numbered releases (you always had to compile your own to use).

What was accomplished

Here’s a quick summary of what was accomplished:

21 projects were moved into the core (including “examples” projects) (UPDATE: more are being migrated - this number has grown)
32 folders were removed from trunk into the attic
All that in over 73 commits!
This left us with around 30-something folders left in trunk - and hopefully most of those will move into the core project.

Here’s a status page that I’ll be updating as more progress is made:

http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Reorg+-+Status+and+List+of+Changes

Wicket in Action Book Signing

Jeremy Thomerson — Tue, 18 Nov 2008 17:10:18 +0000

: Martijn signs my book!

Yes, it’s dumb, but I took advantage of ApacheCon 2008 by having Martijn Dashorst sign my personal copy of Wicket in Action. Fortunately Bruno Borges was on-hand to document the momentous occasion!

Now I just need to meet Eelco……

Wicket QuickStart Tutorial

Jeremy Thomerson — Tue, 18 Nov 2008 01:26:56 +0000

So, you posted something to the Wicket mailing list saying that you thought you found a bug or you had a problem and were told to “create a quickstart” duplicating the problem. And then you said “how”? There are two ways and each will be described here:

Wicket QuickStart - The Maven Way

If you already have Maven running on your machine, I recommend using this method. It is very simple, especially if you need to create more than one quickstart or if you hate downloading jars from all over the internet yourself.

Enter the following command to create the archetype of a quickstart (a complete project, ready to run):
1. mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.4-SNAPSHOT -DgroupId=com.example -DartifactId=test -DremoteRepositories=http://wicketstuff.org/maven/repository/
2. For more about creating and using this quickstart, you can see: http://wicket.apache.org/quickstart.html
Change directory into the project directory that was just created for you (i.e. “cd test”)
Now to get the project ready for your IDE of choice, you can also use Maven. Here is an example of how to do so with Eclipse:
1. mvn eclipse:eclipse
2. Note that your workspace will have to have the classpath variable M2_REPO set to point to the directory where your local Maven repository exists. You can see this page for how to do that with Eclipse: http://maven.apache.org/plugins/maven-eclipse-plugin/usage.html

The quickstart is now created and ready for you to import into your IDE. After you’ve imported it into your IDE, now comes the “duplicate the problem” part. Try to create pages or components that reproduce the problem you were trying to report. You can run the Start.java class from your IDE and go to http://localhost:8080/ to see your test application.

Cleaning up before you submit the quickstart

Once you have reproduced the desired behavior in your quickstart, it would be best to make it as small as possible before submitting. The best way to do this is to run the “mvn clean” command from the project directory. Then zip the whole directory up and submit the zip file. (The mvn clean command removes all of the compiled classes and generated artifacts, generally in your “target” directory, leaving only the actual source.)

Wicket QuickStart - The Zip File Way

If you don’t have Maven installed, use these steps:

Checkout the wicket-quickstart project by running this command:
1. svn co http://svn.apache.org/repos/asf/wicket/trunk/wicket-quickstart
Import or add that folder to your favorite IDE as a new project.
You’ll need to add the following jars to your build path:
1. wicket.jar (version of your choice)
2. slf4j (I used 1.5.0)
3. Some slf4j implementation (I used log4j which meant I also needed to add log4j to my build path)
4. junit (I used 4.4)
5. jetty and jetty-util (I used 6.1.11)
6. servlet-api (I used 2.4)

Now, you’ll need to do the same as above: add your classes to reproduce the problem, run Start.java and view http://localhost:8080/quickstart to test it. Once again, you’ll want to remove your “target” folder (or “bin”, etc) with all the compiled classes before submitting it.

If you choose this method, I’ve tried to assist by building this basic wicket quickstart zip file. You should be able to download it (here: wicket-quickstart) and add it to Eclipse and just run with it. I hope it works for you. Of course, I provide no warranty for it, written or implied.

Meet the Wicket Community - Little ol’ Me!

Jeremy Thomerson — Wed, 12 Nov 2008 22:56:57 +0000

After a great week at ApacheCon last week, it was an extra privilege to spend the time with Martijn Dashorst and Bruno Borges. An added privilege was the opportunity to complete my interview with Martijn in person at ApacheCon.

To read more about me and my Wicket experiences, check out his interview with me at: http://wicketinaction.com/2008/11/meet-the-wicket-community-jeremy-thomerson/

ApacheCon - Java Monitoring and Troubleshooting Tools in Action

Jeremy Thomerson — Fri, 07 Nov 2008 16:59:22 +0000

Presented by Bill Au, of the Platform Infrastructure group at CNET

Bill is going to help us learn about how to troubleshoot and monitor java apps, thread and heap dumps, hung or slow apps, OutOfMemoryErrors, and JVM crashes. All of the tools he is going to show us are free tools - open source or free for download.

NOTE: This was a very interesting session. One of the things I was impressed with was his demonstrations of some tools that I have not seen. There was the HP JMeter tool, an open source tool called Samurai, and a perl script that he wrote. All of them look very helpful, and I want to try them all out (not that I have every written any apps that ever have performance issues - but I’m sure I can help someone else look at theirs!)

Monitoring

Within JDK 5 (Sun’s), there is a java.lang.management package that has quite a few MX beans (i.e. MemoryMXBean, RuntimeMXBean). These beans will allow you to get all of the information you might need to monitor the JVM. You can see sample code for how to use them in: $JAVA_HOME/demo/management.

Management tools

jinfo - for getting rutntime info
jmap - for getting heap info and taking heap dump
jstack - for thread dumps

The tools above can be run against a running JVM or a core dump file if the JVM crashed.

jstat - can be run against a running instance from a command line to get monitoring information.
jconsole - a GUI for those not comfortable with the console - must open JMX port on running JVM (in JDK 6 there is an attach-on-demand functionality). jconsole also support plugins. There is an example in $JAVA_HOME/demo/management/JTop that is a very useful plugin.
garbage collection enable this because it is handy: -Xloggc:. It will give you the timestamp of GC events and size before and after.

Thread and Heap Dumps

kill -3 (or kill –SIGQUIT) will give you a thread dump
ThreadMXBean or jstack or jconsole can also give you thread dumps.

Bill recommends taking one, and then after five seconds, take another (do this several times). Once you have several, you can compare where threads are to see which ones are locking.

If you turn this option (-XX:+HeapDumpOnOutOfMemoryError) on, then if you get an OOM, the memory will be logged so that you can debug where the memory was used at the time of the crash. jmap and jconsole also allow you to take heap dumps. hprof can also give you information for the heap, but it was significant overhead - so you don’t want to use it in production.

Hung or Slow App - Debugging

Look in garbage collection logs - how long is the application pausing for garbage collection (five seconds is a long time). Look for how much overall time that the JVM is spending garbage collecting rather than running your code? You can tune this by modifying the heap size - of course, a larger heap takes a longer time to garbage collect. Making one change at a time obviously gives you more of an opportunity to see what actual worked.
HPjmeter.jar - a free tool from HP (this is not Apache JMeter). This is a tool for monitoring HP’s JVM, but it can also analyze garbage collection logs from most JVMs. It will give you a chart of how much time is spent in garbage collection, and how many GC events, as well as average duration, etc.
One comment was made that if you are using large heap sizes (8gb-16gb), you need to make sure to use the appropriate (larger) page size. I’ll have to Google this to find out more.
Beware of over-optimizing - your app will change over time. Bill suggests trying to find a good heap size, and perhaps using concurrent garbage collection rather than full garbage collection, even though this has higher overhead.
Deadlock - if you encounter a dead lock, you obviously want to take a thread dump (see above) to run the deadlock detector.
Loop threads - You may get certain threads in a long-running loop. To find this, monitor your CPU times of threads, using ThreadMXBean or jconsole with jtop (see above for more details)
Blocked threads - there is an open source GUI tool called “samurai” that analyzes thread dumps for you. It can also understand consequtive thread dumps and display the information in an easy-to-read format.
Bill also wrote a perl script that gives you an overview of a thread dump. Both of these tools are located in the same folder as his slides (link included at bottom of this post). His perl script gives a very nice overview, including how many threads are locked, and where they are locked. Running it against several thread dumps that are several seconds apart gives you a good look at what’s going on.
Stuck threads - you may not have deadlocks, but you can still get stuck threads. Typical causes include network I/O without a timeout set. You can use the thread dump techniques to analyze this the same as you would if you had deadlocked threads.

OutOfMemoryError - heap

Some common causes:

Your heap may be too small, so you could increase the heap size (-Xms)
Excessive use of finalizers (analyze with MemoryMXBean, jmap, jconsole)
look for logic error in array allocation code - allocating larger arrays than you need
Memory leak - take a heap dump (see above for helpful tools) and see if you are holding on to things that you didn’t think you were holding on to.
jhat - Java Heap Analysis Tool - this is a very helpful tool for analyzing a heap dump file that you have taken. When you start it, you can browse http://localhost:7000 and walk through the heap, seeing where everything is being referenced, and see where you’re holding on to objects that you shouldn’t be

OutOfMemoryError - permgen

Some common causes:

If you hot-reload your webapp, your server uses a new classloader, and if somewhere in your code you accidentally held on to a classloader (or possibly class?) from the old classloader - those classes can’t be garbage collected, and you run out of perm gen space.
If you do have a leak like just described, look for threads that you started running in the background that may be holding on to old classes / classloaders.
You can use JHAT again - look for references to a class loader. If you find what’s holding on to the classloader, you’ve found the leak.

OutOfMemoryError - too many threads

You can run out of stack size if you have too many threads. Each Java thread has a native thread and a stack. You can either lower the maximum number of threads or decrease the maximum stack size (per thread) - but be careful - you may run into StackOverflowError

OutOfMemoryError - native memory

This happens when your system actually runs out of memory, and you can’t allocate any more to the JVM. Look for other processes that are using too much memory.
You may also have a leak in JNI or a native method. The stack trace in the OOM will tell you what native thread caused this.
There have also been leaks in older JVM codes. You will get an error log with the JVM crash. Obviously the fix for this is to update to the latest JVM. You can also look into hs_err_.log to see where it’s happening and possibly find a workaround. Or you can check Sun’s bug database (http://bugs.sun.com/) or post to Sun’s java forum and / or open a bug. Bill says the Sun developers are very helpful.
One workaround he has had to use in the past was running the JVM in client mode rather than server mode (this only works in 32-bit systems - on 64-bit, it always runs in server mode, regardless of what you told it to do).

You can download Bill’s slides here: http://people.apache.org/~billa/apacheconus2008/

ApacheCon - Guidelines and Best Practices - System Architecture of Web Applications

Jeremy Thomerson — Fri, 07 Nov 2008 00:02:48 +0000

Presented by Ravi Saraswathiamma, architect with AOL / Time-Warner

When setting up an application, you have to identify hardware / software / networking / infrastructure architecture. How do you do this? The first step is of course gathering the requirements - what is required? What kind of application is it? Do you need HTTPS, etc. What are the best practices?

Ravi’s team has done scalability tests with many of the possible applications out there. The most performant combination they found was: Apache HTTPD / Tomcat / MySQL. They don’t use EJB containers, and in 95% of their applications, they find that MySQL is better performing than commercial alternatives.

Most web applications can use a Layer 4 VIP (hardware load balancer) like NetScaler or Foundry, etc. You can put a VIP in front of Apache, and also between Apache and Tomcat. You can also just use a VIP in front of multiple Apache servers, and they point to multiple Tomcat servers. Ravi goes through quite a few slides of various configurations that are possible. I have attached them to this post so that you can download them in the future and review them (click here to download: Ravi Saraswathi - Slides).

I recommend downloading the slides for the rest of the presentation. It was hard to capture all of that information (mostly displayed as pictures) in the form of written notes.

ApacheCon - Securing Apache Tomcat for your Environment

Jeremy Thomerson — Thu, 06 Nov 2008 23:22:19 +0000

Presented by Mark Thomas, committer on Tomcat for five years

There have generally been few Tomcat threats in the wild (at least that have been reported). One in July 2008 was reported that was hackers installing a webapp, always named fex*.war (* for something - anything). It allowed hackers to get access to a shell on your server. If you were running as root, game over. The way this was being installed was through deployed servers with a Tomcat admin that had not been secured (blank or default passwords). This is obviously a very poor idea.

How can you protect yourself against Tomcat security attacks? Read more to find out.

The first rule of thumb is to make sure you have taken your standard precautions, such as OS hardening, firewalls, etc. Next, uninstall all of the default Tomcat applications, which are much better used in development environments (docs / examples / host-manager / manager / default ROOT application). You can run Tomcat in a security manager, but this is not a well tested method - you will need to completely test your application before deploying with it.

Tomcat is reasonably secure by default. One of the first things you can do is get rid of most of server.xml, including comments, to make it easier to read, etc. Using port=”-1″ disables a tag. The shutdown port should obviously use a strong password (long, and random). Another tip, not necessarily related to security, but to availability is that the tag is not well supported natively on Solaris.

Note on the following points - there was a lot to cover, and he was moving through it quickly. These notes are a bit sparse, but are his recommended best practices. He said to email the users list if you have further questions.

Do you need HTTP and AJP enabled?
address=”…” (defaults to all) - can you lock this down to a single IP? i.e. your proxy?
allowTrace=”false” - you should leave this off
xpoweredBy=”false” / server=”Server: Apache-Coyote/1.1″ - you can change these to try “security by obscurity” by confusing hackers as to what server you are actually running.

AJP specific configuration:

request.secret=”…” should be strong if used / although AJP connections are not encrypted, so this secret will be in plain text between the two servers - so not necessarily all that useful
tomcatAuthentication=”true” (default) - if you want httpd (for example) to do your authentication, you can set this to “false”, and configure mod_jk appropriately so that your front-end proxy can handle authentication and pass the username back to Tomcat

autoDeploy=”false” - should change it to false (defaults true)
deployOnStartup=”true” - if you change this and autoDeploy to false, the only apps deployed will be those defined in server.xml - which can block accidental (or malicious) app deployment

crossContext should normally be false
allowLinking - should not be changed on case-insensitive operating systems

Always configure an access log valve so that you can confirm when things happened and debug issues
Remove / archive old log files
Typically, do one per host
Use a remote address filter where possible
using allow for this is better than deny - only allow known addresses that should be able to access the application (don’t forget to escape the periods in the IP address - this attribute is a regex - use \.)

Don’t use memory or UserDatabase or JDBC realm in production. The first two require Tomcat restart, and the JDBC only uses a single JDBC connection.
You can use DataSource realm.
JNDI realm also uses a single connection
JAAS realm is not wisely used, and commonly has unreported bugs. They do support it, but because it’s not widely used, there can be untested issues that arise.
There is no account lock-out implemented - which allows brute-force attacks to work after some time. They are trying to get a fix for this into 6.0.19
New in 6.0.19 should be LockOut realm - it wraps around standard realms and provides a lock-out mechanism for multiple failed attempts for the same user. With this, there will also be the ability to have multiple realms for authentication - if any match, you get access - so you could use, for example, a tomcat users file for admins and a JNDI realm for users.

entropy=”this.toString()” can be deterministic, so you can use APR or randomClass=”java.util.Random” to define a true random entropy provider

System properties

org.apache.catalina.connector.RECYCLE_FACADES=”false” - I didn’t catch all of the details on this, but he said the docs are right - look at them, even though they sound counter-intuitive
org.apache.catalina.CoyoteAdapter.ALLOW_BACKSLASH=”false” - recommended setting
org.apache.tomcat.util.buf.Udecoder.ALLOW_ENCODED_SLASH=”false” - recommended setting
org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=”false” - recommended setting - if you turn it on, make sure that everything put into your sendError calls is in ASCII - don’t allow user data to be put into sendError calls

Other points:

Consider locking your database down to where the username that your web app uses to access the DB is only valid when it comes from the IP of your Tomcat server.
in the default servlet, you should use -readonly=”true” and -listings=”false”. For one thing, directory listings are not that secure of an idea, and they are very slow on Tomcat. If you absolutely need them, there is a patch that speeds them up - you’ll need to research and apply yourself.
He says “the invoker servlet is horrible, evil - don’t even use it, ever”.
Most monitoring tools also provide management functionality, which introduces risk that you’ll need to really think about. LambdaProbe is a good monitoring app, but weirdly disappeared from the net a couple months ago. He says to email the users list and someone there will provide it for you.
Hash out what you will do in the even of an attack ahead of time - don’t waste the time after you were attacked.
Using a cluster obviously reduces downtime - load balance it with httpd or similar.
Easing upgrades - you can separate your configuration files from your binary tomcat files by using CATALINA_BASE=/your/instance/config/path, and then start and stop which binary dist you want to use.

Wicket - the power of nested models

Jeremy Thomerson — Thu, 06 Nov 2008 20:52:59 +0000

Many times on the Wicket user list, we hear questions like “How do I return a different value when my model object is null?”, or “how do I make a label that says ‘none’ when the model object is null?”, or “How do I make a Label that capitalizes all it’s text?”…. You get the idea. Typically, the gut reaction is to do something like override getConverter in the Label or onComponentTagBody and sort of abuse that facility to change what value the Label uses. This works, but it isn’t reusable. One of the greatest powers of Wicket is creating reusable pieces of code that can be used anywhere in your application.

A great way to create a reusable piece of code to cover this scenario is to use nested models. If you are familiar with Wicket, you know that models, or implementations of IModel, are basically data locators - an abstraction layer that the component uses to locate it’s data. One power that this layer of abstraction gives you is that a component doesn’t need to know where it’s data came from. And, one model can use another model and add on to it’s behavior by composition. Let’s look at some code for a couple of examples.

EXAMPLE ONE - You want to provide a different value for the case when your model object is null


public class DefaultWhenNullModel implements IModel {

private static final long serialVersionUID = 1L;

private final IModel mNestedModel;
private final T mDefaultValue;

public DefaultWhenNullModel(IModel nestedModel, T defaultValue) {
mNestedModel = nestedModel;
mDefaultValue = defaultValue;
}

public T getObject() {
T val = mNestedModel.getObject();
return val == null ? mDefaultValue : val;
}

public void setObject(T object) {
mNestedModel.setObject(object);
}

public void detach() {
mNestedModel.detach();
}
}

EXAMPLE TWO - You want to capitalize the text in a label


public class CapitalizedStringModel implements IModel {

private static final long serialVersionUID = 1L;

private final IModel mNestedModel;

public CapitalizedStringModel(IModel nestedModel) {
mNestedModel = nestedModel;
}

public String getObject() {
String value = mNestedModel.getObject();
return value.toUpperCase();
}

public void setObject(T object) {
mNestedModel.setObject(object);
}

public void detach() {
mNestedModel.detach();
}
}

Use of these:


new Label("mylabel", new CapitalizeStringModel(new PropertyModel(user, "username")));

As you can see, both examples are very similar. You can take this further by creating a class like AbstractNestedModel (implementing IModel) that takes care of holding the nested model and detaching the nested model, etc. Then you could create these classes with only a getObject() method being implemented per type of model.

Why is this better?

Quite simply, because you can use this anywhere. For instance, if you did this in a Label instead, you could only use it where you use labels. But since models are used by all components that want to display data, you can reuse this for any component, not just a label. For instance, you could use this in MultiLineLabel or a TextField (you may want to add functionality to setObject for a TextField since it is read AND write).

Hopefully you found this brief tutorial helpful. If you are looking for professional Wicket training or support, check out http://www.wickettraining.com.

Great new tutorial on Wicket

Jeremy Thomerson — Thu, 06 Nov 2008 18:28:54 +0000

Someone sent this to the wicket users list today. There is a great article on IBM DeveloperWorks detailing how to get started with Wicket. It covers a wide array of topics, and if you are thinking of getting started with Wicket (and haven’t yet bought Wicket in Action!), you should definitely check out this article:

https://www.ibm.com/developerworks/library/wa-aj-wicket/

Since I’m busy at ApacheCon, I have not been able to read the entire thing. I did notice that he still shows setting up your web.xml with a servlet, although the latest versions of Wicket are all based on a servlet filter instead. But, that’s a small detail - the amount of work Kumarsun put into this tutorial is definitely noteworthy!

ApacheCon - ModSecurity

Jeremy Thomerson — Thu, 06 Nov 2008 16:55:02 +0000

Presented by Ivan Ristic, a web application firewall expert and author of ModSecurity and Apache Security

The problem: HTTP and browsers are designed for document exchange. We have web applications built using a number of loosely integrated technologies. These are created without a lot of thought about security. Things now are better than ten years ago, but there are also more threats now to defend against.

The solution: (or at least one solution) - a web application firewall.

I apologize in advance - Ivan was moving very fast, and many of the notes are sparse as he was jumping from slide to slide. I couldn’t keep up.

Part 1 - What are Web Application Firewalls?

Web Application Firewalls are a cost-effective technology that works, and can be deployed easily. Ivan explains that network firewalls do not work for many kind of attacks.

Part 2 - ModSecurity

What is it? It’s an open source web application firewall. According to some independent researchers, it is the most widely deployed WAF on the internet. Commerical support has been available through Thinking Stone since 2004 and now Breach Security. It doesn’t do anything implicitly - it’s goal is to empower the user to do what you need, and to do this, it needs to be configured. Fortunately, one of the goals of the project is to be very well documented. There is a separate project called ModSecurity Core Rules. This provides a general set of rules that can typically be used for any web application.

Two ways that it can be used:

Embed it into your existing web servers
Deploy it as a network gateway, using Apache proxy - putting it in front of all of your web servers.

There are five phases:

REQUEST HEADERS - run this as early as possible
REQUEST BODY - it inspects the request body before the Apache server gets it and starts processing it.
RESPONSE HEADERS
RESPONSE BODY
LOGGING

With ModSecurity, you can log the entire transaction, or parts of it. There are two formats: Serial - a single file, convenient but limited. Concurrent - file per transaction, scalable but not suitable for manual handling. Then you can use Mlogc which can take what you logged and send it to a central logging server. There is a free (as in beer - not open source) tool available to analyze logs - ModSecurity Community Console.

ModSecurity Rule Language - it’s a simple, event-based programming language, which lives within the Apache configuration syntax. With it, you can look at any part of the transaction, can trasnform it as needed, and you can combine rules to form complex logic. This means that common tasks are easy, and complex tasks are possible.

Basic syntax: SecRule TARGETS OPERATOR [ACTIONS]

Example: SecRule ARGS|REQUEST_HEADERS “