Étiquette : Java

[Java] Trucs et astuces pour Websphere et Eclipse

[Java] Trucs et astuces pour Websphere et Eclipse

Si vous utilisez l’IDE Eclipse au quotidien et le serveur IBM Websphere dans sa version 9 ou plus, voici quelques petits trucs et astuces pour vous aider dans vos tâches de développement.

Trucs et astuces pour Websphere et Eclipse

Désactiver l’auto-publish

Lorsqu’on se trouve dans Eclipse, et qu’on effectue un build du projet, l’action de publication – ou publish – du projet est réalisée automatiquement et ce même en mode debug du serveur de test. Cependant on peut modifier ce comportement grâce à l’astuce suivante.

  • Rendez-vous dans l’onglet Servers.
  • Double-cliquez sur le serveur WebSphere Application Server vX.Y.
  • Déroulez la catégorie Publishing.
  • Cochez l’option Never publish automatically.
  • Dans la barre d’outils de l’IDE, cliquez sur le bouton Enregistrer.

Lancer en mode debug

Ce mode du serveur est particulièrement utile afin que les modifications des actions et JSP soient immédiatement prises en compte. Et ce sans effectuer l’action de publication.

  • Rendez-vous dans l’onglet Servers.
  • Effectuez un clic droit sur votre serveur WebSphere.
  • Choisir Debug / Restart in Debug.

Publication d’applications en erreur

Par défaut il est impossible de publier une application avec du code en erreur.

Pour résoudre cela:

  • Dans Eclipse, allez dans le menu Window > Preferences.
  • Recherchez le bon paramètre avec le mot clé « Websphere ».
  • Déroulez la catégorie Server, sélectionner Websphere Application Server.
  • Cochez « Allow applications containing errors to be published on a server« .
  • Sauvegardez.

Supprimer la compilation des JSP

Quels sont les symptômes ? Par exemple, si vous renommez une classe de Tag Java, la JSP référencera l’ancien nom même après un publish. Ou encore, certains éléments de la page (ex : une variable statique) ont une valeur différente de celle définie dans le code.

Dès lors, si vous avez vidé le cache du navigateur et que cela persiste, c’est peut-être dû au cache de compilation des JSP géré par Websphere.

Sur votre PC ouvrez le répertoire des fichiers temporaires de votre serveur.

\WebSphere\AppServer_v9.0\profiles\AppSrv01\temp\TestNode01\server1

Supprimez le contenu du dossier. Lors du prochain rafraichissement des pages concernées par le problème, vous devriez obtenir le résultat escompté.

Supprimer les fichiers temporaires

De manière générale, lorsqu’on rencontre un problème avec Websphere, on peut nettoyer les fichiers temporaires générés dans les dossiers suivants. Il est préférable d’arrêter le serveur pour effectuer l’opération.

\WebSphere\AppServer_v9.0\profiles\AppSrv01\temp\TestNode01\server1
\WebSphere\AppServer_v9.0\profiles\AppSrv01\temp\wscache
\WebSphere\AppServer_v9.0\profiles\AppSrv01\wstemp


Ressources

[Sécurité] Découverte d’une faille de sécurité critique dans Spring

[Sécurité] Découverte d’une faille de sécurité critique dans Spring

Comme nous le rapporte le magazine Programmez! VMWare signale la présence d’une faille de sécurité critique dans son produit Spring, permettant l’exécution de code à distance (RCE). Cela touche les versions de Spring Framework 5.2.0 à 5.2.19 et 5.3.0 à 5.3.17, ainsi que des versions plus anciennes. Reprise sous l’identifiant CVE-2022-22965 et baptisée Spring4Shell, cette faille ne peut être exploitée que si certaines conditions sont réunies.

Faille de sécurité Spring

En effet, sont vulnérables des applications Spring MVC ou WebFlux, tournant sur une JDK 9 (ou supérieur) sur un serveur Tomcat, et qui ne sont pas déployées en tant qu’exécutables Spring Boot (mais bien sous la forme d’archives WAR). Dans sa note, VMWare met toutefois en garde que la faille pourrait être exploitée par d’autres moyens.

VMWare recommande de mettre à jour au plus vite vos applications avec une version plus récente de Spring Framework. S’il n’est pas possible pour vous de changer de version, des solutions de contournement sont proposées dans une publication sur le blog de Spring.

Sources

[Java] Mémo – Trucs et astuces impliquant l’API Stream

[Java] Mémo – Trucs et astuces impliquant l’API Stream

Java propose l’API Stream, qui permet de manipuler et effectuer des opérations sur un ensemble de données, telles qu’une collection, un tableau ou même un flux I/O. Elle offre diverses possibilités : tri, parcours de collections, extraction d’éléments à l’aide de filtres, etc.

Dans cet article nous allons voir comment effectuer un tri basique pour retourner une nouvelle liste mais également comment retourner une liste d’objets d’un type spécifique.

Trier une liste

On suppose que l’opération sera effectuée sur une liste d’objets de la classe Client. Cette dernière définit plusieurs membres dont un numéro de client (numClient) et son getter. Nous souhaitons récupérer une nouvelle liste de noms.

listeClients.stream()
	.sorted(Comparator.comparing(Client::getNumClient))
	.map(lo_c -> lo_c.getNomClient())
	.collect(Collectors.toList());

Dans cet exemple nous avons effectué plusieurs opérations sur le stream :

  • Une opération intermédiaire de tri, grâce à la méthode sorted() qui reçoit en paramètre un Comparator.
  • Une seconde opération intermédiaire qui permet de définir ce que l’on souhaite récupérer, en l’occurrence le nom de la personne.
  • Une troisième opération, finale cette fois, qui consiste en une réduction: on demande à ce que le résultat soit sous forme de liste.

Notez que si vous manipulez une List vous pouvez la trier directement à l’aide de la méthode sort(). La méthode effectue l’opération sur la liste existante sans en créer une copie de celle-ci.

Exemple:

listeClients.sort(Comparator.comparing(Client::getNumClient));

Retourner une liste d’un type spécifique

Comme on l’a vu ci-dessus, à l’aide de la méthode map(), on a obtenu une liste de chaines de caractères. Voyons comment aller plus loin pour retourner une liste d’un type spécifique. Toujours sur base d’un client, nous avons une classe nommée ClientDTO qui sera une version réduite. Elle contiendra uniquement le numéro de client et son nom, ainsi qu’un constructeur prenant en paramètre ces deux champs.

listeClients.stream()
	.sorted(Comparator.comparing(Client::getNumClient))
	.collect(Collectors.mapping(lo_c -> {
		return new ClientDTO(
			lo_c.getNumClient(), lo_c.getNomClient()
		);
	}, Collectors.toList()));

Cette fois on effectue un mappage à l’aide de Collectors.mapping(): la fonction en paramètre retourne une instance de ClientDTO avec les champs de notre classe Client. On demande ensuite à ce que le résultat final soit retourné sous forme de liste, comme dans l’exemple ci-dessus.

Bien sûr ce sont deux exemples parmi tant d’autres, l’API offrant énormément de possibilités. Et même si cela a été introduit dans Java 8 on n’a pas toujours la possibilité ou le temps d’en explorer les différentes méthodes. Voici quelques liens qui pourraient vous intéresser pour creuser le sujet:

Bon développement !

[Java] Filtre sur liste avec les streams

[Java] Filtre sur liste avec les streams

L’une des grosses améliorations de Java 8, c’est ce qu’on appelle les streams. C’est un nouveau pattern de manipulation de données et cela permet de se passer notamment des itérateurs que l’on connait. On peut les utiliser sur des collections ou même des tableaux.

On prend la classe suivante comme exemple :

public class MyObject
{
 private String sId;
 private String sName;
 
 // ...
}

Une méthode nous retourne alors une liste qui reprend des objets caractérisés par leur nom et un identifiant. On voudrait filtrer la liste pour ne récupérer que les objets nommés « chair » par exemple.

Stream<MyObject> lo_s = lo_listObj.stream().filter(
 myObj -> myObj.getName().equals("chair")
);

Le paramètre de la méthode filter() est un prédicat (type Predicate). Le code ci-dessus renvoie un stream que l’on peut ensuite manipuler pour retourner une collection ou bien un seul objet. Par exemple on pourrait utiliser la méthode collect() pour renvoyer une nouvelle liste.

List<Myobject> lo_list = lo_s.collect(Collectors.toList());

On peut aussi retourner le premier objet qui correspond au filtre, avec findFirst(). Cela retourne un objet de type Optional.

Optional<MyObject> lo_opt = lo_s.findFirst();

Plusieurs opérations sont possibles sur cet objet. On peut savoir s’il y a bien un résultat avec la méthode isPresent(), ou bien retourner directement le résultat ou une autre valeur si aucun objet n’avait été trouvé lors du filtre.

MyObject lo_result = lo_opt.orElse(lo_defaultObject);

La méthode orElse() renvoie la valeur qui avait été trouvée et si elle n’est pas présente, alors elle renvoie un autre objet du même type.

if (lo_opt.isPresent())
{
 MyObject lo_result = lo_opt.get();
}

L’exemple ci-dessus montre comment récupérer l’objet uniquement s’il est présent et pour également éviter l’exception NoSuchElementException. Cela peut être un raccourci à la méthode orElse(), tout dépend de quoi on a besoin en retour et ce qu’on va en faire.

[Java] Mémo – Validation de beans

[Java] Mémo – Validation de beans

En Java, il est possible d’utiliser la validation de beans pour permettre d’en valider son contenu, donc les différents membres de la classe. Par exemple, si on a une classe « Personne« , qui contient un nom et un prénom, on voudrait valider que ceux-ci ne dépassent pas une certaine taille ou même qu’ils respectent une expression régulière. Plutôt que de créer des méthodes visant à vérifier chaque élément un à un, on va se baser sur des annotations.

Prenons la classe suivante comme référence pour ce 1er exemple :

public class Person
{
    @Size(min = 1, max = 5, message = "cod: btw. 1 and 5")
    private String      cod;
 
    @Size(max = 60, message = "firstName: Length max 60")
    private String      firstName;

    @NotNull(message = "birthdate: mandatory")
    private LocalDate   birthdate;
 
    // ...
}

On utilise l’annotation Size pour définir la taille maximum qu’une chaine peut avoir. Si on ne spécifie pas de minimum, cela veut dire que la chaine peut être vide. A chaque fois on spécifie le paramètre « message » pour indiquer quel sera le message retourné lors de la validation.

Pour récupérer les erreurs sous forme de chaine :

Person lo_p = new Person();
Set<ConstraintViolation<T>> lo_violations = 
 Validation.buildDefaultValidatorFactory()
  .getValidator()
  .validate(lo_p);
for (ConstraintViolation<T> lo_violation : lo_violations)
{
    System.out.println(lo_violation.getMessage());
}

Ce code affiche les messages en fonction des champs qui sont en erreur par rapport à l’objet qu’on donne en paramètre de la méthode validate().

Si notre classe contient une liste d’objets que l’on veut aussi valider, ou un objet d’une autre classe, il faut rajouter une annotation Valid pour qu’il soit pris en compte lors de la validation.

public class PremObj
{
    @Size(min = 1, max = 20, message = "id: btw. 1 and 20")
    private String                  id;
 
    @Valid
    @NotNull(message = "liste_sousobj: Mandatory")
    private List<UnSousObj>  liste_sousobj;
 
    // ...
}

Chaque objet de la liste sera donc analysé. C’est aussi valable si on avait mis un seul objet de type « UnSousObj« . La classe que l’on référence doit évidemment posséder diverses annotations de validation.

Un champ peut également être validé sur base de valeurs d’une énumération. On peut ainsi utiliser l’annotation Enum (sur une variable de type String). Le paramètre obligatoire « enumClass » permet de spécifier la classe qui servira à la validation.

D’autres annotations utiles :

  • Pattern : sur une chaine, permet de faire en sorte qu’elle respecte une expression régulière.
  • Min : indique la valeur minimale d’un nombre.
  • Max : indique la valeur maximale d’un nombre.

Liens

Liste des annotations disponibles

[Java] Gestion des erreurs à l’aide d’une servlet

[Java] Gestion des erreurs à l’aide d’une servlet

Dans votre application web, il est possible de réaliser une gestion d’exceptions – notamment pour intercepter ServletException – en passant par une servlet. Par défaut, les erreurs telles que le code HTTP 500 sont gérées par le serveur et renvoient vers une page par défaut. L’idée est donc de changer ce comportement en renvoyant par exemple une information en JSON ou en redirigeant vers une JSP.

On va donc créer une classe qui hérite de HttpServlet. Celle-ci devra implémenter des fonctions pour gérer les différentes méthodes HTTP (exemple : PUT, GET, POST…).

public class MaServletHttp extends HttpServlet 
{
    public void doGet(HttpServletRequest request, 
        HttpServletResponse response) throws IOException 
    {
        // On gère l'erreur...
    }
}

Comme on peut le constater on a donc créé une fonction qui sera exécutée lorsque la méthode GET est utilisée. Typiquement lorsqu’on appelle une URL et qu’on spécifie un ensemble de paramètres dans celle-ci. Il faudra donc ajouter les autres fonctions comme doPost() – généralement appelée lors d’un envoi de formulaire – ou doPut().On remarque aussi l’annotation @WebServlet qui permet de définir tout un ensemble d’informations utiles, notamment l’ « URL pattern ». On peut soit spécifier cette valeur directement comme dans l’exemple ci-dessus, soit en spécifiant les attributs de la manière suivante.

@WebServlet(
        name = "maBelleServlet",
        description = "Gestion d'exceptions",
        urlPatterns = "/maServletHttp"
)
public class MaServletHttp extends HttpServlet 
{
    // Code de la servlet...
}

Certains attributs de la servlet ne sont utiles que pour les outils utilisés lors du développement (par exemple, description ou encore smallIcon). Ces attributs sont décrits dans la documentation de JavaEE 7.Il faut ensuite modifier le fichier web.xml pour spécifier dans quels cas la servlet doit être appelée pour gérer les exceptions ou les différents code d’erreur. Dans l’exemple ci-dessous on va faire en sorte que la servlet soit appelée en cas d’erreur HTTP 500.

<web-app ... >
    <error-page> 
        <error-code>500</error-code> 
        <location>/maServletHttp</location> 
    </error-page>
</web-app>

On a donc ajouté un élément « error-page » dans le fichier descriptif de l’application. Pour cet élément on a spécifié le code d’erreur grâce à l’élément « error-code » et l’emplacement de la servlet (qui correspond au URL pattern défini précédemment dans l’annotation de la classe Java) représenté par l’élément « location« .

A la place de l’élément « error-code » on peut aussi spécifier « exception-type » et indiquer les erreurs que la servlet devra intercepter. On y spécifie alors le canonical name de la classe d’exception visée (ex : java.lang.NullPointerException).

Une fois le fichier de configuration XML modifié, on peut s’attaquer au code de la servlet. Aussi bien lorsqu’on redirige vers une JSP qu’une servlet, des attributs contenant des informations à propos de l’erreur qui se produit, sont définis au niveau de la requête et peuvent donc être rapatriés dans le code.

@WebServlet("/maServletHttp")
public class MaServletHttp extends HttpServlet 
{
    public void doGet(HttpServletRequest request, 
        HttpServletResponse response) throws IOException 
    {
        Integer li_st = (Integer) request.getAttribute(
                "javax.servlet.error.status_code"
        );

        Throwable lo_e = (Throwable) request.getAttribute(
                "javax.servlet.error.exception"
        );

        String ls_svlt = (String) request.getAttribute(
                "javax.servlet.error.servlet_name"
        );
        
        // Envoi de la réponse après.
        // Voir ci-dessous.
    }
}

Voici le tableau des attributs disponibles (source : tutorialspoint).

L’attribut qui contient le nom de la servlet est intéressant car il s’agit de la source, là où l’erreur s’est produite. Cela signifie qu’en fonction du nom on peut imaginer un traitement différent en retour.L’exemple ci-dessous renvoie simplement du JSON au client après une erreur dans un Web Service.

@WebServlet("/maServletHttp")
public class MaServletHttp extends HttpServlet 
{
    public void doGet(HttpServletRequest request, 
        HttpServletResponse response) throws IOException 
    {
        // Récupération des attributs avant.
        // Voir ci-dessus.
        if (ls_svlt.equals("webserviceServlet"))
        {
            response.setContentType("application/json");
            response.getWriter().print(
                "{ key1: 'val1', key2: 'val2' }"
            );

            response.getWriter().flush();
        }
    }
}

On peut également modifier le code de retour (par exemple, si le code était 500, on peut le redéfinir au niveau de l’objet HttpServletResponse).

Sources

Baeldung
CodeJava.net
LogicBig
Oracle
Tutorialspoint

[Java] Evaluer une expression avec Groovy

[Java] Evaluer une expression avec Groovy

Apache Groovy est à la base un langage de programmation pouvant s’intégrer à des logiciels développés pour la plateforme Java. Les librairies qu’il propose peuvent être importées dans un projet, notamment pour diverses raisons comme le besoin d’évaluer dynamiquement une expression.

En téléchargeant les binaires de la version stable 2.4.12, vous trouverez dans le sous-répertoire « lib » un JAR – groovy-2.4.12.jar – à intégrer dans votre application. La méthode qui nous intéresse se trouve dans le package « groovy.util.* ». Il s’agit de Eval.me().

Integer res = (Integer) Eval.me(" 2 * 4 + 2");

Cela va tout simplement retourner 10 et le stocker dans la variable.

Il existe également trois variantes, qui permettent de passer jusqu’à 3 variables automatiquement nommées « x », « y » et « z ».

Eval.x(2, " x * 4 + 2")

On donne en premier paramètre la valeur de « x » ensuite, il suffit de donner l’expression qu’on veut évaluer.

Si on creuse un peu, cette méthode réalise ceci :

Binding bind = new Binding(); 
bind.setVariable("x", 2); 
GroovyShell sh = new GroovyShell(bind); 
sh.evaluate(" x * 4 + 2");

Cela signifie qu’on peut évidemment définir plus de variables que prévu… Ouf! Et on peut même explicitement renvoyer une variable différente selon une condition remplie. Sympa non ?

[Java] JPA : Fetch dans une requête JPQL

[Java] JPA : Fetch dans une requête JPQL

Quand on crée des entités avec la Java Persistence API, on peut spécifier des jointures qui se présentent alors sous forme d’objets liés à d’autres entités, plutôt que sous la forme de variables comme des chaines ou des Long. Voici un exemple de relation entre un client et ses factures.

@Entity @Table(name = "CLIENT", schema = "maDb")
public class Client implements Serializable 
{ 
	@Column(name = "CLI_ID_CLIENT") 
	private Long l_idClient; 
	
	@OneToMany(mappedBy = "objClient") 
	private List<Facture> objListFactures; 
	
	// ... 
} 

@Entity @Table(name = "FACTURE", schema = "maDb")
public class Facture implements Serializable 
{ 
	@Column(name = "FAC_ID_FACTURE")
	private Long l_idFacture; 
	
	@ManyToOne @JoinColumn(name = "FAC_ID_CLIENT") 
	private Client objClient; 
	
	// ... 
}

Ce qu’on a fait :

  • Dans l’entité Client, on a créé une liste de factures, en spécifiant le tag @OneToMany (relation 1-N soit un client peut avoir plusieurs factures) avec pour attribut mappedBy le nom de la variable Client qui a été ajoutée dans notre entité Facture.
  • Dans cette dernière, on doit spécifier la relation dans l’autre sens, donc avec le tag @ManyToOne (relation N-1, soit plusieurs factures pour un même client).
  • On doit également ajouter le tag qui indiquera sur quelle colonne on effectue la jointure afin que la relation fonctionne (@JoinColumn + attribut name). Il faut indiquer le nom de la colonne tel que spécifié dans la base de données.

Par défaut, quand on récupérera plusieurs clients, leurs factures ne seront pas immédiatement chargées. C’est ce qu’on appelle « Lazy Loading » qui est le comportement par défaut quand on ne spécifie pas l’attribut fetch au niveau de la relation.

Afin de récupérer les factures lorsqu’on récupère un client, nous avons plusieurs choix qui se présentent à nous :

Spécifier l’attribut FETCH

On peut spécifier au niveau de la relation, l’attribut fetch avec la valeur EAGER. Cela signifie que pour chaque client on récupérera toujours ses factures, ce qui n’est probablement pas ce que l’on souhaite (attention aux temps d’accès et aux accès en cascade s’il y a d’autres entités liées de cette manière).

@OneToMany(mappedBy = "objClient", fetch = FetchType.EAGER) 
private List<Facture> objListFactures;

Accéder à la liste

Lorsqu’on récupère l’objet client depuis la base de données dans notre Session Bean, on peut accéder à la liste pour que son contenu soit chargé.

Client cliFromDb = ... ;
cliFromDb.getObjListFactures().size();

Créer une requête JPQL

On crée une requête avec la syntaxe JPQL, ce qu’on appelle des « Named queries« . Elles sont définies soit dans une méthode que vous aurez pris soin d’écrire, soit directement au niveau de l’entité, à l’aide des tags adéquats.

@NamedQueries({ 
	@NamedQuery( name = "Client.findClientByPkWithFactures",
		query = "select c from Client c 
			left join FETCH c.objListFactures 
			where c.l_idClient = :idClient") 
})

Exemple de classe qui définit des fonctions pour la gestion des clients. Ces fonctions seront appelées depuis notre Session Bean.

public class ClientManager 
{ 
	private EntityManager em; 
	
	public ClientManager(EntityManager em) 
	{ 
		this.em = em; 
	} 
	
	public Client findClientByPkWithFactures(Long pId) 
	{ 
		Query query = em.createNamedQuery( 
			"Client.findClientByPkWithFactures"
		).setParameter("idClient", pId);

		Client res = (Client) query
			.getSingleResult(); 
		return res; 
	} 
}

Bon développement !

[Java] Appel de méthode avec l’API Reflection

[Java] Appel de méthode avec l’API Reflection

Vous avez par exemple deux classes qui possèdent la même méthode (même nom, même signature) mais au moment de l’exécution, vous souhaitez choisir dynamiquement laquelle appeler à l’exécution. L’API Reflection permet d’effectuer cela de manière plutôt simple.

Supposons la classe suivante, « MaClasse1 » dans laquelle on a écrit une fonction « getHello« , qui prend en paramètres une chaine de caractère, et un nombre quelconque dans un objet de type Long. La fonction retournera C1= suivi du contenu de la chaine. Dans l’exemple nous n’afficherons pas le nombre passé en second paramètre.

public class MaClasse1 
{
	public String getHello(String text, Long nbTest) 
	{ 
		return "C1=" + text;
	}
}

Nous créerons deux classes supplémentaires, appelées « MaClasse2 » et « MaClasse3« , qui implémenteront la même fonction en retournant cette fois C2 ou C3, tous deux suivis du contenu du paramètre.

Class myClass = ...; 
Object instClasse = myClass.newInstance(); 
Class paramTypes[] = new Class[2]; 
paramTypes[0] = String.class; 
paramTypes[1] = Long.class; 
Method laMethode = myClass.getMethod(
	"getListeDestinataire",  
	lo_parameterType
); 

Object paramVal[] = new Object[2]; 
paramVal[0] = ...; 
paramVal[1] = 2L; 
System.out.println(
	laMethode.invoke(instClasse, paramVal)
);

Ce qu’on a fait :

  • Instancier un objet de classe en spécifiant (par exemple, dans une fonction), la classe (ex : MaClasse1.class) ou avec Class.forName(« Class FQN »).
  • Créer un tableau contenant les types de paramètres. Ce sera un tableau de classes. Dans notre cas, ce sont des objets classiques, mais on peut aussi utiliser Class.forName().
  • On crée un objet de type Method, en utilisant getMethod() de l’objet Class (pas l’instance). On passe en paramètres le nom de la fonction, et le tableau de types.
  • Créer un tableau, cette fois qui contiendra des éléments Object.
  • Spécifier les valeurs des paramètres.
  • Appeler la méthode invoke() de l’objet Method, avec en paramètres l’instance de la classe et les valeurs des différents paramètres.

Ainsi, si on écrit :

Class myClass = MaClasse2.class; 
// ... 
paramVal[0] = "test";

Lors de l’affichage, on obtiendra « C1=test ».

Dans ce petit bout de code on a donné les valeurs aux différents objets en « dur »… Il ne vous reste plus qu’à adapter tout ça 😉 Bon amusement !

[Java] Log d’un repository SVN

[Java] Log d’un repository SVN

Tout d’abord, télécharger SVNKit sur svnkit.com (lien ici). Choisir la version « standalone » puis décompresser les librairies qui se trouvent dans « lib », à l’aide de WinRAR ou 7zip par exemple.

Ajoutez ensuite les différentes archives JAR à votre projet. Clic droit sur le projet dans Eclipse -> Properties -> Java Build Path, onglet Libraries. Cliquez sur le bouton « Add Library« , choisissez « User Library ». Indiquez un nom et sélectionnez les fichiers précédemment extraits.

Dans le code, il faut réaliser les manipulations suivantes :

DAVRepositoryFactory.setup();

On indique que l’on va interroger un repository SVN dont on renseignera l’URL, en HTTP ou HTTPS.

String ls_url = "http://xxx.com/svn/mySVN";
String ls_username = "user"; 
String ls_password = "password123";

Il faut ensuite définir quelques variables dont l’URL, le nom d’utilisateur et le mot de passe. Dans le code d’exemple ils sont en dur mais on peut imaginer les récupérer par une saisie utilisateur.

On va maintenant s’identifier.

sUrl = SVNEncodingUtil.autoURIEncode(ls_url); 
SVNRepository repo = SVNRepositoryFactory.create( 
	SVNURL.parseURIEncoded(sUrl)
); 

ISVNAuthenticationManager authManager = 
	SVNWCUtil.createDefaultAuthenticationManager( 
		ls_username, 
		ls_password.toCharArray()
	);

repo.setAuthenticationManager(lo_authManager);

On doit donc :

  • Instancier un objet SVNRepository à l’aide de la fabrique SVNRepositoryFactory. On passe en paramètre un objet SVNURL.
  • Créer un gestionnaire d’authentification à l’aide de la classe SVNWCUtil. On passe en paramètre de la fonction le nom d’utilisateur et le mot de passe (ce dernier étant passé sous forme de tableau de caractères).
  • Une fois celui-ci créé, on le lie au repository.

On peut savoir quelle est la dernière révision en appelant:

SVNDirEntry entry = repo.info(".", -1);

Pour récupérer les entrées entre deux révisions on procède comme suit :

Collection colLogEntries = null; 
colLogEntries = repo.log(
	new String[] {""}, 
	null, 
	lStartRevision, 
	lEndRevision, 
	true, 
	true
);

On déclare d’abord une collection dans laquelle on pourra stocker le résultat. Ensuite, on appelle la fonction « log » sur notre repository précédemment créé. On passe en paramètre un tableau vide (chemins cible), la valeur nulle pour le second paramètre (qui attend une collection), la révision de début, la révision de fin, et deux flags (« changed paths » – pour lister tout ce qui a été modifié, et « strict node »). Voir plus de détails dans la documentation.

Astuce : on peut aussi utiliser getDatedRevision(Date date) pour retrouver un numéro de révision correspondant à la date donnée en paramètre, ou du moins proche de celle-ci.

Parcourir la collection récupérée.

for(SVNLogEntry entry : colLogEntries) 
{ 
	System.out.println(
		logEntry.getRevision()
	); 
	
	System.out.println(
		logEntry.getAuthor()
	); 
	
	//... 
}

On peut afficher différentes informations (auteur, message, numéro de révision, date). Dans cette boucle, on peut en rajouter une autre :

Set changedPathsSet = 
	logEntry
		.getChangedPaths()
		.keySet(); 
for (String sFullPath : changedPathsSet) 
{ 
	SVNLogEntryPath entryPath = 
		(SVNLogEntryPath) logEntry.getChangedPaths()
			.get(sFullPath); 
	System.out.println(
		entryPath.getPath()
	); 
	
	System.out.println(
		entryPath.getType()
	); 
	
	//...
}

Ce qui va permettre d’afficher les chemins des fichiers modifiés et le « type » de modification (M = modified, A = added, D = deleted). Reste à afficher tout cela de manière bien plus sympa que dans une simple console…

Et pour fermer proprement la session :

repo.closeSession();

Voilà, c’est tout pour aujourd’hui !