[magnolia-dev] [JIRA] Created: (MAGNOLIA-3166) Nice Editor couts line only to value=1500 and starts afterwards with 1 again
Nice Editor couts line only to value=1500 and starts afterwards with 1 again Key: MAGNOLIA-3166 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3166 Project: Magnolia Issue Type: Bug Components: gui Affects Versions: 4.3.1, 4.2.3, 4.1.4 Reporter: Christian Ringele Assignee: Boris Kraft Priority: Minor The problem shows up on stk's css. The css has more lines than 1500. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Assigned: (MAGNOLIA-3166) Nice Editor couts line only to value=1500 and starts afterwards with 1 again
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Federico Grilli reassigned MAGNOLIA-3166: - Assignee: Federico Grilli (was: Boris Kraft) Nice Editor couts line only to value=1500 and starts afterwards with 1 again Key: MAGNOLIA-3166 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3166 Project: Magnolia Issue Type: Bug Components: gui Affects Versions: 4.1.4, 4.2.3, 4.3.1 Reporter: Christian Ringele Assignee: Federico Grilli Priority: Minor The problem shows up on stk's css. The css has more lines than 1500. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Fwd: Meeting with Openmind (2010.03.26): Protocol
FYI Subject: Meeting with Openmind (2010.03.26): Protocol Cache concept page will improve based on todays implementation we focus on direct streaming (memory issues) simplified configuration Content API / Performance introduce methods returning iterators without breaking existing code? By adding getChildrenInterator()? new API? rather not Search new API/library based on the implementation by openmind needs some cleanup/finalization STK write down criticized points on the wiki to start an open discussion STK 2.0 will be a topic at some point splitting the core framework and STK templates overwork the resource handlin For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3166) Nice Editor couts line only to value=1500 and starts afterwards with 1 again
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27646#action_27646 ] Federico Grilli commented on MAGNOLIA-3166: --- Yes, the line numbers are actually a long png repeated on the y axis. The guys of created codepress thought that 1500 was a fair number but evidently it is not :) Nice Editor couts line only to value=1500 and starts afterwards with 1 again Key: MAGNOLIA-3166 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3166 Project: Magnolia Issue Type: Bug Components: gui Affects Versions: 4.1.4, 4.2.3, 4.3.1 Reporter: Christian Ringele Assignee: Federico Grilli Priority: Minor The problem shows up on stk's css. The css has more lines than 1500. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Issue Comment Edited: (MAGNOLIA-3166) Nice Editor couts line only to value=1500 and starts afterwards with 1 again
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27646#action_27646 ] Federico Grilli edited comment on MAGNOLIA-3166 at 3/26/10 11:14 AM: - Yes, the line numbers are actually a long png repeated on the y axis. The guys who created codepress thought that 1500 was a fair number but evidently it is not :) was (Author: fgrilli): Yes, the line numbers are actually a long png repeated on the y axis. The guys of created codepress thought that 1500 was a fair number but evidently it is not :) Nice Editor couts line only to value=1500 and starts afterwards with 1 again Key: MAGNOLIA-3166 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3166 Project: Magnolia Issue Type: Bug Components: gui Affects Versions: 4.1.4, 4.2.3, 4.3.1 Reporter: Christian Ringele Assignee: Federico Grilli Priority: Minor The problem shows up on stk's css. The css has more lines than 1500. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-3167) cache: single blocking request can block all other requests to cached content
cache: single blocking request can block all other requests to cached content -- Key: MAGNOLIA-3167 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3167 Project: Magnolia Issue Type: Bug Affects Versions: 4.3.1, 4.2.3, 4.1.4, 3.6.8 Reporter: Philipp Bärfuss Assignee: Boris Kraft Fix For: 4.3.x the cache mechanism can block all requests: * cache.get() will block if an other request is caching the same key (this is a feature of the BlockingCache) ** mutex per key kept until cache.put() is called (either with an entry or null value) * this code is again in a synchronized block which synchronizes on the cache object itself ** this blocks all other request trying to enter the synchronization block The critical scenario which can prevent magnolia from responding any request (all threads blocked) is the following 1) first request to a resource which is slow or never returns (request to a service, poor database connection, ..) 2) second request to the same resource: -- thread is blocked at EhCacheWrapper.get(key):56, but also keeps the lock on the cache 3) all other caching requests are blocked (no matter which url) due to the synchronize block at Default.shouldCache(Cache, AggregationState, FlushPolicy):89 Solution: * don't synchronize on the cache (why are we doing this???) * allow configuration of [BlockingCache.timeoutMillis|http://ehcache.org/apidocs/net/sf/ehcache/constructs/blocking/BlockingCache.html#timeoutMillis] ** throw an exception if a request waits for to long * uncomment finally block at doFilter(HttpServletRequest, HttpServletResponse, FilterChain), this is a safety net and should log a FATAL ERROR message ** only relevant if the result is a store request -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Issue Comment Edited: (MGNLSTK-614) Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception if i18nBasename property is not set for paragraph
[
http://jira.magnolia-cms.com/browse/MGNLSTK-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27651#action_27651
]
Grégory Joseph edited comment on MGNLSTK-614 at 3/26/10 12:24 PM:
--
{quote}Calling \$\{i18n[]} in a template that does not define i18nBasename
throws a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no matter
what the i18nBasename is.
{quote}
Makes sense, especially since we always a fallback to the default message
bundle anyway (i think)
{quote}
Having no i18nBasename property in the paragraph definition should IMO be
handled as if the i18n messages file isn't available and should not result in
an exception.
{quote}
It should probably have the same behavior as
{{info.magnolia.cms.i18n.EmptyMessages}}.
{quote}
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
{quote}
That would just be confusing.
{quote}
Christian Ringele added a comment - 26/Mar/10 12:00 PM
I think the i18nBasename property should be definable on the site definition as
a default value.
So paragraphstemplate not defining the value explicit, would inherit it from
the site configuration.
{quote}
I'm not sure about this: you'll want to redefine that property on your custom
site to override the messages such as read on etc; BUT the *same*
i18nBasename is also used to translate the paragraphs and templates
names/definitions.
I like the idea, but we'd need some clarifications as to what translations go
where. Perhaps the few translations such as read on should not even be in the
paragraph definition's translations. OR, the site-i18nBasename could have
priority, and fall back to the paragraph's for keys that are not defined in the
site's i18n bundle.
was (Author: gjoseph):
{quote}Calling \${i18n[]} in a template that does not define
i18nBasename throws a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no matter
what the i18nBasename is.
{quote}
Makes sense, especially since we always a fallback to the default message
bundle anyway (i think)
{quote}
Having no i18nBasename property in the paragraph definition should IMO be
handled as if the i18n messages file isn't available and should not result in
an exception.
{quote}
It should probably have the same behavior as
{{info.magnolia.cms.i18n.EmptyMessages}}.
{quote}
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
{quote}
That would just be confusing.
{quote}
Christian Ringele added a comment - 26/Mar/10 12:00 PM
I think the i18nBasename property should be definable on the site definition as
a default value.
So paragraphstemplate not defining the value explicit, would inherit it from
the site configuration.
{quote}
I'm not sure about this: you'll want to redefine that property on your custom
site to override the messages such as read on etc; BUT the *same*
i18nBasename is also used to translate the paragraphs and templates
names/definitions.
I like the idea, but we'd need some clarifications as to what translations go
where. Perhaps the few translations such as read on should not even be in the
paragraph definition's translations. OR, the site-i18nBasename could have
priority, and fall back to the paragraph's for keys that are not defined in the
site's i18n bundle.
Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception
if i18nBasename property is not set for paragraph
---
Key: MGNLSTK-614
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-614
Project: Magnolia Standard Templating Kit
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Vivian Steller
Assignee: Philipp Bärfuss
Calling ${i18n[]} in a template that does not define i18nBasename throws
a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no
matter what the i18nBasename is. Having no i18nBasename property in the
paragraph definition should IMO be handled as if the i18n messages file isn't
available and should not result in an exception.
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
--
This message is automatically generated by JIRA.
-
If you think it was
[magnolia-dev] [JIRA] Issue Comment Edited: (MGNLSTK-614) Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception if i18nBasename property is not set for paragraph
[
http://jira.magnolia-cms.com/browse/MGNLSTK-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27651#action_27651
]
Grégory Joseph edited comment on MGNLSTK-614 at 3/26/10 12:24 PM:
--
{quote}Calling \${i18n[]} in a template that does not define i18nBasename
throws a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no matter
what the i18nBasename is.
{quote}
Makes sense, especially since we always a fallback to the default message
bundle anyway (i think)
{quote}
Having no i18nBasename property in the paragraph definition should IMO be
handled as if the i18n messages file isn't available and should not result in
an exception.
{quote}
It should probably have the same behavior as
{{info.magnolia.cms.i18n.EmptyMessages}}.
{quote}
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
{quote}
That would just be confusing.
{quote}
Christian Ringele added a comment - 26/Mar/10 12:00 PM
I think the i18nBasename property should be definable on the site definition as
a default value.
So paragraphstemplate not defining the value explicit, would inherit it from
the site configuration.
{quote}
I'm not sure about this: you'll want to redefine that property on your custom
site to override the messages such as read on etc; BUT the *same*
i18nBasename is also used to translate the paragraphs and templates
names/definitions.
I like the idea, but we'd need some clarifications as to what translations go
where. Perhaps the few translations such as read on should not even be in the
paragraph definition's translations. OR, the site-i18nBasename could have
priority, and fall back to the paragraph's for keys that are not defined in the
site's i18n bundle.
was (Author: gjoseph):
{quote}Calling ${i18n[]} in a template that does not define
i18nBasename throws a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no matter
what the i18nBasename is.
{quote}
Makes sense, especially since we always a fallback to the default message
bundle anyway (i think)
{quote}
Having no i18nBasename property in the paragraph definition should IMO be
handled as if the i18n messages file isn't available and should not result in
an exception.
{quote}
It should probably have the same behavior as
{{info.magnolia.cms.i18n.EmptyMessages}}.
{quote}
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
{quote}
That would just be confusing.
{quote}
Christian Ringele added a comment - 26/Mar/10 12:00 PM
I think the i18nBasename property should be definable on the site definition as
a default value.
So paragraphstemplate not defining the value explicit, would inherit it from
the site configuration.
{quote}
I'm not sure about this: you'll want to redefine that property on your custom
site to override the messages such as read on etc; BUT the *same*
i18nBasename is also used to translate the paragraphs and templates
names/definitions.
I like the idea, but we'd need some clarifications as to what translations go
where. Perhaps the few translations such as read on should not even be in the
paragraph definition's translations. OR, the site-i18nBasename could have
priority, and fall back to the paragraph's for keys that are not defined in the
site's i18n bundle.
Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception
if i18nBasename property is not set for paragraph
---
Key: MGNLSTK-614
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-614
Project: Magnolia Standard Templating Kit
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Vivian Steller
Assignee: Philipp Bärfuss
Calling ${i18n[]} in a template that does not define i18nBasename throws
a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no
matter what the i18nBasename is. Having no i18nBasename property in the
paragraph definition should IMO be handled as if the i18n messages file isn't
available and should not result in an exception.
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
--
This message is automatically generated by JIRA.
-
If you think it was
[magnolia-dev] [JIRA] Commented: (MGNLSTK-614) Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception if i18nBasename property is not set for paragraph
[
http://jira.magnolia-cms.com/browse/MGNLSTK-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27651#action_27651
]
Grégory Joseph commented on MGNLSTK-614:
{quote}Calling ${i18n[]} in a template that does not define i18nBasename
throws a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no matter
what the i18nBasename is.
{quote}
Makes sense, especially since we always a fallback to the default message
bundle anyway (i think)
{quote}
Having no i18nBasename property in the paragraph definition should IMO be
handled as if the i18n messages file isn't available and should not result in
an exception.
{quote}
It should probably have the same behavior as
{{info.magnolia.cms.i18n.EmptyMessages}}.
{quote}
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
{quote}
That would just be confusing.
{quote}
Christian Ringele added a comment - 26/Mar/10 12:00 PM
I think the i18nBasename property should be definable on the site definition as
a default value.
So paragraphstemplate not defining the value explicit, would inherit it from
the site configuration.
{quote}
I'm not sure about this: you'll want to redefine that property on your custom
site to override the messages such as read on etc; BUT the *same*
i18nBasename is also used to translate the paragraphs and templates
names/definitions.
I like the idea, but we'd need some clarifications as to what translations go
where. Perhaps the few translations such as read on should not even be in the
paragraph definition's translations. OR, the site-i18nBasename could have
priority, and fall back to the paragraph's for keys that are not defined in the
site's i18n bundle.
Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception
if i18nBasename property is not set for paragraph
---
Key: MGNLSTK-614
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-614
Project: Magnolia Standard Templating Kit
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Vivian Steller
Assignee: Philipp Bärfuss
Calling ${i18n[]} in a template that does not define i18nBasename throws
a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no
matter what the i18nBasename is. Having no i18nBasename property in the
paragraph definition should IMO be handled as if the i18n messages file isn't
available and should not result in an exception.
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Issue Comment Edited: (MGNLSTK-614) Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception if i18nBasename property is not set for paragraph
[
http://jira.magnolia-cms.com/browse/MGNLSTK-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27651#action_27651
]
Grégory Joseph edited comment on MGNLSTK-614 at 3/26/10 12:24 PM:
--
{quote}Calling $\{i18n[]} in a template that does not define i18nBasename
throws a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no matter
what the i18nBasename is.
{quote}
Makes sense, especially since we always a fallback to the default message
bundle anyway (i think)
{quote}
Having no i18nBasename property in the paragraph definition should IMO be
handled as if the i18n messages file isn't available and should not result in
an exception.
{quote}
It should probably have the same behavior as
{{info.magnolia.cms.i18n.EmptyMessages}}.
{quote}
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
{quote}
That would just be confusing.
{quote}
Christian Ringele added a comment - 26/Mar/10 12:00 PM
I think the i18nBasename property should be definable on the site definition as
a default value.
So paragraphstemplate not defining the value explicit, would inherit it from
the site configuration.
{quote}
I'm not sure about this: you'll want to redefine that property on your custom
site to override the messages such as read on etc; BUT the *same*
i18nBasename is also used to translate the paragraphs and templates
names/definitions.
I like the idea, but we'd need some clarifications as to what translations go
where. Perhaps the few translations such as read on should not even be in the
paragraph definition's translations. OR, the site-i18nBasename could have
priority, and fall back to the paragraph's for keys that are not defined in the
site's i18n bundle.
was (Author: gjoseph):
{quote}Calling \$\{i18n[]} in a template that does not define
i18nBasename throws a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no matter
what the i18nBasename is.
{quote}
Makes sense, especially since we always a fallback to the default message
bundle anyway (i think)
{quote}
Having no i18nBasename property in the paragraph definition should IMO be
handled as if the i18n messages file isn't available and should not result in
an exception.
{quote}
It should probably have the same behavior as
{{info.magnolia.cms.i18n.EmptyMessages}}.
{quote}
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
{quote}
That would just be confusing.
{quote}
Christian Ringele added a comment - 26/Mar/10 12:00 PM
I think the i18nBasename property should be definable on the site definition as
a default value.
So paragraphstemplate not defining the value explicit, would inherit it from
the site configuration.
{quote}
I'm not sure about this: you'll want to redefine that property on your custom
site to override the messages such as read on etc; BUT the *same*
i18nBasename is also used to translate the paragraphs and templates
names/definitions.
I like the idea, but we'd need some clarifications as to what translations go
where. Perhaps the few translations such as read on should not even be in the
paragraph definition's translations. OR, the site-i18nBasename could have
priority, and fall back to the paragraph's for keys that are not defined in the
site's i18n bundle.
Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception
if i18nBasename property is not set for paragraph
---
Key: MGNLSTK-614
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-614
Project: Magnolia Standard Templating Kit
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Vivian Steller
Assignee: Philipp Bärfuss
Calling ${i18n[]} in a template that does not define i18nBasename throws
a freemarker exception Expression i18n is undefined.
I suggest that the i18n array should always be defined in freemarker, no
matter what the i18nBasename is. Having no i18nBasename property in the
paragraph definition should IMO be handled as if the i18n messages file isn't
available and should not result in an exception.
So, this is most probably not a STK issue yet, however, I think it would make
sense to integrate something like ${i18n(...)} (method call, not array) into
STK to achieve the desired behavior.
--
This message is automatically generated by JIRA.
-
If you think it was
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3167) cache: single blocking request can block all other requests to cached content
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27652#action_27652
]
Grégory Joseph commented on MAGNOLIA-3167:
--
I think the main reason we synchronize on the cache instance is to avoid
relying on specifics of EhCache's implementation.
Given the above, we could consider not doing it, but rather change our Cache
interface to enforce locking at key level like EhCache's BlockingCache does (by
means of simply naming methods appropriately, providing extra facilities to do
said locking ourselves (should be doable with java 5's
{{java.util.concurrent.locks}}?), or define such contracts in the javadoc - or
of course all of this)
cache: single blocking request can block all other requests to cached content
--
Key: MAGNOLIA-3167
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3167
Project: Magnolia
Issue Type: Bug
Affects Versions: 3.6.8, 4.1.4, 4.2.3, 4.3.1
Reporter: Philipp Bärfuss
Assignee: Boris Kraft
Fix For: 4.3.x
the cache mechanism can block all requests:
* cache.get() will block if an other request is caching the same key (this is
a feature of the BlockingCache)
** mutex per key kept until cache.put() is called (either with an entry or
null value)
* this code is again in a synchronized block which synchronizes on the cache
object itself
** this blocks all other request trying to enter the synchronization block
The critical scenario which can prevent magnolia from responding any request
(all threads blocked) is the following
1) first request to a resource which is slow or never returns (request to a
service, poor database connection, ..)
2) second request to the same resource: -- thread is blocked at
EhCacheWrapper.get(key):56, but also keeps the lock on the cache
3) all other caching requests are blocked (no matter which url) due to the
synchronize block at Default.shouldCache(Cache, AggregationState,
FlushPolicy):89
Solution:
* don't synchronize on the cache (why are we doing this???)
* allow configuration of
[BlockingCache.timeoutMillis|http://ehcache.org/apidocs/net/sf/ehcache/constructs/blocking/BlockingCache.html#timeoutMillis]
** throw an exception if a request waits for to long
* uncomment finally block at doFilter(HttpServletRequest,
HttpServletResponse, FilterChain), this is a safety net and should log a
FATAL ERROR message
** only relevant if the result is a store request
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MGNLGROOVY-21) If a property is of type binary, return the NodeData instance, not the inputStream
If a property is of type binary, return the NodeData instance, not the inputStream -- Key: MGNLGROOVY-21 URL: http://jira.magnolia-cms.com/browse/MGNLGROOVY-21 Project: Magnolia Groovy Module Issue Type: Improvement Components: integration Affects Versions: 1.0 Reporter: Federico Grilli Assignee: Federico Grilli Fix For: 1.1 When writing a groovy script to do a bulk images update in the data repository I realized that having the MgnlGroovyNode return an instance of the inputStream is not very much useful. You can't access, for example, file name, height, width and other attributes of that image. it is much more handy in this case to have the BinaryNodeData itself. It is also important that the javadoc for MgnlGroovyNode.getNodeDataValue(..) states clearly what kind of object is returned according to the underlying jcr type. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Resolved: (MGNLGROOVY-21) If a property is of type binary, return the NodeData instance, not the inputStream
[ http://jira.magnolia-cms.com/browse/MGNLGROOVY-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Federico Grilli resolved MGNLGROOVY-21. --- Resolution: Fixed If a property is of type binary, return the NodeData instance, not the inputStream -- Key: MGNLGROOVY-21 URL: http://jira.magnolia-cms.com/browse/MGNLGROOVY-21 Project: Magnolia Groovy Module Issue Type: Improvement Components: integration Affects Versions: 1.0 Reporter: Federico Grilli Assignee: Federico Grilli Fix For: 1.1 When writing a groovy script to do a bulk images update in the data repository I realized that having the MgnlGroovyNode return an instance of the inputStream is not very much useful. You can't access, for example, file name, height, width and other attributes of that image. it is much more handy in this case to have the BinaryNodeData itself. It is also important that the javadoc for MgnlGroovyNode.getNodeDataValue(..) states clearly what kind of object is returned according to the underlying jcr type. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MGNLGROOVY-21) If a property is of type binary, return the NodeData instance, not the inputStream
[ http://jira.magnolia-cms.com/browse/MGNLGROOVY-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27654#action_27654 ] Hudson CI server commented on MGNLGROOVY-21: Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia-module-groovy #355|http://hudson.magnolia-cms.com/job/magnolia-module-groovy/355/] MGNLGROOVY-21: return nodeData instance if property type is Binary. Added javadoc. If a property is of type binary, return the NodeData instance, not the inputStream -- Key: MGNLGROOVY-21 URL: http://jira.magnolia-cms.com/browse/MGNLGROOVY-21 Project: Magnolia Groovy Module Issue Type: Improvement Components: integration Affects Versions: 1.0 Reporter: Federico Grilli Assignee: Federico Grilli Fix For: 1.1 When writing a groovy script to do a bulk images update in the data repository I realized that having the MgnlGroovyNode return an instance of the inputStream is not very much useful. You can't access, for example, file name, height, width and other attributes of that image. it is much more handy in this case to have the BinaryNodeData itself. It is also important that the javadoc for MgnlGroovyNode.getNodeDataValue(..) states clearly what kind of object is returned according to the underlying jcr type. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3167) cache: single blocking request can block all other requests to cached content
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27656#action_27656
]
Jan Haderka commented on MAGNOLIA-3167:
---
Actually the reason we synchronize is the related to the fact that we use
blocking cache by default. If I'm not mistaken the scenario that requires
synchronization is this:
# Requst A calls {{hasElement()}} which in turn will call {{get(key)}}. Since
key is not yet in the cache {{get()}} method will return null and place a mutex
on the key. At which point {{hasElement()}} return false and cache policy will
return store. and request will proceed to generate the cache entry
# while the cache entry is being generated, the request B comes for the same
resource, and the {{hasElement()}} will block in the subsequent call to
{{cache.get(key)}} (since we use the blocking cache)
# still while the cache entry requested by the A is generated, the request C
comes and gets stuck in the exactly same place as request B
# now finally, the cache entry have been generated and placed in the cache at
which point the request A returns.
# since the cache entry have been put in the cache, it will remove the mutex
and request B will proceed, find the entry in the cache, and will go on with
the useCache behavior.
# unfortunatelly, the reuqest C will be still blocked and will stay that way
forever since removing the mutex by A released only the first blocked {{get()}}
call, but all of them. So what applies to C applies to any number of requests
that come in that very same time window.
The behavior above was a reason why we introduced the synchronization on cache
in 3.6. I might have explained it in even more details in the user list in the
past.
Now, considering this issue, the timeout is probably bast solution to avoid
being locked forever if the thread handling request A gets stuck forever.
As for serving multiple entries from the cache, we should lock on the key
rather then on the whole cache so only the requests to the cache for given key
ever gets serialized access as Greg already suggested above. ... Alternatively
we can drop whole policy/executor based implementation and implement cache in a
way that would not allow calls to cache to escape ever.
cache: single blocking request can block all other requests to cached content
--
Key: MAGNOLIA-3167
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3167
Project: Magnolia
Issue Type: Bug
Affects Versions: 3.6.8, 4.1.4, 4.2.3, 4.3.1
Reporter: Philipp Bärfuss
Assignee: Boris Kraft
Fix For: 4.3.x
the cache mechanism can block all requests:
* cache.get() will block if an other request is caching the same key (this is
a feature of the BlockingCache)
** mutex per key kept until cache.put() is called (either with an entry or
null value)
* this code is again in a synchronized block which synchronizes on the cache
object itself
** this blocks all other request trying to enter the synchronization block
The critical scenario which can prevent magnolia from responding any request
(all threads blocked) is the following
1) first request to a resource which is slow or never returns (request to a
service, poor database connection, ..)
2) second request to the same resource: -- thread is blocked at
EhCacheWrapper.get(key):56, but also keeps the lock on the cache
3) all other caching requests are blocked (no matter which url) due to the
synchronize block at Default.shouldCache(Cache, AggregationState,
FlushPolicy):89
Solution:
* don't synchronize on the cache (why are we doing this???)
* allow configuration of
[BlockingCache.timeoutMillis|http://ehcache.org/apidocs/net/sf/ehcache/constructs/blocking/BlockingCache.html#timeoutMillis]
** throw an exception if a request waits for to long
* uncomment finally block at doFilter(HttpServletRequest,
HttpServletResponse, FilterChain), this is a safety net and should log a
FATAL ERROR message
** only relevant if the result is a store request
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3167) cache: single blocking request can block all other requests to cached content
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Haderka updated MAGNOLIA-3167: -- Component/s: cache cache: single blocking request can block all other requests to cached content -- Key: MAGNOLIA-3167 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3167 Project: Magnolia Issue Type: Bug Components: cache Affects Versions: 3.6.8, 4.1.4, 4.2.3, 4.3.1 Reporter: Philipp Bärfuss Assignee: Boris Kraft Fix For: 4.3.x the cache mechanism can block all requests: * cache.get() will block if an other request is caching the same key (this is a feature of the BlockingCache) ** mutex per key kept until cache.put() is called (either with an entry or null value) * this code is again in a synchronized block which synchronizes on the cache object itself ** this blocks all other request trying to enter the synchronization block The critical scenario which can prevent magnolia from responding any request (all threads blocked) is the following 1) first request to a resource which is slow or never returns (request to a service, poor database connection, ..) 2) second request to the same resource: -- thread is blocked at EhCacheWrapper.get(key):56, but also keeps the lock on the cache 3) all other caching requests are blocked (no matter which url) due to the synchronize block at Default.shouldCache(Cache, AggregationState, FlushPolicy):89 Solution: * don't synchronize on the cache (why are we doing this???) * allow configuration of [BlockingCache.timeoutMillis|http://ehcache.org/apidocs/net/sf/ehcache/constructs/blocking/BlockingCache.html#timeoutMillis] ** throw an exception if a request waits for to long * uncomment finally block at doFilter(HttpServletRequest, HttpServletResponse, FilterChain), this is a safety net and should log a FATAL ERROR message ** only relevant if the result is a store request -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (STORE-1) Build (ldap, ...)
[ http://jira.magnolia-cms.com/browse/STORE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27657#action_27657 ] Hudson CI server commented on STORE-1: -- Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia-store #33|http://hudson.magnolia-cms.com/job/magnolia-store/33/] [maven-release-plugin] prepare release magnolia-store-1.0.3 Build (ldap, ...) - Key: STORE-1 URL: http://jira.magnolia-cms.com/browse/STORE-1 Project: Magnolia Store (server-side) Issue Type: Task Security Level: Public Components: server Reporter: Grégory Joseph Assignee: Grégory Joseph Fix For: 1.0 * simplify configuration files, remove duplicates * use ldap * basic editor/publisher role -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3167) cache: single blocking request can block all other requests to cached content
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27658#action_27658
]
Philipp Bärfuss commented on MAGNOLIA-3167:
---
{quote}unfortunatelly, the reuqest C will be still blocked and will stay that
way forever since removing the mutex{quote}
If I understand that right the following will happen if the synchronization
block is removed
1) A gets mutext
2) B tries to acquire the mutix
3) C tries to acquire the mutix
4) A releases (calls put)
5) B succeeds but does never release the mutex
-- C is blocked for ever
Well then we have to find a better solution, just blocking all requests for
that reason is not an option. But looking at the following code of
net.sf.ehcache.constructs.blocking.BlockingCache.get(Object) (version 1.5)
{code}
if (element != null) {
//ok let the other threads in
lock.release();
return element;
} else {
{code}
It seams as if they handle the case in which the cache was populated while that
thread was blocked. Either something is very fishy but that extra
synchronization block is wrong/obsolete.
cache: single blocking request can block all other requests to cached content
--
Key: MAGNOLIA-3167
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3167
Project: Magnolia
Issue Type: Bug
Components: cache
Affects Versions: 3.6.8, 4.1.4, 4.2.3, 4.3.1
Reporter: Philipp Bärfuss
Assignee: Boris Kraft
Fix For: 4.3.x
the cache mechanism can block all requests:
* cache.get() will block if an other request is caching the same key (this is
a feature of the BlockingCache)
** mutex per key kept until cache.put() is called (either with an entry or
null value)
* this code is again in a synchronized block which synchronizes on the cache
object itself
** this blocks all other request trying to enter the synchronization block
The critical scenario which can prevent magnolia from responding any request
(all threads blocked) is the following
1) first request to a resource which is slow or never returns (request to a
service, poor database connection, ..)
2) second request to the same resource: -- thread is blocked at
EhCacheWrapper.get(key):56, but also keeps the lock on the cache
3) all other caching requests are blocked (no matter which url) due to the
synchronize block at Default.shouldCache(Cache, AggregationState,
FlushPolicy):89
Solution:
* don't synchronize on the cache (why are we doing this???)
* allow configuration of
[BlockingCache.timeoutMillis|http://ehcache.org/apidocs/net/sf/ehcache/constructs/blocking/BlockingCache.html#timeoutMillis]
** throw an exception if a request waits for to long
* uncomment finally block at doFilter(HttpServletRequest,
HttpServletResponse, FilterChain), this is a safety net and should log a
FATAL ERROR message
** only relevant if the result is a store request
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Assigned: (MAGNOLIA-2989) Admin interface causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grégory Joseph reassigned MAGNOLIA-2989: Assignee: Grégory Joseph (was: Philipp Bärfuss) Admin interface causes getWriter() has already been called for this response error to be thrown on Glassfish v3 - Key: MAGNOLIA-2989 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989 Project: Magnolia Issue Type: Bug Components: admininterface Affects Versions: 4.2.3 Reporter: joshua portway Assignee: Grégory Joseph Fix For: 4.3.x Attachments: NetBeansScreenSnapz001.png, screenshot-2.jpg, vcs-diff7973054169198951414.patch Original Estimate: 0d Remaining Estimate: 0d Immediately after logging in this error is thrown by the server, and the admin page never renders. This means that magnolia is effectively completely unusable under Glassfish v3. This has been a problem in previous version of glassfish, and with previous versions of Magnolia (going back to at least 3.5, probably earlier, but I can't remember), but in previous version of glassfish the problem only caused a warning to be logged. Glassfish version 3 treats this as a fatal error and aborts rendering the page. With previous versions of Magnolia running under glassfish 2.5 (such as sites I currently have running) it's only the admin interface that causes this problem - rendering normal pages does not cause a warning to be logged. here's the stack trace : java.lang.IllegalStateException: PWC3990: getWriter() has already been called for this response at org.apache.catalina.connector.Response.getOutputStream(Response.java:676) at org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205) at info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106) at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:84) at info.magnolia.cms.filters.CosMultipartRequestFilter.doFilter(CosMultipartRequestFilter.java:87) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.BaseSecurityFilter.doFilter(BaseSecurityFilter.java:61) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.LogoutFilter.doFilter(LogoutFilter.java:89) at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.auth.login.LoginFilter.doFilter(LoginFilter.java:84) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.ContentTypeFilter.doFilter(ContentTypeFilter.java:84) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.ContextFilter.doFilter(ContextFilter.java:87) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:64) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:96) at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:199) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
[magnolia-dev] [JIRA] Work started: (MAGNOLIA-2989) Admin interface causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MAGNOLIA-2989 started by Grégory Joseph. Admin interface causes getWriter() has already been called for this response error to be thrown on Glassfish v3 - Key: MAGNOLIA-2989 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989 Project: Magnolia Issue Type: Bug Components: admininterface Affects Versions: 4.2.3 Reporter: joshua portway Assignee: Grégory Joseph Fix For: 4.3.x Attachments: NetBeansScreenSnapz001.png, screenshot-2.jpg, vcs-diff7973054169198951414.patch Original Estimate: 0d Remaining Estimate: 0d Immediately after logging in this error is thrown by the server, and the admin page never renders. This means that magnolia is effectively completely unusable under Glassfish v3. This has been a problem in previous version of glassfish, and with previous versions of Magnolia (going back to at least 3.5, probably earlier, but I can't remember), but in previous version of glassfish the problem only caused a warning to be logged. Glassfish version 3 treats this as a fatal error and aborts rendering the page. With previous versions of Magnolia running under glassfish 2.5 (such as sites I currently have running) it's only the admin interface that causes this problem - rendering normal pages does not cause a warning to be logged. here's the stack trace : java.lang.IllegalStateException: PWC3990: getWriter() has already been called for this response at org.apache.catalina.connector.Response.getOutputStream(Response.java:676) at org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205) at info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106) at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:84) at info.magnolia.cms.filters.CosMultipartRequestFilter.doFilter(CosMultipartRequestFilter.java:87) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.BaseSecurityFilter.doFilter(BaseSecurityFilter.java:61) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.LogoutFilter.doFilter(LogoutFilter.java:89) at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.auth.login.LoginFilter.doFilter(LoginFilter.java:84) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.ContentTypeFilter.doFilter(ContentTypeFilter.java:84) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.ContextFilter.doFilter(ContextFilter.java:87) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:64) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:96) at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:199) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97) at
[magnolia-dev] [JIRA] Updated: (MAGNOLIA-2989) GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grégory Joseph updated MAGNOLIA-2989: - Summary: GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3 (was: Admin interface causes getWriter() has already been called for this response error to be thrown on Glassfish v3) Component/s: cache core GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3 Key: MAGNOLIA-2989 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989 Project: Magnolia Issue Type: Bug Components: admininterface, cache, core Affects Versions: 4.2.3 Reporter: joshua portway Assignee: Grégory Joseph Fix For: 4.3.x Attachments: NetBeansScreenSnapz001.png, screenshot-2.jpg, vcs-diff7973054169198951414.patch Original Estimate: 0d Remaining Estimate: 0d Immediately after logging in this error is thrown by the server, and the admin page never renders. This means that magnolia is effectively completely unusable under Glassfish v3. This has been a problem in previous version of glassfish, and with previous versions of Magnolia (going back to at least 3.5, probably earlier, but I can't remember), but in previous version of glassfish the problem only caused a warning to be logged. Glassfish version 3 treats this as a fatal error and aborts rendering the page. With previous versions of Magnolia running under glassfish 2.5 (such as sites I currently have running) it's only the admin interface that causes this problem - rendering normal pages does not cause a warning to be logged. here's the stack trace : java.lang.IllegalStateException: PWC3990: getWriter() has already been called for this response at org.apache.catalina.connector.Response.getOutputStream(Response.java:676) at org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205) at info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106) at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:84) at info.magnolia.cms.filters.CosMultipartRequestFilter.doFilter(CosMultipartRequestFilter.java:87) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.BaseSecurityFilter.doFilter(BaseSecurityFilter.java:61) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.LogoutFilter.doFilter(LogoutFilter.java:89) at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.security.auth.login.LoginFilter.doFilter(LoginFilter.java:84) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.ContentTypeFilter.doFilter(ContentTypeFilter.java:84) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.ContextFilter.doFilter(ContextFilter.java:87) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:64) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70) at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:96) at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:199) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at
[magnolia-dev] [JIRA] Resolved: (MAGNOLIA-2989) GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grégory Joseph resolved MAGNOLIA-2989.
--
Resolution: Fixed
Patch applied, thanks !
At first I was dubious, since we make sure we write to the same single stream,
whether getWriter or getOutputStream is called further down the chain with
{{info.magnolia.module.cache.filter.CacheResponseWrapper}} (so that renderers
and template engines may use whatever they want); however this specific filter
called getOutputstream AFTER the use of this response wrapper.
(the wrapper is also used when caching content, which does not happen in this
case)
GZipFilter causes getWriter() has already been called for this response
error to be thrown on Glassfish v3
Key: MAGNOLIA-2989
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989
Project: Magnolia
Issue Type: Bug
Components: admininterface, cache, core
Affects Versions: 4.2.3
Reporter: joshua portway
Assignee: Grégory Joseph
Fix For: 4.3.x
Attachments: NetBeansScreenSnapz001.png, screenshot-2.jpg,
vcs-diff7973054169198951414.patch
Original Estimate: 0d
Remaining Estimate: 0d
Immediately after logging in this error is thrown by the server, and the
admin page never renders.
This means that magnolia is effectively completely unusable under Glassfish
v3.
This has been a problem in previous version of glassfish, and with previous
versions of Magnolia (going back to at least 3.5, probably earlier, but I
can't remember), but in previous version of glassfish the problem only caused
a warning to be logged. Glassfish version 3 treats this as a fatal error and
aborts rendering the page.
With previous versions of Magnolia running under glassfish 2.5 (such as sites
I currently have running) it's only the admin interface that causes this
problem - rendering normal pages does not cause a warning to be logged.
here's the stack trace :
java.lang.IllegalStateException: PWC3990: getWriter() has already been called
for this response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:676)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205)
at
info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:84)
at
info.magnolia.cms.filters.CosMultipartRequestFilter.doFilter(CosMultipartRequestFilter.java:87)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.security.BaseSecurityFilter.doFilter(BaseSecurityFilter.java:61)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.security.LogoutFilter.doFilter(LogoutFilter.java:89)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.security.auth.login.LoginFilter.doFilter(LoginFilter.java:84)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.filters.ContentTypeFilter.doFilter(ContentTypeFilter.java:84)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.filters.ContextFilter.doFilter(ContextFilter.java:87)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:64)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:96)
at
info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:199)
at
[magnolia-dev] [JIRA] Updated: (MAGNOLIA-2989) GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grégory Joseph updated MAGNOLIA-2989:
-
Attachment: MAGNOLIA-2989-stracktrace.txt
Description:
Immediately after logging in this error is thrown by the server, and the admin
page never renders.
This means that magnolia is effectively completely unusable under Glassfish v3.
This has been a problem in previous version of glassfish, and with previous
versions of Magnolia (going back to at least 3.5, probably earlier, but I can't
remember), but in previous version of glassfish the problem only caused a
warning to be logged. Glassfish version 3 treats this as a fatal error and
aborts rendering the page.
With previous versions of Magnolia running under glassfish 2.5 (such as sites I
currently have running) it's only the admin interface that causes this problem
- rendering normal pages does not cause a warning to be logged.
here's the stack trace :
{noformat}
java.lang.IllegalStateException: PWC3990: getWriter() has already been called
for this response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:676)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205)
at
info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
[...]
{noformat}
was:
Immediately after logging in this error is thrown by the server, and the admin
page never renders.
This means that magnolia is effectively completely unusable under Glassfish v3.
This has been a problem in previous version of glassfish, and with previous
versions of Magnolia (going back to at least 3.5, probably earlier, but I can't
remember), but in previous version of glassfish the problem only caused a
warning to be logged. Glassfish version 3 treats this as a fatal error and
aborts rendering the page.
With previous versions of Magnolia running under glassfish 2.5 (such as sites I
currently have running) it's only the admin interface that causes this problem
- rendering normal pages does not cause a warning to be logged.
here's the stack trace :
java.lang.IllegalStateException: PWC3990: getWriter() has already been called
for this response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:676)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205)
at
info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:84)
at
info.magnolia.cms.filters.CosMultipartRequestFilter.doFilter(CosMultipartRequestFilter.java:87)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.security.BaseSecurityFilter.doFilter(BaseSecurityFilter.java:61)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at info.magnolia.cms.security.LogoutFilter.doFilter(LogoutFilter.java:89)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.security.auth.login.LoginFilter.doFilter(LoginFilter.java:84)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.filters.ContentTypeFilter.doFilter(ContentTypeFilter.java:84)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.filters.ContextFilter.doFilter(ContextFilter.java:87)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82)
at
info.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:64)
at
info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:70)
at
info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:96)
at
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-2989) GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27663#action_27663
]
Hudson CI server commented on MAGNOLIA-2989:
Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif!
[magnolia_main-trunk
#1581|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1581/]
MAGNOLIA-2989: patch applied, thanks to Joshua Portway ! Only bother to
write anything to the output stream if there's something to write (length of
response 0)
GZipFilter causes getWriter() has already been called for this response
error to be thrown on Glassfish v3
Key: MAGNOLIA-2989
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989
Project: Magnolia
Issue Type: Bug
Components: admininterface, cache, core
Affects Versions: 4.2.3
Reporter: joshua portway
Assignee: Grégory Joseph
Fix For: 4.3.x
Attachments: MAGNOLIA-2989-stracktrace.txt,
NetBeansScreenSnapz001.png, screenshot-2.jpg,
vcs-diff7973054169198951414.patch
Original Estimate: 0d
Remaining Estimate: 0d
Immediately after logging in this error is thrown by the server, and the
admin page never renders.
This means that magnolia is effectively completely unusable under Glassfish
v3.
This has been a problem in previous version of glassfish, and with previous
versions of Magnolia (going back to at least 3.5, probably earlier, but I
can't remember), but in previous version of glassfish the problem only caused
a warning to be logged. Glassfish version 3 treats this as a fatal error and
aborts rendering the page.
With previous versions of Magnolia running under glassfish 2.5 (such as sites
I currently have running) it's only the admin interface that causes this
problem - rendering normal pages does not cause a warning to be logged.
here's the stack trace :
{noformat}
java.lang.IllegalStateException: PWC3990: getWriter() has already been called
for this response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:676)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205)
at
info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
[...]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-2989) GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27664#action_27664
]
Grégory Joseph commented on MAGNOLIA-2989:
--
Also applied patch to the 4.2, 4.1 and 4.0 branches, although 4.1 and 4.0 will
probably still suffer from MAGNOLIA-2936.
GZipFilter causes getWriter() has already been called for this response
error to be thrown on Glassfish v3
Key: MAGNOLIA-2989
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989
Project: Magnolia
Issue Type: Bug
Components: admininterface, cache, core
Affects Versions: 4.2.3
Reporter: joshua portway
Assignee: Grégory Joseph
Fix For: 4.3.x
Attachments: MAGNOLIA-2989-stracktrace.txt,
NetBeansScreenSnapz001.png, screenshot-2.jpg,
vcs-diff7973054169198951414.patch
Original Estimate: 0d
Remaining Estimate: 0d
Immediately after logging in this error is thrown by the server, and the
admin page never renders.
This means that magnolia is effectively completely unusable under Glassfish
v3.
This has been a problem in previous version of glassfish, and with previous
versions of Magnolia (going back to at least 3.5, probably earlier, but I
can't remember), but in previous version of glassfish the problem only caused
a warning to be logged. Glassfish version 3 treats this as a fatal error and
aborts rendering the page.
With previous versions of Magnolia running under glassfish 2.5 (such as sites
I currently have running) it's only the admin interface that causes this
problem - rendering normal pages does not cause a warning to be logged.
here's the stack trace :
{noformat}
java.lang.IllegalStateException: PWC3990: getWriter() has already been called
for this response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:676)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205)
at
info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
[...]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-2989) GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27665#action_27665
]
Hudson CI server commented on MAGNOLIA-2989:
Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif!
[magnolia_main-4.2-branch
#26|http://hudson.magnolia-cms.com/job/magnolia_main-4.2-branch/26/]
merging r33320 from trunk: MAGNOLIA-2989: patch applied, thanks to Joshua
Portway ! Only bother to write anything to the output stream if there's
something to write (length of response 0)
GZipFilter causes getWriter() has already been called for this response
error to be thrown on Glassfish v3
Key: MAGNOLIA-2989
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989
Project: Magnolia
Issue Type: Bug
Components: admininterface, cache, core
Affects Versions: 4.2.3
Reporter: joshua portway
Assignee: Grégory Joseph
Fix For: 4.3.x
Attachments: MAGNOLIA-2989-stracktrace.txt,
NetBeansScreenSnapz001.png, screenshot-2.jpg,
vcs-diff7973054169198951414.patch
Original Estimate: 0d
Remaining Estimate: 0d
Immediately after logging in this error is thrown by the server, and the
admin page never renders.
This means that magnolia is effectively completely unusable under Glassfish
v3.
This has been a problem in previous version of glassfish, and with previous
versions of Magnolia (going back to at least 3.5, probably earlier, but I
can't remember), but in previous version of glassfish the problem only caused
a warning to be logged. Glassfish version 3 treats this as a fatal error and
aborts rendering the page.
With previous versions of Magnolia running under glassfish 2.5 (such as sites
I currently have running) it's only the admin interface that causes this
problem - rendering normal pages does not cause a warning to be logged.
here's the stack trace :
{noformat}
java.lang.IllegalStateException: PWC3990: getWriter() has already been called
for this response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:676)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205)
at
info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
[...]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-2989) GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27666#action_27666
]
Hudson CI server commented on MAGNOLIA-2989:
Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif!
[magnolia_main-4.0-branch
#76|http://hudson.magnolia-cms.com/job/magnolia_main-4.0-branch/76/]
merging r33320 from trunk: MAGNOLIA-2989: patch applied, thanks to Joshua
Portway ! Only bother to write anything to the output stream if there's
something to write (length of response 0)
GZipFilter causes getWriter() has already been called for this response
error to be thrown on Glassfish v3
Key: MAGNOLIA-2989
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989
Project: Magnolia
Issue Type: Bug
Components: admininterface, cache, core
Affects Versions: 4.2.3
Reporter: joshua portway
Assignee: Grégory Joseph
Fix For: 4.3.x
Attachments: MAGNOLIA-2989-stracktrace.txt,
NetBeansScreenSnapz001.png, screenshot-2.jpg,
vcs-diff7973054169198951414.patch
Original Estimate: 0d
Remaining Estimate: 0d
Immediately after logging in this error is thrown by the server, and the
admin page never renders.
This means that magnolia is effectively completely unusable under Glassfish
v3.
This has been a problem in previous version of glassfish, and with previous
versions of Magnolia (going back to at least 3.5, probably earlier, but I
can't remember), but in previous version of glassfish the problem only caused
a warning to be logged. Glassfish version 3 treats this as a fatal error and
aborts rendering the page.
With previous versions of Magnolia running under glassfish 2.5 (such as sites
I currently have running) it's only the admin interface that causes this
problem - rendering normal pages does not cause a warning to be logged.
here's the stack trace :
{noformat}
java.lang.IllegalStateException: PWC3990: getWriter() has already been called
for this response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:676)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205)
at
info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
[...]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-2989) GZipFilter causes getWriter() has already been called for this response error to be thrown on Glassfish v3
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27667#action_27667
]
Hudson CI server commented on MAGNOLIA-2989:
Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif!
[magnolia_main-4.1-branch
#23|http://hudson.magnolia-cms.com/job/magnolia_main-4.1-branch/23/]
merging r33320 from trunk: MAGNOLIA-2989: patch applied, thanks to Joshua
Portway ! Only bother to write anything to the output stream if there's
something to write (length of response 0)
GZipFilter causes getWriter() has already been called for this response
error to be thrown on Glassfish v3
Key: MAGNOLIA-2989
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2989
Project: Magnolia
Issue Type: Bug
Components: admininterface, cache, core
Affects Versions: 4.2.3
Reporter: joshua portway
Assignee: Grégory Joseph
Fix For: 4.3.x
Attachments: MAGNOLIA-2989-stracktrace.txt,
NetBeansScreenSnapz001.png, screenshot-2.jpg,
vcs-diff7973054169198951414.patch
Original Estimate: 0d
Remaining Estimate: 0d
Immediately after logging in this error is thrown by the server, and the
admin page never renders.
This means that magnolia is effectively completely unusable under Glassfish
v3.
This has been a problem in previous version of glassfish, and with previous
versions of Magnolia (going back to at least 3.5, probably earlier, but I
can't remember), but in previous version of glassfish the problem only caused
a warning to be logged. Glassfish version 3 treats this as a fatal error and
aborts rendering the page.
With previous versions of Magnolia running under glassfish 2.5 (such as sites
I currently have running) it's only the admin interface that causes this
problem - rendering normal pages does not cause a warning to be logged.
here's the stack trace :
{noformat}
java.lang.IllegalStateException: PWC3990: getWriter() has already been called
for this response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:676)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:205)
at
info.magnolia.module.cache.filter.GZipFilter.doFilter(GZipFilter.java:106)
at
info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:62)
[...]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3014) call to response.getOutputStream() during the rendering process fails
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=27668#action_27668
]
Grégory Joseph commented on MAGNOLIA-3014:
--
Couldn't this be solved by using
{{info.magnolia.module.cache.filter.CacheResponseWrapper}} (or similar) ?
It's currently only used when caching content
({{info.magnolia.module.cache.executor.Store}}) and by the GZipFilter.
Which you actually only run into this sort of issue when you're not caching
(which is the case in the in the linked support issue, see
{{executor.Bypass.processCacheReques}} in the stacktrace), which is an ugly
side-effect.
call to response.getOutputStream() during the rendering process fails
-
Key: MAGNOLIA-3014
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3014
Project: Magnolia
Issue Type: Bug
Affects Versions: 4.2
Reporter: Philipp Bärfuss
Assignee: Boris Kraft
Fix For: 4.3.x
After the refactoring of the renderers in 4.0 we pass now the writer directly
to the renderer. Which is done by calling response.getWriter(). This is very
useful as this makes the rendering in general independent of the servlet API
and allows direct calls to the rendering engine by Java code (for instance
servlets or tests).
Unfortunately a later call to response.getOutputStream() will fail as this
violates the Servlet API specifications. There are several solutions possible.
Workaround: registering your custom servlet (at the servlets filter) and let
the request be rendered by the servlet and not by the rendering filter
A) Pass a lazy wrapper instead of the writer
instead of passing the writer we pass a lazy wrapper which will call
response.getWriter() only once the first operation is performed on the writer
- not very transparent
+ no changes in the API needed
B) Change the API
Support both variations of renderers. This can be achieved by various ways
B.1) pass a object (magnolia response?) providing both methods which delegate
to the response
B.2) have two methods render(.., writer) and render(.. stream) (most likely
by having two interfaces)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Hudson build became unstable: magnolia-bundle_trunk #864
See http://hudson.magnolia-cms.com/job/magnolia-bundle_trunk/864/ For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Hudson build became unstable: ma gnolia-bundle_4-0-branch » magnolia-integration -tests #104
See http://hudson.magnolia-cms.com/job/magnolia-bundle_4-0-branch/info.magnolia$magnolia-integration-tests/104/ For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Hudson build became unstable: ma gnolia-bundle_trunk » magnolia-integration-test s #864
See http://hudson.magnolia-cms.com/job/magnolia-bundle_trunk/info.magnolia$magnolia-integration-tests/864/ For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Hudson build became unstable: magnolia-bundle_4-0-branch #104
See http://hudson.magnolia-cms.com/job/magnolia-bundle_4-0-branch/104/ For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Hudson build is back to stable: magnolia-bundle_trunk » magnolia-integration-t ests #865
See http://hudson.magnolia-cms.com/job/magnolia-bundle_trunk/info.magnolia$magnolia-integration-tests/865/ For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Hudson build is back to stable: magnolia-bundle_trunk #865
See http://hudson.magnolia-cms.com/job/magnolia-bundle_trunk/865/ For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Hudson build is back to stable: magnolia-bundle_4-0-branch #105
See http://hudson.magnolia-cms.com/job/magnolia-bundle_4-0-branch/105/ For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] Hudson build is back to stable: magnolia-bundle_4-0-branch » magnolia-integrat ion-tests #105
See http://hudson.magnolia-cms.com/job/magnolia-bundle_4-0-branch/info.magnolia$magnolia-integration-tests/105/ For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
