Reprise du message précédent :

tu peux vérifier isLightweightComponent(button) stp ? j'ai comme un doute.

Me renvoi false, mais tu m'as mis le doute et j'ai jeté un œil sur la javadoc de isLightweight():

Edit : même chose en virant le Look & Feel.
Redit : le problème ne vient peut-être pas du lightweight ou pas, j'ai parlé de ça comme j'aurais pu parler des pommes que j'ai mangé ce matin. L'idée est de savoir pourquoi (ou comment si c'est normal) un click sur un bouton ne se propage pas jusqu'à la fenêtre parente. Si le seul moyen est d'ajouter un listener sur les composants, je le ferais, mais je pensais que quelque chose d'équivalent à l'event bubbling existait.

Est ce qu'il y a moyen de migrer un projet struts en douceur vers spring-mvc ?

la partie qui me trouble c'est concernant le dispatchServlet

comment faire coexister les deux

edit: bon je pense qu'il suffit de déclarer une autre racine de mapping, genre /smvc/*.do

autre truc pas clair, mon appli avait déjà un fichier de beans spring spring.xml
 
là le dispatchservlet à besoin d'un autre fichier, mais est-ce qu'ils sont censés être séparés comme ça ou commun ?

Médiateur ?

Je maîtrise pas trop, mais je pense que l'événement à été consommé.

 
Je cherchais du buit-in, en soit, un pattern là dessus ne m'apportera rien (de plus que l'ajout des listeners sur les composants qui rechignent à propager).
 

 
Oué, je suis fucké. Je trouve le principe de bubbling pas con pour ce genres de cas, je suis étonné que ça n'existe pas en Swing. (Et je suis pas au bureau là, mais je trouve quand même curieux que mes composants soit détectés heavyweight)
 

https://jaxb.dev.java.net/guide/Mig [...] aSE_6.html
bordel de merde, sous mac y'a pas de tools.jar, tout est directement dans rt.jar, ce qui veut dire que xjc est endorsed par défaut

La deuxième assertion ne passe pas, débatez.

J'vois pas trop ce qu'il y a à débattre.

bi.compareTo(negSixtyFour) < 0 c'est équivalent à bi < negSixtyFour, or aux dernières nouvelles c'est encore moins le cas que pour sixtyFour

Question webstart. J'ai une appli qui se charge sur certains postes, mais pas d'autres... Sans arriver à trouver de dénominateur commun. Sur un intranet, même configuration proxy (d'ailleurs même comportement quand je passe en connexion directe), même version de Java. Quand ça suxx, ça lance une failed to download machinchose sur l'un des jars de dépendances.
 
Ça parle à quelqu'un ?

oui on en a deja parlé ici. bonne lecture

trouvé: http://forum.hardware.fr/hfr/Progr [...] m#t2012283

 
Oui, on remarque d'ailleurs que j'ai participé au débat    
Là c'est différent, puisque connexion directe ne fonctionne pas (c'est ce qui était sortie comme solution pour elmo au problème que tu link).
 

Bonjour,
 
J'utilise l'API d'un programme, et en appellant une methode, j'obtiens ceci:
 

 
Comment je sais quel .jar inclure dans mon projet ?

A priori inclure Xalan de chez Apache paraît pas mal

Ben c'est ce que je pensais, je l'ai DL et ajouté en jar externe et adapté le ClassPath et il me refait le coup

En fait, l'arborescence du xalan.jar que j'ai ne correspond pas a org/apache/xalan/xpath/xml/XMLParserLiaison
XMLParserLiaison ne s'y trouve pas
 
'vais voir des anciennes versions

Le contenu de ce message a été effacé par son auteur

Bon, collectivement, on pense quoi de l'auto-(un)boxing ?  
 
Moi je déteste (-ais), mais je pense pas avoir de bonne raison.

C'est le broll pour les comparaisons et les pool donnent des comportements inattendus tant que tu ne connais pas la pool policy de chaque type.

Tu pourrais élaborer, concernant les comparaisons ?
Et... les pool de quoi ?

moi j'aimais bien avant de tomber là dessus :

class Pwet {
    private Integer attribut;
 
    public int getAttribut() {
        return attribut;
    }
 
    public static void main(String[] args) {
        Pwet p = new Pwet();
        int attributVal = p.getAttribut(); //==> NullPointerException
    }
}

le comportement est évidemment logique, mais quant tu as une NPE sur p.getAttribut(), tu t'attends plus à ce que p soit null, et non pas le membre attribut que tu essayes de récupérer.

P.S. : on est bien d'accord que ce code est foireux, c'ets pour montrer l'exemple rapidement

Float pointFive = .5f;
Float alsoPointFive = .5f;
System.out.println(pointFive == alsoPointFive);

Ça donne false, et même si au final ça suit une certaine logique (puisque l'autoboxing renvoi des objets), on s'attend pas à ça la première fois. C'est pas grave, on a compris, donc on passe à :

Integer thousand = 1000;
Integer alsoThousand = 1000;
System.out.println(thousand == alsoThousand);

qui renvoi false, et là on se dit qu'on a capté, jusqu'à ce que

Integer one = 1;
Integer alsoOne = 1;
System.out.println(one == alsoOne);

renvoie true, puisque l'autoboxing cache les entiers entre -127 et 127 (le fameux pool dont je parlais). C'est assez merdique tout ça.

Edit : sur le principe, on devrait bien entendu utiliser equals() plutôt que l'opérateur, mais même amalgame (à mon sens moins connu) que pour String.

Bof, il est dit a aucun moment que les instances creees par autoboxing devraient etre toutes toujours les memes ou toujours differentes, en plus c'est quelque chose clairement indique dans la doc, j'ai envie de dire que c'est meme pas lie a l'autoboxing mais plus generalement a Integer.valueOf(int) qui a le meme comportement:
 

 
Le vrai probleme vient surtout a mon avis du fait qu'il y ait des types primitifs et pour la NPE j'ai envie de dire que ca vient du concept de null qui est tres chiant aussi IMO. Des corner cases y en a plein et ca ce n'est qu'un parmi d'autres  

On est d'accord, ce sont des comportements documentés. Mais t'en connait beaucoup des langages où les numériques objets n'ont pas un comportement de primitif avec l'opérateur de comparaison ? Ca induit de méchantes erreurs chez les débutants, et j'ai jamais eu besoin de comparer des numériques par référence.

Float pointFive = .5f;
Float alsoPointFive = .5f;
System.out.println(pointFive == alsoPointFive);

Integer thousand = 1000;
Integer alsoThousand = 1000;
System.out.println(thousand == alsoThousand);

Integer one = 1;
Integer alsoOne = 1;
System.out.println(one == alsoOne);

ok, ouais, je vois le genre de mauvaises surprises (c'est pas l'autoboxing qui cache les entiers, c'est Integer et ses valueOf ...

 
ouais.. que ça soit documenté, ça aide pas les erreurs de débutant.. ou d'innatention.. et effectivement si j'utilise l'auto boxing, i.e si je vire les warnings dans mon ide, j'vais pas tjs aller voir si l'attribut a été initialisé en primitif ou en objet... mais ça rend le code tellement moins verbeux que c'est tentant de les utiliser, quoi ..

Au final, l'autoboxing c'est bien quand c'est complètement transparent (que le langage boxe les types natifs quand tu appelles des méthodes dessus, mais que l'utilisateur n'a pas de moyen simple de faire la différence entre une valeur boxée et une valeur unboxée (c'est un détail d'implé), mais c'est pas du tout du tout le cas en java, et donc ça te pête régulièrement dans les dents.

en clair, le soucis, c'est qu'il y est besoin de auto/un/boxing.
 
s'il n'y avait pas de types primitifs, ça serait encore plus mieux. Et Java aurait été 100% Object. Tout ça c'est la faute à Oracle.
 
non?

À Sun

c'est la faute à personne, le language est vieux ..

Pull the other one, it's got bells on.

Ca depend de la definition de "100% Objet" </enculage-de-mouche>

Quelle que soit la définition, tu peux difficilement argumenter que java y corresponde.

Il y avait déjà des platrées de langages sans ce genre de trucs quand il est sorti.

ouais enfin j'imagine qu'il y a des raisons, genre perfs, qui ont été prises en compte a l'epoque (ou les applets etaient une vraie target, ou les machines avaient moins de resources, et ou la vm etait moins avancée)

Dite les gens, vous faites comment pour gérer les accès concurrent en sauvegarde dans une DB?
Pour l'instant je mets des champs lastModification un peu partout, ca marche pas mal mais ca me gave mnt.
 
Par exemple, on a une appli web basique avec des fiches sauver dans une DB.
La secrétaire A commence à éditer la fiche Z, pendant qu'elle tape et avant qu'elle clique sur sauver, sa collège, la secrétaire B, ouvre justement la meme fiche Z.
 
On n'a pas le droit de bloquer les fiches et dire à B "non tu peux pas ouvrir la fiche Z car qqun l'a deja ouverte" ou "tu peux l'ouvrir mais pas la modifier", sinon ca serai trop facile.
 
La secrétaire A à fini ses modifications et sauve la ficher Z.
Lorsque la secrétaire B veut sauver ses modifs (apres A), un message la prévient que qqun à modifié la fiche Z, lui dit gentiment que ses modifications sont perdu    et que la fiche Z va se rafraîchir.
 
Pour faire ca, j'ai mis un champs timestamp LastModification à la class fiche, et juste avant de sauver, dans la même transaction, je regarde si lastmodification de mon objet en mémoire correspond bien à celui dans la DB. Si oui, je sauve, sinon, qqun à modifié entre temps, je sauvegarde pas et je rafraîchis.
 
J'ai testé avec 5 utilisateurs dans la meme piece en cliquant à 5 en meme temps sur sauver, ca marche bien (enfin ca en envoie 4 sur les roses mais c'est normal)
 
Mais j'ai besoin de mettre un champs timestamp dans chaque class et à la fin c'est pas très pratique.
 
y'a pas qqch de plus simple?
 
merci