HOAB

Le problème :

Avec une stack JHipster, spring-boot n'affiche pas les ressources statiques en mode développement.

Ddonc par exemple pas de index.html...

Pour autant si on lance la commande avec le war serverless (cf spring-boot-maven-plugin), ça fonctionne.

Je suis sous Intellij, à l'évidence quelque chose manque dans le lancement de la tâche Intellij spring-boot

L'architecture est mavenisé donc le root contexte est sous : src/main/webapp

Cependant spring-boot semble chercher ses ressources ailleurs : cf la documentation

Par quelle magie spring-boot doit-il trouver ses ressources dans src/main/webapp ??

Solution :

Beaucoup de recherches, de debug et autre (il y a un peu de spring-secu dans le lot). Au final les services jhipster classiques (health, dump, etc...) fonctionnent mais toujours pas de ressources statiques.

Vérification :

• de la tâche de lancement Intellij, elle semble correcte.
• des classpaths (on met src/main/webapp dans le classpath, on l'enlève) 
• des paramètres de lancement (profil Spring et autre)

Au final la mise en debug m'a permis de trouver un log perdu parmi les autres :

Tiens donc le Tomcat embarqué de spring-boot a ses propres chemins de recherches... (pas tout à fait décrit dans la doc Spring ci-dessus).

Breakpoint, watch, et paf, le chemin vers src/main/webapp en absolu n'est pas le bon.

Tout ça parce que le répertoire de travail de ma tâche spring-boot sous Intellij n'était pas fixé. Comment Intellij détermine cette valeur ? Mystère. En mettant donc le répertoire de travail égal au répertoire qui contient le src/main/webapp, tout roule (ici le répertoire de travail serait : /home/user/projets/monprojet/webportal.

On retrouve le log :

Eclairé aussi par ce lien

Problem :

After an update of my debian, I lost :

• power management icon
• multiple screen configuration and here
• background images and here
• media keys

And when I tried to apply new screen configuration I had :

GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service

Many references on the net, many solutions :

1. reinstall cinnamon
2. remove configuration file
3. start /usr/bin/cinnamon-settings-daemon
4. ...

All tried, none work.

Solution :

Due to previous ressources and tests, I notice that when starting :

/usr/bin/cinnamon-settings-daemon

I had an error :

You can only run one xsettings manager at a time; exiting

After checking that is wasn't already started with :

ps -aef | grep cinnamon-settings-daemon

I perform a grep with :

ps -aef | grep settings

And I found that I had a gnome-settings-daemon running. Eurêka ! Gnome was my previous X manager.

So after a few checks :

sudo apt-get purge gnome-control-center gnome-settings-daemon gnome-control-center-data gnome-desktop3-data gnome-accessibility-themes

Restart, and all works.

Problème :

Faire des threadumps un peu assisté pour Java sous Windows. Normalement, il faut :

• repérer le pid
• appeler jstack sur le pid
• stocker le résultat dans un fichier unique

Mais j'avais besoin d'un script oneshot que les utilisateurs puissent lancer facilement et plusieurs fois

Solution :

Merci aux différentes ressources du net, voici un petit script rapide :

@echo off

SET JAVA_HOME=c:\Program Files\Java\jdk1.7.0_51\
SET OUTPUT_DIR=c:\temp\lzg_threaddumps
SET COMMAND_TO_CHECK=java.exe

setlocal enableextensions
if not exist "%OUTPUT_DIR%" md "%OUTPUT_DIR%"
endlocal

for /f "tokens=2" %%F in ('tasklist /nh /fi "imagename eq %COMMAND_TO_CHECK%"') do (


    SET DEST_FILE="%OUTPUT_DIR%\%%F_%date:~-4,4%%date:~-7,2%%date:~-10,2%_%time:~-11,2%%time:~-8,2%%time:~-5,2%%time:~-2,2%.txt"
    @echo Dumping %%F to file %DEST_FILE%
    rem echo "%JAVA_HOME%\bin\jstack.exe" %%F
    "%JAVA_HOME%\bin\jstack.exe" %%F > %DEST_FILE%
)

Problem :

I have two thread groups that must be synchronized. I want to use

java.util.concurrent.CountDownLatch

to achieve this.

I read (here, or here) how to synchronize JMeter thread groups (you have to use properties and not variables). Properties can be access in :

• bsh sampler : bsh.shared.<property name>
• jsr223 sample : props.put(<property name>)
• the org/apache/jmeter/util/JMeterUtils.class is the source of these properties.

I add to my test plan an initial element in bsh, jsr223 to create the latch. But when I get the latch in the thread groups, I always had different instance of my shared latch.

Solution :

Easy when we know.

I made the mistake to add the piece of code in a Pre-Processor

• Test Plan
  • PreProcessor BSH : init latch
  • Thread Group 1
    • Sampler BSH : wait for latch
  • Thread Group 2
    • Sampler BSH : count down latch

In this case, the PreProcessor is run before each thread initialization. I run X times the preprocess sample.

Correct test plan :

• Test Plan
  • Set up Thread Group
    • Sampler BSH : init latch
  • Thread Group 1
    • Sampler BSH : wait for latch
  • Thread Group 2
    • Sampler BSH : count down latch

The setup Thread Group is run before the others thread groups (these ones are parallel until you say not to do)

Le problème :

I know that many post have been written on the subject, but has I do not had a quick solution. Here is some few more information.

When connecting to webex from Linux, I had no sharing.

Solution :

First I used Firefox 64 and JVM 64. It doesn't work. Whatever I read on the net (from this link, or there).

So :

1. Install i386 architecture
2. install firefox32 (< 52.x otherwise Java is not working for now)
3. create a separate profile
4. install missing packages... (when starting firefox32)
5. install 32bits JVM
6. create a link to the JVM plugin in the new profile
7. remove any shared plugin (for example JVM 64bits plugin in shared plugins library) : use plugins directory in profile

This is a quick & dirty, I'll try to update it after.

Useful tips :

• about:plugins in firefox
  • if the 32bits plugins is not there, or the JVM64 is still there, don't go further, correct this
• http://java.com/verify/
• remove webex directory : ~/.webex
• install missing packages for webex (ldd tips)
• sometimes it can be long when you are behind a proxy