gatein-dev November 2013

gatein-dev@lists.jboss.org

9 participants
5 discussions

by Marek Posolda

Hi all, We've been requested several times by our users/customers to add "impersonation" feature. It may be useful for portal administrator to have possibility to temporary login as another user without knowing his password. For example: User /root/ wants to verify that user /mary/ really doesn't have permission to see page X or portlet Y on page Z. I've added specification page here https://community.jboss.org/wiki/ImpersonationInGateInPortal . Feel free to provide feedback here or in comments of specification. Have a nice weekend! Marek

11 years, 7 months

3
9
0 / 0

SessionManagerContainer in exo.kernel.container 2.6.0-Alpha3

by Lucas Ponce

Hello, There is a issue in current master that is impacting to REST management services in GateIn. https://issues.jboss.org/browse/GTNPORTAL-3308 Investigating it looks like that issue appears since migration to 2.6.0-Alpha3 core. Main symptom is a NPE in POMSessionManager class: https://github.com/gatein/gatein-portal/blob/428874e25ee9e6dada3fd1a54a4a... One of the changes of 2.6.0-Alpha3 is to drop the SessionManagerContainer interface from PortalContainer. Is there a workaround to access to same functionality in order to fix this issue ? Thanks in advance, Lucas

11 years, 10 months

4
16
0 / 0

Favicon - Request for comments (and suggestions)

by Juraci Paixão Kröhling

All, We have a request to display a specific favicon for JBoss Portal, and it seems there's no "easy" (or correct) solution in place for that right now. The first intuitive solution would be to override the templates, to make them link to the desired favicon. This doesn't scales, as the whole template is duplicated and it will only cause headaches in the future. The second possible solution would be to incorporate the path to the favicon into the properties file, but this means having a fixed path to the favicon, which is a step backwards from what there is today: in one of the templates for /portal, it gets the favicon for the context path, so, if the current portal is /example-portal, it currently gets the favicon at /example-portal/favicon . With the favicon coming from the properties file, this would not be the case anymore, as all favicons would be coming from a fixed path. The third solution would be to build a FaviconService, that would take care of determining the proper favicon path. It sounds to me that this is a bit of overkill, but would be a clean solution. Of course, the best option would be to be possible to override the favicon from /portal, but this doesn't seems to be possible at the moment. It seems that only templates are overriden. Before proceeding with the third solution (which seems the most desirable as of now), I would like to get your comments, opinions and suggestions on how this could be better handled. Best Regards, Juca.

11 years, 10 months

3
6
0 / 0

responsive portlets

by Julien Viet

Hi, I would like to know why there is a mapping “one war file per portlet” for the responsive portlets since GateIn 3.6 : https://github.com/gatein/gatein-portal/tree/master/mobile-integration/po... I would like to group them in a single war file (for obvious reasons). what do you think ? Julien

11 years, 10 months

3
3
0 / 0

RepositoryContainer as the first thing to stop during shutdown

by Juraci Paixão Kröhling

All, I'm currently working on GTNPORTAL-3281 [1], and I have a question. The WARN message on the logs occurs during the shutdown of the server, when the method WSRPServiceIntegration.stop() is called. During this stop() method, both producer and consumers are then requested to be stopped, but the configuration for the producer and the list of consumers requires access to the workspace, which is already shut down, as RepositoryContainer is stopped before WSRPServiceIntegration. While stopping the producer is possible without requesting the workspace to be active, shutting down the consumers currently require a fresh list of consumers, which in turn requires access to the workspace. When looking into why WSRPServiceIntegration is stopped after RepositoryContainer, I noticed that the list of services to start during the boot contains 36 items, while the shutdown contains 37. The difference is exactly the RepositoryContainer. So, does anyone knows if it is appropriate for RepositoryContainer to be stopped before everything else, including WSRPServiceIntegration? If not, I would then look for the place where RepositoryContainer is added and add it to the head of the list, instead of appending it (this means that RepositoryContainer will be the last thing to be stopped, instead of the first, as it currently is). If RepositoryContainer should indeed be the first thing to be shut down, then the solution that I can see is to get the cached list of consumers, instead of getting a fresh one. This should remove the requirement of the workspace to exist during the shutdown of WSRPServiceIntegration. 1 - https://issues.jboss.org/browse/GTNPORTAL-3281 Thanks! Juca.

11 years, 10 months

2
9
0 / 0

← Newer
1
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-dev November 2013