Discussion :

[malkomad]

Bonjour a tous

Voila, j'ai fait ma p'tit appli ( avec votre aide deja :p pour qqes elements ) qui utilise des fichiers textes et travaille dessus ( historisation des comptes rendus d'appels etc ... )
ce qui fait que le repertoire de travail doit etre en dehors de mon appli executable (.jar)...
hum ok , je peux toujours resoudre cela en travaillant dans doc'nsetting ou autre, mais l'application doit etre portable puisqu'elle est fournie sur un reseau, et l'utilisateur doit pouvoir lancer cette appli depuis le reseau entreprise et ce quelque soit son poste de travail, du coup la sauvegarde de ces fichiers sur le poste est impossible.

Ma derniere possibilite et donc idee est d'en faire un auto extractible, comme ca mon historisation se fait dns le repertoire de travail de mon application ( donc sur une partition appartenant au reseau ).
Bon ... ok ... il existe des outils pour ce faire, mais la c'est ma curiosite qui me gratte.
la commande jar permet de decompresser les archives ( jar x ... ) , oui c'est bien mes mes postes clients n'ont pas la commande jar...

ma question : comment pourrais-je m'arranger pour inclure le minimum des classes necessaires a l'extraction jar dans mon appli, de facon a le rendre auto extractible meme sur un poste ou les zip et autre rar sont prohibes ?

juste un aiguillage dans mes recherches me serait bien precieuse.
j'ai trouve qqes sources de prog faisant cela, mais uniquement sous divers-unix, ce qui exclu donc le reseau d'entreprise sur lequel je souhaite developper cette petite appli.

xml serait il necessaire a ce type d'operation ? ( j'y connais dalle ! snif )

d'avance merci de votre patiente.

[phantomass]

Je ne comprends pas ton problême.
Tu as une appli qui est distribué sur un reseau et en toute logique est donc utilisé par n personnes.
Chaque personne peut donc modfier un(des) fichiers et ces modifications doivent être accessible par les autres utilisateurs de l'appli ?
J'ai bon ?

[malkomad]

Non l'architecture est plutot inverse en fait ...
chaque utilisateur, sus loggé a une "partition personnelle" dans le reseau qui lui est attribue, d'ou il acccede depuis n'importe quel poste.
Dans cette partition doit se trouver l'historique de ses comptes rendus, avec le repertoire applicatif contenant le programme, qui lui n'est pas (encore ) en reseau .
De plus un fichier config lui est modifiable et de preference range avec le repertoire du programme (j'aime pas polluer ou tripatouiller dans les os ou leur "doc'n settings" )

mm ... <reflechit en repondant ...> a moins de mettre l'appli vide ( de reglages) sur la partition commune, et ne garder que la partie settings sur la partition perso.
Sauf que bien sur, pour debuggage, cette appli ne fonctionnera pas chez moi ... et pas partout ...si y'a un bug reseau tout est mort ...

Actuellement, l'outil n'est qu'en developpement et les terminaisons d'installation sont encores a debattre en realite. Applet ? Apli en dur ? ou simple jar autoextractible ? je pencherais plus facilement pour l'instant sur le jar autoextractible car en cas de panne reseau il est toujours telechargeble rapidement sur le net, il suffit de mettre a jour les derniers comptes rendus qd le reseau est revenu.Il n'est pas prevu de base de donnee, le but de ce truc est d'etre leger.

J'en suis reelement a l'etude de faisabilite en fait ... et suis assez curieux de savoir si je dois me recogner les algo de compression ou si des classes java recuperables sur une jre permettent de faire ca comme une connexion ODBC ... en gros et si oui, quel chemin dois je prendre pour entammer mes recherches :p .

Ou alors je suis un gros naze et il est possible de modifier des fichiers dans une archive ( fichiers de type texte hein ! ).
Si c'est possible faut me le dire, j'irai me cacher sous le lit en criant "pas taper ! pas taper !"

Je veux pas me perdre l'utilisateur dans des reglages de path ou autre truc effrayant pour certains, l'appli a deja ses contraintes par essence.Donc un double click doit suffire pour rendre l'appli executable ..en gros ... avec l'historique dans le repertoire source a cote du rep bin et images ...

Y'a p'tet un contresens dans l'idee de l'architecture, vu le contexte, mais mes cours sont loins ^^ et je me degrippe justement :p

Maditativement.

[phantomass]

Je dois être "bouché" mais je ne saisis pas ton problème, ou du moins est-il mal posé ?
Ton appli (peu importe la stratégie de déploiement) travaille sur des fichiers qui sont dans un répertoire réseau spécifique à un user.
Les données ne sont donc pas mutualisées par utilisateur, par contre un utilisateur peut utiliser n'importe quel poste de travail ?
Si c'est le cas et que tu souhaites éviter l'usage généralisé d'une base de données :
- Soit l'utilisateur doit indiquer explicitement quand il utilise l'appli le nom du répertoire réseau de travail lui correspondant.
- Soit ton appli charge systématiquement un fichier CENTRALISé sur le réseau (éventuellement crypté) qui contient l'url réseau du répertoire ou se trouve les fichiers de travail en fonction de l'utilisateur.
Concernant le déploiement t'as la possibilité d'utiliser javawebstart. L'avantage serait qu'à chaque modification/évolution de ton appli ou du paramétrage elle sera mise à jour automatiquement du coté du poste client.

Dans tout les cas tu n'a pas à bidouiller tes jars pour régler ton problème

[malkomad]

mm, en effet, l'utilisation du webstart serait une bonne solution, afin d'aller chercher les fichiers courants sur lesquels l'utilisateur va travailler.
Du coup je n'ai plus besoin comme tu dis de trifouiller mon jar...
Cela exclut donc l'utilisation d'un auto extractible... en effet...
ce qui est pas mal du tout, simplement par defaut l'appli irait chercher sur le reseau le ou les fichiers necessaires a l'utilisateur et en cas de reseau indisponible sauvegarderait directement les fichiers crees de la session sur le poste en attendant le retour du reseau.

Bon bah j'ai plus qu'a me manger les qqes tutoriaux du java webstart que je ne connais absolument pas

bah merci de ton aide dans cette reflexion :p , j'ai deja une idee plus concise du comment ...
Maddictivement.