Reprise du message précédent :

?
 

 
Le plugin de ton fournisseur, il est packagé comment ? C'est quoi le nom du fichier ?
 

 
Problème de path oui, certainement dû à la manière dont tu package ta classe et dont tu déploie ton package. CF ma question précédente, et dis nous en plus sur ta tentative : ta classe est dans un Jar tout bête ? Elle est bien chargée par ton conteneur ?
 

t'es sur qu'il est pas activé par un <activation> dans ton pom, justement ?

<profile>
            <id>postgresql-8.4</id>
            <dependencies>
                <dependency>
                    <groupId>postgresql</groupId>
                    <artifactId>postgresql</artifactId>
                    <version>${postgresql.8.version}</version>
                </dependency>
            </dependencies>
        </profile>

 
Testé avec Maven 2.2.1 (help plugin version 2.2.1-SNAPSHOT) et Maven 3.0.3 (help plugin version 2.2 ?!?).

meme conditions ici, la diff etant que le profil est déclaré dans un parent ...

Le profile foo n'existe pas

Le profile enable-clover est déclaré dans un parent:

Salut,
 

Il est package dans le meme jar ou il y a l'interface.
En gros les classes c'est:
x.y.z.interfaces.AuthenticationInterface
x.y.z.interfaces.impl.LDAPExternalAuthenticationPlugin
 

Oui jar tout bidon, fait a la main meme (zip+rename).
J'ai aucune idee de comment je peux verifier si elle est chargee. J'ai juste redemarre le serveur.
 
Mais cherchez pas plus loin pour le moment, en allant verifier comment le plugin existant est package, j'ai trouve un readme dans la racine du jar qui raconte qu'il faut mettre son plugin dans un autre jar bien precis (qui existe deja bien sur, je suppose qu'utiliser n'importe lequel deja existant ferait aussi l'affaire).
 
J'vais faire d'autres essais, merci pour le coup de main.

 
Effectivement, testé à l'instant, si le profil est déclaré dans un POM parent il n'apparait pas dans la liste, même avec déclaration d'usage explicite.
Bug report?
 

Ouais, les bug reports chez maven c'est souvent décourageant mais bon, ... Si j'oublie pas...

Euh... chez moi il apparait bien (maven 3.0.4)

merde. t'as un 2.2 sous le coude ? Je crois que j'ai un 3.x je tenterai demain.

Hum, non, pas de 2.2 au boulot (firewall a la con). Je peux tester sur un 2.2 chez moi ce soir si je n'oublie pas.

http://openjdk.java.net/jeps/182

c'est toujours bon à savoir, merci.
 
cela étant, on a toujours un JBoss 3.2.1 qui tourne avec une 1.4.2 en production... dire que ses jours sont comptés depuis 3 ans

JBoss depuis 3, 2, 1, 0
 
edith : si la machine crame, concrètement, vous avez le moyen de réinstaller un 1.4 quelque part ?

ouaish, elle cramera pas    
 
virtualisée, backupée, les sources au chaud, le JDK au chaud, ...
 
c'est maîtrisé    
 

Générer un hash password + salt :
 

final String banana = password + salt;
MessageDigest md = MessageDigest.getInstance("SHA-256" );
byte[] digest = md.digest(banana.getBytes());

 
?
Ou là non vraiment, on n'utilise pas les classes du JDK pour un truc comme ça ?
Ou là non vraiment, implémentation trop triviale ?

Là non, on n'utilise ni les classes du JDK, ni une implémentation aussi triviale.
 
On n'utilise ça: http://www.mindrot.org/projects/jBCrypt/ (qui existe aussi dans spring security, si tu l'utilises dans ton projet).

Dispo sur le central, utilisation simpliste

Dispo sur le central, utilisation simpliste
Pas d'activité, dernière évocation d'une 0.4 en 2011
 
Je vais partir là dessus (en googlant un peu, ça m'a l'air d'être le consensus), merci

'tention avec les digest, ça prend au format hexa en entrée :  
 
http://stackoverflow.com/questions [...] ncy-castle

Rhaaa! mais combien de fois devra-t-on le répéter:
 
POUR ENCODER UN PASSWORD ON N'UTILISE PAS UNE FONCTION DE HASHING CLASSIQUE!!!
 
Pourquoi? Parce qu'elles sont concues pour être rapide et que c'est justement ce un des points que l'on veut éviter pour la protection des password.

Pour encoder un password, on utilise une fonction pour encoder un password. En fait.

ou un simple rot13

Can't tell if serious or ignorant

On a une appli JBoss qui tourne sur une JVM 32b, l'OS est un Windows 2003 Serveur 64b.
 
Ce matin, un correctif de sécurité a été diffusé (j'attends qu'on m'en donne la teneur, pour l'instant j'ai pas plus d'info) et au redémarrage, l'appli n'a jamais voulu se lancer, 'Could not reserve enough space for object heap'.
 
J'ai ajouté dans l'urgence un -XX:MaxHeapSize=256m et ça roule, mais il n'y a eu strictement aucune modif sur notre appli, ni aucune mise à jour de la JVM.
 
D'où ma question : qu'est ce qui point de vue système aurait pu causer une gestion différente du heap ?

fix de sécurité JBoss ou JVM (ou Windows ?) ?
est-ce possible que la valeur par défaut de la XMX ait été rabotée ?

Nope, les modifications qui ont eu lieu sont des correctifs MS via Windows Update Agent.
 
Pour le XMX, qu'est ce qui sur le système aurait pu modifier la façon dont cette valeur est calculée ?
 
Je précise qu'avant la modif, je ne spécifiais pas le MaxHeapSize donc effectivement, si la valeur par défaut à changé (sans modif de la JVM), il y a de fortes chances que ça vienne de là.
 
Edit : Si -Xmx et -XX:MaxHeapSize sont bien équivalent, alors oui, -Xmx était défini (à hauteur de 768M, pour un Xms à 256). Du coup, ça impliquerais que soudainement, le système ne pouvait plus réserver l'espace contigu demandé, reste à savoir pourquoi.

 
Je suspecterait l'antivirus qui mettrait le process java.exe en sandbox avec des effets de bord limite.
Sinon, suspicion du mode de compatibilité windows qui se lancerait automatiquement pour l'appli

 
J'ai édité entre temps.
Je ne crois pas qu'il y ai eu de changement au niveau des règles d'AV, mais je garde la piste sous le coude.
 

bon courage, n'oublie pas que windows dispose d'un safe mode

cas vécu, une machine virtuelle s'est vue raboter sa RAM allouée lors de son reboot par erreur de manip.
 
La JVM ne bootera en effet que si elle a suffisamment de RAM (nécessaire=XMX+PermGen+broutilles)
 
Mais cela ne concorde pas avec ta modification de Heap à 256Mb.
Ou alors, un process bouffait tout et ta modif est un coup d'épée dans l'eau car entretemps, le système avait rendu de la RAM ?

Tu as une option explicite -server sur la commande java qui lance ton truc? Sinon le mode par défaut dépends de l'os et peut-être que le correctif l'a flingué?

à propos de problèmes a la con. Un build avec des tests d'intégration et cargo. marche bien avec un port http hardcodé. Vu qu'on commence a avoir plusieurs projets qui font ça, ça clache dans tous les sens, donc build-helper:reserve-network-port à la rescousse. Ca marche bien localement. Sur Hudson, l'appli (web) part en OOM:PermGen quand le plugin est enablé . Ca parle à qqun ?

 
La chronologie, c'est -Xmx768M => mise à jour OS => 'Could not reserve enough space for object heap'
Donc soudainement, plus assez de mémoire lors de l'allocation du tas. En  réduisant à -Xmx256M ça passe.
 
Le heap requiert une zone continue de mémoire, apparemment ça peut poser problème sur un système 32b ou sur une machine avec peu de RAM, mais je ne suis dans aucun de ces cas.
 
Si ça ne s'était produis qu'une seule fois, j'aurais eu tendance à être d'accord avec ton hypothèse, mais on a tenté plusieurs reboot avant de modifier le XMX, avec toujours le même phénomène.
 
Fun fact pendant que j'y suis : on n'arrive évidemment pas à reproduire l'ano sur le serveur de test, même machine physique et mêmes patchs passés
 

 
Ha oui, -server n'est pas dans les options JBoss par défaut  
J'aurais peut-être pu penser à vérifier ça  
 
Les valeurs par défauts sont différentes, on peut trouver ça quelque part ?

Pour les valeurs par défaut (si jvm récente, pas testé sur une 1.6)

 
Bon à savoir
 

Alors là, y'a un truc...
 
Sur mon poste de dev, en ouvrant un projet Intellij qui est loin d'être colossal :
 

 
C'est douteux comme coïncidence à 1 semaine d’intervalle...

z'auriez pas reçu un update système dans votre dos qui aurait baissé les params mémoire de votre OS ?

ça c'est de la bonne came...

2 Hosts Linux 64bits (même noyau, version...), 2 JDK Sun 'server' 32bits (même version), même command line pour booter.

sur la machine la moins musclée "PermGen", sur la plus musclée "PS PermGen".

'tain.

 
question jpa / orm  
 
je suis à la recherche d'un article, ou d'un blog qui exposeraient des pattern pour spécifier proprement les collections lazy que je veux fetcher de ma base  
 
par exemple : j'ai ma classe livre et plusieurs collections 'review/commentaires/dispos/séries/traductions'
 
et suivant certains cas, je veux pas tout retourner, d'autre fois seulement une selection précise de ces catégories  
 
comment vous faites vous ?