Spring Boot ne sert pas les ressources statiques

Rédigé par gorki - - Aucun commentaire

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 :

[DEBUG] org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory - None of the document roots [src/main/webapp, public, static] point to a directory and will be ignored.

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.

[DEBUG] org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory - Document root: /home/qwbt2550/projets/portailLCRI/lcri-portal/src/main/webapp

 

 

Cinnamon and Gnome : org.cinnamon.SettingsDaemon

Rédigé par gorki - - Aucun commentaire

Problem :

After an update of my debian, I lost :

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.

 

 

 

 

Java threaddump sous windows

Rédigé par gorki - - Aucun commentaire

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%
)

 

 

JMeter and shared variables between thread group

Rédigé par gorki - - Aucun commentaire

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)

Webex and linux

Rédigé par gorki - - Aucun commentaire

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
Fil RSS des articles