Salve a tutti, in questi giorni mi sono addentrato ancora nel mondo del continuous integration perchè sto lavorando su un progetto in Java, gestito in outsourcing, dove aiuto un gruppo di sviluppatori ad utilizzare strumenti di sviluppo che facilitano il lavoro quali un sistema di continuos integration.

Sono partito da un progetto con subversion installato su una macchina e so che nel progetto usano Jboss con JDK 1.5 (ancora non so perchè)

Su un’altra macchina remota vado e installo JDK 1.5.0.22, Ant 1.7.1, Maven 2.2.1 (fino ad ora (2 mesi di progetto) hanno usato solo Ant e vorrebbero passare a Maven), Jboss 5.1.0, Webclient for SVN 3.1.0 e Artifactory 2.1.2.

Piccola nota: volevo usare Sventon ma l’ultima versione aveva problemi con le librerie e le precedenti mi davano anch’esse problemi.

Non sapete cosa è Artifactory ??? Allora è possibile che siete ancora freschi su Maven (non è che io non lo sia )

Artifactory è una applicazione web che permette di gestire repository Maven, sviluppata in Java e rilasciata con licenza LGPL 3.0. L’applicazione è realizzata da JFrog Ltd, una società privata isreliana.

Strutturalmente si poggia su Apache Jackrabbit per l’implemetazione delle specifiche JSR 170 per il cosiddetto Java Content Repository (anche altri content manager come Nuxeo si appoggiano su Jackrabbit).

Piccola nota: la JSR 170 (rilasciata nel 2005) è seguita dalla JSR 283 da poco rilasciata (25 Settempre 2009) ed entrambe sono condotte da David Nuescheler, CTO della società svizzera Day Software.

Inoltre Artifactory si basa su Apache Lucene per indicizzare i file e Apache Wicket per l’interfaccia utente.

Ora l’applicazione è rilasciata come standalone ma esiste la versione war che può essere deployata su un application server e quindi l’ho messa su Jboss insieme ad Hudson e Webclient for SVN (questi 2 li ho poi legati con il plugin di hudson per Polarion che permette di linkare la lista di file modificati ai file presenti sul webclient e si possono anche vedere le differenze con le versioni precedenti).

La struttura è basata anche su database, di default Apache Derby ma che può essere cambiato (vedi anche qui).

A parte il fatto che Artifactory permette di base una autenticazione LDAP, quello che lascia senza parole è la semplicità di uso (andrebbe confrontato con Nexus ma non ne ho tempo, di sicuro nella versione base manca LDAP (anche se ho scoperto di recente che esiste un plugin di terze parti) e di sicuro gli sviluppatori hanno realizzato una bella guida a maven e un plugin per Eclipse). Una volta andato su

http://localhost:8080/artifactory

e loggato, sono andato sul pannello amministrativo e nella sezione repository ho creato un repository locale dove fare il deploy dei propri jar file e un repository virtuale in cui aggiungo quello locale più tutti i remoti quali quello di Maven, Jboss ecc ecc. Fatto ! Ora potete generare anche la sezione del file settings.xml da aggiungere nel vostro progetto Maven.

Per una vecchia guida vi rimando qui. Per un confronto con Nexus e Archiva vi rimando a questo link (attenzione è scritto dallo stesso autore della guida su Artifactory ma sembra serio)

Buon maven a tutti !

Nota: Webclient for SVN si basa su Subversion 1.4 (con versioni successive ho avuto problemi perchè usa un SVNKit vecchio che non posso aggiornare perchè c’è una particolare classe non più presente nelle ultime versioni), potete trovare Subversion 1.4 qui:

http://downloads-guests.open.collab.net/servlets/ProjectDocumentList?folderID=6

When using the back/forward buttons in FF3.x, pages are cached and delivered from cache very strictly. Obviously (unlike normal caching) even page headers like Pragma, Expires etc. are ignored. This special cache is often referred to as bfcache (back/forward cache).

This behavior caused exceptions in my wicket app, where ajax funtionality is used, here’s what happens:
* Load page containing panelA
* User interaction, replacing panelA with panelB using ajax
* User clicks back button
* User clicks forward button
-> initial page content (markup) is loaded from fbcache, including panelA
-> in wicket pageMap, panelA is not existent, since it has been replaced with panelB
* User interacts with an ajax element on panelA
-> exception is thrown “Component x not found on page”

Solution: add an unload handler to the page’s body tag. This causes firefox to reload the page instead of simply grabbing it from bfcache, so that server and client side state is in sync again

Sometimes we need to forward to a servlet or resource that’s outside of Wicket such as a servlet. Here’s how:

1. Modify your web.xml to define your servlet as well as your Wicket application “ignorePaths” init-param:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
 <display-name>Wicket Example</display-name>
 <filter>
 <filter-name>MyApplication</filter-name>
 <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
 <init-param>
 <param-name>applicationClassName</param-name>
 <param-value>com.gu.MyApplication</param-value>
 </init-param>
 <init-param>
 <param-name>wicket.configuration</param-name>
 <param-value>deployment</param-value>
 </init-param>
 <init-param>
 <param-name>ignorePaths</param-name>
 <param-value>images/,s/</param-value>
 </init-param>
 </filter>
 <filter-mapping>
 <filter-name>MyApplication</filter-name>
 <url-pattern>/*</url-pattern>
 </filter-mapping>
 <servlet>
 <servlet-name>SomeServlet</servlet-name>
 <servlet-class>com.gu.SomeServlet</servlet-class>
 </servlet>
 <servlet-mapping>
 <servlet-name>SomeServlet</servlet-name>
 <url-pattern>/s/koolkat.do</url-pattern>
 </servlet-mapping>
</web-app>

The first observation is that Wicket is running as a Filter and not a Servlet. Second, the init-param – “ignorePaths” says that anything in the “/images” and “/s/*” will be ignored by Wicket Filter and passed along downstream.

2. Next in your Wicket Form, within your onSubmit method override you can do the following:

class TestForm extends Form(id){
  @override
  public TestForm(String id, SomeFormModel ghfm)
  {
    //Code removed
  }
  @override
  public onSubmit()
  {
    String url = "/s/koolkat.do"; //some url within the same web-context
    getRequestCycle().setRequestTarget(new RedirectRequestTarget(url));
  }
}

Notice that the url field does not contain the “ContextPath”. Wicket takes care of that in the background. On the other hand, suppose you wanted to redirect to a URL ourside of your web context or to an external site then you would set the variable like this.

String url = "http://mythinkpond.wordpress.com/2009/11/13/forwarding-to-a-url-from-wicket/";  //or
url = "http://myserver:port/othercontext/someurl";

On some rare occasions, you might want to get the servlet Request Dispatcher to forward a request. For that it gets a little tricky.

– In your class you want to grab the “HttpServletResponse”. I’ve been unsuccessful in getting it in the class.

class xyz extends WebPage{
  public xyz()
  {
     HttpServletResponse response = getWebRequestCycle().getWebResponse().getHttpServletResponse();
     //additional code
     xyxForm thisForm = new xyzForm(thisModel, response);
  }
}

class xyzForm extends Form{
  HttpServletResponse response;

  public xyzForm(xyzModel model, HttpServletResponse thisResponse)
  {
     response = thisResponse;
  }

   public onSubmit() {
     HttpServletRequest request = getWebRequest().getHttpServletRequest();
     //additional code here
     getWebRequest().getHttpServletRequest().getRequestDispatcher(url).forward(request, response);
  }
}

Please note that the above code is pseudo-code and not actual code because I was writing it in Scala and not Java. But for the audience, I’m trying to express it in Java so that it can have the greatest impact.

That’s it! Happy Coding!

If you find this article useful, consider signing up for my RSS feed or Email Newsletter. See links on the right side.

One of the first things I found as I was getting familiar with Wicket is how do you point to resources that are part of a page. Well I did some digging around to find out so I’m documenting it here for others who might be facing the same challenges as they discover Apache Wicket.

Problem:
You have pages in Wicket that are HTML with “Wicket” tags. But then you might want to point to resources such as CSS style sheets or JavaScript that’s part of a page. Here’s an example of a typical JSP page:

<html>
<head>
<style type="text/css" media="screen">@import \" + request.getContextPath() + "/styles/site.css\";</style>
</head>
...

Well, the above code works when you have a JSP page that gets compiled at run-time before being served. But in the case of Wicket, it does not. So how do you handle such situations?

Solution:

Step-1: Add “<wicket:head>” and “</wicket:head>” between your HTML page like this:

<html>
<head>
<wicket:head>
<!-- Other existing HTML tags can continue to go here -->
</wicket:head>
</head>
...

Step-2: Get the ServletContext and in turn the Context-Path for the web application in your Java/Scala code.

For application servers implementing Servlet 2.5 and above: (Tomcat 6.x implements Servlet 2.5)

ServletContext servletContext = WebApplication.get().getServletContext();
String contextPath = servletContext.getContextPath();

For application servers implementing Servlet 2.4: (Tomcat 5.5x implements Servlet 2.4)

String contextPath = getWebRequestCycle().getWebRequest().getHttpServletRequest().getContextPath();

What’s the difference? Well, in Servlet 2.5, a new method was added
String javax.servlet.ServletContext.getContextPath()
But if you are deploying your code in an earlier Tomcat or other application servers that do not implement Servlet 2.5, you will be at a disadvantage. So in those cases, use the other approach.

Step-3: In your Java/Scala Wicket code, just as you add labels or other components to your page you can add the following:

add(new StringHeaderContributor("<style type=\"text/css\" media=\"screen\">@import \"" + contextPath + "/styles/site.css\";</style>"));

So here’s what happens. In step-2, we created a variable called “contextPath” with the Servlet Context Path as it’s value. And when you add a “StringHeaderContributor”, it adds an entry into the pages header. It’s that simple!

So now after your browser goes through the request you now have the correct “ContextPath” inserted into your application:

<style type="text/css" media="screen">@import "/sampleapp/styles/site.css";</style>

After I posted the article I noticed I had left out a few additional details on this topic. If you are
adding resources such as images on your page, Wicket provides you with a easy way to do this. There is a org.apache.wicket.markup.html.image.ContextImage class that you can use to create image html tags in your
page.

In your Java or Scala class you can do the following:

add(new ContextImage("logo", contextPath + "/i/logo.jpg"))

and in your html (Wicket) page you can add a html-wicket element like this:

<img wicket:id="logo"/>

Wicket matches the wicket:id “logo” with the element added in the code and displays the image with the correct context-path.

If you find this article useful, consider signing up for my RSS feed or Email Newsletter. See links on the right side.

The standard solution for unit testing Wicket apps is WicketTester. It works fine, but doesn’t offer much for testing ListViews. The assertListView method lets you test the contents of the ListView, but not the UI.

You can always extract the ListView rows into a Panel, of course. But when you don’t want to do that for whatever reason, it’s simple to side-step WicketTester and do the necessary tests yourself, especially since rows that are not in a panel of their own should be pretty simple.

An approach that works well for me is visiting the ListItems using MarkupContainer.visitChildren() and then accessing their components via Component.get(). To focus on the essential part, I’m using a method listView() in my example that gets the ListView from the rendered page. Once we have it, we visit its items.

listView().visitChildren(ListItem.class, new IVisitor<ListItem>()
{
	public Object component(ListItem item)
	{
		Component uri = item.get("uri");
		assertNotNull(uri);
		assertTrue(uri.getClass().isAssignableFrom(ExternalLink.class));

		// etc.

		// If testing one row is enough, we can stop here.
		return IVisitor.STOP_TRAVERSAL;
	}
});

Once you see it, it’s trivial. WicketTester’s assertComponent() isn’t magic, you can do the same in three lines: get the Component via its path, assert it’s actually present, and assert it’s the right type.

If you want to do further tests on the component’s internals, I find it practical to expose those through package-scoped methods, provided your tests are in the same package than your app.

Finally, something that bit me once: how ListItems work with the list model. Say we have this (just a rough sketch):

class Foo
{
	List bars;
	List<Bar> getBars() { return bars; }
}

// On some page, the model is a CompoundPropertyModel<Foo>.
add(new ListView<Bar>("bars")
{
	protected void populateItem(final ListItem<Bar> item)
	{
		item.add(new WebMarkupContainer("id"));
	}
});

If you get hold of the WebMarkupContainer(“id”), for instance using an IVisitor like I showed above, and you call getDefaultModelObject() on it, what do you get? One might expect a Bar; after all, it’s a ListView<Bar>. Not so – you get a Foo.

ListViews work on the original List instead of a copy. Each ListItem is backed by a ListItemModel, which knows the index of the element it represents, but has no model itself. When the model is looked up, the normal Wicket model chaining happens, so we get to the CompoundPropertyModel. The ListView code of course knows about this and uses the ListItemModel’s index to get the right Bar from the list. But getDefaultModelObject() doesn’t know about this and simply returns the Foo.

If you are in that situation, explicitly ask for the ListItemModel:

((ListItemModel) component.getDefaultModel()).getObject()

should give you a Bar. Of course, if you visit the ListItem itself like in the example above instead of a nested component, you can just call getObject() on it and it does the right thing.

Hello,

I‘m beginning to think that the wicket mailing list has more traffic because they need more help.

I’m bothered that their standard idiom for the java class that backs a page does a lot of work in its constructor.

I’m finding the code examples are invariably hard to understand. For example, this is from one of the constructors from one of their sample apps.  Look at the populateItem method; it receives an item parameter, which it calls getModelObject() on, then it takes the result from that and calls add() on the item parameter to add a Label.  It just seems convoluted.

ListView view = new ListView("list", new PropertyModel(this, "results")) {
    protected void populateItem(ListItem item) {
        String result = (String) item.getModelObject();
        item.add(new Label("item", result));
    }
};

I still haven’t figured out how you’re supposed to handle the non-serializable objects in these page backing classes; e.g., the dao. The page backing classes are serialized and shared across instances in a clustered setup.

Sometimes in the constructor they call methods on the dao.  That just seems wrong. For why, see this article by Miško Hevery.

The past few days I’ve been prototyping for a new project we’re starting up at work. Previous web projects we’ve done have mainly been using JSF, however for this project I’ve been looking into Apache Wicket.

My first impressions are, I like it. I like it a lot, in fact. It seems to achieve a much more clean separation between code / components and HTML than other frameworks do. It does take a while to get your head around it though – I’ve only been working with it for a few days so am still finding my way round!

But I expect I will blog up some info when I’ve got my head around it.

It is starting to cold these days, I think winter is almost here.

I attempted to port the Seam “hotel booking” sample to Grails 1.1.1 as well as Tapestry 5.1, to add to this head-to-head comparison of Apache Wicket and JBoss Seam done earlier this year. You can find the code here: [browse] [SVN]

Here are the relative performance test results (page response time in milliseconds):

Heap-dump comparison for 20 concurrent user / sessions:

I’ll save detailed framework impressions and comparison for a later blog post, and I may need to make updates to the code based on feedback. Here are some overall observations:

• Grails was far more productive than Tapestry 5. This was mainly due to the documentation quality of Grails compared to the scattered and not very well organized Tapestry documentation.
• Ease of writing custom tag-libraries is IMO one of the best things about Grails.
• The two missing rows in the Tapestry performance test results are because I gave up trying to implement form field validation over Ajax when the user “tabs out”. Actually I didn’t implement form-field validation at all because I could not figure out how to integrate Hibernate Validator. Maybe I missed something obvious, do let me know.
• Grails still has some way to go in terms of performance. I am told that significant performance optimizations for GSP will make it into 1.2
• Overall, Wicket is fastest, with Tapestry coming a close second.
• Wicket also takes up the least amount of heap. 31 MB of the Grails heap alone is taken up by instances of the “groovy.lang.ExpandoMetaClass”.
• Session usage of the Seam + JSF combination is significantly higher compared to all the rest, around 760 KB per session.

Thoughts on Tapestry 5

I was very interested in seeing if Tapestry 5 lived up to its promise of significantly better performance and scalability – which is known to come at a cost: a programming model that treats web-pages as static structures that can be “pooled”. One example of what this means is that you can’t rely on constructors anymore so you now have to figure out other ways of re-initializing your server-state (if applicable) after you are handed an instance from the pool. The “magic” of getting a page from the pool or getting hold of request or session scoped variables is all achieved predictably – using annotations.

Another example: due to the way Tapestry does byte-code manipulation – the annotation approach works only for “private” fields and not “protected” ones. I found this out the hard way, encountering an exception when I tried to extend from an abstract base class and re-use code the “old-fashioned” object-oriented way.

There’s a lot more I can go into, but for now, to summarize my experience as a long-time Wicket user trying out Tapestry 5 – the top few differences I found are:

• Having to work around the implications of Tapestry pages being static and “annotation driven” programming like I described above.
• Tapestry does not have the equivalent of Wicket Model-s which give you fine-grained control over the data you need to render (and bind) within a page and how much of it you decide to persist in the session. Model-s are certainly the aspect of Wicket that takes the most getting-used-to, but I have a new-found respect for them now after trying Tapestry.
• I would rate the Ajax infrastructure of Wicket higher: for example Wicket Behavior-s are cleaner compared to Tapestry Mixin-s, and calling / handling Ajax requests (especially when you depend on server-side state) is far easier.
• Tapestry 5 does not have built-in support for web-flow or “conversation scope” so I had to write some code to maintain a map of bookings in the session. BTW I did not have to do this for Grails as I could use WebFlow.

So coming back to the question, does the “Tapestry way” have a distinct advantage and are the quirks of the programming model worth it? The opinion of the Tapestry team on this is pretty clear. Take this quote from the Tapestry home page for example:

In some Tapestry-like frameworks, such as Faces and Wicket, the page structure is more dynamic, at the cost of storing much, much more data in the HttpSession.

Well, looking at the performance comparison results, my personal conclusion is that statements like the above are incorrect. In fact Tapestry seems to take up more heap space than Wicket for the same functionality. Also worth noting are the results of running the Wicket application using the HttpSessionStore instead of the default SecondLevelCacheSessionStore + DiskPageStore:

Because this time, Wicket is faster now even for the “post confirm booking” page. This particular action actually ends up displaying 200 items in an HTML table by the end of the test run for 20 concurrent users, since pagination is not being used.

The benchmark has been designed to be easy for you to run once you check-out the code, refer the end of this blog post for details. The details of the environment I used for the results posted here are as follows:

• java.runtime.version : 1.6.0_16-b01
• java.vm.name : Java HotSpot(TM) Server VM
• java.vendor : Sun Microsystems Inc.
• os.name : Windows XP
• os.version : 5.1
• sun.os.patch.level : Service Pack 3
• Intel Core 2 Duo 3.01GHz
• 3 GB RAM

Feel free to post your results or suggest changes to the code.

Here are some slides from a Wicket presentation I gave last Thursday night.

It is Sunday night. For those of you keeping score at home, that means I’ve made it through the first official week here. Last week, I’d have to say, didn’t count. It was full of buying chairs and desks and beds and generally trying to nest. This was the first real week.

Overall, orientation seemed really intense. Firstly, we had a project to complete about ourselves. It was officially the most open-ended project I’ve ever done. It just said to use an 8.5×11 sheet of paper about yourself. It could be anything. So I stayed up all night designing mine:

Needless to say, Kinko’s messed it up, so it came out looking terrible, although I was really happy with how it looked on screen. So let’s just pretend that’s how it came out.

On Monday, we had a full day of orientation, then class with Dan Allender, which was, needless to say, intense. I came away feeling like I had gotten hit by a train. A theological train that speaks in stream of consciousness.

Again on Tuesday, we had a long day. Then on Wednesday, we had orientation from 10:30-3, Interpersonal Foundations from 3:30-6, and Hermeneutics from 6-8. It was crazy, but even though I rode my bike 18 miles that day, I came home with enough energy to walk Wicket. That told me that, rather than being drained by the classes, I was actually energized by what I was learning.

However, I woke up the next day and had a terrible cold.

Go figure.

I’ve tried to make this weekend as relaxing as possible. On the upside, I’ve gotten 8 hours of sleep or more for the past 7 days straight. I think that’s a record for me. Literally.

On the down side, I still don’t have a job. I interviewed at REI the other day, but it’s hard to get a seasonal job when you’re firm on not being able to work during Christmas. So…there’s that. We’ll see if I get a call back. Meanwhile, I think I might just have to suck it up and try to apply to a few Starbucks locations. My roommate Dan has taught me that I’m not too good for any job. He’s looking to wash dishes. That’s awesome.

I’ve been doing my readings and really enjoying it.

I’ll check in after I get some seat time in during a real week of classes.

Meanwhile, send me good job-finding energy.

x factor auditions wales, some good singers there.

Grilling tips and techniques for holding the best bbq ever?

Back to school time of the year. Many people are depressed at the idea, kids, teachers and everyone in general.