[JBoss JIRA] Created: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
8:35 a.m.
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
8:37 a.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Michael Hauer updated GTNPORTAL-1939:
-------------------------------------
Description:
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 request (localhost/myportal/private/myportal) for 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.
was:
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.
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 request (localhost/myportal/private/myportal) for 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
2:39 a.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Minh Hoang TO updated GTNPORTAL-1939:
-------------------------------------
Labels: portal-s56 (was: )
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
Labels: portal-s56
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 request (localhost/myportal/private/myportal) for 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
10:46 p.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Minh Hoang TO updated GTNPORTAL-1939:
-------------------------------------
Assignee: Minh Hoang TO
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
Assignee: Minh Hoang TO
Labels: portal-s56
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 request (localhost/myportal/private/myportal) for 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:08 a.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Trong Tran updated GTNPORTAL-1939:
----------------------------------
Original Estimate: 2 hours
Remaining Estimate: 2 hours
Labels: portal-s56 review_julien (was: portal-s56)
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
Assignee: Minh Hoang TO
Labels: portal-s56, review_julien
Original Estimate: 2 hours
Remaining Estimate: 2 hours
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 request (localhost/myportal/private/myportal) for 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
10:50 p.m.
New subject: [JBoss JIRA] Work started: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Work on GTNPORTAL-1939 started by Minh Hoang TO.
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
Assignee: Minh Hoang TO
Labels: portal-s56, review_julien
Original Estimate: 2 hours
Remaining Estimate: 2 hours
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 request (localhost/myportal/private/myportal) for 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
4:51 a.m.
New subject: [JBoss JIRA] Commented: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Minh Hoang TO commented on GTNPORTAL-1939:
------------------------------------------
Could you explain more why you tend to put some attributes to current PortalContainer?
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
Assignee: Minh Hoang TO
Labels: portal-s56, review_julien
Original Estimate: 2 hours
Remaining Estimate: 2 hours
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 request (localhost/myportal/private/myportal) for 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
4:53 a.m.
New subject: [JBoss JIRA] Commented: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Minh Hoang TO commented on GTNPORTAL-1939:
------------------------------------------
I think you have a custom PortalContainer instead of an extension of default
PortalContainer. By the way, the RootContainer provides access to PortalContainer by name
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
Assignee: Minh Hoang TO
Labels: portal-s56, review_julien
Original Estimate: 2 hours
Remaining Estimate: 2 hours
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 request (localhost/myportal/private/myportal) for 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
5:05 a.m.
New subject: [JBoss JIRA] Commented: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Michael Hauer commented on GTNPORTAL-1939:
------------------------------------------
In the meantime we got it all working and we are now also aware of all the methods which
provide the PortalContainer in one or the other way, so from my point of view, no further
investigation/adjustment is necessary. Thank's for your help!
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
Assignee: Minh Hoang TO
Labels: portal-s56, review_julien
Original Estimate: 2 hours
Remaining Estimate: 2 hours
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 request (localhost/myportal/private/myportal) for 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
5:18 a.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Minh Hoang TO updated GTNPORTAL-1939:
-------------------------------------
Labels: portal-s56 review_julien worked (was: portal-s56 review_julien)
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
Assignee: Minh Hoang TO
Labels: portal-s56, review_julien, worked
Original Estimate: 2 hours
Remaining Estimate: 2 hours
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 request (localhost/myportal/private/myportal) for 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
5:20 a.m.
New subject: [JBoss JIRA] Work stopped: (GTNPORTAL-1939) PortalContainer#getInstance() must not set the DEFAULT_PORTAL_CONTAINER_NAME "portal"
[
https://issues.jboss.org/browse/GTNPORTAL-1939?page=com.atlassian.jira.pl...
]
Work on GTNPORTAL-1939 stopped by Minh Hoang TO.
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
Assignee: Minh Hoang TO
Labels: portal-s56, review_julien, worked
Original Estimate: 2 hours
Remaining Estimate: 2 hours
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 request (localhost/myportal/private/myportal) for 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
4715
days inactive
4735
days old
10 comments
3 participants
participants (3)
-
Michael Hauer (JIRA) -
Minh Hoang TO (JIRA)
-
Trong Tran (JIRA)