Po 9 týdnech vývoje od vydání Linuxu 7.0 oznámil Linus Torvalds vydání Linuxu 7.1. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a časem také na Linux Kernel Newbies.
Cheat Engine (Wikipedie) je s verzí 7.7 k dispozici už také pro Linux. Jedná se o proprietární skener/debugger paměti používaný především k cheatování v počítačových hrách.
Vláda USA nařídila společnosti Anthropic pozastavit přístup k modelům Fable 5 a Mythos 5 pro všechny cizince, včetně zaměstnanců Anthropicu.
Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
WebAppContext metodu addHandler(), takže stačí do příslušného <context>.xml dopsat pár řádků, jak je uvedeno např. na http://docs.codehaus.org/display/JETTY/Logging+Requests dole.
U verze 7 třída WebAppContext metodu addHandler() nemá, takže tento postup nefunguje. Tuto metodu jsem ale našel u třídy HandlerCollection, ovšem nevím, jak to do konfiguračního souboru zakomponovat. Navíc se zdá, že instance HandlerCollection je společná pro třídu Server, takže nevím, zda je vhodné/možné tam přidávat handlery pro jednotlivé webapps. Nebo je třeba založit vlastní instanci?
Jsem zmaten a google nepomáhá. Našel jsem pár podobných otázek, ale bez odpovědi.
Řešení dotazu:
ContextHandler, do něj vložte HandlerCollection, který postupně zavolá všechny vložené handlery bez ohledu na výsledek předchozího handleru, a do něj vložte postupně WebAppContext a po něm RequestLogHandler.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure class="org.eclipse.jetty.server.handler.ContextHandler">
<Set name="contextPath">/</Set>
<Set name="resourceBase">
<SystemProperty name="jetty.home" default="."/>/webapps/neco.cz
</Set>
<Set name="virtualHosts">
<Array type="java.lang.String">
<Item>local.neco.cz</Item>
</Array>
</Set>
<New class="org.eclipse.jetty.server.handler.HandlerCollection">
<Call name="addHandler">
<Arg>
<New class="org.eclipse.jetty.server.handler.RequestLogHandler">
<Set name="requestLog">
<New id="RequestLogImpl" class="org.eclipse.jetty.server.NCSARequestLog">
<Arg>
<SystemProperty name="jetty.logs" default="./logs"/>/yyyy_mm_dd-neco.cz-request.log
</Arg>
<Set name="retainDays">90</Set>
<Set name="append">true</Set>
<Set name="extended">true</Set>
<Set name="logCookies">false</Set>
<Set name="LogTimeZone">GMT</Set>
</New>
</Set>
</New>
</Arg>
</Call>
</New>
<New class="org.eclipse.jetty.webapp.WebAppContext">
</New>
</Configure>
Nejen, že to neloguje (resp. ani soubor pro log neotevře), ale navíc místo obsahu patřičného virtualhosta posílá obsah default contextu.
Zkoušel jsem <Set name="virtualHosts"> ... přmístit do WebAppContext, ale výsledek je stejný.
Přiznávám, že některá zákoutí konfigurace jetty jsou pro mne zatím španělská vesnice, hodně tápu. A dokumentace se mi zdá na rozdíl od jiných projektů dost neuchopitelná.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure class="org.eclipse.jetty.server.handler.ContextHandler">
<Set name="contextPath">/</Set>
<Set name="virtualHosts">
<Array type="java.lang.String">
<Item>local.neco.cz</Item>
</Array>
</Set>
<Set name="handler">
<New class="org.eclipse.jetty.server.handler.HandlerCollection">
<Call name="addHandler">
<Arg>
<New class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="contextPath">/</Set>
<Set name="resourceBase">
<SystemProperty name="jetty.home" default="."/>/webapps/neco.cz
</Set>
</New>
</Arg>
</Call>
<Call name="addHandler">
<Arg>
<New class="org.eclipse.jetty.server.handler.RequestLogHandler">
<Set name="requestLog">
<New id="RequestLogImpl" class="org.eclipse.jetty.server.NCSARequestLog">
<Arg>
<SystemProperty name="jetty.logs" default="./logs"/>/yyyy_mm_dd-neco.cz-request.log
</Arg>
<Set name="retainDays">90</Set>
<Set name="append">true</Set>
<Set name="extended">true</Set>
<Set name="logCookies">false</Set>
<Set name="LogTimeZone">GMT</Set>
</New>
</Set>
</New>
</Arg>
</Call>
</New>
</set>
</Configure>
index.jsp, ale dostanu java.lang.StackOverflowError. Pokud napíšu úplnou cestu, je to v pořádku. To už je ale jiný problém, mrknu na to zítra (zřejmě chybí nastavení, které jsem předtím odněkud dědil).
... at org.eclipse.jetty.server.Dispatcher$ForwardAttributes.setAttribute(Dispatcher.java:474) at org.eclipse.jetty.server.Dispatcher$ForwardAttributes.removeAttribute(Dispatcher.java:495) at org.eclipse.jetty.server.Dispatcher$ForwardAttributes.setAttribute(Dispatcher.java:474) at org.eclipse.jetty.server.Dispatcher$ForwardAttributes.removeAttribute(Dispatcher.java:495) at org.eclipse.jetty.server.Dispatcher$ForwardAttributes.setAttribute(Dispatcher.java:474) at org.eclipse.jetty.server.Dispatcher$ForwardAttributes.removeAttribute(Dispatcher.java:495) at org.eclipse.jetty.server.Dispatcher$ForwardAttributes.setAttribute(Dispatcher.java:474) at org.eclipse.jetty.server.Dispatcher$ForwardAttributes.removeAttribute(Dispatcher.java:495) at org.eclipse.jetty.server.Request.removeAttribute(Request.java:1371) at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:212) at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:115) ...Metoda
removeAttribute(name) volá setAttribute(name, null) a ta při splnění určitých podmínek (které jsou v tomto případě evidentně splněny) volá opět removeAttribute(name).
Podle dalšího pohledu do zdrojáku se zdá, že pravou příčinou je zajímavě okomentovaný řádek:
request.removeAttribute(__JSP_FILE); // TODO remove when glassfish 1044 is fixed
Takže jsem asi narazil na chybu, která vznikla ja dočasný workaround chyby 1044 v Glassfish.
A teď, babo raď...
__JSP_FILE s tím nesouvisí. Pokud používáte nějakou starší verzi, zkuste nejnovější stabilní, a jinak napište, jakou verzi používáte – protože tohle spíš vypadá na chybu v Jetty (kdyby to byla chyba v konfiguraci, muselo by se to zacyklit už dřív).
Tiskni
Sdílej: