Reprise du message précédent :
petite incompréhension de montée en charge.

une instance d'un cluster Glassfish = 1 JVM ("1.6 Hotspot -server" pour l'histoire)
le host: une machine virtuelle RHE 5 sur du quad CPU.

souci: l'instance monte en charge (~750 threads actifs sur 125K threads créés en un jour et demi) -> alerte CPU car la JVM prend 200% CPU.

où puis-je voir que la VM balance bien des native threads et non des green threads ? (je suppose que c'est native threads mais c'est pour être sûr)

pourquoi la VM ne prendrait-elle pas 400% CPU puisque 4 CPUs et que les autres process ne font (presque) rien, bottleneck de configuration qque part ?

 
Jette un oeil sur jvisualvm, y'a des infos détaillées sur les threads par process, et tu peux monitorer les VM distantes.
 

 
Supposition simpliste : le nombre max de native threads autorisé n'est pas suffisant pour justifier 400 % ?  
 

supposition naïve: parce que la VM (pas J) n'est pas autorisée a utiliser plus sur son host (JVM > VM > Host - le quad est sur l'host, mais tu ne dis/confirme pas que la VM en dessous peut tout manger)

bah oui, c'est par là que je le monitore... c'est de là que j'ai vu que j'avais ~750 threads en cours
 

pas complètement idiot, mais je m'attendrais plutôt qu'elle se déverse sur les 4 quand même.
 

en effet, je n'ai pas été complet: c'est la VM qui est un quad, le host (ESX) en contient 16 je crois.

sous wicket les fichiers template des pages html sont au même niveau que les pages java
./MaPage.java
./MaPage.html
 
lors du package c'est facile de mettre un filtre pour que tout soit au même niveau dans le WEB-INF/classes/
 
WEB-INF/classes/com.../MaPage.java
WEB-INF/classes/com.../MaPage.html
 
mais je voudrait l'avoir aussi dans target/classes
 
target/classes/com....../MaPage.java
target/classes/com....../MaPage.html
 
pour pouvoir déployer mon module sur tomcat par exemple ou sur weblogic, et développer sans avoir à packager un war
 
en modifiant à la main le buildpath je peux ajouter **/*.html au côtés de **/*.java , ou alors en le faisant par le GUI.
Mais par contre avec le plugin eclipse de maven, je parviens pas à créer un truc similaire
 
et j'ai ce problème avec groovy d'ailleurs, pour que les fichiers .groovy soient dans le buildpathh

mets tes .html dans le sous-répertoire sr/main/resources en respectant tes noms de packages.
 
ou configure le plugin maven-copy-resources (ou un nom du genre) pour prendre src/main/java comme répertoire de ressources

ça correspond pas mal à qu'est-ce que j'ai dit  
 

les templates toto.html vont de paire avec les toto.java
je préfère du coup ajouter **/*.html manuellement au build path après chaque eclipse:eclipse potentiel, que de les avoir dans des répertoires différents

il faudrait faire une commande maven à chaque fois, et c'est probable que éclipse les vire automatiquement à chaque rebuild

 
 
(also, t'es en train de faire un truc qui ne builde que DANS eclipse? Si c'est le cas, pourquoi tu te fais chier à utiliser Maven alors ?)

 
non tu n'as pas compris
le plugin maven eclipse sert à configurer .project et .classpath, donc des trucs propres à l'environnement eclipse
 
les fichiers html n'ont besoin d'être au même niveau dans l'arborescence du WEB-INF/classes que au runtime
là le truc était configuré de façon à ce que lors du package, le plugin maven war inclue correctement les fichier .html dans le classpath au niveau des .java, donc en déployant un war on a bien les fichiers ou il faut au runtime
 
mais moi je veux déployer sur weblogic par eclipse, par l'intermédiaire du plugin weblogic de eclipse, de façon à pouvoir modifier les fichier à chaud et surtout ne pas avoir à repackager un war à chaque fois que je veux tester une modif de code
 
donc il faut que les fichiers .html soient au bon endroit dans le classpath même avant le packaging
 

 
?
 
histoire de builder partout comme te le fait remarquer --

Je sais - mais tu devrais utiliser m2e à la place de ce truc antique (integration dans l'autre sens)

tu lis la doc sur la config des resources maven et on en parle plus.

 
le jour ou je réussirais à faire marcher correctement m2e je l'utiliserait, mais avant que ce jour magique n'arrive je me préfère m'en passer
 

 
tu me files une config qui marche l'enplacement exact dans la doc ou tu te tais c'est tout
 

 
mais non bon sang, ça ne fonctionne pas  

ben ouais, forcément, t'utilises un plugin qui supporte à moitié rien ...
 
Also, google maven resources.
 
Also, t'es dans un war, donc c'est pas gagné que les <resources> soient prises en compte.
 
Also, fais un <include>**/*</include>, chuis pas sur que ça soit le pattern par défaut

non mais la le probleme c'est que même en mettant une confing théoriquement bonne, le plugin maven eclipse décide de lui même
"hah bah non on peut pas pas mettre autre chose que des .java dans le dossier source donc je dégage tout ce qu'est pas java"
 

tes propos n'avancent en rien du tout, je me demande si tu t'en rends compte  

dire que tu ne veux pas de la solution parce que tu n'as pas réussit à installer un plugin que la moitier des dev sous Eclipse utilisent... bof.
 
Quand tu cherches à faire un truc simple, et que ça devient compliqué, c'est peut-être que ta situation de départ est daubée

il faut croire que je fais partie de l'autre moitié qui n'est pas convaincue par le plugin m2 tout simplement

ou peut être pas vu que je viens enfin de trouver comment faire avec le plugin maven eclipse  

c'est bô, on dirait du vô

est-ce que maven n'est pas censé résoudre des soucis de builds complexes ? à vous lire, j'ai l'impression qu'il n'arrive pas (ou plus) à résoudre des cas (relativement) simples...
 
non ?

maven permet aussi d'automatiser la configuration des environnements de devs si il y a les plugins pour
là mon soucis c'était pas un soucis de build maven

non, pas directement, i.e pas en shoehornant ce que t'as décidé (sans raison) de faire.
Et en l'occurence c'est pas tant un probleme de maven qu'un probleme d'un gars qui utilise un plugin antédéluvien, plugin qui est notoirement bourré de limitations à la con (sauf joyeuseutés comme joli démontrées dans la "solution" )

juste pour un remettre une couche, si c'est ça que tu veux faire, c'est pas maven qu'il te faut. tu fous tes fichiers .eclipse et autres sur le scm et basta ..

ouais et je met aussi les .class et les .jar dans le scm au passage, et je vais chercher les jars à la main dans le répo quand maven me fait chier à ramener des dépendances à la con
en fait j'utilise plus maven quoi, c'est vraiment trop de la merde tu as raison

Gros +1, Maven est la raison pour laquelle j'avais switché vers Intellij et certainement celle qui fait que j'ai peur de retourner sous Eclipse.

Pour rester dans le sujet, Maven peut être très galère, mais t'as un cinglé qui va se prendre la tête sur un point précis qui profitera ensuite au build de tout le monde. Je préfèrerais toujours ça à un Wiki - même à jour - sur la procédure pour builder xxx.jar sous Eclipse avec une conf exotique et un plugin plus maintenu. L'IDE il édite, basta.

assez d'accord, c'est pour ça que je délègue les builds à Hudson.
 
cela étant, chuis toujours avec Ant... mais ça marche.

--- APPEAU A BRISSOU (puisqu'il a l'air de connaître JCA) ---
 
Question sur un connecteur JCA, mais je pense que les habitués JEE peuvent répondre quand même.
 
Soit un connecteur sous forme d'un RAR dans le déploiement, appelons-le foo.rar. Un connecteur gère des connexions entrantes (sens extérieur vers les EJB, appelé inbound) et sortantes (EJB vers l'extérieur, ou outbound). Ledit connecteur a de plus besoin qu'on lui sette une propriété à la connexion.
 
En faisant ça, ça marche :
 
Inbound
 

@ResourceAdapter("foo.rar" )
@MessageDriven(activationConfig = {@ActivationConfigProperty(propertyName = "myProperty", propertyValue = "bar" )})
public class MyListener implements FooListener {
}

 
Outbound
 

@Stateless
public class MySender implements MySenderLocal {
    @Resource(mappedName="java:/FooConnector" )
    private DataSource dataSource
}

 
Ici "javaFooConnector" est le nom JNDI de mon connector, configuré dans la datasource (où l'on en profite pour setter la property) :

<!DOCTYPE connection-factories PUBLIC
          "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
          "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd">
<connection-factories>
    <no-tx-connection-factory>
        <jndi-name>FooConnector</jndi-name>
        <rar-name>foo.rar</rar-name>
        <connection-definition>
            com.foo.DataSource
        </connection-definition>
        <config-property name="myProperty" type="java.lang.String">bar</config-property>
    </no-tx-connection-factory>
</connection-factories>

 
Ce qui me dérange, c'est de setter deux fois myProperty, d'autant qu'une est direct dans le code source. j'aimerais que l'inbound (le MDB donc) viennent directement se connecter à la datasource, et ainsi y lire les property. C'est là que ça coince, j'ai essayé :
 

@MessageDriven(activationConfig = @ActivationConfigProperty(propertyName = "JmsProviderAdapterJNDI", propertyValue = "java:/FooConnector" ))

@MessageDriven(activationConfig = @ActivationConfigProperty(propertyName = "providerAdapterJNDI", propertyValue = "java:/FooConnector" ))

@MessageDriven
@ResourceAdapter("java:/FooConnector" )

 
Mais rien ne passe. les deux premières vont quand même chercher le resource adapter par défaut pour le messaging (jms-ra.rar), et donc ne trouvent pas ma classe FooListener, le dernier me pète sans surprise une Malformed puisqu'il attend le nom du rar, et tique donc sur le ':' de l'espace JNDI. Sauf que si je lui met le nom du RAR, il ne passe pas par la datasource, donc ne sette pas la propriété, donc il faudrait que je la sette dans le code, donc c'est moche et pas portable.
 
Merci

Ce week-end, vous êtes peut-être passés à côté d'un post ma foi foutrement intéressant. Il précède celui-ci, vous n'aurez donc même pas à scroller bien longtemps.
 
Bonne lecture et bonne semaine

en fait, mon expérience JCA se limite à la récupération d'un connecteur écrit en dépit des paterns, à une époque où Java 1.3 était encore le roi.
 
Désolé, je vais pas pouvoir t'aider des masses

Et j'imagine donc que d'un strict point de vue JEE, ça te parle pas ? Je cherche aussi le "et t'as pas essayé tout connement un <machin-bidule>, comme avec <papa-dans-maman> ?", question ouverte aux experts de tout bord donc.
Merci quand même
/balle-dans-le-crâne-de-bon-matin

tiens, mini-sondage: dans vos tomcat (ou autres) unpackWARs est a true ou false ? Il est true par defaut, et j'ai jamais pris le temps d'expérimenter bcp. Je vois un bel avantage a le mettre à false (éviter d'avoir a virer le repertoire décompressé lors d'une update), mais j'imagine qu'il y a des inconvénients ?

Chez nous il est à false.
Autrement la conf par défaut "maison" fait que le contexte se lance 2 fois

Ouais enfin si c'est la raison, c'est borderline pebcak la...

il vire le répertoire seul quand il détecte un changement du war

le war explosé peut être pratique pour faire des trucs crades sans repaquer un war, par exemple changer log4j ou un properties
voir même juste déposer un .class ou modifier une jsp

 
faut pas trop faire confiance à ce comportement...

nan. ou alors il détecte mal quand tu changes le docBase pour pointer vers un .war different.

non, je confirme, c'est pas toujours très clair

de quoi nan ?

quand t'écrase le war à chaud et qu'il y a l'autodeploy il me semble que ça marche bien
quand le war est écrasé et que le serveur est à l'arrêt c'est pas toujours très clair ce qui se passe au redémarrage

enfin quoiqu'il en est dans le doute vaut mieux tout effacer à la main

vous connaissez une librairie plus sympa que le MessageFormat pour faire

MessageeFormat.format("There's an incorrect value \"{0}\" in column # {1}", x, y);

avec par exemple des noms comme pour substituer un peu comme dans les namedquery hiberate, ou bien des ${bla.truc} comme dans freemarker ?

et sinon ça serait abusé d'utiliser freemarker pour générer un fichier plat non html/xml ?

Pour l'i18n j'aime bien le principe de http://java.net/projects/localizer/ mais j'ai jamais eu l'occasion de l'utiliser.
 

non pourquoi ?