jeudi 24 mars 2022

Déployer une application Spring Boot / Angular

Plusieurs solutions sont disponibles pour pouvoir déployer une application développé en Springboot et Angular pour le front(ui)

1. Fussionner les deux parties ui et backend dans spring boot et utiliser Maven pour builder l'application

2. Sépérer les deux partie et permettre l'accès à l'application à travers un serveur web tel que NGINX
Autre contrainte pour déployer plusieurs instances de la partie front avec plusieurs path :
Solution 1 : builder l'application en ajoutant les paramètres : --base-href=/${base-href-value}/ --deploy-url=/${base-href-value}/
et on aura une image Docker par chaque configuration différente Solution 2 : builder une seule image Docker avec un script à rajouter dans la page d'acceuil permettant de mettre à jour la valeur de " " et remplacer sa valeur :
document.getElementById('baseHref').href = '/' + window.location.pathname.split('/')[1] + "/";

cela va permettre de déployer la même image Docker avec plusieurs configuration sous plusieurs paths , exemple :
https://monapp.com/instance1/ https://monapp.com/instance2/

jeudi 21 juin 2012

WebServices SOAP avec Apache CXF

Introduction

De manière simplifiée, SOAP permet de faire de l'appel de procédure à distance au dessus du protocole HTTP. Les données échangées sont au format XML.

Apache CXF est un framwork Java qui permet de simplifier la creation de Webservices SOAP

Architechture

L'idée est de faire un package pour le client (un jar), un package pour le serveur (un war), et un package commun (jar) aux deux qui contiendra les interfaces et les POJO échangés entre les deux services.

Cela simplifie la création d'un client en Java, mais cela n'empêche pas de créer un webservice simplement à partir du WSDL qui sera généré à la demande par CXF.

Dépendances Maven pour CXF

01<dependency>
02    <groupId>javax.servlet</groupId>
03    <artifactId>servlet-api</artifactId>
04    <version>2.5</version>
05    <scope>provided</scope>
06</dependency>
07 
08<dependency>
09    <groupId>org.apache.cxf</groupId>
10    <artifactId>cxf-rt-frontend-jaxws</artifactId>
11    <version>2.1.3</version>
12</dependency>
13 
14<dependency>
15    <groupId>org.apache.cxf</groupId>
16    <artifactId>cxf-rt-transports-http</artifactId>
17    <version>2.1.3</version>
18</dependency>

Package Commun

Tout d'abord l'interface du service

01package org.djo.example;
02 
03import javax.jws.WebParam;
04import javax.jws.WebResult;
05import javax.jws.WebService;
06 
07@WebService
08public interface MonService {
09 
10    @WebResult(name = "helloresponse")
11    Hello sayHello(@WebParam(name = "name") String name);
12 
13}

Puis une classe POJO simple pour le retour. Ce n'est pas obligatoire, on aurait pu faire un return String tout simple pour notre méthode sayHello.

01package org.djo.example;
02 
03import java.util.Date;
04 
05public class Hello {
06 
07    private Date when;
08 
09    private String hello;
10 
11    public Date getWhen() {
12        return when;
13    }
14 
15    public void setWhen(Date when) {
16        this.when = when;
17    }
18 
19    public String getHello() {
20        return hello;
21    }
22 
23    public void setHello(String hello) {
24        this.hello = hello;
25    }
26}

Package serveur

Implémentation du service

01package org.djo.example;
02 
03public class MonServiceImpl implements MonService {
04 
05    public Hello sayHello(String name) {
06        Hello response = new Hello();
07        response.setHello("Hello " + name);
08        return response;
09    }
10 
11}

WEB-INF/web.xml

01<?xml version="1.0" encoding="UTF-8"?>
02<!DOCTYPE web-app
03    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
05<web-app>
06    <context-param>
07        <param-name>contextConfigLocation</param-name>
08        <param-value>WEB-INF/beans.xml</param-value>
09    </context-param>
10 
11    <listener>
12        <listener-class>
13            org.springframework.web.context.ContextLoaderListener
14        </listener-class>
15    </listener>
16 
17 
18    <servlet>
19        <servlet-name>CXFServlet</servlet-name>
20        <display-name>CXF Servlet</display-name>
21        <servlet-class>
22            org.apache.cxf.transport.servlet.CXFServlet
23        </servlet-class>
24        <load-on-startup>1</load-on-startup>
25    </servlet>
26 
27 
28    <servlet-mapping>
29        <servlet-name>CXFServlet</servlet-name>
30        <url-pattern>/services/*</url-pattern>
31    </servlet-mapping>
32</web-app>

WEB-INF/beans.xml

Ce fichier va être chargé automatiquement par Spring (dont dépend CXF), afin de déclarer nos services.

01<?xml version="1.0" encoding="UTF-8"?>
06 
07    <import resource="classpath:META-INF/cxf/cxf.xml" />
08    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
09    <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
10 
11    <jaxws:endpoint id="MonService" implementor="org.djo.example.MonServiceImpl"
12        address="/MonService" />
13 
14</beans>

Execution

Un fois le package déployé, le WSDL du service sera disponible par exemple à l'URL http://localhost:8080/service.server/services/MonService?wsdl

Package Client

Le client aura besoin d'importer le package commun, qui contient la déclaration de l'interface et les pojo partagés. Bien sur, il est possible de générer ces pojo et cette interface à partir du WSDL, mais ce n'est pas l'objet de cet article.

Le client est alors aussi simple que cela:

01package org.djo.example;
02 
03import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
04 
05public class TestService {
06 
07    public static String address = "http://localhost:8080/service.server/services/MonService";
08 
09    public static MonService getMonService() {
10        JaxWsProxyFactoryBean factoryBean = new JaxWsProxyFactoryBean();
11        factoryBean.setServiceClass(MonService.class);
12        factoryBean.setAddress(address);
13        MonService monService = (MonService) factoryBean.create();
14        return monService;
15    }
16 
17    public static void main(String[] args) {
18        Hello response = getMonService().sayHello("WAJDI");
19        System.out.println(response.getHello());
20    }
21}

jeudi 14 juin 2012

JSF VS GWT


JSF est un MVC permettant de séparer la présentation d’une vue du traitement métier pour une application web, GWT est un compilateur qui va transformer du code Java, langage informatique universel, en HTML/Java-script/CSS pour la vue.
 Pour comprendre l’enjeu, il faut revenir à la préhistoire de l’informatique.
Avant, on envoyait une requête au serveur, le serveur traitait, et il rechargeait toute la page. JSF part de ce principe.
Le java-script, langage interprété par votre navigateur, était peu utilisé.

Aujourd’hui, le java-script, combiné avec le CSS et le HTML, est mieux utilisé. Votre page web devient une application à part entière et il est possible de demander au serveur de ne recharger qu’une partie de la page.
C’est l’avènement des technologies AJAX et de la philosophie web 2.0.
C’est beau?
Oui mais, il y a un problème: le java-script dépend de votre navigateur, et certains navigateurs sont des cauchemars pour les développeurs (enfin surtout un: Internet Explorer).

C’est là qu’intervient GWT: GWT va compiler un site en plusieurs versions, et il va le faire pour chaque navigateur. GWT va optimiser le java-script pour chaque navigateur.
Là est la force de GWT.
Par ailleurs, grâce à l’IDE Eclipse, il sera possible de lancer le site en mode Hosted pour le débogage.

Seulement, le choix entre GWT et JSF n’est pas si évident, et aujourd’hui, j’ai tendance à préférer JSF.
La première raison est que JSF est plus facile à maîtriser et qu’il permet de séparer la vue des autres couches plus facilement.
La seconde raison est que JSF ou GWT doivent s’intégrer facilement dans les autres technologies qui ont fait leurs preuves, c’est à dire Maven pour la construction de projet, Hibernate pour la persistance, et Spring pour l’injection de dépendance.
Et comme en mode hosted Google nous impose un Jetty comme moteur de Servlet (alors que le Tomcat est tellement plus simple).

JSF a une structure tellement flexible, que Aujourd’hui, il est possible de faire de l’AJAX sans toucher au java-script.
Il existe des librairies de composants comme Primefaces ou RichFaces.

lundi 12 septembre 2011

WebServices SOAP avec Spring et Apache CXF

WebServices SOAP avec Apache CXF

 Introduction

De manière simplifiée, SOAP permet de faire de l'appel de procédure à distance au dessus du protocole HTTP. Les données échangées sont au format XML.
Apache CXF est un framwork Java qui permet de simplifier la creation de Webservices SOAP

Architechture

L'idée est de faire un package pour le client (un jar), un package pour le serveur (un war), et un package commun (jar) aux deux qui contiendra les interfaces et les POJO échangés entre les deux services.
Cela simplifie la création d'un client en Java, mais cela n'empêche pas de créer un webservice simplement à partir du WSDL qui sera généré à la demande par CXF.

Dépendances Maven pour CXF








Package Commun

Tout d'abord l'interface du service





Puis une classe POJO simple pour le retour. Ce n'est pas obligatoire, on aurait pu faire un return String tout simple pour notre méthode sayHello.







Package serveur

Implémentation du service







WEB-INF/web.xml





WEB-INF/beans.xml

Ce fichier va être chargé automatiquement par Spring (dont dépend CXF), afin de déclarer nos services.

 



Execution

Un fois le package déployé, le WSDL du service sera disponible par exemple à l'URL http://localhost:8080/service.server/services/MonService?wsdl

Package Client

Le client aura besoin d'importer le package commun, qui contient la déclaration de l'interface et les pojo partagés. Bien sur, il est possible de générer ces pojo et cette interface à partir du WSDL, mais ce n'est pas l'objet de cet article.
Le client est alors aussi simple que cela:
 
referencements gratuits - lingerie sexy - voyance - photographe mariage marseille
Referencement