DO NOT REPLY [Bug 50535] New: Support resources serving from /WEB-INF/classes/META-INF/resources directory
https://issues.apache.org/bugzilla/show_bug.cgi?id=50535 Summary: Support resources serving from /WEB-INF/classes/META-INF/resources directory Product: Tomcat 7 Version: 7.0.5 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: kiralyattila...@gmail.com Servlet 3.0 introduced the feature to serve static files from META-INF/resources directory. The specification only demands support for this if the META-INF/resources is inside of a jar file in the /WEB-INF/lib directory. Tomcat passes this requirement because it serves files from jar but not from WEB-INF/classes. It seems Glassfish 3.0.1 however supports both type of locations. It would be nice if Tomcat would support it too. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50535] Support resources serving from /WEB-INF/classes/META-INF/resources directory
https://issues.apache.org/bugzilla/show_bug.cgi?id=50535 Attila Király changed: What|Removed |Added CC||kiralyattila...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46052] SetLocaleSupport is slow to initialize when many large items are on the classpath
https://issues.apache.org/bugzilla/show_bug.cgi?id=46052 --- Comment #2 from Jeremy Boynes 2011-01-01 14:40:29 EST --- Java6 introduced the java.util.spi.LocaleServiceProvider mechanism as a pluggable mechanism for supporting additional Locales which requires searching the classpath for LocaleServiceProvider implementations when supporting getAvailableLocales(). Prior to 1.6 there was no extension mechanism and getAvailableLocales() only returned the pre-defined Locales supported by the JVM. The matching algorithm described by LocaleServiceProvider is the same as that defined in the JSTL specification 9.3.2 LocaleLookup. We might be able to resolve this issue by switching to the JVM's implementation. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50265] FormatDateSupport.dateFormatCache lazy init is not safe
https://issues.apache.org/bugzilla/show_bug.cgi?id=50265 Jeremy Boynes changed: What|Removed |Added Depends on||32311 --- Comment #1 from Jeremy Boynes 2011-01-01 15:18:25 EST --- The caching was added to resolve 32311, which was opened due to contention issues with DateFormat.getTimeInstance() calling Calendar.getInstance() which was synchronized. However, the synchronized keyword was removed with Java 1.4 so this should no longer be an issue for us. #32311 also notes that the calls to format() on the cached formatters are not thread safe and need to be synchronized; this is missing from the current implementation. However, in many applications the date/time patterns and Locale are likely to be the same and the cache only holds one instance of the formatter. By synchronizing on it we will introduce a contention point just like the the fix was trying to avoid. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 32311] Performance: fmt:formatDate regarding calls to Calendar.getInstance
https://issues.apache.org/bugzilla/show_bug.cgi?id=32311 Jeremy Boynes changed: What|Removed |Added Blocks||50265 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 50265] FormatDateSupport.dateFormatCache lazy init is not safe
The caching change for #32311 has never been released. I'd like to suggest we revert that change and go back to creating formatters as needed (as we did in the last release). Due to the removal of synchronized on Calendar#getInstance() this will solve the original issue and not add any threading issues. If we want to improve the performance we can do that later by caching formatters in each tag instance, or by using a thread-safe date/time library uch as Joda. Thoughts? Jeremy On Jan 1, 2011, at 12:18 PM, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=50265 > > Jeremy Boynes changed: > > What|Removed |Added > > Depends on||32311 > > --- Comment #1 from Jeremy Boynes 2011-01-01 15:18:25 > EST --- > The caching was added to resolve 32311, which was opened due to contention > issues with DateFormat.getTimeInstance() calling Calendar.getInstance() which > was synchronized. However, the synchronized keyword was removed with Java 1.4 > so this should no longer be an issue for us. > > #32311 also notes that the calls to format() on the cached formatters are not > thread safe and need to be synchronized; this is missing from the current > implementation. However, in many applications the date/time patterns and > Locale > are likely to be the same and the cache only holds one instance of the > formatter. By synchronizing on it we will introduce a contention point just > like the the fix was trying to avoid. > > -- > Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are the assignee for the bug. > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
