Wydarzenie trwało dwa dni i odbywało się w Pałacu Kultury i Nauki w Warszawie. Na kilkudziesięciu sesjach występowali zarówno prelegenci polscy jak i zagraniczni. Całość otwierała sesja generalna, na której najważniejsze osobistości MS’u opowiadały o wizji oraz planowaniu wydatków przez Microsoft (sic!). Mimo iż była to głównie marketingowa papka, trzeba przyznać, że zrobiona perfekcyjnie. Sala kongresowa pękała w szwach i chyba nawet nikt nie wychodził w trakcie. Trzy ogromne rzutniki w połączeniu z muzyką, światłami oraz ogromną charyzmą na scenie stworzyły wybuchową mieszankę.

Po zakończonej sesji wychodziło się z sali z myślą „Tak!.. jestem deweloperem i jestem z tego dumny!” (wiecie co mam na myśli ?:). Potem przyszedł czas na konkrety.
W kilku salach jednocześnie odbywały się prelekcje na które każdy zapisywał się indywidualnie układając sobie harmonogram. Uczestnicy otrzymywali karty identyfikacyjne z kodami kreskowymi, skanowane czytnikiem przez co wszystko przebiegało bardzo szybko i sprawnie. Jeżeli 5 minut po rozpoczęciu sesji były wolne miejsca, można było wejść na salę, na która nie było się zapisanym. Dzięki temu, jeżeli komuś zależało na jakiejś sesji, mógł się tam dostać bez większych problemów.

W trakcie trwania wydarzenia były godziny, w których prelegenci stacjonowali w boksach i odpowiadali na pytania uczestników (ask the expert). Muszę przyznać, że była to część, która najbardziej mi się podobała. Bez żadnego dystansu, można było nawiązać kontakty i porozmawiać o swoich ulubionych technologiach, powymieniać doświadczenia czy pośmiać się z bug’ów w nowym sofcie MSu:)

Inne minusy organizacyjne to samo miejsce, w którym odbywała się konferencja było jakby trochę za małe na taką liczbę osób(ale czy są większe?), przez co posiłki część osób musiała konsumować na ziemi.

Jeżeli chodzi o same sesje, to część z nich niestety nie zachwycała i było widać przysypiających uczestników (niektórzy chrapali!). Na szczególną uwagę zasługują prelekcje Tomasza Onyszko, który z dużą dawką humoru prowadził sesje w taki sposób, że nawet ktoś kto nie był zbytnio związany z tematyką dość szybko rozumiał nawet zaawansowane zagadnienia. W 3 sesjach przez niego prowadzonych można było zrozumieć tematykę Single Sign On przez ActiveDirectory właściwie od A do Z (oczywiście na tyle ile można zrozumieć coś od a do z oglądając prezentację). Dodatkowo bardzo podobał mi się dystans prowadzącego, który otwarcie mówił, że używa WireSharka, pokazywał dużo produktów nie-microsoftowych i uczył jak integrować linuxa z AD

Innym prelegentem, który potrafił ‘uwieść’ swoją charyzmą i sposobem prowadzenia prezentacji był Mark Minasi prowadzący Uncovering Windows’ Two Least-Understood Security Stars: UAC and WIL. Show w pełnym tego słowa znaczeniu z dużą dawką poczucia humoru i ten czysto amerykański staajl, który budził nawet najbardziej sennych słuchaczy. Niestety nie była to najbardziej intensywna dawka wiedzy technologicznej ale zrekompensowana lekkością i przyjemnością z słuchania.

Jeżeli ktoś lubi bardziej technologiczne wykłady powinien zajrzeć na sesję Tomka Kopacza. Miałem przyjemność uczestniczyć w dwóch prezentacjach. Pierwsza „Usługi w świecie Microsoft: WCF,REST, .NET Service Bus, Workflow Services”, była podróżą w której uczestnik poruszał się po wszystkich zagadnieniach związanych z usługami w przerażającym tempie. Tomek bardzo precyzyjnie zwracał uwagę na wszystkie pułapki wydajnościowe oraz sugerował w jaki sposób można sobie z nimi radzić.
Niestety rozczarowała mnie trochę druga sesja o Entities framework, ale nie wiem czy to przez samego prelegenta, czy może bardziej przez technologię. Mając doświadczenia z ORMami takimi jak Hibernate/NHibernate można wysnuć jedyny wniosek – nowy świetny produkt MSu to przepisane stare rozwiązania, a w dodatku bez połowy funkcjonalności i nazwaniem tego „nowa jakość pisania oprogramowania”. W nowych wersjach pojawiają się kolejne moduły, które są już w innych orm’ach i sprzedawane jako technologia, która zbawi świat. Nie zaskoczy mnie jak w wersji .net 4.5 MS przepisze kilka kolejnych rzeczy takich jak adnotacje(attrybuty w świecie .net), cache, wersjonowanie encji czy search(Hibernate’a).

Poza tymi kilkoma szczegółami na pewno warto było pojawić się na konferencji, chociażby po to, aby zobaczyć cały rozmach z jakim została ona zorganizowana. Można było na niej znaleźć inspirację i poznać technologię, którymi warto się zainteresować. Dla kogoś kto jest związany z nimi na co dzień raczej bez fajerwerków.

No to zaczynamy…

Integracja Struts2 – Spring – Groovy

Od jakiegoś czasu wdrażam się w tematykę groovy’iego & grails’a i wszystkimi aspektami z nimi związanymi. W skrócie groovy to język dynamiczny kompilowany do klas Javy, a grails to cały framework z wbudowanymi min. Hibernate’m i spring’iem wspierający paradygmat konwencja ponad konfiguracją. Jeżeli chodzi o zalety, to mamy bardzo dużo rzeczy ‘za darmo’  i konfigurujemy tylko to co jest nam potrzebne. Nie chciałbym ich wszystkich tutaj wymieniać, bo można znaleźć setki artykułów, na ten temat.

Ponieważ od jakiegoś czasu używam połączenia spring + jpa + struts2 zacząłem zastanawiać się jak rozszerzyć je o wsparcie dla groovy’iego. Istnieje  plugin do struts’a implementujący fabrykę obiektów pozwalającą na budowanie instancji  bezpośrednio z plików .groovy. Niestety plugin ten został stworzony jako rozszerzenie StrutsObjectFactory bez uwzględnienia springa, co ogranicza nam możliwość wstrzykiwania Beanów do struts’owych akcji.

Spróbujmy rozszerzyć struts-spring-plugin tak, aby pozwalał ładowanie skryptów groovy.

A więc od początku…

Zaczynamy od uruchomienia eclipse’a, wraz z wtyczką wspierającej pisanie w groovym.

Jako serwer aplikacji wykorzystamy Tomcat’a 6.0.

Następnym krokiem będzie ściągnięcie wszystkich niezbędnych bibliotek

• Struts2 wraz ze źródłami
• Spring 2.5.6-SEC
• Groovy 1.6.3

W obszarze roboczym tworzymy dwa projekty

• SpringGroovy – będący prostą aplikacją webową do testowania pluginu
• SpringGroovyPlugin – nasze rozszerzenie

Ponieważ twórcy struts’a nie zalecają tworzenia wtyczek zależnych od siebie zdecydowałem się rozszerzyć istniejący plugin do integracji ze springiem. Podpinamy źródła wtyczki znajdujące się w
struts-2.1.6\src\plugins\spring\src\main\java

Źródła zawierają w zasadzie tylko dwa pliki, klasę Java \org\apache\struts2\spring\StrutsSpringObjectFactory.java która rozszerza SpringObjectFactory oraz plik konfiguracyjny struts-plugin.xml, który zawiera konfigurację

<!DOCTYPE struts PUBLIC
„-//Apache Software Foundation//DTD Struts Configuration 2.0//EN”
„http://struts.apache.org/dtds/struts-2.0.dtd”>

<struts>
<bean type=”com.opensymphony.xwork2.ObjectFactory” name=”spring” />

<!–  Make the Spring object factory the automatic default –>
<constant name=”struts.objectFactory” value=”spring” />

<package name=”spring-default”>
<interceptors>
<interceptor name=”autowiring”/>
<interceptor name=”sessionAutowiring”/>
</interceptors>
</package>
</struts>

Najbardziej interesujący nas fragment to

<bean type=”com.opensymphony.xwork2.ObjectFactory” name=”spring” />

Czyli definicja ziarna o nazwie spring będąca fabryką obiektów StrutsSpringObjectFactory oraz

<constant name=”struts.objectFactory” value=”spring” />

czyli ustawienie wyżej zadeklarowanego ziarna jako domyślnej fabryki obiektów.
Obie definicje za chwilę zastąpimy własną implementacją.
Tworzymy klasą dziedziczącą po spring’owym factory:

package com.ds.struts2.plugin;

import groovy.lang.GroovyClassLoader;

import java.io.File;
import java.io.IOException;
import java.net.URL;

import javax.servlet.ServletContext;

import org.apache.struts2.StrutsConstants;
import org.apache.struts2.spring.StrutsSpringObjectFactory;

import com.opensymphony.xwork2.inject.Inject;
import com.opensymphony.xwork2.util.logging.Logger;
import com.opensymphony.xwork2.util.logging.LoggerFactory;

public class SpringGroovyObjectFactory extends StrutsSpringObjectFactory {
 private static final long serialVersionUID = -1890684310820252562L;
 private static final Logger LOG = LoggerFactory.getLogger(
SpringGroovyObjectFactory.class.getName());
 private GroovyClassLoader gcl;
 
 @Inject
    public SpringGroovyObjectFactory (
            @Inject(value=StrutsConstants.STRUTS_OBJECTFACTORY_SPRING_AUTOWIRE,
required=false) String autoWire,
            @Inject(value=StrutsConstants.STRUTS_OBJECTFACTORY_SPRING_AUTOWIRE_ALWAYS_RESPECT,
required=false) String alwaysAutoWire,
            @Inject(value=StrutsConstants.STRUTS_OBJECTFACTORY_SPRING_USE_CLASS_CACHE,
required=false) String useClassCacheStr,
            @Inject ServletContext servletContext) {
  
  super(autoWire,alwaysAutoWire,useClassCacheStr,servletContext);
       
  //inicjalizacja class loadera z groovy utils
  gcl = new GroovyClassLoader(this.getClass().getClassLoader());

  LOG.info(„… initialized Struts-Spring-Groovy integration successfully”, new String[0]);
 }
 
 public Class getClassInstance(String s) throws ClassNotFoundException {
     //jezeli brak rozszerzenia .groovy uzywa springowego factory
  if(!s.endsWith(„.groovy”))
         return super.getClassInstance(s);
     Class clazz = null;
     try {
         clazz = loadGroovyClass(s);
     } catch(Exception ex){
         LOG.error(„Groovy object factory error”, ex);
     }
     return clazz;
 }

 private Class loadGroovyClass(String s)throws ClassNotFoundException, IOException {
  s = s.substring(0, s.length() – „.groovy”.length());
  URL r = getClass().getResource(„/”);
  String path = r.getFile();
  s = s.replace(„.”, „/”);
  s += „.groovy”;
  path += s;

        Class clazz = gcl.parseClass(new File(path));
        return clazz;
    }
}

Ponieważ przesłaniamy konstruktor springa, musimy oznaczyć go adnotacją @Inject z takimi samymi parametrami jakie miał konstruktor klasy bazowej, aby struts wiedział, co ma wstrzyknąć podczas inicjalizacji.
W konstruktorze tworzymy class loader z pakietu groovy.lang

gcl = new GroovyClassLoader(this.getClass().getClassLoader());

który pozwala nam na ładowanie klas ze skryptów grooviego, jak widać w metodzie loadGroovyClass(String s).

Metoda getClassInstance jest wywoływana za każdym razem, gdy wywołamy akcję zdefiniowana w pliku struts.xml i w przypadku kiedy akcją jest zwykłą klasą, zostaje wywołana metoda klasy bazowej.

if(!s.endsWith(„.groovy”))
return super.getClassInstance(s);

Jeżeli jednak jest to plik .groovy korzystamy z metody parseClass podając ścieżkę do pliku. Zastanawia mnie jaki ma to skutek wydajnościowy, ponieważ, za każdym razem zostaje parsowany plik ze skryptem. Być może warto było by pokusić się o cache’owanie tak zainicjalizowanych klas (a może biblioteka dostarczona z groovym sama dba o to?) lub w momencie tworzenia paczki produkcyjnej wcześniejsze kompilowanie wszystkich skryptów do postaci .class.

Mamy fabrykę więc pozostało wprowadzić zmiany w konfiguracji:

<struts>
<bean type=”com.opensymphony.xwork2.ObjectFactory” name=”springGroovyObjectFactory” />

<!–  Make the Groovy-Spring object factory the automatic default –>
<constant name=”struts.objectFactory” value=”springGroovyObjectFactory” />

<package name=”spring-default”>
<interceptors>
<interceptor name=”autowiring”/>
<interceptor name=”sessionAutowiring”/>
</interceptors>
</package>

</struts>

Eksportujemy projekt do postaci pliku .jar i podgrywamy do projektu SpringGroovy w celu przetestowania rozwiązania.

Utworzyłem plik Web.xml ze standardowymi filtrami dla strutsa i springa:

<filter>
<filter-name>struts2</filter-name>
<filter-class>
org.apache.struts2.dispatcher.FilterDispatcher
</filter-class>
</filter>

<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>

Następnie bardzo prostą akcję napisaną w groovy’im wyświetlającą komunikat na ekranie:
package com.action.groovy

import org.apache.struts2.convention.annotation.Result
import com.opensymphony.xwork2.ActionSupport
import org.apache.struts2.convention.annotation.Action

public class GroovyHelloWorld extends ActionSupport{

String msg = "Hello groovy!"

public String execute(){
addActionMessage(getMsg());
return SUCCESS;
}
}
Pozostało zdefiniowanie akcji w pliku struts.xml

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<!DOCTYPE struts PUBLIC
„-//Apache Software Foundation//DTD Struts Configuration 2.0//EN”
„http://struts.apache.org/dtds/struts-2.0.dtd”>
<struts>
<constant name=”struts.objectFactory” value=”springGroovyObjectFactory” />
<constant name=”struts.devMode” value=”true” />

<package name=”basic” extends=”struts-default”>

<action name=”groovy” method=”execute”>
<result>/WEB-INF/jsp/basic/groovy.jsp</result>
</action>

</package>

</struts>
Oraz utworzenia widoku /WEB-INF/jsp/basic/groovy.jsp

<?xml version=”1.0″ encoding=”ISO-8859-1″ ?>
<%@ page language=”java” contentType=”text/html; charset=UTF-8″
pageEncoding=”ISO-8859-1″%>
<%@ taglib prefix=”s” uri=”/struts-tags”%>

<!DOCTYPE html PUBLIC „-//W3C//DTD XHTML 1.0 Transitional//EN” „http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1″ />
<title>Insert title here</title>
</head>
<body>
<s:actionmessage/>
</body>
</html>

Po uruchomieniu serwera w moim przypadku okazało się, że plugin nie działa tak jak powinien. Eclipse podczas budowania projektu ignoruje pakiety, w których nie ma żadnych klas (a przecież my mamy tylko plik .groovy) i nie kopiuje ich do katalogu classes, gdzie classloader szuka skryptu. Nie udało mi się znaleźć ustawienia, które by załatwiło sprawę, więc na czas testów dodałem do pakietu pustą klasę.
Tym razem plugin powinien działać bez zarzutu.