titanz
/
matrix-docker-ansible-deploy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'd7eb2d097f'
${ noResults }
matrix-docker-ansible-deploy/roles/matrix-jitsi/templates/jvb/logging.properties.j2

21 lines
671 B
Raw Normal View History Unescape

Fix Jitsi logging.properties conditional being interpreted as Jinja code Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1464
3 years ago
{% raw %}
Jitsi update - sentry logging added
3 years ago
{{ if .Env.SENTRY_DSN | default "0" | toBool }}
handlers=java.util.logging.ConsoleHandler,io.sentry.jul.SentryHandler
{{ else }}
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
handlers= java.util.logging.ConsoleHandler
Jitsi update - sentry logging added
3 years ago
{{ end }}
Fix Jitsi logging.properties conditional being interpreted as Jinja code Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1464
3 years ago
{% endraw %}
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = net.java.sip.communicator.util.ScLogFormatter
net.java.sip.communicator.util.ScLogFormatter.programname=JVB
.level=INFO
org.jitsi.videobridge.xmpp.ComponentImpl.level=FINE
Jitsi update - sentry logging added
3 years ago
io.sentry.jul.SentryHandler.level=WARNING
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
# All of the INFO level logs from MediaStreamImpl are unnecessary in the context of jitsi-videobridge.
org.jitsi.impl.neomedia.MediaStreamImpl.level=WARNING