Reprise du message précédent :

Ba non justement, c'est l'intérêt de passer par une factory, c'est que tu te fous de l'implé. Si je dois mater la conf pour savoir ce que veut le user directement dans mon code appelant, autant instancier direct les implés et foutre la factory à la benne

Oui, j'avais pensé à grouper mais spareil, je trouvais pas ça très malin. A bien y regarder, c'est p'têt ce qu'il y a de moins con

Possible, j'ai pas regardé, j'avais le souvenir que le compilo grognait, donc p'têt c'est juste un warning dans mon Eclipse Chu un peu casse-couille avec les warnings, j'aime pas en avoir.

Voilà, comme dit ci-dessus. J'pense je vais partir là-dessus si j'ai pas plus d'inspiration pendant le déjeuner

Merci bien les gros

 
2. perso, j'ai vu deux facons :  
* une base de données (ou fichier) qui les liste
* un répertoire qui contient des jars, avec les infos nécéssaire au chargement dans le manifest de chaque jar (avec bien sur 1 jar => 1 plugin)

 
La deuxième étant commande parce qu'elle permet de désinstaller le plugin à l'arrache.

et la premiere étant chouette parce que tu peux gérer des droits plus fins.
bref, comme d'hab, ca dépend des cas

le warning, ça devait être le contraire : tu devais vouloir catcher une exception jamais lancé.
genre  
 

try {
            String str = "Salut";
        } catch (IOException ex) {
            ex.printStackTrace();
        }

 
par contre,  

try {
            String str = "Salut";
        } catch (Exception ex) {
            ex.printStackTrace();
        }

ne génère aucun warning/error, c'est spécial pour Exception ?    
 
 

logique, RuntimeException n'est pas checked, et tu ne sais pas quand tu vas t'en prendre une, et vu qu'une RuntimeException est une Exception, il est possible d'en prendre une sans qu'elle soit déclarée.

 
Demande à ta factory de créer une paire d'objet (ou un seul mais avec 2 rôles), le 1er est ton InterfaceStorage (qui throw des exceptions wrappées), le second est un handler d'exception (qui unwrap l'exception et fait le boulot de "parsing" de l'exception réelle et soit résouds le pb, soit traduit ça en exception moins générique connue de la partie commune du programme (genre TransientException, NonTransientException...) .

Ouais vala, le 2 se rapproche du principe du ServiceLoader de la 1.6.

Ah ouais, tout à fait

Bien vu Je vais creuser dans cette voie, en me gardant la possibilité de recracher l'exception d'origine sous le coude.
Merci

Pour ton histoire d'exception, perso, ce que je ferais :

• définir les infos dont j'ai besoin pour afficher un message d'erreur qui a du sens à l'utilisateur (ou pour toute autre traitement de l'erreur)
• créer un bean qui encapsule tout ça
• mettre une instance de ce bean dans l'exception, à charge de l'implementation de remplir les différents champs

POJO en forsse
Mais sinon c'est l'idée ouais, la factory possède cet objet et le passe aux implé qui l'appellent en cas d'exception ; le code appelant peut ensuite récup cet objet en cas de problème et roulorze.

moment lol :
 

 
en appelant .size() dessus avec de la reflexion.
 
Le meme code sur une ArrayList avec le même unique item dedans fonctionne, normal.

 
Il me semble que c'est la visibilité de ton inner class qui est trop faible dans ce cas, pas celle de .size() (et ouais, le message d'erreur est stupide).

la classe est effectivement privée. Comment je peux m'en sortir, sans parcourir manuellement la liste des classes mères ?

Ici c'est ce que je fais
 
Sinon http://java.sun.com/javase/6/docs/ [...] bject.html mais faut pas avoir un SecurityManager à coté...

Bon alors comme c'est ma journée "questions cons", je vous ai trouvé un bonus
 
J'ai une chaîne contenant une date au format ISO8601, par exemple : 2009-04-01T07:47:00.000-05:00
Bon. Y a tout plein de trucs pour parser ça, j'utilise Joda Time et j'en suis très content. En revanche, j'aimerais connaître la time zone (ou du moins l'offset) de ce truc. En l'occurrence, l'offset c'est -05:00, soit GMT-5, mais j'aimerais un truc qui me le parse sous forme d'entier genre "-5" (ou de float, si on veut jouer avec le Vénézuela et son -5.5 ).
Je pensais trouver ça dans les frameworks de date/time (donc le SimpleDateFormat du JDK ou Joda Time), mais je trouve rien. J'ai pas super envie de me taper une regexp mais s'il faut je le ferai ; zavez déjà eu vent de ça ?

une question frameworks WEB.

Je vais devoir réécrire une appli PHP en Java. L'archi du client emploie de base du Struts1. bof bof donc...

Je veux leur proposer une solution à base de frameworks plus souple et plus récents. J'aurais bien aimé leur vendre du Stripes, mais pas moyen, mon chef veut pas (manque de communauté, doc en mousse...) donc je m'oriente sur Spring-MVC. Puisqu'on va d'utiliser Spring (grosse communauté... oui c'est du cargo cult), autant ne pas rajouter une couche.

Sauf qu'en regardant Spring-MVC de plus près, j'ai du mal à voir ses avantages par rapport à Struts. Gros fichier de conf XML, aucune convention... J'ai regardé le tuto Spring MVC. Ce qui à l'air sympa, c'est la testabilité du truc, mais ça, comme d'hab', le client s'en tape. Je trouve pas trop d'arguments, à part que c'est moins vieux que Struts.

Z'avez des idées ? Merci !

Euh... au contraire, t'as du mal lire la doc! Y a pas mal de convention dans Spring MVC (pas autant que dans d'autres, mais quand meme), et la conf XML est largement reduite en utilisant les annotations.

j'ai oublié de précisé que c'est pour tourner sur du WAS5.1, donc JDK 1.4, donc pas d'annotations. Et effectivement, je ne vois pas les conventions dans cet infame XML :

<bean name="/priceincrease.htm" class="springapp.web.PriceIncreaseFormController">
        <property name="sessionForm" value="true"/>
        <property name="commandName" value="priceIncrease"/>
        <property name="commandClass" value="springapp.service.PriceIncrease"/>
        <property name="validator">
            <bean class="springapp.service.PriceIncreaseValidator"/>
        </property>
        <property name="formView" value="priceincrease"/>
        <property name="successView" value="hello.htm"/>
        <property name="productManager" ref="productManager"/>
    </bean>

ou alors il y a des subtilités qui m'échappent.

Bah deja si tu utilisais le CoC pour le mapping plutot que de declarer to bean, ca faciliterait deja les choses
 
Regarde du cote du chapitre 13.11 de Spring 2 (le 2.5 est java 5+ si je me souviens bien), apres y a moyen de voir plus en detail, mais t'es rarement obliger d'ecrire toute cette merde XML.

effectivement, on ne précise plus l'url, et quelques conventions sont là, mais bof, on a toujours ça :

<bean class="x.y.RegistrationController">
    <!-- inject dependencies as necessary -->
</bean>

   
 
 
C'est quoi l'interet d'essayer de pousser un framework moderne si c'est pour bosser dans une infrastructure archaique ?
Tu crois pas qu'il faudrait régler *ce* problème là en premier ?
 
 
(eh msieur, on pourrait pas utiliser Cocoa pour notre appli? Ouais enfin faut que ça tourne sur os9 )

<bean class="x.y.RegistrationController">
    <!-- inject dependencies as necessary -->
</bean>

Passer de 11 lignes à 1, c'est quand meme pas mal.

il manque toutes les dépendances, non ? les propriétés, tous ça, les validateurs.

sinon, effectivement, c'est pas moi qui choisi l'archi de mes clients, c'est vrai.

 
Comme je n'aimerais pas être à ta place... Mes dernières expériences avec WAS, ça a été un vrai cauchemar...

boarf... je commence à connaitre là.
 
mais on s'éloigne du sujet :
 
Spring-MVC, pourquoi c'est bien ?

 
je comprends pas bien ton approche là : si t'as déjà une expérience Struts dans la boite, pkoi obligatoirement vouloir changer de framework pour en mettre un que tu ne connais pas et dont tu ne vois pas l'intéret ?
 
j'aurais fait pareil à ta place : j'aurais mis Stripes...mais si tu peux pas, il peut etre sage de rester sur une structure que tu maitrises...

T'façon Stripes c'est un framework 1.5 (oui il y a une couche de compat' 1.4 via retrotranslator mais beurk, un peu) alors si t'as coincé en 1.4 je vois pas l'intérêt

Effectivement, y a aussi cette solution, c'est pas complètement déconnant...

L'intérêt était aussi d'avoir une plateforme plus pérenne.
Mais Struts1 semble encore maintenu, puisqu'une version est sortie en fin d'année dernière.
Admettons.

L'autre intérêt, c'était de voir un truc nouveau. Struts, j'en fait depuis 2002, j'en ai marre. Hibernate aussi, mais j'en ai pas marre, c'est différent. Et disons qu'Hibernate reste hype, alors que Struts a du plomb dans l'aile. Du coup j'aurais bien aimé voir autre chose. Et comme j'envisageais qu'on pourrait mettre du Spring pour faire de IoC, on aurait pu se servir de Spring-MVC, puisqu'on l'avait sous la main.

j'ai pas dit le contraire, et j'ai bien compris dés le début que pour Stripes, c'était malheureusement mort.

Je suggérerais la même chose que -- perso: commencer par passer en 1.5 (ou même en 1.6, 1.5 va être en fin de support dans 6 mois, autant passer direct à la suite) et bâtir le reste là dessus (Stripes, Guice, ...)

Ba en même temps, s'il contrôle pas l'environnement du client, ça va pas être facile Nous on a encore du WebSphere 6.0 (donc Java 1.4) en prod, la migration 6.1/Java 1.5 est prévue depuis un an, on devrait en voir le bout avant juin

mais moi aussi en fait. Mais le client ne veut pas passer à la version supérieur de WAS.
Et encore moins passer sur un autre serveur. J'ai les mains liées sur WAS 5.1 et Java 1.4.
y a pas de débat sur ce sujet.

Sinon, tu peux toujours aussi essayer de combiner Spring MVC avec XDoclet, qui devrait te generer tout le bouzin de IoC en XML, ce qui reduirait deja grandement ce que tu dois vraiment te taper comme config.

oui, moi non plus de toute façon
 
mais on va faire sans Spring, avec de belles factories à la mano, et du Struts pour le Web.
 
vala.

tu peux faire du pico si t'arrives à le connecter à ton environnement.

oui j'imaginais ça aussi
 
mais je sent que ça va encore manquer de doc/communauté/support pour mon super client

Bin côté support, WAS 5.1 c'est pas un peu mort ? Ou bientôt, en tout cas ?

j'ai pas dit que le client était logique non plus