You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
(33) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(17) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(4) |
Aug
(2) |
Sep
(5) |
Oct
(2) |
Nov
(2) |
Dec
|
2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(1) |
2014 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
(1) |
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
22
|
23
|
24
(1) |
25
|
26
|
27
|
28
|
29
|
30
|
31
|
|
|
|
|
From: Stefan M. <ste...@ho...> - 2017-01-24 15:51:10
|
Hello, I would like to propose an improvement to CSSOMParser.java. In my use case, the synchronized code block in the constructor causes a major execution bottleneck. My first patch was to minimize the scope of the synchronized block (see below). This reduced thread contention by a great deal. But as System.getProperty boils down to Hashtable.get, it also contains synchronized code. To further improve the concurrency of this code part, I need to understand it better. What’s the use case behind retrieving the configuration from system properties? Just to add the possibility for configuration from outside? If this is the case, the synchronization can probably be avoided in cases where CSSOMParser is initiated with a valid Parser object. Best regards, Stefan public CSSOMParser(final Parser parser) { if (null != parser) { parser_ = parser; String parserCanonicalName = parser.getClass().getCanonicalName(); if (!parserCanonicalName.equals(System.getProperty(SYS_PRPOPERTY))) { synchronized (LOCK) { System.setProperty(SYS_PRPOPERTY, parserCanonicalName); } } return; } // no parser provided, determine the correct one synchronized (LOCK) { String currentParser = System.getProperty("org.w3c.css.sac.parser"); try { // use the direct method if we already failed once before if (null != LastFailed_ && LastFailed_.equals(currentParser)) { parser_ = new SACParserCSS21(); } else { if (null == currentParser) { System.setProperty("org.w3c.css.sac.parser", DEFAULT_PARSER); currentParser = DEFAULT_PARSER; } final ParserFactory factory = new ParserFactory(); parser_ = factory.makeParser(); } } catch (final Exception e) { final Logger log = Logger.getLogger("com.steadystate.css"); log.warning(e.toString()); log.warning("using the default 'SACParserCSS21' instead"); log.throwing("CSSOMParser", "consturctor", e); LastFailed_ = currentParser; parser_ = new SACParserCSS21(); } } } |
From: Ronald B. <rb...@rb...> - 2017-01-08 13:27:18
|
Version 0.9.21 has been released to Maven and SourceForge download. This version includes the usual bugfixes and some parser improvements (nested media rules support, unucode range support). Have a look at the release notes (http://cssparser.sourceforge.net/changes-report.html#a0.9.21) for details. Enjoy css parsing. RBRi -------------------------- Wetator Smart web application testing http://www.wetator.org |