Portál AbcLinuxu, 30. října 2025 18:56
574 - LL - hezčí stránka informující, že stránka neexistuje
Dokument se můžete pokusit najít pomocí našeho mocného fulltextového hledání.Řekl bych, že to "mocné" je poněkud odvážné tvrzení. To hledání je dost pomalé a mám pocit, že Google se site:abclinuxu.cz dává lepší výsledky (ve smyslu že najde to, co jsem hledal)
Ábíčko je moc pěkně strukturované, takže i Google dokáže hledat
jen v části, kterou zadám a je lepší mít více výsledků než, aby
ten, o který stojím, nebyl nalezen:
site:www.abclinuxu.cz/blog
site:www.abclinuxu.cz/hardware
site:www.abclinuxu.cz/software
site:www.abclinuxu.cz/faq
site:www.abclinuxu.cz/poradna
site:www.abclinuxu.cz/ucebnice
site:www.abclinuxu.cz/zpravicky
site:www.abclinuxu.cz/clanky
Nebo ještě podrobněji:
site:www.abclinuxu.cz/clanky/programovani
Samozřejmě, že jsem to nemyslel jako buzeraci
Vážím si Tě a toho co děláš pro Ábíčko... Zajímala mě odpověď na to v čem je v tomto případě problém. Ostatně zdrojáky jsou k dispozici a tam se odpověď najde
Hledání je rychlé, pomalé je generování zvýrazněných částí nalezeného textu.Aha.
Navic casu mam tak malo, nechci jej travit experimentovanim s necim novym, kdyz to stare ovladam a vim, jak funguje.
eclipse je možné pracovat s CVS přímo z IDE naprosto bez problémů (checkout, commit, vytvoření branche, prohlížení historie atd.). Pro SVN existují minimálně dva pluginy do eclipse, ale každý má své mouchy. V poslední době se snad ledy hnuly a bude alespoň jeden normálně použitelný…
A pro Abíčko myslím nevýhody CVS oproti SVN nebudou moc znatelné, protože CVS pro Abíčko je důležité jednak proto, aby byly aktualizované zdrojáky brzy k dispozici a nedalo jejich zveřejnění moc práce, jednak se proti CVS daleko lépe dělají patche (třeba v eclipse je to pár kliknutí, udělat patch proti lokální kopii originálu se mi v eclipse nepodařilo).
Thread 10561: (state = BLOCKED) - java.util.Collections$SynchronizedMap.get(java.lang.Object) @bci=7, line=1979 (Interpreted frame) - org.dom4j.tree.QNameCache.get(java.lang.String) @bci=11, line=88 (Interpreted frame) - org.dom4j.QName.get(java.lang.String) @bci=4, line=86 (Interpreted frame) - org.dom4j.QName.get(java.lang.String, java.lang.String, java.lang.String) @bci=16, line=95 (Interpreted frame) - org.jaxen.dom4j.DocumentNavigator.getChildAxisIterator(java.lang.Object, java.lang.String, java.lang.String, java.lang.String) @bci=19, line=241 (Interpreted frame) - org.jaxen.expr.iter.IterableChildAxis.namedAccessIterator(java.lang.Object, org.jaxen.ContextSupport, java.lang.String, java.lang.String, java.lang.String) @bci=17, line=100 (Interpreted frame) - org.jaxen.expr.DefaultNameStep.evaluate(org.jaxen.Context) @bci=348, line=231 (Interpreted frame) - org.jaxen.expr.DefaultLocationPath.evaluate(org.jaxen.Context) @bci=87, line=151 (Interpreted frame) - org.jaxen.expr.DefaultAbsoluteLocationPath.evaluate(org.jaxen.Context) @bci=90, line=117 (Interpreted frame) - org.jaxen.expr.DefaultXPathExpr.asList(org.jaxen.Context) @bci=7, line=108 (Interpreted frame) - org.jaxen.BaseXPath.selectNodesForContext(org.jaxen.Context) @bci=5, line=687 (Interpreted frame) - org.jaxen.BaseXPath.selectNodes(java.lang.Object) @bci=8, line=233 (Interpreted frame) - org.jaxen.BaseXPath.selectSingleNode(java.lang.Object) @bci=2, line=252 (Interpreted frame) - org.dom4j.xpath.DefaultXPath.selectSingleNode(java.lang.Object) @bci=10, line=159 (Interpreted frame) - org.dom4j.tree.AbstractNode.selectSingleNode(java.lang.String) @bci=8, line=185 (Interpreted frame)Zkusim se poptat v DOM4J komunite nebo nastudovat zdrojaky. Mozna zkusim pouzit whirlycache mapu na synchronizaci.
org.dom4j.util.PerThreadSingleton místo org.dom4j.util.SimpleSingleton. Sice se nebudou cache používat napříč thready, takže bude o něco větší spotřeba paměti i bude nutné některé objekty znovu vytvářet, ale to asi bude pořád lepší, než vzájemné zdržování vláken. Mělo by fungovat nastavit systémovou vlastnost org.dom4j.QName.singleton.strategy=org.dom4j.util.PerThreadSingleton.
Další řešení (spíš hack) by bylo oddědit z org.dom4j.util.SimpleSingleton vlastní SingletonStrategy, který bude natvrdo pro třídu org.dom4j.tree.QNameCache vracet jejího potomka, který by byl postaven na jiné cache (přímo určit, která implementace cache se použije nejde, ve zdrojáku je natvrdo singleton.setSingletonClassName(QNameCache.class.getName())).
Nejčistší řešení je upravit dom4j tak, aby bylo možné přes systémovou vlastnost určit třídu místo defaultní QNameCache, a QNameCache přepsat s využitím nové ConcurrentHashMap z Javy 5. S protlačením takové změny do dom4j 1.7 asi problém nebude, protože 1.7 už má být pouze pro Javu 5, ale ofifiální verze 1.7 asi jen tak brzy nebude.
Pokud jde o DOM4J, myslel jsem, ze projekt zamrznul, kdyz jsem jej naposledy kontroloval, nevidel jsem zadnou aktivitu.
Fork se dá udělat vždycky…
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.