[jira] Updated: (COCOON-2072) JSR-168 Portlet-aware CookieModule
[ https://issues.apache.org/jira/browse/COCOON-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated COCOON-2072: --- Affects Version/s: 2.1.12-dev (Current SVN) (was: 2.1.11) JSR-168 Portlet-aware CookieModule -- Key: COCOON-2072 URL: https://issues.apache.org/jira/browse/COCOON-2072 Project: Cocoon Issue Type: Improvement Components: Blocks: Portal Affects Versions: 2.1.12-dev (Current SVN) Reporter: Francesco Chicchiriccò Attachments: PortletAwareCookieModule.java A FAQ here: http://wiki.java.net/bin/view/Portlet/JSR168FAQ#Is_there_a_hack_to_get_set_cooki says that some JSR-168 containers provide their javax.portlet.PortletRequest implementation with cookies, even thought embedded in a string. Looking at sources of Jakarta Pluto (org.apache.pluto.internal.impl.PortletRequestImpl) and Sun's Open Portal - free version of Sun JES Portal Server - (com.sun.portal.portlet.impl.PortletRequestImpl), I found that this is true for both. See attached a simple org.apache.cocoon.components.modules.input.CookieModule extension that can handle all that above, providing cookie access to portlets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-2282) JSR-168 Portlet preferences input module
[ https://issues.apache.org/jira/browse/COCOON-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated COCOON-2282: --- Affects Version/s: 2.1.12-dev (Current SVN) (was: 2.1.11) Any committer interested in this? JSR-168 Portlet preferences input module Key: COCOON-2282 URL: https://issues.apache.org/jira/browse/COCOON-2282 Project: Cocoon Issue Type: Improvement Components: Blocks: Portal Affects Versions: 2.1.12-dev (Current SVN) Reporter: Francesco Chicchiriccò Attachments: PortletPreferencesModule.java A sitemap input module for fetching PortletPreferences as they were cookies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-2284) Making CForms working in JSR-168 portlets
[ https://issues.apache.org/jira/browse/COCOON-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated COCOON-2284: --- Affects Version/s: 2.1.12-dev (Current SVN) (was: 2.1.11) Any committer interested in this? Making CForms working in JSR-168 portlets - Key: COCOON-2284 URL: https://issues.apache.org/jira/browse/COCOON-2284 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms, Blocks: Portal Affects Versions: 2.1.12-dev (Current SVN) Reporter: Francesco Chicchiriccò Attachments: cocoon-2.1.11-as-portlet.tar.gz, Form.js I started from the wiki page at [1]: rather good, even though quite bound to pluto 1.0. I could easily adapt the procedure to Open Portlet Container [2] and Sun Portal Server; unfortunately, when it comes to CForms, the only pointer is [3], very out of date nowadays. The main issue in CForms is related to the fact that also [2] points out: Portlet's ActionRequest can not have any response body. After some struggling, I found the solution by modifying Form.js' sendFormAndWait() to be able to cope with the former issue. Another smaller issue is related to resources URI (for CSS and JS) that must be adapted and rewritten by the LinkRewriter in order to be effective. [1] http://wiki.apache.org/cocoon/CocoonAppAsJSR168Portlet [2] https://portlet-container.dev.java.net/ [3] http://blog.reverycodes.com/archives/18.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-2282) JSR-168 Portlet preferences input module
JSR-168 Portlet preferences input module Key: COCOON-2282 URL: https://issues.apache.org/jira/browse/COCOON-2282 Project: Cocoon Issue Type: Improvement Components: Blocks: Portal Affects Versions: 2.1.11 Reporter: Francesco Chicchiricco A sitemap input module for fetching PortletPreferences as they were cookies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2282) JSR-168 Portlet preferences input module
[ https://issues.apache.org/jira/browse/COCOON-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiricco updated COCOON-2282: --- Attachment: PortletPreferencesModule.java JSR-168 Portlet preferences input module Key: COCOON-2282 URL: https://issues.apache.org/jira/browse/COCOON-2282 Project: Cocoon Issue Type: Improvement Components: Blocks: Portal Affects Versions: 2.1.11 Reporter: Francesco Chicchiricco Attachments: PortletPreferencesModule.java A sitemap input module for fetching PortletPreferences as they were cookies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2072) JSR.168 Portlet-aware CookieModule
[
https://issues.apache.org/jira/browse/COCOON-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiricco updated COCOON-2072:
---
Description:
A FAQ here:
http://wiki.java.net/bin/view/Portlet/JSR168FAQ#Is_there_a_hack_to_get_set_cooki
says that some JSR-168 containers provide their javax.portlet.PortletRequest
implementation with cookies, even thought embedded in a string.
Looking at sources of Jakarta Pluto
(org.apache.pluto.internal.impl.PortletRequestImpl) and Sun's Open Portal -
free version of Sun JES Portal Server -
(com.sun.portal.portlet.impl.PortletRequestImpl), I found that this is true for
both.
See attached a simple org.apache.cocoon.components.modules.input.CookieModule
extension that can handle all that above, providing cookie access to portlets.
was:
A FAQ here:
http://wiki.java.net/bin/view/Portlet/JSR168FAQ#Is_there_a_hack_to_get_set_cooki
says that some JSR-168 containers provide their javax.portlet.PortletRequest
implementation with cookies, even thought embedded in a string.
Looking at sources of Jakarta Pluto
(org.apache.pluto.internal.impl.PortletRequestImpl) and Sun's Open Portal -
free version of Sun JES Portal Server -
(com.sun.portal.portlet.impl.PortletRequestImpl), I found that this is true for
both.
So, I wrote a simple org.apache.cocoon.components.modules.input.CookieModule
extension that can handle all that above, providing cookie access to portlets:
Here's the code:
public class PortletAwareCookieModule extends CookieModule {
final protected String COOKIE = cookie;
@Override
protected Map getCookieMap(Map objectModel) {
if
(!objectModel.containsKey(PortletObjectModelHelper.PORTLET_REQUEST_OBJECT))
return super.getCookieMap(objectModel);
PortletRequest portletRequest =
PortletObjectModelHelper.getPortletRequest(objectModel);
String cookieList = portletRequest.getProperty(COOKIE);
StringTokenizer cookieTok = new StringTokenizer(cookieList,
;);
String[] cookieParts = null;
MapString, HttpCookie cookieMap = new HashMapString,
HttpCookie();
while (cookieTok.hasMoreTokens()) {
cookieParts = cookieTok.nextToken()
.trim()
.split(=);
cookieMap.put(cookieParts[0],
new HttpCookie(cookieParts[0],
cookieParts[1]));
}
return cookieMap;
}
}
Affects Version/s: 2.1.11
JSR.168 Portlet-aware CookieModule
--
Key: COCOON-2072
URL: https://issues.apache.org/jira/browse/COCOON-2072
Project: Cocoon
Issue Type: Improvement
Components: Blocks: Portal
Affects Versions: 2.1.11
Reporter: Francesco Chicchiricco
Attachments: PortletAwareCookieModule.java
A FAQ here:
http://wiki.java.net/bin/view/Portlet/JSR168FAQ#Is_there_a_hack_to_get_set_cooki
says that some JSR-168 containers provide their javax.portlet.PortletRequest
implementation with cookies, even thought embedded in a string.
Looking at sources of Jakarta Pluto
(org.apache.pluto.internal.impl.PortletRequestImpl) and Sun's Open Portal -
free version of Sun JES Portal Server -
(com.sun.portal.portlet.impl.PortletRequestImpl), I found that this is true
for both.
See attached a simple org.apache.cocoon.components.modules.input.CookieModule
extension that can handle all that above, providing cookie access to portlets.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2072) JSR.168 Portlet-aware CookieModule
[
https://issues.apache.org/jira/browse/COCOON-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiricco updated COCOON-2072:
---
Attachment: PortletAwareCookieModule.java
JSR.168 Portlet-aware CookieModule
--
Key: COCOON-2072
URL: https://issues.apache.org/jira/browse/COCOON-2072
Project: Cocoon
Issue Type: Improvement
Components: Blocks: Portal
Affects Versions: 2.1.11
Reporter: Francesco Chicchiricco
Attachments: PortletAwareCookieModule.java
A FAQ here:
http://wiki.java.net/bin/view/Portlet/JSR168FAQ#Is_there_a_hack_to_get_set_cooki
says that some JSR-168 containers provide their javax.portlet.PortletRequest
implementation with cookies, even thought embedded in a string.
Looking at sources of Jakarta Pluto
(org.apache.pluto.internal.impl.PortletRequestImpl) and Sun's Open Portal -
free version of Sun JES Portal Server -
(com.sun.portal.portlet.impl.PortletRequestImpl), I found that this is true
for both.
So, I wrote a simple org.apache.cocoon.components.modules.input.CookieModule
extension that can handle all that above, providing cookie access to portlets:
Here's the code:
public class PortletAwareCookieModule extends CookieModule {
final protected String COOKIE = cookie;
@Override
protected Map getCookieMap(Map objectModel) {
if
(!objectModel.containsKey(PortletObjectModelHelper.PORTLET_REQUEST_OBJECT))
return super.getCookieMap(objectModel);
PortletRequest portletRequest =
PortletObjectModelHelper.getPortletRequest(objectModel);
String cookieList = portletRequest.getProperty(COOKIE);
StringTokenizer cookieTok = new StringTokenizer(cookieList,
;);
String[] cookieParts = null;
MapString, HttpCookie cookieMap = new HashMapString,
HttpCookie();
while (cookieTok.hasMoreTokens()) {
cookieParts = cookieTok.nextToken()
.trim()
.split(=);
cookieMap.put(cookieParts[0],
new HttpCookie(cookieParts[0],
cookieParts[1]));
}
return cookieMap;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2072) JSR-168 Portlet-aware CookieModule
[ https://issues.apache.org/jira/browse/COCOON-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated COCOON-2072: --- Summary: JSR-168 Portlet-aware CookieModule (was: JSR.168 Portlet-aware CookieModule) JSR-168 Portlet-aware CookieModule -- Key: COCOON-2072 URL: https://issues.apache.org/jira/browse/COCOON-2072 Project: Cocoon Issue Type: Improvement Components: Blocks: Portal Affects Versions: 2.1.11 Reporter: Francesco Chicchiriccò Attachments: PortletAwareCookieModule.java A FAQ here: http://wiki.java.net/bin/view/Portlet/JSR168FAQ#Is_there_a_hack_to_get_set_cooki says that some JSR-168 containers provide their javax.portlet.PortletRequest implementation with cookies, even thought embedded in a string. Looking at sources of Jakarta Pluto (org.apache.pluto.internal.impl.PortletRequestImpl) and Sun's Open Portal - free version of Sun JES Portal Server - (com.sun.portal.portlet.impl.PortletRequestImpl), I found that this is true for both. See attached a simple org.apache.cocoon.components.modules.input.CookieModule extension that can handle all that above, providing cookie access to portlets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2284) Making CForms working in JSR-168 portlets
Making CForms working in JSR-168 portlets - Key: COCOON-2284 URL: https://issues.apache.org/jira/browse/COCOON-2284 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms, Blocks: Portal Affects Versions: 2.1.11 Reporter: Francesco Chicchiriccò I started from the wiki page at [1]: rather good, even though quite bound to pluto 1.0. I could easily adapt the procedure to Open Portlet Container [2] and Sun Portal Server; unfortunately, when it comes to CForms, the only pointer is [3], very out of date nowadays. The main issue in CForms is related to the fact that also [2] points out: Portlet's ActionRequest can not have any response body. After some struggling, I found the solution by modifying Form.js' sendFormAndWait() to be able to cope with the former issue. Another smaller issue is related to resources URI (for CSS and JS) that must be adapted and rewritten by the LinkRewriter in order to be effective. [1] http://wiki.apache.org/cocoon/CocoonAppAsJSR168Portlet [2] https://portlet-container.dev.java.net/ [3] http://blog.reverycodes.com/archives/18.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2284) Making CForms working in JSR-168 portlets
[ https://issues.apache.org/jira/browse/COCOON-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated COCOON-2284: --- Attachment: Form.js Form.js extension able to deal with JSR-168 portlets. Making CForms working in JSR-168 portlets - Key: COCOON-2284 URL: https://issues.apache.org/jira/browse/COCOON-2284 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms, Blocks: Portal Affects Versions: 2.1.11 Reporter: Francesco Chicchiriccò Attachments: Form.js I started from the wiki page at [1]: rather good, even though quite bound to pluto 1.0. I could easily adapt the procedure to Open Portlet Container [2] and Sun Portal Server; unfortunately, when it comes to CForms, the only pointer is [3], very out of date nowadays. The main issue in CForms is related to the fact that also [2] points out: Portlet's ActionRequest can not have any response body. After some struggling, I found the solution by modifying Form.js' sendFormAndWait() to be able to cope with the former issue. Another smaller issue is related to resources URI (for CSS and JS) that must be adapted and rewritten by the LinkRewriter in order to be effective. [1] http://wiki.apache.org/cocoon/CocoonAppAsJSR168Portlet [2] https://portlet-container.dev.java.net/ [3] http://blog.reverycodes.com/archives/18.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2284) Making CForms working in JSR-168 portlets
[ https://issues.apache.org/jira/browse/COCOON-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated COCOON-2284: --- Attachment: cocoon-2.1.11-as-portlet.tar.gz Simple maven 1.0 project for a Cocoon 2.1.11 portlet with working CForm and other portlet goodies. Making CForms working in JSR-168 portlets - Key: COCOON-2284 URL: https://issues.apache.org/jira/browse/COCOON-2284 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms, Blocks: Portal Affects Versions: 2.1.11 Reporter: Francesco Chicchiriccò Attachments: cocoon-2.1.11-as-portlet.tar.gz, Form.js I started from the wiki page at [1]: rather good, even though quite bound to pluto 1.0. I could easily adapt the procedure to Open Portlet Container [2] and Sun Portal Server; unfortunately, when it comes to CForms, the only pointer is [3], very out of date nowadays. The main issue in CForms is related to the fact that also [2] points out: Portlet's ActionRequest can not have any response body. After some struggling, I found the solution by modifying Form.js' sendFormAndWait() to be able to cope with the former issue. Another smaller issue is related to resources URI (for CSS and JS) that must be adapted and rewritten by the LinkRewriter in order to be effective. [1] http://wiki.apache.org/cocoon/CocoonAppAsJSR168Portlet [2] https://portlet-container.dev.java.net/ [3] http://blog.reverycodes.com/archives/18.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2072) JSR.168 Portlet-aware CookieModule
JSR.168 Portlet-aware CookieModule
--
Key: COCOON-2072
URL: https://issues.apache.org/jira/browse/COCOON-2072
Project: Cocoon
Issue Type: Improvement
Components: Blocks: Portal
Reporter: Francesco Chicchiricco
A FAQ here:
http://wiki.java.net/bin/view/Portlet/JSR168FAQ#Is_there_a_hack_to_get_set_cooki
says that some JSR-168 containers provide their javax.portlet.PortletRequest
implementation with cookies, even thought embedded in a string.
Looking at sources of Jakarta Pluto
(org.apache.pluto.internal.impl.PortletRequestImpl) and Sun's Open Portal -
free version of Sun JES Portal Server -
(com.sun.portal.portlet.impl.PortletRequestImpl), I found that this is true for
both.
So, I wrote a simple org.apache.cocoon.components.modules.input.CookieModule
extension that can handle all that above, providing cookie access to portlets:
Here's the code:
public class PortletAwareCookieModule extends CookieModule {
final protected String COOKIE = cookie;
@Override
protected Map getCookieMap(Map objectModel) {
if
(!objectModel.containsKey(PortletObjectModelHelper.PORTLET_REQUEST_OBJECT))
return super.getCookieMap(objectModel);
PortletRequest portletRequest =
PortletObjectModelHelper.getPortletRequest(objectModel);
String cookieList = portletRequest.getProperty(COOKIE);
StringTokenizer cookieTok = new StringTokenizer(cookieList,
;);
String[] cookieParts = null;
MapString, HttpCookie cookieMap = new HashMapString,
HttpCookie();
while (cookieTok.hasMoreTokens()) {
cookieParts = cookieTok.nextToken()
.trim()
.split(=);
cookieMap.put(cookieParts[0],
new HttpCookie(cookieParts[0],
cookieParts[1]));
}
return cookieMap;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.
[ https://issues.apache.org/jira/browse/COCOON-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-1666: -- Fix Version/s: (was: 2.1.8) Affects Version/s: (was: 2.1.8) 2.1.7 Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: https://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Issue Type: Bug Components: Blocks: Portal Affects Versions: 2.1.7 Reporter: Ralph Goers Assigned To: Ralph Goers Saving of JSR-168 preferences does not appear to be working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.
[ http://issues.apache.org/jira/browse/COCOON-1666?page=comments#action_12356173 ] Carsten Ziegeler commented on COCOON-1666: -- Hmm, it did work on monday for me; strange, I'll have a look at it right now Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: http://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Fix For: 2.1.8-dev (Current SVN) Saving of JSR-168 preferences does not appear to be working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.
[ http://issues.apache.org/jira/browse/COCOON-1666?page=comments#action_12356177 ] Carsten Ziegeler commented on COCOON-1666: -- Just tested the portal demo from latest svn, and it works for me Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: http://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Fix For: 2.1.8-dev (Current SVN) Saving of JSR-168 preferences does not appear to be working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.
[ http://issues.apache.org/jira/browse/COCOON-1666?page=all ] Ralph Goers updated COCOON-1666: Assign To: Ralph Goers The test was with page labels and marshalling enabled. I missed one configuration item - uncommenting the parameter-name for the request-parameter aspect. I verified that it does indeed work. I will close this. Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: http://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Assignee: Ralph Goers Fix For: 2.1.8-dev (Current SVN) Saving of JSR-168 preferences does not appear to be working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.
[ http://issues.apache.org/jira/browse/COCOON-1666?page=all ] Ralph Goers closed COCOON-1666: --- Resolution: Invalid Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: http://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Assignee: Ralph Goers Fix For: 2.1.8-dev (Current SVN) Saving of JSR-168 preferences does not appear to be working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.
Saving of JSR-168 preferences does not appear to be working. Key: COCOON-1666 URL: http://issues.apache.org/jira/browse/COCOON-1666 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Ralph Goers Fix For: 2.1.8-dev (Current SVN) Saving of JSR-168 preferences does not appear to be working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1359) Portal: attributes not set for local JSR-168 portlets
[ http://issues.apache.org/jira/browse/COCOON-1359?page=all ] Pier Fumagalli updated COCOON-1359: --- Reporter: Ralph Goers (was: Ralph Goers) Portal: attributes not set for local JSR-168 portlets - Key: COCOON-1359 URL: http://issues.apache.org/jira/browse/COCOON-1359 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1.6 Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Ralph Goers Cocoon does not set values for attributes javax.portlet.request and javax.portlet.response for JSR-168 portlets running in the Cocoon webapp. This is required by the JSR-168 specification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
DO NOT REPLY [Bug 33091] - JSR-168 portlets may not render properly if the page is reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33091 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Summary|JSR-168 portlets may not|JSR-168 portlets may not |render properly if the page |render properly if the page |is reloaded |is reloaded -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
DO NOT REPLY [Bug 33091] - JSR-168 portlets may not render properly if the page is reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33091 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-14 17:42 --- The fix has been applied. Documentation is available at http://wiki.apache.org/cocoon/PortalPageLabels. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
DO NOT REPLY [Bug 33091] - JSR-168 portlets may not render properly if the page is reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33091 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
JSR-168 Portlet minimize and maximize in 2.2
I'm noticing that the minimize and maximize buttons are not appearing on the windows for the portlets in the JSR-168 samples page in 2.2. Why is that? Ralph
DO NOT REPLY [Bug 33091] New: - JSR-168 portlets may not render properly if the page is reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33091 Summary: JSR-168 portlets may not render properly if the page is reloaded Product: Cocoon 2 Version: Current SVN 2.1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: blocks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: dev@cocoon.apache.org During testing we noticed that when the page was refereshed some pages would minimize. Because portlet actions cause a redirect, performing the refresh executes the event that was the result of performing the action instead of the action itself. The solution to this is to marshall the event data into the urls so that the events can be created during event processing. The fix will require specific enablement so that the portal remains backward compatable. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
DO NOT REPLY [Bug 32417] New: - Portal: attributes not set for local JSR-168 portlets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32417. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32417 Summary: Portal: attributes not set for local JSR-168 portlets Product: Cocoon 2 Version: 2.1.6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: blocks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Cocoon does not set values for attributes javax.portlet.request and javax.portlet.response for JSR-168 portlets running in the Cocoon webapp. This is required by the JSR-168 specification. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
DO NOT REPLY [Bug 32417] - Portal: attributes not set for local JSR-168 portlets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32417. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32417 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-28 07:26 --- Fix applied. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
DO NOT REPLY [Bug 32417] - Portal: attributes not set for local JSR-168 portlets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32417. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32417 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
RE: JSR-168 Portlets
Ralph Goers wrote: Well, I like the idea of deploying them inside of Cocoon. I'm not sure why the Portlet spec says they should be web apps. I might be wrong but afaiu the spec, it only says that a portlet should be deployed as a web app. But in my understanding this does not include that it runs as a real web application. So deploying them inside of Cocoon seems to conform to the spec. Carsten
RE: JSR-168 Portlets
Carsten Ziegeler wrote: I did get it running in Tomcat with just the Pluto libs in lib/shared and it worked - it's a long time ago Now, the better way imho would be if the portlets would run inside of Cocoon rather than inside of Tomcat. So, you deploy your portlet wars into your Cocoon war (or a totally different place) and you don't have to deploy the portlets as usual web applications in your servlet engine. I think this should be possible, but of course needs some work to be done. Apart from that, if you have any issues/questions/suggestions about Pluto, just asked on the pluto mailing list ;) Carsten Well, I like the idea of deploying them inside of Cocoon. I'm not sure why the Portlet spec says they should be web apps. The spec says that the portlet applications are supposed to use existing servlet environment. IMHO they wanted to use as much from existing servlet infrastructure as possible. That ended in conclusion that every single portlet application should be packaged and deployed as servlet application. But I have good news. I was able to get a portlet to work with the portlet deployed as a war file and I didn't have to change any code. First of all I am wondering why there are any problems with pluto.jar placed in shared/lib. We use it for pluto.jar for Cocoon-2.1.5 and pluto-1.0.1 and it's working correctly. Moreover we also packaged both portal.war + portlet.war + pluto.jar into one enterprise application (ear) and after few patches to cocoon it is working as well (patches been recently submitted to bugzilla). simply put the pluto and portlet-api jars in Tomcat's common/lib directory instead of shared/lib and that got rid of the ClassNotFoundException. I guess there is either a bug in Tomcat or I am not reading their documentation properly. There might be some change in Tomcat. We are using Tomcat 4.1.27 and know nothing about Tomcat 5, but in Tomcat 4.1 classloader hierarchy is as of: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html From the picture there it is evident that shared/lib should be good enough placement for all libraries that should be shared between deployed web applications (portal.war + portlet.war). Only libraries that need to be visible also from container (cataline) should be placed to common/lib. Example for this can be custom Pricipal object shared between custom authentication realm (that instantiate it) and web application (that is reading it). Michal
Re: JSR-168 Portlets
DURDINA Michal wrote: There might be some change in Tomcat. We are using Tomcat 4.1.27 and know nothing about Tomcat 5, but in Tomcat 4.1 classloader hierarchy is as of: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html From the picture there it is evident that shared/lib should be good enough placement for all libraries that should be shared between deployed web applications (portal.war + portlet.war). Only libraries that need to be visible also from container (cataline) should be placed to common/lib. Example for this can be custom Pricipal object shared between custom authentication realm (that instantiate it) and web application (that is reading it). The doc for 5.0 says the same thing. But it didn't work. Moreover, I was able to find a post on the Tomcat mailing list (with no response) asking why shared/lib didn't work. I'm just upset because I spent the last 3 days trying to figure out what in Cocoon or Pluto was broken and how to fix it. The fact that I was getting a ClassNotFoundException for a pluto class when trying to instantiate PortletPortalManager never made sense to me, but I just assumed I was wrong. I also changed the name of the servlet class in web.xml to something that didn't exist by accident. Tomcat then very nicely dumped a list of all the jars and classes in its class loaders. shared/lib and shared/classes aren't listed. Ralph
RE: JSR-168 Portlets
Carsten Ziegeler wrote: Ralph Goers wrote: Well, I like the idea of deploying them inside of Cocoon. I'm not sure why the Portlet spec says they should be web apps. I might be wrong but afaiu the spec, it only says that a portlet should be deployed as a web app. But in my understanding this does not include that it runs as a real web application. So deploying them inside of Cocoon seems to conform to the spec. Ok, I have thought about this: running the portlets as a web app inside Cocoon sounds like a great idea, but emulation a servlet engine or even worse an app server seems not like the easiest thing to do. I looked briefly at Jetspeed-2 and they are using a different approach. You deploy a portlet into jetspeed as a war file and then it seems that jetspeed deploys the portlet web application into Tomcat. Don't know how that works :( But if this is compatible to different servlet engines than it seems like a good compromise: the portal is used for deployment of portlets and the portal delegates it to the underlying servlet engine. Thoughts? Carsten
RE: JSR-168 Portlets
Carsten Ziegeler said: Carsten Ziegeler wrote: Ok, I have thought about this: running the portlets as a web app inside Cocoon sounds like a great idea, but emulation a servlet engine or even worse an app server seems not like the easiest thing to do. I looked briefly at Jetspeed-2 and they are using a different approach. You deploy a portlet into jetspeed as a war file and then it seems that jetspeed deploys the portlet web application into Tomcat. Don't know how that works :( But if this is compatible to different servlet engines than it seems like a good compromise: the portal is used for deployment of portlets and the portal delegates it to the underlying servlet engine. It looks like Jetspeed 2 is very tied to Tomcat. If this requires something only provided by Tomcat that would be a problem. Guess we'll need to look at their code. Ralph
RE: JSR-168 Portlets
I did get it running in Tomcat with just the Pluto libs in lib/shared and it worked - it's a long time ago Now, the better way imho would be if the portlets would run inside of Cocoon rather than inside of Tomcat. So, you deploy your portlet wars into your Cocoon war (or a totally different place) and you don't have to deploy the portlets as usual web applications in your servlet engine. I think this should be possible, but of course needs some work to be done. Apart from that, if you have any issues/questions/suggestions about Pluto, just asked on the pluto mailing list ;) Carsten -Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Saturday, November 13, 2004 1:40 AM To: [EMAIL PROTECTED] Subject: JSR-168 Portlets I have been working for the last 2 days trying to figure out how to get JSR-168 portlets, packaged as their own webapp, to work with the Cocoon portal. Has anyone ever gotten this to work? I have come to the conclusion that, due to the design of Pluto, it is not realistically possible. The problem I am seeing is that Pluto has a couple of singleton classes that it needs to share between the Portal webapp (i.e. Cocoon) and the portlet webapp. This requires that the pluto jar file be placed in Tomcat's shared/lib directory. However, because Tomcat places the WEB-INF/lib above shared/lib in the class loader chain any Cocoon classes that reference pluto classes will get a ClassNotFoundException unless they are also placed in shared lib. Needless to say, this will end up with all of Cocoon and everything it uses in shared/lib in short order. Maybe I'm missing something, but I just don't understand why Pluto has to require the singleton classes. It would make more sense to me for Pluto to store references to the singleton objects in ServletContext attributes and then anchor those into a singleton in the Portlet webapp when Pluto's PortletServlet is entered. Comments? Ralph
Re: JSR-168 Portlets
Carsten Ziegeler wrote: I did get it running in Tomcat with just the Pluto libs in lib/shared and it worked - it's a long time ago Now, the better way imho would be if the portlets would run inside of Cocoon rather than inside of Tomcat. So, you deploy your portlet wars into your Cocoon war (or a totally different place) and you don't have to deploy the portlets as usual web applications in your servlet engine. I think this should be possible, but of course needs some work to be done. Apart from that, if you have any issues/questions/suggestions about Pluto, just asked on the pluto mailing list ;) Carsten Well, I like the idea of deploying them inside of Cocoon. I'm not sure why the Portlet spec says they should be web apps. But I have good news. I was able to get a portlet to work with the portlet deployed as a war file and I didn't have to change any code. I simply put the pluto and portlet-api jars in Tomcat's common/lib directory instead of shared/lib and that got rid of the ClassNotFoundException. I guess there is either a bug in Tomcat or I am not reading their documentation properly. Ralph
Re: JSR-168 Portlets
Ralph Goers wrote: Carsten Ziegeler wrote: I did get it running in Tomcat with just the Pluto libs in lib/shared and it worked - it's a long time ago Now, the better way imho would be if the portlets would run inside of Cocoon rather than inside of Tomcat. So, you deploy your portlet wars into your Cocoon war (or a totally different place) and you don't have to deploy the portlets as usual web applications in your servlet engine. I think this should be possible, but of course needs some work to be done. Apart from that, if you have any issues/questions/suggestions about Pluto, just asked on the pluto mailing list ;) Carsten By the way, I noticed a patch submitted to Pluto that allows a configuration file to be used to provide the information needed to deploy the portlets. This allows the portlets to be packaged as war files as it no longer has to scan the servlet container's webapp directory. I believe we should take the same approach. I'm just not sure where would be the best place to put that configuration. Ralph
[Portal] JSR 168 Included attributes
I posted this the other day and haven't got a response. Sorry for posting again but I need to know how to address this issue. We have a JSR 168 portlet that includes a JSP. We have placed the portlet in the Cocoon webapp. The JSP is trying to use Pluto's tag library and it is getting a NullPointerException in the tag library because the request attributes listed in PLT 16.3.2 are not being set. This works fine in the Pluto portal, so I am suspecting that Cocoon has provided its own PortletInvoker (LocalPortletInvokerImpl?). Is this a bug? The spec says that these attributes should always be set in the target of the include. Ralph
RE: [Portal] JSR 168 Included attributes
This sounds like a bug to me. Carsten -Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 8:38 AM To: [EMAIL PROTECTED] Subject: [Portal] JSR 168 Included attributes I posted this the other day and haven't got a response. Sorry for posting again but I need to know how to address this issue. We have a JSR 168 portlet that includes a JSP. We have placed the portlet in the Cocoon webapp. The JSP is trying to use Pluto's tag library and it is getting a NullPointerException in the tag library because the request attributes listed in PLT 16.3.2 are not being set. This works fine in the Pluto portal, so I am suspecting that Cocoon has provided its own PortletInvoker (LocalPortletInvokerImpl?). Is this a bug? The spec says that these attributes should always be set in the target of the include. Ralph
JSR 168 Included Request Attributes.
We have a JSR 168 portlet that includes a JSP. We have placed the portlet in the Cocoon webapp. The JSP is trying to use Pluto's tag library and it is getting a NullPointerException in the tag library because the request attributes listed in PLT 16.3.2 are not being set. This works fine in the Pluto portal, so I am suspecting that Cocoon has provided its own PortletInvoker (LocalPortletInvokerImpl?). Is this a bug? Ralph
RE: Cocoon JSR 168 Portlet in Cocoon Portal
Vadim Gritsenko wrote: It's actually very easy to reproduce: 1. cvs up 2. build clean; build 3. cocoon servlet 4. http://localhost:/samples/blocks/portal/portal 5. login 6. JSR-168 tab Exception is printed neatly within JSR-168 Cocoon Portlet content pane. Please bear in mind, call stack here is the following: CocoonServlet Cocoon (1) Treeprocessor, ... CopletSource ManagedCocoonPortlet Cocoon (2) EnvironmentHelper Where, (1) and (2) are the same instance of the Cocoon class, on the same thread. I think that's why it is confused. Here is head of trace. Ah, ok, than life is much simpler :) The check currently assumes that on method entry the stack stored in the thread local is empty. Thus it checks on exit if the stack is empty again. We could store the current number of elements in the stack on method entry and check if the stack has the same size on exit. This would just be a local int variable. WDYT? Carsten
Re: Cocoon JSR 168 Portlet in Cocoon Portal
Carsten Ziegeler wrote: Vadim Gritsenko wrote: It's actually very easy to reproduce: 1. cvs up 2. build clean; build 3. cocoon servlet 4. http://localhost:/samples/blocks/portal/portal 5. login 6. JSR-168 tab Exception is printed neatly within JSR-168 Cocoon Portlet content pane. Please bear in mind, call stack here is the following: CocoonServlet Cocoon (1) Treeprocessor, ... CopletSource ManagedCocoonPortlet Cocoon (2) EnvironmentHelper Where, (1) and (2) are the same instance of the Cocoon class, on the same thread. I think that's why it is confused. Here is head of trace. Ah, ok, than life is much simpler :) The check currently assumes that on method entry the stack stored in the thread local is empty. Thus it checks on exit if the stack is empty again. We could store the current number of elements in the stack on method entry and check if the stack has the same size on exit. This would just be a local int variable. WDYT? Done, please double check :-) Demo works out of the box now. Vadim
RE: Cocoon JSR 168 Portlet in Cocoon Portal
Looks good to me! Thanks Carsten -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 2:43 PM To: [EMAIL PROTECTED] Subject: Re: Cocoon JSR 168 Portlet in Cocoon Portal Carsten Ziegeler wrote: Vadim Gritsenko wrote: It's actually very easy to reproduce: 1. cvs up 2. build clean; build 3. cocoon servlet 4. http://localhost:/samples/blocks/portal/portal 5. login 6. JSR-168 tab Exception is printed neatly within JSR-168 Cocoon Portlet content pane. Please bear in mind, call stack here is the following: CocoonServlet Cocoon (1) Treeprocessor, ... CopletSource ManagedCocoonPortlet Cocoon (2) EnvironmentHelper Where, (1) and (2) are the same instance of the Cocoon class, on the same thread. I think that's why it is confused. Here is head of trace. Ah, ok, than life is much simpler :) The check currently assumes that on method entry the stack stored in the thread local is empty. Thus it checks on exit if the stack is empty again. We could store the current number of elements in the stack on method entry and check if the stack has the same size on exit. This would just be a local int variable. WDYT? Done, please double check :-) Demo works out of the box now. Vadim
RE: Cocoon JSR 168 Portlet in Cocoon Portal
Vadim Gritsenko wrote:
Hi all,
I have successfully deployed Cocoon JSR-168 Portlet into
Cocoon Portal.
Now, you can deploy your portlets implemented using Cocoon
into Cocoon's own portal.
Cool!!
There is a very simple demo of the Cocoon JSR-168 portlet
included, just go to the JSR168 tab in the portal block
demo. The only thing you need to do before running demo is to
comment out implementation of the
checkEnvironment() method in the EnvironmentHelper:
Index:
src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/environment/in
ternal/EnvironmentHelper.java,v
retrieving revision 1.3
diff -u -r1.3 EnvironmentHelper.java
---
src/java/org/apache/cocoon/environment/internal/EnvironmentHel
per.java
29 May 2004 17:39:38 - 1.3
+++
src/java/org/apache/cocoon/environment/internal/EnvironmentHel
per.java
6 Jul 2004 20:42:33 -
@@ -288,6 +288,7 @@
public static void checkEnvironment(Logger logger)
throws Exception {
// TODO (CZ): This is only for testing - remove it later on
+/*
final EnvironmentStack stack =
(EnvironmentStack)environmentStack.get();
if (stack != null !stack.isEmpty() ) {
logger.error(ENVIRONMENT STACK HAS NOT BEEN
CLEANED PROPERLY); @@ -295,6 +296,7 @@
+Please report
this (if possible together with a test case)
+to the Cocoon
developers.);
}
+*/
}
/**
Carsten, can you shed more light as to what will be the best
course for this?
Argh, ok, perhaps we can finally find the bug with this!
The checkEnvironment is an integrated test to see if something went
wrong with the internal environment handling. So if this method
logs the exception, something went wrong :)
We have an internal stack, bound as a thread local variable, that keeps
track of the current environment and sitemap. So, if you enter
a sitemap, the current environment and sitemap processor are pushed
onto the stack and when the sitemap is left, the values are taken
from the stack.
The checkEnvironment() method checks at the end of the processing if the
stack is empty. If not, something has not been taken from stack.
Now, this gets more complicated, when internal pipeline calls are used.
As these run in the same thread, the environment of the internal pipeline
and of the external call are both on the same stack. An index for
each pipeline keeps track of which environment belongs to which pipeline.
It seems that the problem arises when this index somehow gets confused
or, when something is not taken from the stack.
I checked the code several times, but push and pop always come in a pair,
so I'm a little bit clueless :)
Is the message reproducable with every coplet? What do I have to do,
to reproduce it?
Carsten
Re: Cocoon JSR 168 Portlet in Cocoon Portal
Carsten Ziegeler wrote: Vadim Gritsenko wrote: There is a very simple demo of the Cocoon JSR-168 portlet included, just go to the JSR168 tab in the portal block demo. The only thing you need to do before running demo is to comment out implementation of the checkEnvironment() method in the EnvironmentHelper: ... Carsten, can you shed more light as to what will be the best course for this? Argh, ok, perhaps we can finally find the bug with this! The checkEnvironment is an integrated test to see if something went wrong with the internal environment handling. So if this method logs the exception, something went wrong :) We have an internal stack, bound as a thread local variable, that keeps track of the current environment and sitemap. So, if you enter a sitemap, the current environment and sitemap processor are pushed onto the stack and when the sitemap is left, the values are taken from the stack. The checkEnvironment() method checks at the end of the processing if the stack is empty. If not, something has not been taken from stack. Now, this gets more complicated, when internal pipeline calls are used. As these run in the same thread, the environment of the internal pipeline and of the external call are both on the same stack. An index for each pipeline keeps track of which environment belongs to which pipeline. It seems that the problem arises when this index somehow gets confused or, when something is not taken from the stack. I checked the code several times, but push and pop always come in a pair, so I'm a little bit clueless :) Is the message reproducable with every coplet? What do I have to do, to reproduce it? It's actually very easy to reproduce: 1. cvs up 2. build clean; build 3. cocoon servlet 4. http://localhost:/samples/blocks/portal/portal 5. login 6. JSR-168 tab Exception is printed neatly within JSR-168 Cocoon Portlet content pane. Please bear in mind, call stack here is the following: CocoonServlet Cocoon (1) Treeprocessor, ... CopletSource ManagedCocoonPortlet Cocoon (2) EnvironmentHelper Where, (1) and (2) are the same instance of the Cocoon class, on the same thread. I think that's why it is confused. Here is head of trace: org.apache.cocoon.ProcessingException: Environment stack has not been cleaned up properly. Please report this (if possible together with a test case) to the Cocoon developers. at org.apache.cocoon.environment.internal.EnvironmentHelper.checkEnvironment(EnvironmentHelper.java:294) at org.apache.cocoon.Cocoon.process(Cocoon.java:692) at org.apache.cocoon.portlet.ManagedCocoonPortlet.render(ManagedCocoonPortlet.java:557) at org.apache.cocoon.portal.pluto.factory.LocalPortletInvokerImpl.render(LocalPortletInvokerImpl.java:140) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103) at org.apache.cocoon.portal.coplet.adapter.impl.PortletAdapter.streamContent(PortletAdapter.java:168) at org.apache.cocoon.portal.coplet.adapter.impl.AbstractCopletAdapter.toSAX(AbstractCopletAdapter.java:128) at org.apache.cocoon.portal.source.CopletSource.toSAX(CopletSource.java:168) at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:134) at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:114) at org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:545) Vadim
Cocoon JSR 168 Portlet in Cocoon Portal
Hi all,
I have successfully deployed Cocoon JSR-168 Portlet into Cocoon Portal.
Now, you can deploy your portlets implemented using Cocoon into Cocoon's
own portal.
There is a very simple demo of the Cocoon JSR-168 portlet included, just
go to the JSR168 tab in the portal block demo. The only thing you need
to do before running demo is to comment out implementation of the
checkEnvironment() method in the EnvironmentHelper:
Index:
src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java,v
retrieving revision 1.3
diff -u -r1.3 EnvironmentHelper.java
---
src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java
29 May 2004 17:39:38 - 1.3
+++
src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java
6 Jul 2004 20:42:33 -
@@ -288,6 +288,7 @@
public static void checkEnvironment(Logger logger)
throws Exception {
// TODO (CZ): This is only for testing - remove it later on
+/*
final EnvironmentStack stack =
(EnvironmentStack)environmentStack.get();
if (stack != null !stack.isEmpty() ) {
logger.error(ENVIRONMENT STACK HAS NOT BEEN CLEANED
PROPERLY);
@@ -295,6 +296,7 @@
+Please report this (if
possible together with a test case)
+to the Cocoon developers.);
}
+*/
}
/**
Carsten, can you shed more light as to what will be the best course for
this?
Vadim
RE: JSR 168 in new portal
The version of the Tomcat is 4.1.30. Pluto (version 1.0.1) was build and deployed by maven rc1. (maven fullDeployment command). Then I check pluto instalation - test portlets were OK. I stopped tomcat. I unpacked cocoon war into the tomcat's webapps dir and removed pluto*.jar and porlet-api*.jar. I start Tomcat. And there were no output for test portlet #1, #2. -Original Message- From: Menke, John [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 4:44 PM To: '[EMAIL PROTECTED]' Subject: RE: JSR 168 in new portal I deployed cocoon app as JSR 168 compatibile portlet into the pluto. What version of Tomcat are you using? You deployed by creating the .war and putting it in the webapp folder right? i am using 4.1.30 and Cocoon is not coming up -jm __ Informacia od NOD32 1.574 (20031206) __ Tato sprava bola preverena antivirusovym systemom NOD32. http://www.eset.sk
RE: JSR 168 in new portal
You have to enable cross context access for Cocoon. Add a cocoon.xml in the webapps directory with the following content: Context path=/cocoon docBase=cocoon crossContext=true /Context Then it should work. HTH Carsten -Original Message- From: Grofcík Martin [mailto:[EMAIL PROTECTED] Sent: Friday, June 25, 2004 8:09 AM To: [EMAIL PROTECTED] Subject: RE: JSR 168 in new portal The version of the Tomcat is 4.1.30. Pluto (version 1.0.1) was build and deployed by maven rc1. (maven fullDeployment command). Then I check pluto instalation - test portlets were OK. I stopped tomcat. I unpacked cocoon war into the tomcat's webapps dir and removed pluto*.jar and porlet-api*.jar. I start Tomcat. And there were no output for test portlet #1, #2. -Original Message- From: Menke, John [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 4:44 PM To: '[EMAIL PROTECTED]' Subject: RE: JSR 168 in new portal I deployed cocoon app as JSR 168 compatibile portlet into the pluto. What version of Tomcat are you using? You deployed by creating the .war and putting it in the webapp folder right? i am using 4.1.30 and Cocoon is not coming up -jm __ Informacia od NOD32 1.574 (20031206) __ Tato sprava bola preverena antivirusovym systemom NOD32. http://www.eset.sk
RE: JSR 168 in new portal
Thak you a lot. It helps. Regards Martin -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Friday, June 25, 2004 10:27 AM To: [EMAIL PROTECTED] Subject: RE: JSR 168 in new portal You have to enable cross context access for Cocoon. Add a cocoon.xml in the webapps directory with the following content: Context path=/cocoon docBase=cocoon crossContext=true /Context Then it should work. HTH Carsten -Original Message- From: Grofck Martin [mailto:[EMAIL PROTECTED] Sent: Friday, June 25, 2004 8:09 AM To: [EMAIL PROTECTED] Subject: RE: JSR 168 in new portal The version of the Tomcat is 4.1.30. Pluto (version 1.0.1) was build and deployed by maven rc1. (maven fullDeployment command). Then I check pluto instalation - test portlets were OK. I stopped tomcat. I unpacked cocoon war into the tomcat's webapps dir and removed pluto*.jar and porlet-api*.jar. I start Tomcat. And there were no output for test portlet #1, #2. -Original Message- From: Menke, John [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 4:44 PM To: '[EMAIL PROTECTED]' Subject: RE: JSR 168 in new portal I deployed cocoon app as JSR 168 compatibile portlet into the pluto. What version of Tomcat are you using? You deployed by creating the .war and putting it in the webapp folder right? i am using 4.1.30 and Cocoon is not coming up -jm __ Informacia od NOD32 1.574 (20031206) __ Tato sprava bola preverena antivirusovym systemom NOD32. http://www.eset.sk __ Informacia od NOD32 1.574 (20031206) __ Tato sprava bola preverena antivirusovym systemom NOD32. http://www.eset.sk
JSR 168 in new portal
Hi, I have a question to the new portal, which is with the Cocoon version 2.1.5-dev thereby. If one logs in in the portal as ' cocoon ' user, then there is a tab ' JSR-168 '. Under this tab, are 3 Coplets, which shows nothing. Instead of the content, one indicates: The coplet inst is currently not available. question: What i have to do, to bring these coplets up? Thanks Seb -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
RE: JSR 168 in new portal
I deployed cocoon app as JSR 168 compatibile portlet into the pluto. What version of Tomcat are you using? You deployed by creating the .war and putting it in the webapp folder right? i am using 4.1.30 and Cocoon is not coming up -jm
JSR 168
Hi, Are there an tutorial for adding JSR 168 coplets to the portal? Seb -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
JSR 168
Hello all, I would like to get answer to these questions: First of all: 1. How could I deploy JSR 168 porlet in to the 2.1.4 Cocoon portal engine? 2. I am trying to make cocoon coplet as JSR168 compatible portlet and pack it in to the war file. And again deploy it in to the Cocoon portal engine. There is some description in the http://wiki.cocoondev.org/Wiki.jsp?page=JSR168Portlet. But how can I do it. 3. Is there any possibility to separate coplets from Cocoon portal engine? Coplets can be developed by different people andthen deployed in to the finall solution. Thank you in advance for answer. Regards Martin
RE: JSR 168
-Original Message- From: Grofcík Martin [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 2:43 PM To: [EMAIL PROTECTED] Subject: JSR 168 Hello all, I would like to get answer to these questions: First of all: 1. How could I deploy JSR 168 porlet in to the 2.1.4 Cocoon portal engine? Deploying portlets into Cocoon isn't currently that easy :( A deployment tool is missing (hint for someone who wants to do it). Now, what you can do is: deploy your portlet using Pluto (http://portals.apache.org/pluto) and then use the deployed portlet within Cocoon.You will find a configuration for the test portlets delivered with Pluto in the Cocoon portal. Have a look at the configuration file for the coplet data, there you will find references to the portlets. So, if you want to include your own portlets you have to change this. HTH Carsten
Coplets JSR 168 compatible
Hello, My question is little bit simple: Is it possible to develop coplet which are JSR168 compatible? If yes How could I do it. Thank yu in advance for answer. Regards Martin begin:vcard fn:Martin Grofcik n:Grofcik;Martin email;internet:[EMAIL PROTECTED] version:2.1 end:vcard
Re: Coplets JSR 168 compatible
grofcik.lan dijo: Hello, My question is little bit simple: Is it possible to develop coplet which are JSR168 compatible? If yes How could I do it. Hi: Yes. Look at the portal Engine, it is a work in progress. Best Regards, Antonio Gallardo. PS: Can you ask Ms. Balun if he knows me? Not sure, but I think we worked in Novitech in 1995.
Re: Coplets JSR 168 compatible
grofcik.lan dijo: Hello, My question is little bit simple: Is it possible to develop coplet which are JSR168 compatible? If yes How could I do it. Hi again: I forgot to post this link: http://wiki.cocoondev.org/Wiki.jsp?page=JSR168Portlet Best Regards, Antonio Gallardo
[Portal] Question: Why JSR-168 portlet impl moved?
Hi, I am curious why Carsten moved portlet implementation from scratchpad to portal block... I thought JSR-168 portlet implementation would go to core. I think that CocoonPortlet (JSR-168 portlet implementation) and portal block are two different things. CocoonPortlet makes cocoon applications work under portlet container (i.e. Jakarta Pluto). Portal block IS a portlet container (Portal Engine makes environment for coplets and portlets). So I don't see the reason why to mix these two. Why must I be dependent on the whole portal block (jar is 330kB and will be more) when I want to implement just one JSR-168 portlet using cocoon? I supposed that JSR-168 portlet implementation would go to core, where other env implementations are (Servlet and CLI). What was the reason for not doing so? Thanks, Michal BTW: Tiny patch for CocoonPortal.java is now in Bugzilla #27188
RE: [Portal] Question: Why JSR-168 portlet impl moved?
See: http://marc.theaimsgroup.com/?t=10771857645r=1w=2 Thanks Carsten -Original Message- From: DURDINA Michal [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 3:58 PM To: [EMAIL PROTECTED] Subject: [Portal] Question: Why JSR-168 portlet impl moved? Hi, I am curious why Carsten moved portlet implementation from scratchpad to portal block... I thought JSR-168 portlet implementation would go to core. I think that CocoonPortlet (JSR-168 portlet implementation) and portal block are two different things. CocoonPortlet makes cocoon applications work under portlet container (i.e. Jakarta Pluto). Portal block IS a portlet container (Portal Engine makes environment for coplets and portlets). So I don't see the reason why to mix these two. Why must I be dependent on the whole portal block (jar is 330kB and will be more) when I want to implement just one JSR-168 portlet using cocoon? I supposed that JSR-168 portlet implementation would go to core, where other env implementations are (Servlet and CLI). What was the reason for not doing so? Thanks, Michal BTW: Tiny patch for CocoonPortal.java is now in Bugzilla #27188
RE: [Portal] Question: Why JSR-168 portlet impl moved?
Thanks for pointing me there. Inspite of that, my questions remain: 1. Why must I be dependent on the whole portal block (jar is 330kB and will be more) when I want to implement just one JSR-168 portlet using Cocoon and using 3rd party portlet container? 2. What was the reason for not moving that code to src/java? Thank you and appologize me :) Michal -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 4:04 PM To: [EMAIL PROTECTED] Subject: RE: [Portal] Question: Why JSR-168 portlet impl moved? See: http://marc.theaimsgroup.com/?t=10771857645r=1w=2 Thanks Carsten -Original Message- From: DURDINA Michal [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 3:58 PM To: [EMAIL PROTECTED] Subject: [Portal] Question: Why JSR-168 portlet impl moved? Hi, I am curious why Carsten moved portlet implementation from scratchpad to portal block... I thought JSR-168 portlet implementation would go to core. I think that CocoonPortlet (JSR-168 portlet implementation) and portal block are two different things. CocoonPortlet makes cocoon applications work under portlet container (i.e. Jakarta Pluto). Portal block IS a portlet container (Portal Engine makes environment for coplets and portlets). So I don't see the reason why to mix these two. Why must I be dependent on the whole portal block (jar is 330kB and will be more) when I want to implement just one JSR-168 portlet using cocoon? I supposed that JSR-168 portlet implementation would go to core, where other env implementations are (Servlet and CLI). What was the reason for not doing so? Thanks, Michal BTW: Tiny patch for CocoonPortal.java is now in Bugzilla #27188 __ Informacia od NOD32 __ Tato sprava bola preverena antivirusovym systemom NOD32. http://www.eset.com
RE: [Portal] Question: Why JSR-168 portlet impl moved?
DURDINA Michal wrote: Thanks for pointing me there. Inspite of that, my questions remain: 1. Why must I be dependent on the whole portal block (jar is 330kB and will be more) when I want to implement just one JSR-168 portlet using Cocoon and using 3rd party portlet container? I really understand your concern, but we feel that all JSR 168 related code should go into the same directory space and that is currently the portal block. Sooner or later, things might change a little bit here and perhaps the portal block will move to the portals TLP (or not). And perhaps the portal block will build two jar files, one for the environment and one for the portal. But I think these are two different things: where the code is placed best and what the result of a build is. I can only try to promise that this will change sometime in the next weeks/months. 2. What was the reason for not moving that code to src/java? Now, this doesn't belong to the core. Not everyone needs a portlet environment and as the portlet environment requires the portlet api as a jar, we want to keep the core clean of that. HTH Carsten
