PUBLIC MARKS from holyver with tag java

Une des nouveautés de liferay 5 est l’ajout d’un nouveau type de plugin, nommé hook, dans le Plugin SDK. Il impacte fortement la façon de customiser liferay car il permet de changer le comportement et l’interface de liferay de manière plus intelligente.

# SiteMesh is a web-page layout and decoration framework and web- application integration framework to aid in creating large sites consisting of many pages for which a consistent look/feel, navigation and layout scheme is required. # SiteMesh intercepts requests to any static or dynamically generated HTML page requested through the web-server, parses the page, obtains properties and data from the content and generates an appropriate final page with modifications to the original. This is based upon the well-known GangOfFour Decorator design pattern. # SiteMesh can also include entire HTML pages as a Panel within another page. This is similar to a Server-Side Include, except that the HTML document will be modified to create a visual window (using the document's Meta-data as an aid) within a page. Using this feature, Portal type web sites can be built very quickly and effectively. This is based upon the well-known GangOfFour Composite design pattern. # SiteMesh is built using Java 2 with Servlet, JSP and XML technologies. This makes it ideal for use with J2EE applications, however it can be integrated with server-side web architectures that are not Java based such as CGI (Perl/Python/C/C /etc), PHP, Cold Fusion, etc... # SiteMesh is very extensible and is designed in a way in which it is easy to extend for custom needs.

JSR-168 is a collection of Java APIs for portlet developers. There are a number of reasons to design JSR-168 portlets that adhere to the specification. Portability is an obvious benefit. Code written according to the specification will be easier to move to among portal servers. The majority of Java-based portal servers support JSR-168 portlets. Another benefit is easier federation. Exposing JSR-168 Portlets via Web Services for Remote Portlets (WSRP) producers is easier when portlets adhere to the JSR-168 specification. WSRP provides a standard to federate portlet content via Web services. JSR-168 and WSRP 1.0 portlet capabilities are tightly coupled. JSR-168 to WSRP portlet bridges utilize JSR-168's URL rewriting APIs. This article illustrates best practices for developing JSR-168 portlets for portability.

What is Metro? Metro is a high-performance, extensible, easy-to-use web service stack. It is a one-stop shop for all your web service needs, from the simplest hello world web service to reliable, secured, and transacted web service that involves .NET services. The Metro web service stack is a part of the GlassFish community, but it can be also used outside GlassFish.

A year ago, the article Asynchronous Rendering of Portlet Content With Ajax Technology demonstrated how to apply Asynchronous JavaScript and XML (Ajax) to portlets. Since then, Ajax has become increasingly popular in the software arena and many new Ajax technologies have emerged. Examples are JavaScript libraries and toolkits, such as the Dojo Toolkit, the Yahoo! UI Library, the Google Web Toolkit, Script.aculo.us, and DHTML Goodies. In addition, new standards bodies like Open Ajax and the Dojo Foundation are key players. In light of the many developments in the past year and the host of feedback on how to use Ajax in portlets, this article describes several helpful tips and practices on how best to exploit Ajax in portlets that comply with the Java Specification Request (JSR) 168: Portlet Specification.

There are several approaches that I could take when discussing the JCR. In this article, I examine the features offered by the JSR-170 specification from a developer's perspective, focusing on the available API and the interfaces that allow a programmer to efficiently use the JSR-170 repository in designing a content application. As an artificial example, I'll implement a trivial back end for a Wikipedia-like encyclopedia system, called JCRWiki, with support for binary content, versioning, backup, and search. I use Apache Jackrabbit, an open source implementation of JSR-170, to develop this application.

It is extremely common for applications to store various pieces of information, most of the time in relational databases. While they do a great job when working with regular data types, they are not very efficient when dealing with binary data, for example images or documents. File systems can be used as an alternative and while they offer better performance, there is neither a query language for searching information nor a notion of relationship or transaction.

The Java Content Repository specification (JSR-170) focuses on "content services," where these not only manage data, but offer author based versioning, full-text searches, fine grained access control, content categorization and content event monitoring. Programmers can use repositories in many ways just like a JDBC connection accesses a database: programmers obtain a connection to a repository, open a session, use the session to access a set of data, and then close the session. The JCR specification has multiple levels of compliance; the most simple level offers read-only access to a repository, XPath-like queries, and some other elements, while other levels of the specification offer a SQL-like query syntax, write capabilities, and more advanced features.

Now that Apache Geronimo has earned Java™ 2 Platform, Enterprise Edition (J2EE) 1.4 certification and has reached version 1.1.1, many developers will be moving away from building their software on top of more restrictive platforms. Specifically, there have been a number of articles and tutorials written lately describing migrating away from the JBoss application server to Apache Geronimo. This installment of The Geronimo renegade column describes many advantages of doing so.

Lors de cette présentation, nous essaierons d'améliorer notre compréhension des Web Services, ferons un survol des normes les plus importantes de l'industrie (WSDL, SOAP et UDDI) et regarderons rapidement quels sont les alternatives d'implémentations (styles et REST). La vidéo : http://video.google.ca/videoplay?docid=3598302564468341554&q=web+services

If your enterprise Java development is light weight and strictly avoids EJBs, you would probably consider Apache Tomcat as your first choice application server. However not only has Tomcat become rather heavy over time but it also isn't the only option you have. The list of Java servers is quite long, but it normally comes down to Tomcat, Jetty and Resin.Apache Tomcat is easily the most popular of the three and the "Powered By Tomcat" section lists some of the more well known names running Tomcat.

jWebUnit is a Java framework that facilitates creation of acceptance tests for web applications. It evolved from a project where we were using JUnit to create acceptance tests. Also, we can have different testing engines. Currently, only HtmlUnit plugin is ready. As the tests were being written, they were continuously refactored to remove duplication and other bad smells in the test code. jWebUnit is the result of these refactorings.

In this article, Andres March shows how OSCache can be used to save your processing requirement by storing data or content, to prevent continually re-reading it or re-generating it, including a quick walkthrough of what OSCache can do, through caching objects, entire HTTP responses, or fragments of HTTP via a JSP tag library.

Open Source Cache Solutions in Java

In route to their final storage destination on the World Wide Web, characters move through various layers of programming interfaces and can cross software and hardware boundaries. This article provides helpful hints and best practices for accurately transporting character data from browser to database … and back again.

PolePosition is a benchmark test suite to compare database engines and object-relational mapping technology. As of today it is by no means complete. Database vendors and open source database project participants are invited to improve the test implementations and to contribute further disciplines ("Circuits"). The PolePosition framework source code will help to implement own tests quickly and to time and output the results as number series and graphic visualisations.

Je suis novice dans la J2EE alors excusez moi pour la remarque, mais je souhaiterais connaître la différence entre un Web Sevice et un EJB, pas du point de vu de la programmation, mais savoir ce que chacun me permet de faire quoi exactement. En effet, j'ai du mal à discerner les fonctionnalités de chacun. Je ne sais si je suis un cas isolé, mais quand je lis que c'est facile à comprendre et à programmer, excusez moi du peu, mais j'ai du mal.

Je bataille aujourd'hui pour faire adopter par mon entreprise les serveurs d'applications J2EE, et donc commencer à basculer vers une architecture distribuée. J'aurais aimé connaître votre point de vue sur les arguments que l'on m'a opposés, ainsi que quelques clarifications qui ne feront pas de mal. Normes EJB Tout d'abord, concernant l'utilisation des EJBs, je me suis vu répondre que la norme EJB n'était pas encore stabilisée et en constante évolution. Alors que la plupart des serveurs sont validés pour la norme EJB 2.0 et qu'apparaît la norme 3.0, on peut effectivement s'interroger. Les changements entre les normes sont-ils importants ? Vaut-il mieux attendre la norme 3.0 ou bien commencer avec la mature 2.0 ? Question complémentaire : qu'en est-il des protocoles utilisés pour la communication (CORBA, SOAP, RMI...) Serveurs d'application Après discussions, si serveur d'application il y a, il sera choisi entre JOnAS, JBoss ou Websphere. JOnAS et JBoss parcequ'ils sont libres, ou WAS parcequ'il est déjà utilisé dans le groupe (choix le plus probable, au passage). Sans être redondant avec le post-it "[SERVEUR J2EE] Quelles différences entre les serveurs J2EE ?", mais pour actualiser un peu (la plupart des posts datent de 2003, la situation a certainement évolué depuis), qu'en est-il aujourd'hui de ces serveurs en terme de coût de possession, de perennité de la solution (cette dernière question concerne plus JOnAS, apparemment en perte de vitesse) et.. de performances ?

Autrement dit:si je fais parti d une entreprise, que je vais chez un client, que je lui présente l'architecture J2EE, qu'il constate que la partie métier est constituées d EJB, comment lui justifierai je l usage d'un framework de mapping O/R et ke finalement l application n a pas besoin d etre conforme a l architecture J2EE a 100%?

Je suis en train de modéliser en UML une base de données qui à donc un diagramme de classe. Cette BDD contiendra les infos de mon système. Et j'ai un système que je veux développer en JAVA qui a aussi un diagramme de classe. J'ai construit le diagramme de classe du système de façon identique au diagramme de classe de ma BDD. sauf que mon diagramme de classe du sytème contient des méthodes en plus. Je voudrais savoir si mon raisonnement est le bon? Quelqu'un pourrait-il me donner son avis?

Est-il possible de faire tout un projet J2EE sans passer par les EJB ?? Quels sont les différentes autres méthodes ?? S'il y a un plus au niveau des performances ... Petite explication : je fais partie d'un projet et nous avons développé tout le code métier via des EJB ... Etant tous débutants, la prise en main des EJB fut laborieuse (problème de transactions, paramétrages ...) Nous devons faire une autre application (J2EE aussi) et je me demandais si on ne pouvait pas faire abstraction des EJB ou faire un mélange pour éviter tous les problèmes rencontrés ...

Est-il possible d'ajouter les fichier necessaire à l'exposition d'un EJB en tant que service Web et de continuer à se servir de l'EJB normalement et en même temps de s'en servir en tant que Web Service ? - La méthode pour exposer un EJB en tant que Service Web : 1) créer fichier config.xml (contenant la config du service) 2) utiliser wscompile -define config.xml 3) mettre les fichiers générés (.wsdl,webservice.xml, mapping.xml) dans le jar 4) déployer l'EJB Est ce une bonne méthode ?

Je me pose une question depuis un moment. Lorsqu'on parle de J2EE et plus précisemment de sa couche métier, on parle tout le temps d'EJB. Est-ce qu'il est pas possible d'avoir autre chose que des EJB comme par exemple un programme Java accessible par RMI ou JMS ? Si c'est le cas, est ce que des outils comme JBoss permettent de faire tourner des couches métier qui ne sont pas des EJB ? Il y a surement des topics qui parlent déjà de ça mais j'ai pas réussi à les trouver, si c'est le cas, je veux bien que vous m'envoyez les liens. J'ai bien essayé de chercher mais c'est pas évident pour une question aussi générale.

Tutorials for Hibernate, EJB 2, EJB 3 Struts, JavaServerfaces (JSF) Tomcat, JBoss, Myeclipse, Eclipse and other

Portlet Frequently Asked Questions (FAQ) - a collection by Punit Pandey