Main.Teaching History
Hide minor edits - Show changes to output
Changed line 1 from:
!! Test et Maintenance - Intégration Continue (GIS2A5, Polytech'Lille))
to:
!! Test et Maintenance - Intégration Continue (GIS2A5, Polytech'Lille)
Changed lines 2-4 from:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue-prez.pdf|Continous Integration (slides)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue.pdf|Continous Integration (training document)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/4-ci-training.pdf|Continous Integration (practice)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/
to:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/ic-polytech-2015/formation-integration-continue-prez.pdf|Continous Integration (slides)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/ic-polytech-2015/formation-integration-continue.pdf|Continous Integration (training document)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/ic-polytech-2015/ci-training.pdf|Continous Integration (practice)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/ic-polytech-2015/formation-integration-continue.pdf|Continous Integration (training document)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/ic-polytech-2015/ci-training.pdf|Continous Integration (practice)]]
Deleted lines 1-2:
!! Conception Agile des logiciels (Master 2 IAGL, Université de Lille 1)
Added line 6:
!! Conception Agile des logiciels (Master 2 IAGL, Université de Lille 1)
Added lines 1-2:
!! Test et Maintenance - Intégration Continue (GIS2A5, Polytech'Lille))
Added lines 4-6:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue-prez.pdf|Continous Integration (slides)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue.pdf|Continous Integration (training document)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/4-ci-training.pdf|Continous Integration (practice)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue.pdf|Continous Integration (training document)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/4-ci-training.pdf|Continous Integration (practice)]]
Added line 9:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/4-ci-training.pdf|Continous Integration (practice)]]
Changed line 8 from:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue-prez.pdf|Continous Integration (training document)]]
to:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue.pdf|Continous Integration (training document)]]
Added lines 7-8:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue-prez.pdf|Continous Integration (slides)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue-prez.pdf|Continous Integration (training document)]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/5-formation-integration-continue-prez.pdf|Continous Integration (training document)]]
Added line 6:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/3-cours-build-2014.pdf|Automated build]]
Changed lines 2-4 from:
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/1-prez-inria.pdf|Présentation Inria]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-cours-vcs-2014.pdf|Version Control Systems]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-git-for-beginners-handout.pdf|Git for beginners handout (from A. Baire)]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-cours-vcs-2014.pdf|Version Control Systems]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-git-for-beginners-handout.pdf|Git for beginners handout (from A. Baire)]]
to:
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/1-prez-inria.pdf|Présentation Inria]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-cours-vcs-2014.pdf|Version Control Systems]]
* [[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-git-for-beginners-handout.pdf|Git for beginners handout (from A. Baire)]]
Added lines 1-6:
!! Conception Agile des logiciels (Master 2 IAGL, Université de Lille 1)
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/1-prez-inria.pdf|Présentation Inria]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-cours-vcs-2014.pdf|Version Control Systems]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-git-for-beginners-handout.pdf|Git for beginners handout (from A. Baire)]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/1-prez-inria.pdf|Présentation Inria]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-cours-vcs-2014.pdf|Version Control Systems]]
[[http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/iagl-cal2014/2-git-for-beginners-handout.pdf|Git for beginners handout (from A. Baire)]]
Changed lines 98-111 from:
!!! Eager / Lazy fetching
to:
!!! Eager / Lazy fetching
Lorsque l'on manipule des objets, on manipule très rarement des objets isolés mais plutôt des objets inter-connectés formant un graphe d'objets. Si lors de l'accés à un objet, nous devions charger complétement le graphe d'objets auquels il se réfère, ce serait très coûteux en temps d'exécution (et nécessiterait aussi un espace mémoire non négligeable).
C'est pour cela que, dans la mesure du possible, on ne charge les objets qu'à la demande.
Afin de pouvoir gérer la stratégie de chargement, JPA fournit 2 modes pour la récupération des objets:
* Eager fetching: chargement du graphe d'objets. En mode détaché, tout le graphe d'objet est accessible
* Lazy fetching: chargement à la demande des objets. Un inconvénient de cette méthode est le nombre important de requêtes pouvant être effectuées sur la base de données. En mode détaché, les informations non chargés en mémoire ne sont pas disponibles.
Mode de chargement par défaut selon les cardinalités:
|| border=1 width=50% rules=cols frame=vsides
||! Eager fetching ||! Lazy fetching ||
|| @OneToOne || @OneToMany ||
|| @ManyToOne || @ManyToMany ||
En effet, lorsqu'il n'y a qu'une entité à charger plutôt qu'une collection, il n'est pas trés coûteux de le faire.
Lorsque l'on manipule des objets, on manipule très rarement des objets isolés mais plutôt des objets inter-connectés formant un graphe d'objets. Si lors de l'accés à un objet, nous devions charger complétement le graphe d'objets auquels il se réfère, ce serait très coûteux en temps d'exécution (et nécessiterait aussi un espace mémoire non négligeable).
C'est pour cela que, dans la mesure du possible, on ne charge les objets qu'à la demande.
Afin de pouvoir gérer la stratégie de chargement, JPA fournit 2 modes pour la récupération des objets:
* Eager fetching: chargement du graphe d'objets. En mode détaché, tout le graphe d'objet est accessible
* Lazy fetching: chargement à la demande des objets. Un inconvénient de cette méthode est le nombre important de requêtes pouvant être effectuées sur la base de données. En mode détaché, les informations non chargés en mémoire ne sont pas disponibles.
Mode de chargement par défaut selon les cardinalités:
|| border=1 width=50% rules=cols frame=vsides
||! Eager fetching ||! Lazy fetching ||
|| @OneToOne || @OneToMany ||
|| @ManyToOne || @ManyToMany ||
En effet, lorsqu'il n'y a qu'une entité à charger plutôt qu'une collection, il n'est pas trés coûteux de le faire.
Changed line 84 from:
Pour un accès local, on utilisera une adresse commançant par %black%java:%%. Pour un accès distant, il faut utiliser une adresse commançant par %black%ejb:%%.
to:
Pour un '''accès local''', on utilisera une adresse commançant par %black%java:%%. Pour un '''accès distant''', il faut utiliser une adresse commançant par %black%ejb:%%.
Changed lines 78-82 from:
# que l'URL de lookup est bien au format suivant (attention au '!') : %black%ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<interface-FQN>%%. <interface-FQN> correspond au nom complet de l'interface (incluant le nom complet du package) remote ou locale. Si l'EJB recherché est un EJB Stateful, ajoutez %black%?stateful%% à la fin de l'URI précédente.
to:
# que l'URL de lookup est bien au format suivant (attention au '!') : %black%ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<interface-FQN>%%.
**<app-name> correspond au nom du fichier ear (sans l'extension) de l'application
**<module-name> corresponfd au nom du fichier jar (sans l'extension) contenant le bean recherché
**<interface-FQN> correspond au nom complet de l'interface (incluant le nom complet du package) remote ou locale.
**Si l'EJB recherché est un EJB Stateful, ajoutez %black%?stateful%% à la fin de l'URI précédente.
**<app-name> correspond au nom du fichier ear (sans l'extension) de l'application
**<module-name> corresponfd au nom du fichier jar (sans l'extension) contenant le bean recherché
**<interface-FQN> correspond au nom complet de l'interface (incluant le nom complet du package) remote ou locale.
**Si l'EJB recherché est un EJB Stateful, ajoutez %black%?stateful%% à la fin de l'URI précédente.
Added line 80:
Pour un accès local, on utilisera une adresse commançant par %black%java:%%. Pour un accès distant, il faut utiliser une adresse commançant par %black%ejb:%%.
Changed lines 49-50 from:
L'association peut être bidirectionnelle. Dans une relation bidirectionnelle, une des extrémités ({+et seulement une+}) doit être la propriétaire : la propriétaire est responsable de la mise à jour des colonnes de l'association. Cela siginife que pour persister les données en base, il faut obligatoirement utiliser le setter du propriétaire de l'association.
to:
L'association peut être bidirectionnelle. Dans une relation bidirectionnelle, une des extrémités ({+et seulement une+}) doit être la propriétaire : la propriétaire est responsable de la mise à jour des colonnes de l'association. Cela signifie que pour persister les données en base, il faut obligatoirement utiliser le setter du propriétaire de l'association.
Added lines 80-93:
!!! Entity Manager
La persistance des EJB entités est assurée par l'%black%EntityManager%%. L'Entity manager sait comment persister les données en base en cherchant dans la configuration de l'ORM (mapping objet-relationnel, ex: hibernate) utilisé par le serveur d'application. Il réalise les opération CRUD (create, read, update et delete) nécessaires.
En résumé, l'Entity Manager gère le cycle de vie des EJB entités. Il est le pont entre le monde objet et le monde relationnel.
Il réalise les opérations suivantes:
* à la création d'un EJB entité, l' EntityManager traduit l'entité en un enregistrement en base de données
* à la MAJ d'un entité, il piste les données en base correspondant aux modification de l'entité et les met à jour
* à la suppression d'un entité, il détruit les données en base correspondantes.
* L'entityManager essaye également de garder les données en base et l'entité synchronisés tant que l'entité est dans un état géré (managed).
Un EJB entité devient détaché dès que l'EntityManager n'est plus accessible: sérialisation d'un entité pour le passer à un autre environnement d'exécution (ex: web tier), suppression de l'entité ou copie de l'entité.
Lorsqu'un EJB entité est détaché, il n'est plus synchronisé avec la base.
!!! Eager / Lazy fetching
Changed line 26 from:
to:
%black%application.xml%% : décrit une application J2EE, notamment les modules (web, ejb) la composant. La balise %black%context-root%% désigne l'url à laquelle sera accessible notre application. Cette url est relative à l'url de déploiement du serveur d'applications (ex: http://localhost:8080).
Changed lines 49-51 from:
L'association peut être bidirectionnelle. Dans une relation bidirectionnelle, une des extrémités (et seulement une) doit être la propriétaire : la propriétaire est responsable de la mise à jour des colonnes de l'association. Pour déclarer une extrémité comme non responsable de la relation, l'attribut mappedBy est utilisé. %black%mappedBy%% référence le nom de la propriété de l'association du côté du propriétaire. Dans l'exemple ci-dessous, A est propriétaire de l'association.
to:
L'association peut être bidirectionnelle. Dans une relation bidirectionnelle, une des extrémités ({+et seulement une+}) doit être la propriétaire : la propriétaire est responsable de la mise à jour des colonnes de l'association. Cela siginife que pour persister les données en base, il faut obligatoirement utiliser le setter du propriétaire de l'association.
Pour déclarer une extrémité comme '''non''' responsable de la relation, l'attribut mappedBy est utilisé. %black%mappedBy%% référence le nom de la propriété de l'association du côté du propriétaire. Dans l'exemple ci-dessous, A est propriétaire de l'association.
Pour déclarer une extrémité comme '''non''' responsable de la relation, l'attribut mappedBy est utilisé. %black%mappedBy%% référence le nom de la propriété de l'association du côté du propriétaire. Dans l'exemple ci-dessous, A est propriétaire de l'association.
Added lines 67-74:
Pour mettre à jour les données, il faut donc procéder comme suit:
(:source lang=Java :)
A anInstanceOfA;
B anInstanceOfB;
...
anInstanceOfA.getRoleB().add( anInstanceOfB );
(:sourceend:)
La mise à jour des données via anInstanceOfB ne provoquera pas d'erreur mais les données ne seront pas persistées en base.
(:source lang=Java :)
A anInstanceOfA;
B anInstanceOfB;
...
anInstanceOfA.getRoleB().add( anInstanceOfB );
(:sourceend:)
La mise à jour des données via anInstanceOfB ne provoquera pas d'erreur mais les données ne seront pas persistées en base.
Changed line 69 from:
# que votre composant session est bien déployé, qu'il est annoté avec %black%@Stateless%% ou %black%@Stateful%%, qu'il implémente bien l'interface locale/remote, que les interfaces sont elles aussi bien annotées, et enfin que vous avez spécifié le déploiment du module concerné dans le descripteur application.xml.
to:
# que votre composant session est bien déployé, qu'il est annoté avec %black%@Stateless%% ou %black%@Stateful%%, qu'il implémente bien l'interface locale/remote, que les interfaces sont elles aussi bien annotées, et enfin que vous avez spécifié le déploiement du module concerné dans le descripteur application.xml.
Changed line 53 from:
@ManyToMany(cascade = CascadeType.ALL)
to:
@ManyToMany
Changed line 54 from:
public B getRoleB() {
to:
public Collection<B> getRoleB() {
Changed line 69 from:
# que votre composant session est bien déployé, qu'il est annoté avec %black%@Stateless%% ou %black%@Stateful%%, qu'il implémente bien l'interface locale/remote, et enfin que les interfaces sont elles aussi bien annotées.
to:
# que votre composant session est bien déployé, qu'il est annoté avec %black%@Stateless%% ou %black%@Stateful%%, qu'il implémente bien l'interface locale/remote, que les interfaces sont elles aussi bien annotées, et enfin que vous avez spécifié le déploiment du module concerné dans le descripteur application.xml.
Changed line 54 from:
public B getB() {
to:
public B getRoleB() {
Changed line 61 from:
public Collection<A> getA() {
to:
public Collection<A> getRoleA() {
Changed lines 67-68 from:
Si, lorsque vous tentez de récupérer une référence vers un EJB distant, une exception NoSuchEJBException est lancée, vérifiez:
# que l'URL de lookup est bien au format suivant (attention au '!') :
# que l'URL de lookup est bien au format suivant (attention au '!') :
to:
Si, lorsque vous tentez de récupérer une référence vers un EJB session distant, une exception NoSuchEJBException est lancée, vérifiez:
# que l'URL de lookup est bien au format suivant (attention au '!') : %black%ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<interface-FQN>%%. <interface-FQN> correspond au nom complet de l'interface (incluant le nom complet du package) remote ou locale. Si l'EJB recherché est un EJB Stateful, ajoutez %black%?stateful%% à la fin de l'URI précédente.
# que l'URL de lookup est bien au format suivant (attention au '!') : %black%ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<interface-FQN>%%. <interface-FQN> correspond au nom complet de l'interface (incluant le nom complet du package) remote ou locale. Si l'EJB recherché est un EJB Stateful, ajoutez %black%?stateful%% à la fin de l'URI précédente.
Changed line 67 from:
Si, lorsque vous tentez de récupérer une référence vers un EJB distant, une exception NoSuchEJBException est lancée, vérifier:
to:
Si, lorsque vous tentez de récupérer une référence vers un EJB distant, une exception NoSuchEJBException est lancée, vérifiez:
Changed lines 64-69 from:
(:sourceend:)
to:
(:sourceend:)
!!! JNDI et jboss
Si, lorsque vous tentez de récupérer une référence vers un EJB distant, une exception NoSuchEJBException est lancée, vérifier:
# que l'URL de lookup est bien au format suivant (attention au '!') :
# que votre composant session est bien déployé, qu'il est annoté avec %black%@Stateless%% ou %black%@Stateful%%, qu'il implémente bien l'interface locale/remote, et enfin que les interfaces sont elles aussi bien annotées.
!!! JNDI et jboss
Si, lorsque vous tentez de récupérer une référence vers un EJB distant, une exception NoSuchEJBException est lancée, vérifier:
# que l'URL de lookup est bien au format suivant (attention au '!') :
# que votre composant session est bien déployé, qu'il est annoté avec %black%@Stateless%% ou %black%@Stateful%%, qu'il implémente bien l'interface locale/remote, et enfin que les interfaces sont elles aussi bien annotées.
Changed line 49 from:
L'association peut être bidirectionnelle. Dans une relation bidirectionnelle, une des extrémités (et seulement une) doit être la propriétaire : la propriétaire est responsable de la mise à jour des colonnes de l'association. Pour déclarer une extrémité comme non responsable de la relation, l'attribut mappedBy est utilisé. %black%mappedBy%% référence le nom de la propriété de l'association du côté du propriétaire.
to:
L'association peut être bidirectionnelle. Dans une relation bidirectionnelle, une des extrémités (et seulement une) doit être la propriétaire : la propriétaire est responsable de la mise à jour des colonnes de l'association. Pour déclarer une extrémité comme non responsable de la relation, l'attribut mappedBy est utilisé. %black%mappedBy%% référence le nom de la propriété de l'association du côté du propriétaire. Dans l'exemple ci-dessous, A est propriétaire de l'association.
Added lines 50-64:
(:source lang=Java :)
@Entity
public class A implements Serializable {
@ManyToMany(cascade = CascadeType.ALL)
public B getB() {
...
}
@Entity
public class B implements Serializable {
@ManyToMany(mappedBy = "roleB")
public Collection<A> getA() {
...
}
(:sourceend:)
@Entity
public class A implements Serializable {
@ManyToMany(cascade = CascadeType.ALL)
public B getB() {
...
}
@Entity
public class B implements Serializable {
@ManyToMany(mappedBy = "roleB")
public Collection<A> getA() {
...
}
(:sourceend:)
Changed line 48 from:
%center%Path:/demarey/pmwiki/images/mappedBy.svg"mappedBy" | '''Figure 2 : Utilisation des rôles dans la définition d'associations'''
to:
%center%Path:/demarey/pmwiki/images/mappedBy.png"mappedBy" | '''Figure 2 : Utilisation des rôles dans la définition d'associations'''
Changed line 48 from:
to:
%center%Path:/demarey/pmwiki/images/mappedBy.svg"mappedBy" | '''Figure 2 : Utilisation des rôles dans la définition d'associations'''
Changed lines 48-49 from:
to:
L'association peut être bidirectionnelle. Dans une relation bidirectionnelle, une des extrémités (et seulement une) doit être la propriétaire : la propriétaire est responsable de la mise à jour des colonnes de l'association. Pour déclarer une extrémité comme non responsable de la relation, l'attribut mappedBy est utilisé. %black%mappedBy%% référence le nom de la propriété de l'association du côté du propriétaire.
Changed lines 44-48 from:
Le lien se fait grâce au nom de l'unité de persistance (unit-name). Le lien avec la base de données se fait, quant à lui, grâce à la source de données (jta-data-source) déclarée dans l'unité de persistance (toujours dans persistence.xml). Cette source de données a été déclarée au niveau du serveur d'application en précisant l'adresse de la base de données, l'utilisateur et le mot de passe à utiliser pour s'y connecter.
to:
Le lien se fait grâce au nom de l'unité de persistance (unit-name). Le lien avec la base de données se fait, quant à lui, grâce à la source de données (jta-data-source) déclarée dans l'unité de persistance (toujours dans persistence.xml). Cette source de données a été déclarée au niveau du serveur d'application en précisant l'adresse de la base de données, l'utilisateur et le mot de passe à utiliser pour s'y connecter.
!!! Associations et EJB Entités
La convention de nommage veut que les accesseurs utilisent les noms de rôle des associations.
Le paramètre mappedBy de certaines associations (OneToOne, OneToMany, ManyToMany) désigne le nom du rôle inverse de l'association. Il désigne le rôle propriétaire de l'association.
!!! Associations et EJB Entités
La convention de nommage veut que les accesseurs utilisent les noms de rôle des associations.
Le paramètre mappedBy de certaines associations (OneToOne, OneToMany, ManyToMany) désigne le nom du rôle inverse de l'association. Il désigne le rôle propriétaire de l'association.
Changed line 23 from:
Les JSP sont une technologie permettant d'ajouter du contenu dynamique à des pages Webs en s'appuyant sur Java. Ils offrent un confort au programmeur en permettant de mixer du code Java (à l'aide de balises JSP) et du code HTML. Les JSP, avant de pouvoir être utilisées, sont transformées en Servlet Java. Le code HTML est encapsulé dans des instructions out.write(""), les déclarations de méthodes et d'attributs deviennent membres de la classe générée, et le code entre balises <% et %> se retrouve dans la méthode _jspService(). Cette méthode est appelée lorsque le browser fait une requête au JSP.
to:
Les JSP sont une technologie permettant d'ajouter du contenu dynamique à des pages Webs en s'appuyant sur Java. Ils offrent un confort au programmeur en permettant de mixer du code Java (à l'aide de balises JSP) et du code HTML. Les JSP, avant de pouvoir être utilisées, sont transformées en Servlet Java. Le code HTML est encapsulé dans des instructions %black%out.write("")%%, les déclarations de méthodes et d'attributs deviennent membres de la classe générée, et le code entre balises %black%<% %% et %black% %> %%se retrouve dans la méthode %black%_jspService()%%. Cette méthode est appelée lorsque le browser fait une requête au JSP.
Changed lines 30-31 from:
to:
(:source lang=Java :)
@PersistenceContext(unitName="myAppDB")
protected EntityManager em;
(:sourceend:)
@PersistenceContext(unitName="myAppDB")
protected EntityManager em;
(:sourceend:)
Changed lines 35-40 from:
to:
(:source lang=XML :)
<persistence>
<persistence-unit name="myAppDB">
<jta-data-source>java:/PostgresDS</jta-data-source>
...
</persistence-unit>
<persistence>
(:sourceend:)
<persistence>
<persistence-unit name="myAppDB">
<jta-data-source>java:/PostgresDS</jta-data-source>
...
</persistence-unit>
<persistence>
(:sourceend:)
Changed line 31 from:
protected EntityManager em;
to:
protected EntityManager em;
Changed line 30 from:
@PersistenceContext(unitName="myAppDB")
to:
@PersistenceContext(unitName="myAppDB")
Changed lines 33-38 from:
<persistence>
<persistence-unit name="myAppDB">
<jta-data-source>java:/PostgresDS</jta-data-source>
...
</persistence-unit>
<persistence>
<jta-data-source>java:/PostgresDS</jta-data-source>
...
</persistence-unit>
<persistence>
to:
<persistence>
<persistence-unit name="myAppDB">
<jta-data-source>java:/PostgresDS</jta-data-source>
...
</persistence-unit>
<persistence>
<persistence-unit name="myAppDB">
<jta-data-source>java:/PostgresDS</jta-data-source>
...
</persistence-unit>
<persistence>
Changed lines 26-40 from:
Application.xml : décrit une application J2EE, notamment les modules (web, ejb) la composant. La balise context-root désigne l'url à laquelle sera accessible notre application. Cette url est relative à l'url de déploiement du serveur d'applications (ex: http://localhost:8080).
to:
Application.xml : décrit une application J2EE, notamment les modules (web, ejb) la composant. La balise context-root désigne l'url à laquelle sera accessible notre application. Cette url est relative à l'url de déploiement du serveur d'applications (ex: http://localhost:8080).
!!! EJB Entité
Afin de pouvoir dialoguer avec la base de données dans un EJB Entité, vous devez déclarer une instance de gestionnaire d'entité :
@PersistenceContext(unitName="myAppDB")
protected EntityManager em;
Celui-ci est associé à un contexte de persitance déclaré dans le descripteur persistence.xml
<persistence>
<persistence-unit name="myAppDB">
<jta-data-source>java:/PostgresDS</jta-data-source>
...
</persistence-unit>
<persistence>
Le lien se fait grâce au nom de l'unité de persistance (unit-name). Le lien avec la base de données se fait, quant à lui, grâce à la source de données (jta-data-source) déclarée dans l'unité de persistance (toujours dans persistence.xml). Cette source de données a été déclarée au niveau du serveur d'application en précisant l'adresse de la base de données, l'utilisateur et le mot de passe à utiliser pour s'y connecter.
!!! EJB Entité
Afin de pouvoir dialoguer avec la base de données dans un EJB Entité, vous devez déclarer une instance de gestionnaire d'entité :
@PersistenceContext(unitName="myAppDB")
protected EntityManager em;
Celui-ci est associé à un contexte de persitance déclaré dans le descripteur persistence.xml
<persistence>
<persistence-unit name="myAppDB">
<jta-data-source>java:/PostgresDS</jta-data-source>
...
</persistence-unit>
<persistence>
Le lien se fait grâce au nom de l'unité de persistance (unit-name). Le lien avec la base de données se fait, quant à lui, grâce à la source de données (jta-data-source) déclarée dans l'unité de persistance (toujours dans persistence.xml). Cette source de données a été déclarée au niveau du serveur d'application en précisant l'adresse de la base de données, l'utilisateur et le mot de passe à utiliser pour s'y connecter.
Changed lines 23-24 from:
Les JSP sont une technologie permettant d'ajouter du contenu dynamique à des pages Webs en s'appuyant sur Java. Ils offrent un confort au programmeur en permettant de mixer du code Java (à l'aide de balises JSP) et du code HTML. Les JSP, avant de pouvoir être utilisées, sont transformées en Servlet Java.
to:
Les JSP sont une technologie permettant d'ajouter du contenu dynamique à des pages Webs en s'appuyant sur Java. Ils offrent un confort au programmeur en permettant de mixer du code Java (à l'aide de balises JSP) et du code HTML. Les JSP, avant de pouvoir être utilisées, sont transformées en Servlet Java. Le code HTML est encapsulé dans des instructions out.write(""), les déclarations de méthodes et d'attributs deviennent membres de la classe générée, et le code entre balises <% et %> se retrouve dans la méthode _jspService(). Cette méthode est appelée lorsque le browser fait une requête au JSP.
Changed line 26 from:
Application.xml : décrit une application J2EE, notamment les modules (web, ejb) la composant. La balise context-root désigne l'url à laquelle sera accessible notre application. Cette url est relative à l'url de déploiement du serveur d'applications (ex: http://localohst:8080).
to:
Application.xml : décrit une application J2EE, notamment les modules (web, ejb) la composant. La balise context-root désigne l'url à laquelle sera accessible notre application. Cette url est relative à l'url de déploiement du serveur d'applications (ex: http://localhost:8080).
Changed lines 23-26 from:
Les JSP sont une technologie permettant d'ajouter du contenu dynamique à des pages Webs en s'appuyant sur Java. Ils offrent un confort au programmeur en permettant de mixer du code Java (à l'aide de balises JSP) et du code HTML. Les JSP, avant de pouvoir être utilisées, sont transformées en Servlet Java.
to:
Les JSP sont une technologie permettant d'ajouter du contenu dynamique à des pages Webs en s'appuyant sur Java. Ils offrent un confort au programmeur en permettant de mixer du code Java (à l'aide de balises JSP) et du code HTML. Les JSP, avant de pouvoir être utilisées, sont transformées en Servlet Java.
!!! Descripteur d'applications J2EE
Application.xml : décrit une application J2EE, notamment les modules (web, ejb) la composant. La balise context-root désigne l'url à laquelle sera accessible notre application. Cette url est relative à l'url de déploiement du serveur d'applications (ex: http://localohst:8080).
!!! Descripteur d'applications J2EE
Application.xml : décrit une application J2EE, notamment les modules (web, ejb) la composant. La balise context-root désigne l'url à laquelle sera accessible notre application. Cette url est relative à l'url de déploiement du serveur d'applications (ex: http://localohst:8080).
Added lines 20-23:
!!! JSP (Java Server Pages)
Les JSP sont une technologie permettant d'ajouter du contenu dynamique à des pages Webs en s'appuyant sur Java. Ils offrent un confort au programmeur en permettant de mixer du code Java (à l'aide de balises JSP) et du code HTML. Les JSP, avant de pouvoir être utilisées, sont transformées en Servlet Java.
Changed line 1 from:
!! Architectures Logielles (GIS4, Polytech'Lille)
to:
!! Architectures Logicielles (GIS4, Polytech'Lille)
Changed line 2 from:
Cours assuré par Olivier Caron ([[http://ocaron.plil.fr/|support de cours]]).
to:
Cours assuré par Olivier Caron ([[http://ocaron.plil.fr/|support de cours]]).\\
Changed lines 3-5 from:
to:
Intervenant en Travaux Pratiques et en tutorat Projet
!!!Comprendre les communications distantes
!!!Comprendre les communications distantes
Changed lines 8-9 from:
Pour masquer la complexité de la couche réseau, les frameworks sont capables de générer des objets : stub (rôle client) et skeleton (rôle serveur), de manière transparente pour l'utilisateur, et qui permettent de manipuler des objets distants tout en ayant l'impression que ce sont des objets locaux.
to:
Pour masquer la complexité de la couche réseau, les frameworks sont capables de générer des objets : stub (rôle client) et skeleton (rôle serveur), de manière transparente pour l'utilisateur, qui permettent de manipuler des objets distants tout en ayant l'impression que ce sont des objets locaux.
Added lines 11-13:
Comme un objet A côté client ne peut pas pas dialoguer avec un objet B côté serveur, nous devons utiliser une librairie d'accès à distance. Il en existe plusieurs, fonctionnant sur le même principe mais différent par le protocole utilisé (IIOP, HTTP, etc.). Quand l'objet B (rôle serveur) sera instancié, un squelette (skeleton) sera instantié en même temps afin de gérer la couche réseau et être à l'écoute des requêtes entrantes. Quand le client voudra dialoguer avec l'objet B, il ne va pas instantier un objet B (dans ce cas, nous aurions 2 objets B différents : un côté serveur et un côté client) mais va demander à la librairie de créer un objet de type B (ou en récupérer un enregistré dans un annuaire) à notre place. La librairie va alors créer un objet stub lié à l'objet distant B dans la machine virtuelle du client. L'objet retourné n'est pas de type B mais du type de l'interface de B (MyServiceInterface): la librairie a construit une sorte de proxy ayant le même comportement que l'objet B (mêmes méthodes) et permettant de dialoguer avec lui en cachant la complexité de la couche réseau.
Les communications entre client et serveur:
Les communications entre client et serveur:
Changed line 2 from:
Cours assuré par Olivier Carion ([[http://ocaron.plil.fr/|support de cours]]).
to:
Cours assuré par Olivier Caron ([[http://ocaron.plil.fr/|support de cours]]).
Changed lines 4-5 from:
Path:/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
to:
%center%Path:/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
Changed lines 10-14 from:
Explications:
to:
Explications:
# Le client souhaite envoyer un message au serveur: sayHello("Christophe"). Cette requête contient un paramètre qui va devoir être encodé (marshalling) pour transiter via la couche réseau.
# Le serveur reçoit la requête et doit maintenant décoder le paramètre envoyé par le client (unmarshalling)
# Le serveur traite le message (exécute le code associé) et produit le résultat. Ce résultat doit à son tour être encodé (marshalling) pour être renvoyé au client.
# Enfin, le client décode le résultat (unmarshalling) renvoyé par le serveur.
# Le client souhaite envoyer un message au serveur: sayHello("Christophe"). Cette requête contient un paramètre qui va devoir être encodé (marshalling) pour transiter via la couche réseau.
# Le serveur reçoit la requête et doit maintenant décoder le paramètre envoyé par le client (unmarshalling)
# Le serveur traite le message (exécute le code associé) et produit le résultat. Ce résultat doit à son tour être encodé (marshalling) pour être renvoyé au client.
# Enfin, le client décode le résultat (unmarshalling) renvoyé par le serveur.
Added lines 5-10:
Dans le monde Java, on parle de communications à distance dès lors qu'un objet d'une machine virtuelle (JVM) échange des données avec un objet d'une autre JVM, même si celle-ci est exécutée sur la même machine : ce sont 2 processus différents qui ne peuvent dialoguer que via la couche réseau.
Pour masquer la complexité de la couche réseau, les frameworks sont capables de générer des objets : stub (rôle client) et skeleton (rôle serveur), de manière transparente pour l'utilisateur, et qui permettent de manipuler des objets distants tout en ayant l'impression que ce sont des objets locaux.
Explications:
Changed line 4 from:
Path:~demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
to:
Path:/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
Changed line 4 from:
Path:/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
to:
Path:~demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
Changed line 4 from:
Path:pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
to:
Path:/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
Changed line 4 from:
to:
Path:pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
Changed lines 3-4 from:
!!!TP/Projet AL/
file:///public_html/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
file:///public_html/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
to:
!!!TP/Projet AL
%width=150px% file:///public_html/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
%width=150px% file:///public_html/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
Changed line 4 from:
file:///public_html/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1'''
to:
file:///public_html/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1 : Envoi de messages client / serveur'''
Changed lines 3-4 from:
TP/Projet AL
to:
!!!TP/Projet AL/
file:///public_html/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1'''
file:///public_html/demarey/pmwiki/images/stub-skeleton.png"client/serveur" | '''Figure 1'''
Changed lines 1-3 from:
to:
!! Architectures Logielles (GIS4, Polytech'Lille)
Cours assuré par Olivier Carion ([[http://ocaron.plil.fr/|support de cours]]).
TP/Projet AL
Cours assuré par Olivier Carion ([[http://ocaron.plil.fr/|support de cours]]).
TP/Projet AL