November 2013 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3257) REST MOP Import doesn't detect errors on commit

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3257?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3257: ---------------------------------------------------- Boleslaw Dawidowicz <bdawidow(a)redhat.com> made a comment on [bug 1004213|https://bugzilla.redhat.com/show_bug.cgi?id=1004213] Looks like fixed in JCR 1.16.x Would require backport to 1.15.x > REST MOP Import doesn't detect errors on commit > ----------------------------------------------- > > Key: GTNPORTAL-3257 > URL: https://issues.jboss.org/browse/GTNPORTAL-3257 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: REST API > Affects Versions: 3.6.0.Final > Reporter: Toshiya Kobayashi > > When you call REST MOP Import: > {noformat} > curl -v -u root:gtn -X PUT -H 'Content-type: application/zip' --upload-file portal_classic_2013-06-10_15-16-53.zip http://localhost:8080/rest/private/managed-components/mop?importMode=over... > {noformat} > It returns 200 OK even if it fails on JCR commit (for example, cache replication timeout). > Because JCR commit happens in RequestLifeCycle.end() after requestHandler.handleRequest() which flushes http response. > https://github.com/exoplatform/ws/blob/master/exo.ws.rest.core/src/main/j... > {code:java} > protected void onService(ExoContainer container, HttpServletRequest httpRequest, HttpServletResponse httpResponse) > throws IOException, ServletException > { > ... > try > { > EnvironmentContext.setCurrent(env); > ServletContainerRequest request = new ServletContainerRequest(httpRequest); > ContainerResponse response = new ContainerResponse(new ServletContainerResponseWriter(httpResponse)); > requestHandler.handleRequest(request, response); > } > ... > finally > { > EnvironmentContext.setCurrent(null); > RequestLifeCycle.end(); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNWSRP-363) WSRP load-balancing & failover embedded into WSRP itself, without httpd in front of the cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNWSRP-363?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on GTNWSRP-363: ------------------------------------------------- Jiri Pallich <jpallich(a)redhat.com> changed the Status of [bug 961242|https://bugzilla.redhat.com/show_bug.cgi?id=961242] from NEW to CLOSED > WSRP load-balancing & failover embedded into WSRP itself, without httpd in front of the cluster > ----------------------------------------------------------------------------------------------- > > Key: GTNWSRP-363 > URL: https://issues.jboss.org/browse/GTNWSRP-363 > Project: GateIn WSRP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Producer, Specification Support > Environment: - JBoss EPP > - 5 > - 6 > Reporter: Adam Kovari > Assignee: Chris Laprun > Priority: Minor > > This is a feature request for having an ability of WSRP to handle clustering on it's own, e.g. without an external load-balancer such as httpd. > The reason for this is an extra weight that external load balancer adds, in environments with 100s-1000s of virtual deployment this is a considerable issue. > It should work like this: > {code} > <wsrp-producer id="business" expiration-cache="500" ws-timeout="10000"> >  > <endpoint-wsdl-url>https://xxx:17111/wsrp-producer/v2/MarkupService?wsdl</endpoint-wsdl-url> > <endpoint-wsdl-url>https://xxx2:17111/wsrp-producer/v2/MarkupService?wsdl</endpoint-wsdl-url> > <registration-data/> > </wsrp-producer> > {code} > So that there would be a possibility to define multiple endpoints of which the WSRP implementation itself would choose based on failover/load-balancing policies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNWSRP-364) RFE - WSRP load-balancing & failover embedded into WSRP itself, without httpd in front of the cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNWSRP-364?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on GTNWSRP-364: ------------------------------------------------- Jiri Pallich <jpallich(a)redhat.com> changed the Status of [bug 961242|https://bugzilla.redhat.com/show_bug.cgi?id=961242] from NEW to CLOSED > RFE - WSRP load-balancing & failover embedded into WSRP itself, without httpd in front of the cluster > ----------------------------------------------------------------------------------------------------- > > Key: GTNWSRP-364 > URL: https://issues.jboss.org/browse/GTNWSRP-364 > Project: GateIn WSRP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Producer, Specification Support > Environment: - JBoss EPP > - 5 > - 6 > Reporter: Adam Kovari > Assignee: Chris Laprun > Priority: Minor > > This is a feature request for having an ability of WSRP to handle clustering on it's own, e.g. without an external load-balancer such as httpd. > The reason for this is an extra weight that external load balancer adds, in environments with 100s-1000s of virtual deployment this is a considerable issue. > It should work like this: > {code} > <wsrp-producer id="business" expiration-cache="500" ws-timeout="10000"> >  > <endpoint-wsdl-url>https://xxx:17111/wsrp-producer/v2/MarkupService?wsdl</endpoint-wsdl-url> > <endpoint-wsdl-url>https://xxx2:17111/wsrp-producer/v2/MarkupService?wsdl</endpoint-wsdl-url> > <registration-data/> > </wsrp-producer> > {code} > So that there would be a possibility to define multiple endpoints of which the WSRP implementation itself would choose based on failover/load-balancing policies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNWSRP-364) RFE - WSRP load-balancing & failover embedded into WSRP itself, without httpd in front of the cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNWSRP-364?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on GTNWSRP-364: ------------------------------------------------- Jiri Pallich <jpallich(a)redhat.com> made a comment on [bug 961242|https://bugzilla.redhat.com/show_bug.cgi?id=961242] We've carefully evaluated the request, but are unable to include it in a future releases. To request that Red Hat re-consider this request, please re-open the bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you. > RFE - WSRP load-balancing & failover embedded into WSRP itself, without httpd in front of the cluster > ----------------------------------------------------------------------------------------------------- > > Key: GTNWSRP-364 > URL: https://issues.jboss.org/browse/GTNWSRP-364 > Project: GateIn WSRP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Producer, Specification Support > Environment: - JBoss EPP > - 5 > - 6 > Reporter: Adam Kovari > Assignee: Chris Laprun > Priority: Minor > > This is a feature request for having an ability of WSRP to handle clustering on it's own, e.g. without an external load-balancer such as httpd. > The reason for this is an extra weight that external load balancer adds, in environments with 100s-1000s of virtual deployment this is a considerable issue. > It should work like this: > {code} > <wsrp-producer id="business" expiration-cache="500" ws-timeout="10000"> >  > <endpoint-wsdl-url>https://xxx:17111/wsrp-producer/v2/MarkupService?wsdl</endpoint-wsdl-url> > <endpoint-wsdl-url>https://xxx2:17111/wsrp-producer/v2/MarkupService?wsdl</endpoint-wsdl-url> > <registration-data/> > </wsrp-producer> > {code} > So that there would be a possibility to define multiple endpoints of which the WSRP implementation itself would choose based on failover/load-balancing policies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNWSRP-363) WSRP load-balancing & failover embedded into WSRP itself, without httpd in front of the cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNWSRP-363?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on GTNWSRP-363: ------------------------------------------------- Jiri Pallich <jpallich(a)redhat.com> made a comment on [bug 961242|https://bugzilla.redhat.com/show_bug.cgi?id=961242] We've carefully evaluated the request, but are unable to include it in a future releases. To request that Red Hat re-consider this request, please re-open the bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you. > WSRP load-balancing & failover embedded into WSRP itself, without httpd in front of the cluster > ----------------------------------------------------------------------------------------------- > > Key: GTNWSRP-363 > URL: https://issues.jboss.org/browse/GTNWSRP-363 > Project: GateIn WSRP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Producer, Specification Support > Environment: - JBoss EPP > - 5 > - 6 > Reporter: Adam Kovari > Assignee: Chris Laprun > Priority: Minor > > This is a feature request for having an ability of WSRP to handle clustering on it's own, e.g. without an external load-balancer such as httpd. > The reason for this is an extra weight that external load balancer adds, in environments with 100s-1000s of virtual deployment this is a considerable issue. > It should work like this: > {code} > <wsrp-producer id="business" expiration-cache="500" ws-timeout="10000"> >  > <endpoint-wsdl-url>https://xxx:17111/wsrp-producer/v2/MarkupService?wsdl</endpoint-wsdl-url> > <endpoint-wsdl-url>https://xxx2:17111/wsrp-producer/v2/MarkupService?wsdl</endpoint-wsdl-url> > <registration-data/> > </wsrp-producer> > {code} > So that there would be a possibility to define multiple endpoints of which the WSRP implementation itself would choose based on failover/load-balancing policies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3287) Portal.hasPermission returns false if Permission parameter contains multiple Memberships

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3287?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3287: ---------------------------------------------------- Boleslaw Dawidowicz <bdawidow(a)redhat.com> changed the Status of [bug 1029005|https://bugzilla.redhat.com/show_bug.cgi?id=1029005] from NEW to ASSIGNED > Portal.hasPermission returns false if Permission parameter contains multiple Memberships > ---------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3287 > URL: https://issues.jboss.org/browse/GTNPORTAL-3287 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Java API > Affects Versions: 3.6.3.Final > Reporter: Martin Weiler > Assignee: Nick Scavelli > > We have 2 sites > http://localhost:8080/portal/default/ > http://localhost:8080/portal/webadmin/ > In a portlet, we need to show a link to "/portal/webadmin/" only if user has access to "webadmin" site. > Site "webadmin" has access permissions set as "*:/platform/administrators/admin group1;*:/platform/administrators/admin group2;*:/platform/administrators/admin group3". > User has Membership Type "member" in "/platform/administrators/admin group1" group. > In a portlet, we are checking permissions with the following snippet: > {code} > PortalRequest portalRequest = PortalRequest.getInstance(); > Site webadminSite = portalRequest.getPortal().getSite(new SiteId("webadmin")); > portal.hasPermission(portalRequest.getUser() , webadminSite.getAccessPermission()); > {code} > hasPermission method is returning false. > Note: access permissions on 'webadmin' site are only set to a single entry (eg. /platform/administrators/admin group1), the method returns true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3264) Topbar navigation menu issues with small screens and RTL languages

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3264?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3264: ---------------------------------------------------- Boleslaw Dawidowicz <bdawidow(a)redhat.com> changed the Status of [bug 1004669|https://bugzilla.redhat.com/show_bug.cgi?id=1004669] from NEW to ASSIGNED > Topbar navigation menu issues with small screens and RTL languages > ------------------------------------------------------------------ > > Key: GTNPORTAL-3264 > URL: https://issues.jboss.org/browse/GTNPORTAL-3264 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Mobile > Reporter: Matt Wringe > Assignee: Matt Wringe > Fix For: 3.7.0.Final > > > When dealing with small screens and RTL languages, the top navigation bar does not render correctly and can start to render outside of the screenspace. > There is also an issue with some of the text not being properly hidden on older browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-2394) The GadgetDeployer should unregister itself as WebAppListener in the stop method

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-2394?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-2394: ---------------------------------------------------- Boleslaw Dawidowicz <bdawidow(a)redhat.com> changed the Status of [bug 987708|https://bugzilla.redhat.com/show_bug.cgi?id=987708] from NEW to ASSIGNED > The GadgetDeployer should unregister itself as WebAppListener in the stop method > -------------------------------------------------------------------------------- > > Key: GTNPORTAL-2394 > URL: https://issues.jboss.org/browse/GTNPORTAL-2394 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.1.0-GA > Reporter: Nicolas Filotto > Labels: gadget > Fix For: 3.6.4.Final, 3.7.0.Final > > Attachments: GTNPORTAL-2394.patch > > > Up to now, when the application tries to stop the component instead of unregistering itself it registers itself another time. Indeed the current code is: > {code} > public void stop() > { > DefaultServletContainerFactory.getInstance().getServletContainer().addWebAppListener(this); > } > {code} > But should be: > {code} > public void stop() > { > DefaultServletContainerFactory.getInstance().getServletContainer().removeWebAppListener(this); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3248) Portlet archive containing gatein-resources.xml fails to redeploy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3248?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3248: ---------------------------------------------------- Boleslaw Dawidowicz <bdawidow(a)redhat.com> changed the Status of [bug 987708|https://bugzilla.redhat.com/show_bug.cgi?id=987708] from NEW to ASSIGNED > Portlet archive containing gatein-resources.xml fails to redeploy > ----------------------------------------------------------------- > > Key: GTNPORTAL-3248 > URL: https://issues.jboss.org/browse/GTNPORTAL-3248 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.6.1.Final > Reporter: Marko Strukelj > Assignee: Vu Viet Phuong > Labels: backlogs > Fix For: 3.7.0.Final > > Attachments: js-modular-reproducer.zip > > Original Estimate: 4 hours > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > During hot redeploy of portlet application JavascripConfigDeployer should remove any resource ids registered during application deploy as a result of using gatein-resources.xml. Logic for that is missing, and we get a duplicate resource id exception: > 19:34:39,162 ERROR [org.exoplatform.web.application.javascript.JavascriptConfigDeployer] (ServerService Thread Pool -- 23) An error occurs while processing 'Javascript in gatein-resources.xml' from the context 'TestJS': java.lang.IllegalStateException: Duplicate ResourceId : PORTLET/js-modular-issue/JSModuleReproducer, later resource definition will be ignored > at org.gatein.portal.controller.resource.script.ScriptGraph.addResource(ScriptGraph.java:223) [exo.portal.component.web.resources-3.6.2.Final-SNAPSHOT.jar:3.6.2.Final-SNAPSHOT] > at org.exoplatform.web.application.javascript.JavascriptTask.execute(JavascriptTask.java:49) [exo.portal.component.web.resources-3.6.2.Final-SNAPSHOT.jar:3.6.2.Final-SNAPSHOT] > at org.exoplatform.web.application.javascript.JavascriptConfigParser.processConfigResource(JavascriptConfigParser.java:124) [exo.portal.component.web.resources-3.6.2.Final-SNAPSHOT.jar:3.6.2.Final-SNAPSHOT] > at org.exoplatform.web.application.javascript.JavascriptConfigDeployer.register(JavascriptConfigDeployer.java:113) [exo.portal.component.web.resources-3.6.2.Final-SNAPSHOT.jar:3.6.2.Final-SNAPSHOT] > at org.exoplatform.web.application.javascript.JavascriptConfigDeployer.access$000(JavascriptConfigDeployer.java:43) [exo.portal.component.web.resources-3.6.2.Final-SNAPSHOT.jar:3.6.2.Final-SNAPSHOT] > at org.exoplatform.web.application.javascript.JavascriptConfigDeployer$1.execute(JavascriptConfigDeployer.java:92) [exo.portal.component.web.resources-3.6.2.Final-SNAPSHOT.jar:3.6.2.Final-SNAPSHOT] > at org.exoplatform.container.RootContainer$PortalContainerPostInitTask.onAlreadyExists(RootContainer.java:1299) [exo.kernel.container-2.4.4-GA.jar:2.4.4-GA] > at org.exoplatform.container.RootContainer.addInitTask(RootContainer.java:1127) [exo.kernel.container-2.4.4-GA.jar:2.4.4-GA] > at org.exoplatform.container.PortalContainer.addInitTask(PortalContainer.java:485) [exo.kernel.container-2.4.4-GA.jar:2.4.4-GA] > at org.exoplatform.web.application.javascript.JavascriptConfigDeployer.add(JavascriptConfigDeployer.java:96) [exo.portal.component.web.resources-3.6.2.Final-SNAPSHOT.jar:3.6.2.Final-SNAPSHOT] > at org.exoplatform.web.application.javascript.JavascriptConfigDeployer.onEvent(JavascriptConfigDeployer.java:71) [exo.portal.component.web.resources-3.6.2.Final-SNAPSHOT.jar:3.6.2.Final-SNAPSHOT] > at org.gatein.wci.ServletContainer.safeFireEvent(ServletContainer.java:319) [wci-wci-2.3.1.Final.jar:2.3.1.Final] > at org.gatein.wci.ServletContainer.fireEvent(ServletContainer.java:338) [wci-wci-2.3.1.Final.jar:2.3.1.Final] > at org.gatein.wci.ServletContainer.access$400(ServletContainer.java:56) [wci-wci-2.3.1.Final.jar:2.3.1.Final] > at org.gatein.wci.ServletContainer$RegistrationImpl.registerWebApp(ServletContainer.java:462) [wci-wci-2.3.1.Final.jar:2.3.1.Final] > at org.gatein.wci.jboss.JB7ServletContainerContext.start(JB7ServletContainerContext.java:369) [wci-jboss7-2.3.1.Final.jar:2.3.1.Final] > at org.gatein.wci.jboss.JB7ServletContainerContext.lifecycleEvent(JB7ServletContainerContext.java:223) [wci-jboss7-2.3.1.Final.jar:2.3.1.Final] > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] > at org.apache.catalina.core.StandardContext.start(StandardContext.java:3772) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] > at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] > at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) [classes.jar:1.6.0_51] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [classes.jar:1.6.0_51] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [classes.jar:1.6.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [classes.jar:1.6.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [classes.jar:1.6.0_51] > at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_51] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > 19:34:39,168 ERROR [org.exoplatform.commons.xml.XMLValidator] (ServerService Thread Pool -- 23) Error in document jndi:/default-host/js-modular-issue/WEB-INF/gatein-resources.xml at (4,89) :cvc-elt.1: Cannot find the declaration of element 'gatein-resources'. > 19:34:39,179 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "js-modular-issue.war" with deployment "js-modular-issue.war" > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3250) The portlets cannot be displayed after a portal reload

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3250?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3250: ---------------------------------------------------- Boleslaw Dawidowicz <bdawidow(a)redhat.com> changed the Status of [bug 987708|https://bugzilla.redhat.com/show_bug.cgi?id=987708] from NEW to ASSIGNED > The portlets cannot be displayed after a portal reload > ------------------------------------------------------ > > Key: GTNPORTAL-3250 > URL: https://issues.jboss.org/browse/GTNPORTAL-3250 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PC integration > Affects Versions: 3.6.1.Final > Reporter: Nicolas Filotto > Assignee: Marko Strukelj > Fix For: 3.6.4.Final, 3.7.0.Final > > Attachments: GTNPORTAL-3250.patch > > Original Estimate: 1 day > Remaining Estimate: 1 day > > If you launch Gatein in developing mode, it is possible to reload only a given portal container either automatically by redeploying a webapp that has been defined as a PortalContainerConfigOwner (in other words you have the listener org.exoplatform.container.web.PortalContainerConfigOwner in your web.xml) or manually using the JMX console. And when you do so, no portlet can be displayed properly anymore (we have the message "This portlet encountered an error and could not be displayed" for all portlets), this issue is due to https://issues.jboss.org/browse/GTNPORTAL-2406. > Here are the steps to reproduce: > * Start GateIn with ./standalone.sh -Dexo.product.developing=true > * launch the JMX Console and call _reload_ with the argument _portal_ on the MBean {{exo:container=root}} > * Once the command is over, go to http://localhost:8080/portal/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues November 2013