Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Používám Tomcat 7.0.29 (ze ZIPu z webu Apache Tomcat), Oracle Linux 6.4 a rád bych deployoval aplikaci myapp s ROOT kontextem s využitím virtualhosta.
Nastavení jsem se snažil provést podle následující dokumentace Tomcatu:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naminghttp://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_contextIf you want to deploy a WAR file or a directory using a context path that is not related to the base file name then one of the following options must be used to prevent double-deployment:
a) Disable autoDeploy and deployOnStartup and define all Contexts in server.xml
b) Locate the WAR and/or directory outside of the Host's appBase and use a context.xml file with a docBase attribute to define it.
Individual Context elements may be explicitly defined:
A. In an individual file at/META-INF/context.xmlinside the application files. Optionally (based on the Host'scopyXMLattribute) this may be copied to$CATALINA_BASE/conf/[enginename]/[hostname]/and renamed to application's base file name plus a ".xml" extension.
B. In individual files (with a ".xml" extension) in the$CATALINA_BASE/conf/[enginename]/[hostname]/directory. The context path and version will be derived from the base name of the file (the file name less the .xml extension). This file will always take precedence over any context.xml file packaged in the web application'sMETA-INFdirectory.
C. Inside a Host element in the mainconf/server.xml.
Požadavky na deployment myapp
context path=""myapp.war (ne ROOT.war)META-INF/context.xml
Abych toto dosáhl, provedl jsem následující
myapphostname s appbasedir $CATALINA_HOME/myapp_dstmyapp.war do složky $CATALINA_HOME/myapp_src (splnění požadavku b)$CATALINA_HOME/conf/Catalina/myapphost/ROOT.xml obsahující context path="" docBase=$CATALINA_HOME/myapp_src/myapp.war (splnění požadavku B)
Předpokládal jsem, že se myapp.war rozbalí do appBase virtualhosta,t.j. do $CATALINA_HOME/myapp_dst nebo do $CATALINA_HOME/myapp_dst/ROOT, ale nestalo se ani jedno. Aplikace myapp beží z nerozbaleného WARu.
Co bych měl změnit v konfiguraci nebo v souborové struktuře, abych dosáhl požadovaného chování?
Předem díky za rady.
Leoš
=== adresářová struktura - relevantní soubory/složky ===$CATALINA_BASE |-- bin |-- conf | |-- Catalina | | |-- localhost | | `-- myapphost | | `-- ROOT.xml | |-- catalina.policy | |-- catalina.properties | |-- context.xml | |-- logging.properties | |-- server.xml | |-- tomcat-users.xml | `-- web.xml |-- lib |-- LICENSE |-- logs |-- NOTICE |-- myapp_dst | |-- mysecondapp | `-- mysecondapp.war |-- myapp_src | `-- myapp.war |-- RELEASE-NOTES |-- temp |-- webapps `-- work=== server.xml - relevantní část ===
<Engine name="Catalina" defaultHost="myapphost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
<Host name="myapphost" appBase="myapp_dst" unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
=== $CATALINA_HOME/conf/Catalina/myapphost/ROOT.xml ===
<Context path="" docBase="/opt/programs/tomcat7b/myapp_src/myapp.war" />
Řešení dotazu:
Děkuji. Ano, je to tak, mimo appBase Tomcat WARy nerozbaluje. Šlo mi o to nastavit <Context path=""/>, rozbalit WAR a zároveň se vyhnout vytvoření složky ROOT.war. Rád bych, aby Tomcat rozbalil WAR pouze do složky myapp, což však nejspíš koliduje s dokumentací, která vyžaduje pro prázdný stríng v Context path složku ROOT nebo soubor ROOT.war.
Rozbalení WAR je požadavek zákazníka, pro kterého nastavení provádím. Panuje obava, že aplikace běžící z nerozbaleného WARu bude běžet pomaleji než z rozbaleného.
docBase, Tomcat WARko nemůže rozbalit, protože vůbec nic neví o cíli – např. jestli je tam povolen zápis. Takže pokud chcete použít automatické rozbalování, musíte WARko nahrát do appBase. ContextPath je pak možné určit buď názvem WARka nebo souborem context.xml ve WARku. Nebo můžete WARko rozbalit předem a docBase nasměrovat na rozbalený adresář. Nebo použít Jetty, které WARka rozbaluje do systémového dočasného adresáře. A nebo se vykašlat na rozbalování, to, že by aplikace běžela pomaleji, je podle mne nesmysl. Týkalo by se to nanejvýš statických souborů, a ty lze stejně nejrychleji odeslat jedině přes NIO, takže je nutné celý mechanismus servletů obejít (Jetty to umí, nevím, zda i Tomcat – ale rozhodně to znamená mnohem víc konfigurace, než jenom někam nahrát WAR).
Děkuji za upřesnění. Díky Vám jsem si ujasnil, že zmíněné požadavky na deploy se nedají splnit současně a to protože se Tomcat chová takto:
<Context path="string"> se jménem WAR nebo rozbalené složky, kdy prázdný string vyžaduje pojmenování ROOT.war, resp. ROOT/ (složka), což dokumentace Tomcatu popisuje zde.appBase do nějakého docBase, kde ovšem ztrácím možnost rozbalení WAR, protože je docBase pro Tomcat neviditelná.
Ještě jednou díky za Vaše postřehy. Řešením v mém případě bude nejspíše nerozbalovat WAR.
Tiskni
Sdílej: