June 2011 - gatein-issues - Jboss List Archives

[JBoss JIRA] Created: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"

by Michael Hauer (JIRA)

PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal" ------------------------------------------------------------------------------------- Key: GTNPORTAL-1939 URL: https://issues.jboss.org/browse/GTNPORTAL-1939 Project: GateIn Portal Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: Common integration Affects Versions: 3.1.0-GA Environment: Doesn't matter Reporter: Michael Hauer The problem we were facing is very curious: While porting our app from jboss 4.3 (plus portal) to jboss 5.1 epp (GateIn), I was facing a problem with the login.jsp which showed the following behaviour: The first login (InitiateLoginServlet) displayed the correct login.jsp we have in our extension. But after trying to login with invalid credentials I kept beeing redirected to the login.jsp from the default portal. I used at least 3 hours to debug the whole bunch of eXo classes (very hard, facing the fact, that not all sources are shipped with the source zip file). Then I realized the problem: I implemented a custom Authenticator which extends OrganizationAuthenticatorImpl. There I tried to put some Attributes to the current PortalContainer using PortalContainer.getInstance().setAttribute("bla", "bla"). What I didn't know is, that this GETInstance sets the default portal if the current container is null. In general a getter is not intended to modify anything. Even considering situations where this might make sense, I think this could cause lots of trouble. I would expect an exception if there is no current container. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
10
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1881) Artifact "exo.portal.web" has a wrong name - GateIn Portal Portlet

by Tomas Kyjovsky (JIRA)

Artifact "exo.portal.web" has a wrong name - GateIn Portal Portlet ------------------------------------------------------------------ Key: GTNPORTAL-1881 URL: https://issues.jboss.org/browse/GTNPORTAL-1881 Project: GateIn Portal Issue Type: Quality Risk Security Level: Public (Everyone can see) Affects Versions: 3.1.0-GA Reporter: Tomas Kyjovsky Priority: Optional gatein/web/pom.xml ... <artifactId>exo.portal.web</artifactId> <name>GateIn Portal Portlet</name> ... Should be: GateIn Portal Web -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
8
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1921) Sprint 54 activities

by Minh Hoang TO (JIRA)

Sprint 54 activities -------------------- Key: GTNPORTAL-1921 URL: https://issues.jboss.org/browse/GTNPORTAL-1921 Project: GateIn Portal Issue Type: Task Security Level: Public (Everyone can see) Reporter: Minh Hoang TO -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1914) OrganizationService lifecycle (and Hibernate transaction) always started in CacheUserProfileFilter during HTTP request of anonymous user

by Marek Posolda (JIRA)

OrganizationService lifecycle (and Hibernate transaction) always started in CacheUserProfileFilter during HTTP request of anonymous user ---------------------------------------------------------------------------------------------------------------------------------------- Key: GTNPORTAL-1914 URL: https://issues.jboss.org/browse/GTNPORTAL-1914 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Marek Posolda In version of SetCurrentIdentityFilter.java from eXo core 2.3.X (version used in GateIn and EPP) is ConversationState for anonymous user not created . But problem is that in eXo core 2.4.0-GA-SNAPSHOT is ConversationState always created even for anonymous user because of EXOJCR-779 . And this is causing performance problem in CacheUserProfileFilter.java : {code} if (state != null) { if (state.getAttribute(USER_PROFILE) == null) { OrganizationService orgService = (OrganizationService)getContainer().getComponentInstanceOfType(OrganizationService.class); begin(orgService); User user = orgService.getUserHandler().findUserByName(state.getIdentity().getUserId()); end(orgService); state.setAttribute(USER_PROFILE, user); } } {code} When we are using eXo core 2.4.0, then ConversationState is never null, which means that the inner clausule is always called, which means expensive start of Hibernate transaction (And this is not good for performance). This is called for every HTTP request of anonymous user, because User is never found and so that statement: "state.getAttribute(USER_PROFILE) == null" is always true. Possible workaround can be use something like: {code} if (state != null && !IdentityConstants.ANONIM.equals(state.getIdentity().getUserId())) {code} in CacheUserProfileFilter.java. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

5
9
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1949) LDAPIdentityStoreImpl: Undocumented Feature "entrySearchScope" subtree searching

by Georg Fleischer (JIRA)

LDAPIdentityStoreImpl: Undocumented Feature "entrySearchScope" subtree searching -------------------------------------------------------------------------------- Key: GTNPORTAL-1949 URL: https://issues.jboss.org/browse/GTNPORTAL-1949 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 3.1.0-GA Environment: Enterprise Portal Platform 5.1.0 CentOS Reporter: Georg Fleischer Assignee: Luc Texier The class LDAPIdentityStoreImpl supports searching in a subtree of a node. The problem is, that it is documented nowhere, not even in the example files provided the gatein.ear file. I was only able to reveal this feature by looking at the source code. Please update the documentation and the example configuration files. Add the infrmation that the class LDAPIdentityStoreImpl supports subtree searching when connecting to an LDAP. It can be configured in the identity configuration, for example in /gatein.ear/02portal.war/WEB-INF/conf/organization/ picketlink-idm/examples/picketlink-idm-msad-readonly-config.xml using the following option. <option> <name>entrySearchScope</name> <value>subtree</value> </option> Kind regards, Georg Fleischer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1947) Support wsrp element in StAX integration

by Minh Hoang TO (JIRA)

Support wsrp element in StAX integration ---------------------------------------- Key: GTNPORTAL-1947 URL: https://issues.jboss.org/browse/GTNPORTAL-1947 Project: GateIn Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Minh Hoang TO Required by GTNPORTAL-1946 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (GTNPC-67) Remove JBoss XB dependency for server based unit tests

by Julien Viet (JIRA)

Remove JBoss XB dependency for server based unit tests ------------------------------------------------------ Key: GTNPC-67 URL: https://issues.jboss.org/browse/GTNPC-67 Project: GateIn Portlet Container Issue Type: Task Reporter: Julien Viet Assignee: Julien Viet Fix For: 2.3.0-Beta05 Still remaining for simple portal (along with JBoss MC) needs to check later if it's really used or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (GTNPC-66) Rewrite portlet xml parsing using staxnav

by Julien Viet (JIRA)

Rewrite portlet xml parsing using staxnav ----------------------------------------- Key: GTNPC-66 URL: https://issues.jboss.org/browse/GTNPC-66 Project: GateIn Portlet Container Issue Type: Task Reporter: Julien Viet Assignee: Julien Viet Fix For: 2.3.0-Beta05 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1425) the navcontroller branch merges into trunk

by Trong Tran (JIRA)

the navcontroller branch merges into trunk ------------------------------------------ Key: GTNPORTAL-1425 URL: https://jira.jboss.org/browse/GTNPORTAL-1425 Project: GateIn Portal Issue Type: Task Security Level: Public (Everyone can see) Reporter: Trong Tran Fix For: 3.2.0-GA the navcontroller branch includes commits for issues that have a *depends* link to this JIRA issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1935) PortletModes and WindowStates are not properly broadcasting events in webui

by Matt Wringe (JIRA)

PortletModes and WindowStates are not properly broadcasting events in webui --------------------------------------------------------------------------- Key: GTNPORTAL-1935 URL: https://issues.jboss.org/browse/GTNPORTAL-1935 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: WebUI Reporter: Matt Wringe Assignee: Matt Wringe The WebUI event broadcast system doesn't work properly when changes occur in the windowstate or the portletmode during a portlet invocation. The current setup assumes that the portlet url will always contain a parameter if the windowstate or portletmode needs to be changed, but this is not always the case. For example, an event can change the portletmode without using a url. Need to monitor if the mode/state changes during invocation and broadcast the event. Since the current event system checks the requestContext requestParameters (which are set based on the url and not editable) we will need to use a requestContext attribute to specify the proper mode/state. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues June 2011