Dans le cadre de la migration d'une application vers le standard J2EE 1.3
(migration qui s'accompagne de la migration de WAS 3.5 vers WAS 5), les
livrables seront uniquement constitués d'une archive ear.
Ma question est : quid des fichiers properties (sachant q'on en a une
tonne...) ? les mettre dans le ear, ejb-jar, ou dans le war sachant qu'il
faut souvent les retoucher (en production) et qu'on aimerait le faire sans
avoir à relivrer un ear... ou bien les externaliser?
En gros quelles sont les "best practice" dans ce domaine ou si ils n'en
existent pas, des retours d'expérience (avantages, inconvénients....)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
sfructus
On a à peu prés les mêmes conditions contraintes avec nos clients. On livre toujours un .zip qui contient les répertoires suivants: /app/deploy /app/util /jboss /doc
Dans le /app/deploy on a le .ear qui est configuré d'aprés les demandes du client (avec à l'intérieur tous les .conf, .properties). Si le client veut lui-même modifier la config, il a la possibilité de faire tourner un utilitaire qui lui refabrique une .ear avec la config voulue. Le /app/util contient les utilitaires pour transformer (à l'aide de xsl) le fichier de config .xml en nouvelle config. Clair ? Ca permet de livrer une release avec une conf et de donner au client les outils pour modifier lui-même sa conf sans avoir à refaire une release... A+ Stéphane
"Terry" wrote in message news:<409fc0e4$0$12730$...
Dans le cadre de la migration d'une application vers le standard J2EE 1.3 (migration qui s'accompagne de la migration de WAS 3.5 vers WAS 5), les livrables seront uniquement constitués d'une archive ear.
Ma question est : quid des fichiers properties (sachant q'on en a une tonne...) ? les mettre dans le ear, ejb-jar, ou dans le war sachant qu'il faut souvent les retoucher (en production) et qu'on aimerait le faire sans avoir à relivrer un ear... ou bien les externaliser?
En gros quelles sont les "best practice" dans ce domaine ou si ils n'en existent pas, des retours d'expérience (avantages, inconvénients....)
Merci d'avance
On a à peu prés les mêmes conditions contraintes avec nos clients.
On livre toujours un .zip qui contient les répertoires suivants:
/app/deploy
/app/util
/jboss
/doc
Dans le /app/deploy on a le .ear qui est configuré d'aprés les
demandes du client (avec à l'intérieur tous les .conf, .properties).
Si le client veut lui-même modifier la config, il a la possibilité de
faire tourner un utilitaire qui lui refabrique une .ear avec la config
voulue.
Le /app/util contient les utilitaires pour transformer (à l'aide de
xsl) le fichier de config .xml en nouvelle config.
Clair ?
Ca permet de livrer une release avec une conf et de donner au client
les outils pour modifier lui-même sa conf sans avoir à refaire une
release...
A+
Stéphane
"Terry" <terence.soussan@free.fr> wrote in message news:<409fc0e4$0$12730$636a15ce@news.free.fr>...
Dans le cadre de la migration d'une application vers le standard J2EE 1.3
(migration qui s'accompagne de la migration de WAS 3.5 vers WAS 5), les
livrables seront uniquement constitués d'une archive ear.
Ma question est : quid des fichiers properties (sachant q'on en a une
tonne...) ? les mettre dans le ear, ejb-jar, ou dans le war sachant qu'il
faut souvent les retoucher (en production) et qu'on aimerait le faire sans
avoir à relivrer un ear... ou bien les externaliser?
En gros quelles sont les "best practice" dans ce domaine ou si ils n'en
existent pas, des retours d'expérience (avantages, inconvénients....)
On a à peu prés les mêmes conditions contraintes avec nos clients. On livre toujours un .zip qui contient les répertoires suivants: /app/deploy /app/util /jboss /doc
Dans le /app/deploy on a le .ear qui est configuré d'aprés les demandes du client (avec à l'intérieur tous les .conf, .properties). Si le client veut lui-même modifier la config, il a la possibilité de faire tourner un utilitaire qui lui refabrique une .ear avec la config voulue. Le /app/util contient les utilitaires pour transformer (à l'aide de xsl) le fichier de config .xml en nouvelle config. Clair ? Ca permet de livrer une release avec une conf et de donner au client les outils pour modifier lui-même sa conf sans avoir à refaire une release... A+ Stéphane
"Terry" wrote in message news:<409fc0e4$0$12730$...
Dans le cadre de la migration d'une application vers le standard J2EE 1.3 (migration qui s'accompagne de la migration de WAS 3.5 vers WAS 5), les livrables seront uniquement constitués d'une archive ear.
Ma question est : quid des fichiers properties (sachant q'on en a une tonne...) ? les mettre dans le ear, ejb-jar, ou dans le war sachant qu'il faut souvent les retoucher (en production) et qu'on aimerait le faire sans avoir à relivrer un ear... ou bien les externaliser?
En gros quelles sont les "best practice" dans ce domaine ou si ils n'en existent pas, des retours d'expérience (avantages, inconvénients....)
Merci d'avance
Terry
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé. Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-) ou pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans l'utilitaire dont tu parles, si tu pouvais m'éclairer...
En tout cas merci,
Terry.
"St?phane" a écrit dans le message de news:
On a à peu prés les mêmes conditions contraintes avec nos clients. On livre toujours un .zip qui contient les répertoires suivants: /app/deploy /app/util /jboss /doc
Dans le /app/deploy on a le .ear qui est configuré d'aprés les demandes du client (avec à l'intérieur tous les .conf, .properties). Si le client veut lui-même modifier la config, il a la possibilité de faire tourner un utilitaire qui lui refabrique une .ear avec la config voulue. Le /app/util contient les utilitaires pour transformer (à l'aide de xsl) le fichier de config .xml en nouvelle config. Clair ? Ca permet de livrer une release avec une conf et de donner au client les outils pour modifier lui-même sa conf sans avoir à refaire une release... A+ Stéphane
"Terry" wrote in message news:<409fc0e4$0$12730$...
Dans le cadre de la migration d'une application vers le standard J2EE 1.3
(migration qui s'accompagne de la migration de WAS 3.5 vers WAS 5), les livrables seront uniquement constitués d'une archive ear.
Ma question est : quid des fichiers properties (sachant q'on en a une tonne...) ? les mettre dans le ear, ejb-jar, ou dans le war sachant qu'il
faut souvent les retoucher (en production) et qu'on aimerait le faire sans
avoir à relivrer un ear... ou bien les externaliser?
En gros quelles sont les "best practice" dans ce domaine ou si ils n'en existent pas, des retours d'expérience (avantages, inconvénients....)
Merci d'avance
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé.
Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-) ou
pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans
l'utilitaire dont tu parles, si tu pouvais m'éclairer...
En tout cas merci,
Terry.
"St?phane" <sfructus@vocognition.com> a écrit dans le message de news:
ced10969.0405110547.2fb67fdb@posting.google.com...
On a à peu prés les mêmes conditions contraintes avec nos clients.
On livre toujours un .zip qui contient les répertoires suivants:
/app/deploy
/app/util
/jboss
/doc
Dans le /app/deploy on a le .ear qui est configuré d'aprés les
demandes du client (avec à l'intérieur tous les .conf, .properties).
Si le client veut lui-même modifier la config, il a la possibilité de
faire tourner un utilitaire qui lui refabrique une .ear avec la config
voulue.
Le /app/util contient les utilitaires pour transformer (à l'aide de
xsl) le fichier de config .xml en nouvelle config.
Clair ?
Ca permet de livrer une release avec une conf et de donner au client
les outils pour modifier lui-même sa conf sans avoir à refaire une
release...
A+
Stéphane
"Terry" <terence.soussan@free.fr> wrote in message
news:<409fc0e4$0$12730$636a15ce@news.free.fr>...
Dans le cadre de la migration d'une application vers le standard J2EE
1.3
(migration qui s'accompagne de la migration de WAS 3.5 vers WAS 5), les
livrables seront uniquement constitués d'une archive ear.
Ma question est : quid des fichiers properties (sachant q'on en a une
tonne...) ? les mettre dans le ear, ejb-jar, ou dans le war sachant
qu'il
faut souvent les retoucher (en production) et qu'on aimerait le faire
sans
avoir à relivrer un ear... ou bien les externaliser?
En gros quelles sont les "best practice" dans ce domaine ou si ils n'en
existent pas, des retours d'expérience (avantages, inconvénients....)
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé. Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-) ou pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans l'utilitaire dont tu parles, si tu pouvais m'éclairer...
En tout cas merci,
Terry.
"St?phane" a écrit dans le message de news:
On a à peu prés les mêmes conditions contraintes avec nos clients. On livre toujours un .zip qui contient les répertoires suivants: /app/deploy /app/util /jboss /doc
Dans le /app/deploy on a le .ear qui est configuré d'aprés les demandes du client (avec à l'intérieur tous les .conf, .properties). Si le client veut lui-même modifier la config, il a la possibilité de faire tourner un utilitaire qui lui refabrique une .ear avec la config voulue. Le /app/util contient les utilitaires pour transformer (à l'aide de xsl) le fichier de config .xml en nouvelle config. Clair ? Ca permet de livrer une release avec une conf et de donner au client les outils pour modifier lui-même sa conf sans avoir à refaire une release... A+ Stéphane
"Terry" wrote in message news:<409fc0e4$0$12730$...
Dans le cadre de la migration d'une application vers le standard J2EE 1.3
(migration qui s'accompagne de la migration de WAS 3.5 vers WAS 5), les livrables seront uniquement constitués d'une archive ear.
Ma question est : quid des fichiers properties (sachant q'on en a une tonne...) ? les mettre dans le ear, ejb-jar, ou dans le war sachant qu'il
faut souvent les retoucher (en production) et qu'on aimerait le faire sans
avoir à relivrer un ear... ou bien les externaliser?
En gros quelles sont les "best practice" dans ce domaine ou si ils n'en existent pas, des retours d'expérience (avantages, inconvénients....)
Merci d'avance
sfructus
En fait l'utilitaire que fait tourner le client est juste un .bat qui lance lui-même ant. Dans le build.xml, on a des target (dans des tag java) qui lance "org.apache.xalan.xslt.Process" avec en entrée les fichiers xsl et en sortie des fichiers de config qui seront à la fin inclus dans le .ear. C'est juste de la transformation, le plus dur étant d'écrire le .xsl A+ Stéphane "Terry" wrote in message news:<40a142cc$0$421$...
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé. Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-) ou pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans l'utilitaire dont tu parles, si tu pouvais m'éclairer...
En tout cas merci,
Terry.
En fait l'utilitaire que fait tourner le client est juste un .bat qui
lance lui-même ant.
Dans le build.xml, on a des target (dans des tag java) qui lance
"org.apache.xalan.xslt.Process" avec en entrée les fichiers xsl et en
sortie des fichiers de config qui seront à la fin inclus dans le .ear.
C'est juste de la transformation, le plus dur étant d'écrire le .xsl
A+
Stéphane
"Terry" <terence.soussan@free.fr> wrote in message news:<40a142cc$0$421$636a15ce@news.free.fr>...
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé.
Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-) ou
pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans
l'utilitaire dont tu parles, si tu pouvais m'éclairer...
En fait l'utilitaire que fait tourner le client est juste un .bat qui lance lui-même ant. Dans le build.xml, on a des target (dans des tag java) qui lance "org.apache.xalan.xslt.Process" avec en entrée les fichiers xsl et en sortie des fichiers de config qui seront à la fin inclus dans le .ear. C'est juste de la transformation, le plus dur étant d'écrire le .xsl A+ Stéphane "Terry" wrote in message news:<40a142cc$0$421$...
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé. Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-) ou pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans l'utilitaire dont tu parles, si tu pouvais m'éclairer...
En tout cas merci,
Terry.
Terry
Bon, j'ai pas trop saisi mais c est pas grave, je te remercie beaucoup pour ton aide. L'idée est bonne, je saurais m'en inspirer .. enfin j'espère ;-)
@+, Terry
"St?phane" a écrit dans le message de news:
En fait l'utilitaire que fait tourner le client est juste un .bat qui lance lui-même ant. Dans le build.xml, on a des target (dans des tag java) qui lance "org.apache.xalan.xslt.Process" avec en entrée les fichiers xsl et en sortie des fichiers de config qui seront à la fin inclus dans le .ear. C'est juste de la transformation, le plus dur étant d'écrire le .xsl A+ Stéphane "Terry" wrote in message news:<40a142cc$0$421$...
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé. Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-) ou
pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans l'utilitaire dont tu parles, si tu pouvais m'éclairer...
En tout cas merci,
Terry.
Bon, j'ai pas trop saisi mais c est pas grave, je te remercie beaucoup pour
ton aide. L'idée est bonne, je saurais m'en inspirer .. enfin j'espère ;-)
@+,
Terry
"St?phane" <sfructus@vocognition.com> a écrit dans le message de news:
ced10969.0405120414.43b0ab23@posting.google.com...
En fait l'utilitaire que fait tourner le client est juste un .bat qui
lance lui-même ant.
Dans le build.xml, on a des target (dans des tag java) qui lance
"org.apache.xalan.xslt.Process" avec en entrée les fichiers xsl et en
sortie des fichiers de config qui seront à la fin inclus dans le .ear.
C'est juste de la transformation, le plus dur étant d'écrire le .xsl
A+
Stéphane
"Terry" <terence.soussan@free.fr> wrote in message
news:<40a142cc$0$421$636a15ce@news.free.fr>...
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé.
Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-)
ou
pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans
l'utilitaire dont tu parles, si tu pouvais m'éclairer...
Bon, j'ai pas trop saisi mais c est pas grave, je te remercie beaucoup pour ton aide. L'idée est bonne, je saurais m'en inspirer .. enfin j'espère ;-)
@+, Terry
"St?phane" a écrit dans le message de news:
En fait l'utilitaire que fait tourner le client est juste un .bat qui lance lui-même ant. Dans le build.xml, on a des target (dans des tag java) qui lance "org.apache.xalan.xslt.Process" avec en entrée les fichiers xsl et en sortie des fichiers de config qui seront à la fin inclus dans le .ear. C'est juste de la transformation, le plus dur étant d'écrire le .xsl A+ Stéphane "Terry" wrote in message news:<40a142cc$0$421$...
Cette solution m'a l'air très élégante, je n'y avais pas du tout pensé. Merci beaucoup pour le tuyau.
En revanche, je sais pas si c'est violer des secrets de fabrication ;-) ou
pas, mais je n'ai pas très bien compris ce que vient faire le xsl dans l'utilitaire dont tu parles, si tu pouvais m'éclairer...
