VT2018 Thorntail - Revision history

Zoran.Chanet: /* Introduction */

2019-02-07T09:00:09Z

Introduction

← Older revision		Revision as of 09:00, 7 February 2019
Line 1:		Line 1:
	=Introduction=		=Introduction=
	Technologie : [[Thorntail]]<br>		Technologie : [[Thorntail]]<br>
	Auteur : CHANET Zoran<br>		Auteur : [[User:Zoran.Chanet \| CHANET Zoran]]<br>
	E-mail : [mailto:zoran.chanet@~~laposte~~.~~net~~ zoran.chanet@~~laposte~~.~~net~~]<br>		E-mail : [mailto:zoran.chanet@etu.univ-grenoble-alpes.fr zoran.chanet@etu.univ-grenoble-alpes.fr]<br>
	Presentation : [[Media:VT2018_Thorntail_presentation.pdf\|Transparents]]<br>		Presentation : [[Media:VT2018_Thorntail_presentation.pdf\|Transparents]]<br>
	Démonstration : [[VT2018 Thorntail Demo\|Démo]]		Démonstration : [[VT2018 Thorntail Demo\|Démo]]

Zoran.Chanet: /* Sources */

2019-01-13T22:59:13Z

Sources

← Older revision		Revision as of 22:59, 13 January 2019
Line 102:		Line 102:
	* [https://blogdesexperts.infotel.com/2016/05/20/retour-sur-devoxx-2016-wildfly-swarm/ blogdesexperts.infotel.com], description claire du projet [[Wildfly_Swarm\|Wildfly Swarm]]		* [https://blogdesexperts.infotel.com/2016/05/20/retour-sur-devoxx-2016-wildfly-swarm/ blogdesexperts.infotel.com], description claire du projet [[Wildfly_Swarm\|Wildfly Swarm]]
	* [https://blog.xebia.fr/2014/02/28/la-notion-de-bom-avec-maven/ blog.xebia.fr], compréhension de la notion de BOM [[Maven]]		* [https://blog.xebia.fr/2014/02/28/la-notion-de-bom-avec-maven/ blog.xebia.fr], compréhension de la notion de BOM [[Maven]]
			* [https://developer.jboss.org/welcome developer.jboss.org], plateforme du serveur JBoss

Zoran.Chanet: /* Efficacité */

2019-01-13T22:50:59Z

Efficacité

← Older revision		Revision as of 22:50, 13 January 2019
Line 90:		Line 90:
	= Efficacité =		= Efficacité =

	Sur l'exemple de la [[VT2018 Thorntail Demo \| démonstration]], une construction classique crée un fichier .war d'une taille de 5,~~7kb~~, alors qu'une construction utilisant thorntail crée un fichier .war d'une taille de 4,2kb. Cependant, il s'agit d'un exemple de petite taille, et l'écart se creuse pour des exemples plus conséquents faisant appel à de plus nombreuses fonctionnalités.		Sur l'exemple de la [[VT2018 Thorntail Demo \| démonstration]], une construction classique (utilisant JBoss) crée un fichier .war d'une taille de 6,2kb, alors qu'une construction utilisant thorntail crée un fichier .war d'une taille de 4,2kb. Cependant, il s'agit d'un exemple de petite taille, et l'écart se creuse pour des exemples plus conséquents faisant appel à de plus nombreuses fonctionnalités.

	= Sources =		= Sources =

Zoran.Chanet at 22:13, 13 January 2019

2019-01-13T22:13:07Z

← Older revision		Revision as of 22:13, 13 January 2019
Line 2:		Line 2:
	Technologie : [[Thorntail]]<br>		Technologie : [[Thorntail]]<br>
	Auteur : CHANET Zoran<br>		Auteur : CHANET Zoran<br>
	E-mail : zoran.chanet@laposte.net<br>		E-mail : [mailto:zoran.chanet@laposte.net zoran.chanet@laposte.net]<br>
	Presentation : [[Media:VT2018_Thorntail_presentation.pdf\|Transparents]]<br>		Presentation : [[Media:VT2018_Thorntail_presentation.pdf\|Transparents]]<br>
	Démonstration : [[VT2018 Thorntail Demo\|Démo]]		Démonstration : [[VT2018 Thorntail Demo\|Démo]]
Line 87:		Line 87:
	[[Thorntail]] permet également la production d'HolloJAR, n'emportant que les composants runtime, dans le but par exemple d'un déploiement en containers avec [[Docker]], de placer l'image des composants runtime à un niveau différent des composants de l'application, qui sont modifiés plus souvent.<br>		[[Thorntail]] permet également la production d'HolloJAR, n'emportant que les composants runtime, dans le but par exemple d'un déploiement en containers avec [[Docker]], de placer l'image des composants runtime à un niveau différent des composants de l'application, qui sont modifiés plus souvent.<br>
	À des fins de test et de développement, il est donc possible d'exécuter l'UberJAR généré, qui sera déployé [http://127.0.0.1 localement], exposant l'API produite.		À des fins de test et de développement, il est donc possible d'exécuter l'UberJAR généré, qui sera déployé [http://127.0.0.1 localement], exposant l'API produite.

			= Efficacité =

			Sur l'exemple de la [[VT2018 Thorntail Demo \| démonstration]], une construction classique crée un fichier .war d'une taille de 5,7kb, alors qu'une construction utilisant thorntail crée un fichier .war d'une taille de 4,2kb. Cependant, il s'agit d'un exemple de petite taille, et l'écart se creuse pour des exemples plus conséquents faisant appel à de plus nombreuses fonctionnalités.

	= Sources =		= Sources =

Zoran.Chanet: /* Introduction */

2018-11-19T01:18:44Z

Introduction

← Older revision		Revision as of 01:18, 19 November 2018
Line 4:		Line 4:
	E-mail : zoran.chanet@laposte.net<br>		E-mail : zoran.chanet@laposte.net<br>
	Presentation : [[Media:VT2018_Thorntail_presentation.pdf\|Transparents]]<br>		Presentation : [[Media:VT2018_Thorntail_presentation.pdf\|Transparents]]<br>
	~~Démo~~ : [[VT2018 Thorntail Demo\|Démo]]		Démonstration : [[VT2018 Thorntail Demo\|Démo]]

	=Résumé=		=Résumé=

Zoran.Chanet at 01:05, 19 November 2018

2018-11-19T01:05:50Z

← Older revision		Revision as of 01:05, 19 November 2018
Line 87:		Line 87:
	[[Thorntail]] permet également la production d'HolloJAR, n'emportant que les composants runtime, dans le but par exemple d'un déploiement en containers avec [[Docker]], de placer l'image des composants runtime à un niveau différent des composants de l'application, qui sont modifiés plus souvent.<br>		[[Thorntail]] permet également la production d'HolloJAR, n'emportant que les composants runtime, dans le but par exemple d'un déploiement en containers avec [[Docker]], de placer l'image des composants runtime à un niveau différent des composants de l'application, qui sont modifiés plus souvent.<br>
	À des fins de test et de développement, il est donc possible d'exécuter l'UberJAR généré, qui sera déployé [http://127.0.0.1 localement], exposant l'API produite.		À des fins de test et de développement, il est donc possible d'exécuter l'UberJAR généré, qui sera déployé [http://127.0.0.1 localement], exposant l'API produite.

			= Sources =
			* [http://thorntail.io thorntail.io], site officiel de la technologie
			* [https://thorntail.io/archive/ thorntail.io/archive], blog officiel de la technologie (annonces et informations sur les versions)
			* [https://docs.thorntail.io/2.2.1.Final/ docs.thorntail.io/2.2.1.Final], documentation de la dernière version stable
			* [https://thorntail.io/generator/ thorntail.io/generator], générateur de projet [[Thorntail]]
			* [https://github.com/thorntail/ github.com/thorntail], GitHub officiel du projet
			* [https://github.com/thorntail/thorntail-examples github.com/thorntail/thorntail-examples], GitHub rassemblant le code source d'innombrables exemples
			* [https://blog.soat.fr/2016/07/faites-des-microservices-java-ee-avec-wildfly-swarm/ blog.soat.fr], compréhension du projet [[Wildfly_Swarm\|Wildfly Swarm]]
			* [https://blogdesexperts.infotel.com/2016/05/20/retour-sur-devoxx-2016-wildfly-swarm/ blogdesexperts.infotel.com], description claire du projet [[Wildfly_Swarm\|Wildfly Swarm]]
			* [https://blog.xebia.fr/2014/02/28/la-notion-de-bom-avec-maven/ blog.xebia.fr], compréhension de la notion de BOM [[Maven]]

Zoran.Chanet at 00:54, 19 November 2018

2018-11-19T00:54:11Z

← Older revision		Revision as of 00:54, 19 November 2018
Line 28:		Line 28:
	== Mise en place ==		== Mise en place ==
	La mise en place de [[Thorntail]] dans un projet se fait par l'intermédiaire du fichier pom.xml du projet. Une fois les lignes données dans les sections [[#Plugin\|Plugin]], [[#BOM\|BOM]] et [[#Fractions\|Fractions]] ajoutées dans le fichier, il suffit de lancer la commande donnée dans la section [[#G.C3.A9n.C3.A9ration\|Génération]] pour compresser l'application (ou le service) en un UberJAR. Cet UberJar est donc le fichier JAR qui devra être déployé. Une commande [[Maven]], également décrite dans la section [[#G.C3.A9n.C3.A9ration\|Génération]], permet de générer l'UberJAR et le déployer en local. L'application (ou le service) sera alors déployé en localhost sur le port 8080.		La mise en place de [[Thorntail]] dans un projet se fait par l'intermédiaire du fichier pom.xml du projet. Une fois les lignes données dans les sections [[#Plugin\|Plugin]], [[#BOM\|BOM]] et [[#Fractions\|Fractions]] ajoutées dans le fichier, il suffit de lancer la commande donnée dans la section [[#G.C3.A9n.C3.A9ration\|Génération]] pour compresser l'application (ou le service) en un UberJAR. Cet UberJar est donc le fichier JAR qui devra être déployé. Une commande [[Maven]], également décrite dans la section [[#G.C3.A9n.C3.A9ration\|Génération]], permet de générer l'UberJAR et le déployer en local. L'application (ou le service) sera alors déployé en localhost sur le port 8080.

	=== Plugin ===		=== Plugin ===
	pom.xml :		pom.xml :
Line 84:		Line 85:
	mvn thorntail:run		mvn thorntail:run
	Le packaging effectué par [[Thorntail]] va produire un UberJAR, contenant donc les composants de l'application, ses dépendances, ainsi que les composants runtime de l'application (le serveur d'application, en quelque sorte). Un tel packaging permet la production d'un exécutable binaire unique, très pratique en cas d'Intégration Continue et [[Continuous_Deliver\|Déploiement Continu]]. Cela permet aussi, dans le cadre d'une application microservice, que chaque service soit fortement indépendant, emportant avec lui ses dépendances et ses composants runtime. Un autre avantage des UberJAR est qu'ils sont avant tout des JAR, et peuvent donc être exécutés comme tout JAR.<br>		Le packaging effectué par [[Thorntail]] va produire un UberJAR, contenant donc les composants de l'application, ses dépendances, ainsi que les composants runtime de l'application (le serveur d'application, en quelque sorte). Un tel packaging permet la production d'un exécutable binaire unique, très pratique en cas d'Intégration Continue et [[Continuous_Deliver\|Déploiement Continu]]. Cela permet aussi, dans le cadre d'une application microservice, que chaque service soit fortement indépendant, emportant avec lui ses dépendances et ses composants runtime. Un autre avantage des UberJAR est qu'ils sont avant tout des JAR, et peuvent donc être exécutés comme tout JAR.<br>
	[[Thorntail]] permet également la production d'HolloJAR, n'emportant que les composants runtime, dans le but par exemple d'un déploiement en containers avec [[Docker]], de placer l'image des composants runtime à un niveau différent des composants de l'application, qui sont modifiés plus souvent.		[[Thorntail]] permet également la production d'HolloJAR, n'emportant que les composants runtime, dans le but par exemple d'un déploiement en containers avec [[Docker]], de placer l'image des composants runtime à un niveau différent des composants de l'application, qui sont modifiés plus souvent.<br>
			À des fins de test et de développement, il est donc possible d'exécuter l'UberJAR généré, qui sera déployé [http://127.0.0.1 localement], exposant l'API produite.

Zoran.Chanet: /* Génération */

2018-11-19T00:49:54Z

Génération

← Older revision		Revision as of 00:49, 19 November 2018
Line 76:		Line 76:

	=== Génération ===		=== Génération ===
			[[File:JAR_Naming.png\|390px\|thumb\|right\|fig.3 : Nommage des JAR par contenu]]
			Packaging :
			mvn package
			Execution :
			java -jar <myapp>-thorntail.jar
			Packaging + Execution :
			mvn thorntail:run
			Le packaging effectué par [[Thorntail]] va produire un UberJAR, contenant donc les composants de l'application, ses dépendances, ainsi que les composants runtime de l'application (le serveur d'application, en quelque sorte). Un tel packaging permet la production d'un exécutable binaire unique, très pratique en cas d'Intégration Continue et [[Continuous_Deliver\|Déploiement Continu]]. Cela permet aussi, dans le cadre d'une application microservice, que chaque service soit fortement indépendant, emportant avec lui ses dépendances et ses composants runtime. Un autre avantage des UberJAR est qu'ils sont avant tout des JAR, et peuvent donc être exécutés comme tout JAR.<br>
			[[Thorntail]] permet également la production d'HolloJAR, n'emportant que les composants runtime, dans le but par exemple d'un déploiement en containers avec [[Docker]], de placer l'image des composants runtime à un niveau différent des composants de l'application, qui sont modifiés plus souvent.

Zoran.Chanet: /* Fractions */

2018-11-19T00:28:04Z

Fractions

← Older revision		Revision as of 00:28, 19 November 2018
Line 72:		Line 72:
	</dependency>		</dependency>
	</source>		</source>
			Nous voici venu au concept de fractions, essentiel à [[Thorntail]]. Une fraction n'est autre qu'un module, originalement un morceau tiré du serveur [[Wildfly]], servant un but précis. En reprenant les figures 1 et 2 de la section [[#Description\|Description]], nous voyons (fig.1) que le serveur [[Wildfly]] implémente un certain nombre de fonction, ''JAX-RS'', ''EJB3'', ''Transactions'', ''CORBA'' et ''Batch''. Une fraction correspond simplement à l'extraction de l'une de ces fonctions. De toutes les fractions pouvant être extraites de la fig.1, l'application décrite par la fig.2 ne nécessite (et donc n'emporte) que la fraction ''JAX-RS''.<br>
			Il suffit donc de déclarer dans le pom.xml une dépendance par fraction nécessaire (en remplaçant ''jaxrs'' par le nom de la fraction, ligne 3). Grâce à la référence au BOM décrite dans [[#BOM\|la section précédente]], nous pouvons faire fi des versions.

	=== Génération ===		=== Génération ===

Zoran.Chanet: /* BOM */

2018-11-19T00:09:00Z

BOM

← Older revision		Revision as of 00:09, 19 November 2018
Line 62:		Line 62:
	</source>		</source>
	Voici les lignes permettant l'import de la dépendance BOM (Bill Of Materials). Le concept de BOM pour [[Maven]] repose sur la notion de ''scope import'' (ligne 7). Le ''scope import'' permet de remplacer la dépendance le déclarant (ici lignes 3 à 9) par la section ''dependecyManagement'' du pom auquel on fait référence (ici, le ''bom'' du groupe ''io.thorntail'', lignes 4 et 5). À la lecture du pom.xml du projet, cette dépendance sera donc remplacée par le contenu du BOM.<br>		Voici les lignes permettant l'import de la dépendance BOM (Bill Of Materials). Le concept de BOM pour [[Maven]] repose sur la notion de ''scope import'' (ligne 7). Le ''scope import'' permet de remplacer la dépendance le déclarant (ici lignes 3 à 9) par la section ''dependecyManagement'' du pom auquel on fait référence (ici, le ''bom'' du groupe ''io.thorntail'', lignes 4 et 5). À la lecture du pom.xml du projet, cette dépendance sera donc remplacée par le contenu du BOM.<br>
	Nous revenons donc à la définition du BOM. Un BOM est simplement un pom (comme indiqué ligne ) qui ne contient que la section ''dependencyManagement'', rassemblant les versions des dépendances qui seront utilisées dans les projets, permettant aux utilisateurs de [[Thorntail]] de s'affranchir de la gestion des versions des différentes fractions auxquelles ils feront appel.		Nous revenons donc à la définition du BOM. Un BOM est simplement un pom (comme indiqué ligne 8) qui ne contient que la section ''dependencyManagement'', rassemblant les versions des dépendances qui seront utilisées dans les projets, permettant aux utilisateurs de [[Thorntail]] de s'affranchir de la gestion des versions des différentes fractions auxquelles ils feront appel.

	=== Fractions ===		=== Fractions ===