Esigate 4.0 has just been released, along with a new home page.

Esigate is a reverse proxy, designed for integration purposes. A typical use is to merge PHP applications like Drupal, eZpublish, … with Java custom developments into a single, very fast web application.

The new website lists some successful users, including the French national railway company, Capgemini, Smile and others companies and public institutions.
We have more users to add to this list, but we are waiting for their authorization. Some of them can be found with simple google search . If you are an esigate user, please get in touch with us to have your logo and name added to the site.

This release introduces a standalone server (it no longer requires a servlet engine) and an extension API making it easier to add new features and change default behavior.

Apache HttpClient now replaces the previous custom HTTP cache implementation. We worked with HTTP client team during the last months to fix several issues which where affecting esigate.

More information and downloads on the new esigate website.

When working on Maven web projects with Eclipse, m2e and m2e-wtp, Webapps can sometimes suddenly stop working, raising ClassNotFoundExceptions on every startup.

This is because the webapp lib folder is no longer published to the server. Cleaning, Publishing, Closing/opening project, restarting Eclipse, nothing restore this folder and its content. Additionally, a new warning appears in the problem view :

Classpath entry org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER will not be exported or published

To solve this issue, just open .classpath at the root of the project and add the following attribute to the maven classpath :

<attribute name="org.eclipse.jst.component.dependency" value="/WEB-INF/lib"/>

Save and publish to the server.

The webapp should start again.

Source: Post from Eclipse forums http://www.eclipse.org/forums/index.php/t/262101/

Le site de Free Mobile a connu beaucoup de problèmes le jour de l’ouverture de l’offre: impossibilité de s’inscrire, inscriptions non prises en compte, etc.

Ne tenant pas la charge, le site à été réécrit pendant la nuit, en effectuant au passage une transition de Java (Jsf) vers Php.

En partant de ce constat, le troll Java Vs PHP est facile, mais plusieurs erreurs de conception ont largement contribué à l’écroulement du site:

Avant l’ouverture:
Avant l’ouverture officielle des inscriptions, le site de Free Mobile affichait un message du type : “dans quelques instants vous pourrez consulter nos offres”

• Première erreur: Rechargement automatique toutes les minutes.

  la page se rafraîchissait automatiquement toutes les minutes.
  En plus des rafraîchissements manuels effectués par les impatients, ce code à généré un surplus de connexions et surtout a agit comme une retenue d’eau : à l’ouverture du vrai site, l’ensemble des utilisateurs en attente y ont accédé dans la première minute.….

À l’ouverture
Le site utilisait un système de “slots” pour le processus d’inscription : seul un nombre limité d’utilisateurs pouvaient s’inscrire simultanément. Les autres devaient attendre.

• Deuxième erreur: Rechargement automatique toutes les 5 secondes.

  Lorsqu’aucun slot était disponible, le site affichait une page d’attente qui se rechargeait automatiquement toutes les 5 secondes pendant plusieurs minutes.
  En réponse à une surcharge, le site a multiplié volontairement la charge au bas mot entre 12x et 60x.

• Troisième erreur: Choix de JSF
  JSF est un framework par composants, orienté applications web (type intranet), qui a besoin de stocker en session, pour chaque utilisateur :
  • L’état de l’ensemble des composants de la page courante
  • Le même état pour les X dernières pages visitées pour permettre l’utilisation du bouton précédent

  … là où les frameworks orientés sites web publics ne stockent que l’identifiant de l’utilisateur, dans le cas où celui-ci est authentifié.

  Dans le cas de free mobile, toutes les inscriptions sont faites par des utilisateurs différents. Le volume de données à stocker est donc énorme et n’est pas adapté à la fonction du site.

  Il est possible dans JSF de reporter ces données coté utilisateur en les intégrant dans le code html, au prix d’une augmentation de la bande passante. Cette configuration n’était pas utilisée sur free mobile.

Après la refonte:
Le site fonctionne maintenant en PHP, mais on peut voir que les leçons ont été tirées des problèmes ci-dessus:

• En cas de surcharge du site, la page d’erreur redirige immédiatement vers la page d’accueil. Il n’y a plus de rechargement automatique. La redirection est même suffisamment rapide pour empêcher les utilisateurs de recharger eux-même la page trop facilement. (Note: La page principale est statique.)
• Le site est en php basique, sans utilisation de framework visible. On se doute qu’il n’y a quasiment pas de données en session, voir pas du tout

Conclusion

• Les rechargement de page en javascript sont dangereux sur les sites à forte charge. Il faut porter une extrême attention à leur impact sur le dimensionnement. Il vaut mieux privilégier un rechargement manuel de la page par l’utilisateur
• La session est un élément sensible des applications web. Pour un site a forte audience, il faut limiter drastiquement les données stockées, ce qui exclut naturellement un certain nombre de frameworks de type JSF.

  En cas de nécessité, il est possible de déporter les données sur des caches mémoire, tels que memcache, ehcache, cohérence.

• Un rappel: l’architecture mise en place ne dépend pas du langage. Faire une application complexe (modèle composant, de multiples couches, plein de données en session) ou ultra-simple quelques lignes dans un fichier est un choix, qui est réalisable de façon sensiblement identique dans les différents langages.

J’en profite également pour placer le projet open source Stateless Filter qui permet de déporter de façon transparente les sessions d’applications Java coté client ou dans un cache mémoire.

Les retours sont bien sûr les bienvenus. Je mettrai à jour l’article pour quelques corrections si nécessaire…

There are a lot of ressources on how to use YUIcompressor on a Maven project, but several examples don’t work with Maven3, or don’t allow to replace javascript and css by their compressed version transparently.

The following example will compress files transparently when packaging the webapp in a WAR file, and keep original files for development.

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-war-plugin</artifactId>
   <version>2.1.1</version>            
   <configuration>
      <warSourceExcludes>**/*.css,**/*.js</warSourceExcludes>
   </configuration>
</plugin>


<plugin>
   <groupId>net.alchim31.maven</groupId>
   <artifactId>yuicompressor-maven-plugin</artifactId>
   <executions>
      <execution>
         <id>compressyui</id>
         <phase>prepare-package</phase>
         <goals>
            <goal>compress</goal>
         </goals>
      </execution>

   </executions>
   <configuration>
      <nosuffix>true</nosuffix>
   </configuration>
</plugin>

XmlField 0.7 which was just released provides a new validation API, based on JSR 303, with some additions borrowed from Hibernate validation.

It is now very simple to ensure objects are valid, without complex XPath expressions or XPath duplication.

Add constraints to your interfaces :
@ResourceXPath("/database")
public interface IDatabase {
   @NotEmpty
   @FieldXPath("@name")
   String getName();

   @Size(min=1)
   @FieldXPath("tables/table")
   ITable[] getTables();
}


Validate :
IDatabase db = new XmlField().xmlToObject( xmlString, IDatabase.class );

Set<ConstraintViolation<Object>> violations = new XmlFieldValidator().validate( db );


Supported annotations :

• @NotEmpty : value exists and is not blank
• @Size : string length, array size
• @Range : numbers between min and max
• @Values : check for accepted values

Enjoy

See also : Introducing XmlField : Java xml/object mapping framework

We have recently released XmlField, a new Java xml/object mapping framework.

There are already a lot of tools for this, but none seemed to fit our requirements :

• A (very) simple API : we wanted to write as few code/configuration as possible, and keep code meaningful.
• The ability to process and update XML documents without altering additional, unsupported data. This means that the XML model can be updated without requiring to update and deploy existing applications in most cases. (for more information see the “Behavior” page on the projet’s site.
• No need to have a 1:1 mapping between the object XML structure, ability to flatten an XML document into a single object

If you’re writing a standalone application and use XML for storing configuration, XmlField will not be a major improvement (you may still like its simple API).

But if you are working in a corporate environment, with multiple applications sharing data using web or REST services, you may already see the benefits of these points.

A typical use case could be a system where user related data is stored in a central repository as xml documents and where this data is exposed through web services and used by several applications (both for reading and writing).

A some point, a new application requires additional data, which is not currently part of the xml model. This usually requires to update the central repository, adding support for this data through a new version of the web services, then maintain 2 versions of these services or move all existing applications to the new model to get rid of the previous one.

With XmlField-based applications, you just have to create your new app which stores additionnal tags in xml doduments. No need to update the central repository nor other applications. They will continue to process and update Xml objects, ignoring the new data but keeping it safe.

On the technical side, XmlField uses annotated interfaces to map xml data to objects. An interface can be written this way :

@ResourceXPath("/modelRootTag")
public interface IModel {
@FieldXPath("version")
String getVersion();

@FieldXPath("flag")
boolean getFlag();

@FieldXPath("entries/entry")
IEntry getEntries();

void setVersion(String version);

void setFlag(boolean flag);

IEntry addToEntries();
}

Then XmlField can be used this way :
// Source Xml
String xml ="";

// Read doc
XmlField xf = new XmlField();
IModel model = xf.xmlToObject(xmlRessource, IModel.class);

// Play with XML
model.setVersion( "1.0" );
String firstEntryName = model.getEntries()[0].getName();

//Add entry
IEntry newEntry = model.addToEntries();
newEntry.setName( "entry4" );
newEntry.setValue( "value4" );

// Back to XML.
xml = xf.objectToXml( model);


For more detailed examples, I just added a quickstart tutorial and a step-by-step example to the project’s website.

Even if the version number is only 0.6 yet, XmlField is stable enough for most uses and is currently used in production by several projects in different companies. We plan to reach 1.0 after the addition of a new document repository module, providing a lightweight xml document store with search and data validation.

Feedback is welcome. Feel free to test, use and report bugs or patchs using the project bugtracker and mailing lists.

XmlField released under the Apache Licence V2.0

http://xmlfield.sourceforge.net

(Related keywords : xml, java, serialization, marshalling, mapping, binding)

When developping Java web apps, you may sometime see random startup errors like this one :

java.lang.IllegalStateException: Unable to instantiate container.
at org.apache.tiles.web.startup.TilesListener.contextInitialized(TilesListener.java:60)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:549)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
(...)


Most of the time your application works, but sometimes it just does not start.

This is because of the dtd resolution mecanism: if you use the reference of a dtd which is not in the webapp classpath, the container will try to get it from internet.

If the remote site is down (in this case http://tiles.apache.org), your app will no longer start.

Sadly, it’s easy to get in this situation.

• Upgrade a library without updating xml headers
• Copy/Paste a snippet from the elsewhere

… and the container will start to fetch dtds from the internet.

In my case, the previous error was caused by :

<?xml version="1.0" encoding="ISO-8859-1" ?>

<tiles-definitions>
(...)
</tiles-definitions>

instead of :

<?xml version="1.0" encoding="ISO-8859-1" ?>

<tiles-definitions>
(...)
</tiles-definitions>

With tiles 2.0.6 in the classpath.

Conclusion
Be sure to use the exact version of the dtd in your classpath. Don’t pickup examples from the internet without double-checking the dtd.
This will prevent longer startup times and potential random errors.

Note: this post dedicated to Olivier and Jimmy

Après une première partie technique, nous allons étudier une partie plus théorique sur les différents usages d’ESIGate dans des projets Web.

Attention: Article en cours de rédaction, les concepts étant relativement complexes à comprendre (mais simples à mettre en oeuvre), vous êtes invités à commenter ce post pour aider à l’améliorer.

Le coeur d’ESIGate est une implémentation Java d’un moteur d’ESI :

• a partir d’un document HTML, le framework va parser le flux à la recherche de directives référençant des contenus à intégrer depuis des URL externes.
• Ces contenus sont récupérés et mis en cache automatiquement, puis insérés dans le flux HTML original.
• Les directives peuvent soit suivre la norme ESI, soit utiliser le format ESIGate, plus riche en terme de fonctionnalités.

ESI, à quoi ça sert ?
Les usages sont multiples, mais à l’origine la norme ESI permet d’étendre les possibilités de mise en cache des pages produites par des applications web et donc d’améliorer grandement leurs performances.

En effet, dans une application web, les pages sont généralement dynamiques et ce, même quand la majorité des contenus restent identiques pour l’ensemble des utilisateurs (le syndrome du ‘Bonjour M. Toto, il est 12h45′ qui, pour quelques caractères, interdit la mise en cache de la page).

L’ESI donne la possibilité de mettre en cache le contenu par fragments. En donnant les directives nécessaires à un cache situé en amont (Akamai, Varnish) pour découper la page en fragments HTML, chacun avec une durée de vie différente et pour récupérer les fragments expirés depuis des urls dédiées.

Ainsi, l’application n’est plus appelée que pour gérer le contenu dépendant de l’utilisateur, réduisant directement la charge du serveur.

Exemple de page utilisant des directives ESI pour Akamai:

<h2>Example 2</h2>
The following esi code is used for the customer testimonials on the www.akamai.com
home page. The included file is a ColdFusion script that selects one of four
graphics at random and displays them. <pre><esi:include src="http://www.akamai.com/cfcgi/quote_swap.dbm" ttl="5m"/><br><esi:remove><br> <img src="/graphics/layout/quote1.jpg" width="144" height="193" border="0"><br></esi:remove><br><br></pre>

<esi:include src="http://www.akamai.com/cfcgi/quote_swap.dbm" ttl="5m"/>
<esi:remove>
<img src="/graphics/layout/quote1.jpg" width="144" height="193" border="0">
</esi:remove>


Ici la directive include va récupérer un contenu externe, lourd à générer et le met en cache 5 minutes.
La directive remove permet de spécifier un contenu ‘bouchon’ qui permet de visualiser la page sans passer par un proxy ESI (très utile pour le travail de montage HTML par exemple).

Aller plus loin
ESIGate va pousser le concept ESI au delà des problématiques de performance, en permettant l’intégration d’applications au sein d’une IHM unique, cohérente, évolutive et surtout simple à mettre en place.

En effet, l’intégration dans un même site web de composants tels que CMS, Outil de e-commerce et développements spécifiques se fait toujours plus ou moins dans la douleur :

Au départ, il y a les fonctionnalités natives de chaque outil qui permettent de choisir celui qui est le plus adapté au besoin. On trouvera toujours un outil qui, utilisé de façon autonome, correspond parfaitement au périmètre fonctionnel demandé.

La situation se complique lorsque l’on souhaite additionner plusieurs outils : frameworks et technologies incompatibles (ex: Java et PHP), fonctions ou IHM à réécrire complètement à cause d’une intégration via API (ex: prévisualisation de contenus, urls propres, inplace-editing, …), duplication des efforts de montage, gestion de l’utilisateur, …. Le coût du projet s’envole.

ESIGate permet de mettre en place les applications de façon indépendante et de réaliser une intégration via leurs flux HTML :

• Le CMS est généralement désigné porteur du thème graphique, les autres applications se synchronisant avec lui.
• Chaque application reste maître de son périmètre (Editorial, Vente, Production, Administration) et intégrera les contenus ou informations provenant des autres applications via fragments HTML.

Pour arriver à ce résultat, il faut tirer partie des fonctions supplémentaires d’ESIGate:

• Le templating distant (sorte d’ESI inversé, où on ne référence pas des fragments externe, mais un thème distant pour lequel on fournit les blocs à intégrer)
• Les substitutions, les paramètres et les blocs nommés dans les fragments à intégrer
• La gestion des sessions distantes (réconciliation des multiples sessions distantes en une seule session visible)
• Propagation des informations d’authentification avec les systèmes SSO supportant les Proxy ticket granting : implémentatation fournie pour Jasig CAS.

Mise en oeuvre

Tout d’abord, il faut présenter les différentes configuration et outils d’ESIGate :

• L’API : le coeur du framework, à n’utiliser que si vous souhaitez un comportement totalement personnalisé. Elle sert de base à l’ensemble des éléments suivants
• Le Reverse proxy ESI : implémentation classique de l’ESI, ESIGate fonctionne en serveur standalone et agrège les flux HTML à partir des directives présentes dans le flux HTML
• La taglib : les fonctions d’intégration sont directement intégrées à une applications Java supportant les JSP
• Les composants JSF : les fonctions d’intégration sont directement intégrées à une application Java/JSF
• Les composants Wicket : les fonctions d’intégration sont directement intégrées à une application Java/wicket
• Le reverse Proxy de développement: plus dédié au développement d’applications Java nécessitant un reverse proxy, il peut simuler une configuration reverse proxy d’Apache directement dans un serveur Java. L’objectif étant de ne pas installer Apache sur le poste des développeurs : checkout->run
• ESIGate Static Assembly: Dédié aux monteurs HTML, permet de bénéficier d’un système de templating HTML brut (pas d’application web ou de serveur à installer), permettant l’utilisation de squelettes et de contenus communs pour l’édition HTML/CSS

Pour l’intégration d’applications, on utilisera le reverse proxy ESI ou les composants/taglib Java. Les configurations classiques sont :

• Pour intégrer une application Java dans un site existant, la solution composant/taglib est la plus simple, car elle n’ajoute pas de serveur/service supplémentaire. ESIGate s’intègre de façon quasi transparente en traitant les inclusions ou le templating à la volée. Seul un serveur Apache est nécessaire pour répartir les requêtes entre les différentes applications (configuation reverse proxy classique)
• Pour intégrer une application utilisant une technologie différente de Java ou tout simplement pour ne poser aucune contrainte, on utilisera le reverse proxy ESI, après le frontal HTTP traditionnel, pour retraiter tous les flux des applications. ESIGate aura le rôle de transmission du flux entrant vers l’application cible et celui d’assemblage du flux sortant en allant interroger les autres applications du site.

- La suite pour bientôt, avec des schémas -

(Ce tutorial est aussi disponible en Français : ESIGate Tutorial – Partie 1)

In this series, I will present the various uses of ESIGate framework (former Assembly Web Tool – WAT).

In Part 1, we will integrate a very simple application in a remote template, only via http. The typical use is a corporate intranet: multiple different applications (content management, HR management, time reporting, etc …) can use the same theme, based on a master application.

This has the following benefits:

• almost no need to work on styling (html/css) in slave applications.
• When the theme changes in the master application, the changes are immediately reflected on all slave applications without restart
• the master application can be replaced with no impact if the new theme is compatible
• If the new master application is incompatible with the previous theme, the synchronization can be ‘broken’ by pointing slave applications on a static html file

We’ll start from the archetype maven-archetype -webapp. In eclipse, create a new Maven project, and select the archetype maven-archetype-webapp. You can also directly use the command line.

Let’s start :

Configuring Jetty:

To let users to easily test the application, add Jetty in the pom.xml: in the build section, add jetty-maven-plugin.

(...)
<build>
<finalName>esigate-tutorial</finalName>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.2.0.RC0</version>
</plugin>
</plugins>
</build>
(...)

Jetty can now be started using:
mvn jetty: run

By pointing your browser to http://localhost:8080/ you should get:

Quick improvement of archetype
We modify the index.jsp file to have a bit more text:

Step 1: Add ESIGate
In the pom.xml, add dependency on ESIGate :
<dependency>
<groupId>net.sourceforge.webassembletool</groupId>
<artifactId>webassembletool-taglib</artifactId>
<version>2.17</version>
</dependency>

and ESIGate’s Maven repository:
<repositories>
<repository>
<id>webassembletool-repository</id>
<name>Website Assembling Toolkit repository</name>
<url>http://webassembletool.sourceforge.net/maven/repository</url>
</repository>
</repositories>

Now we’ll use the template demonstration ESIGate (source, link ).

Step 2: Integrate the template ESIGate example:
Add driver.properties in the package : net.webassembletool:

remoteUrlBase = http://www.esigate.org/examples/

This configuration specifies that all files requested by ESIGate will be located in the examples folder of the site esigate.org.

Then, edit the index.jsp as follows:

In this code, we just :

• Added the taglib
• Specified the template to use: http://www.esigate.org/examples/templates/sparkle/index.html
• Defined 2 blocks: title and colTwo

Things to know :

• Any code that is not included in a block is ignored. Thus html, head and body tags will disappear and be replaced by the template’s own tags
• The demo template defines 8 blocks: title, head, header, menu, colOne, colTwo, colThree and footer

Refresh the page and voila!
Your application is integrated into the example template.

Step 3: Replacing the menu
We will replace the default menu by ours.

The result:

Step 4: Fetch a content block.
ESIGate can also fetch a remote block content and insert it within the page. For this example, we will integrate block ‘block1′ from the content examples .

Result:

Conclusion
With only a few lines of code, we synchronized the theme of our application with the demo template of ESIGate. Any changes will be applied without restarting the application (possibly after several minutes, because of the cache).

Stay tuned for more tutorials.

git config --global user.name "<your-name>"
git config --global user.email "<your-email>"