[JBoss JIRA] (GTNPORTAL-3267) MOP import resource
by Boubaker Khanfir (JIRA)
Boubaker Khanfir created GTNPORTAL-3267:
-------------------------------------------
Summary: MOP import resource
Key: GTNPORTAL-3267
URL: https://issues.jboss.org/browse/GTNPORTAL-3267
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Java API
Affects Versions: 3.5.6.Final
Reporter: Boubaker Khanfir
MOP resource management is based on a custom marshaller/unmarshaller (org.exoplatform.portal.mop.management.binding.xml.*).
I had used the mop managed resource in a custom case:
* Create a new site.
* Add PortalBody in a container.
* Export site using GateIN management.
* Re-import exported site.
=> Exception:
{code}
Operation exception for operation import-resource and address /mop [org.gatein.management.cli<pool-4-thread-1>]
org.gatein.management.api.exceptions.OperationException: Exception reading data for import.
at org.exoplatform.portal.mop.management.operations.MopImportResource.execute(MopImportResource.java:198) ~[exo.portal.component.portal-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
at org.gatein.management.core.api.controller.SimpleManagementController.execute(SimpleManagementController.java:100) ~[gatein-management-core-1.1.0.Final.jar:1.1.0.Final]
...
Caused by: org.staxnav.StaxNavException: Unexpected element 'page-body' at [row,col]:[167,21]
at org.gatein.common.xml.stax.navigator.Exceptions.unexpectedElement(Exceptions.java:45) ~[exo.portal.component.common-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
at org.exoplatform.portal.mop.management.binding.xml.AbstractMarshaller.unmarshalContainer(AbstractMarshaller.java:171) ~[exo.portal.component.portal-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
at org.exoplatform.portal.mop.management.binding.xml.SiteLayoutMarshaller.unmarshalPortalConfig(SiteLayoutMarshaller.java:216) ~[exo.portal.component.portal-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
at org.exoplatform.portal.mop.management.binding.xml.SiteLayoutMarshaller.unmarshal(SiteLayoutMarshaller.java:80) ~[exo.portal.component.portal-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
... 40 common frames omitted
{code}
To fix this I used the *default* MOP marshaller:
{code}
import org.exoplatform.portal.config.model.ModelUnmarshaller;
// ...
public PortalConfig unmarshal(InputStream inputStream) throws BindingException {
try {
return ModelUnmarshaller.unmarshall(PortalConfig.class, inputStream).getObject();
} catch (Exception e) {
throw new BindingException(e);
}
}
//...
public Page.PageSet unmarshal(InputStream inputStream) throws BindingException {
try {
return ModelUnmarshaller.unmarshall(Page.PageSet.class, inputStream).getObject();
} catch (Exception e) {
throw new BindingException(e);
}
}
//...
public PageNavigation unmarshal(InputStream inputStream) throws BindingException {
try {
return ModelUnmarshaller.unmarshall(PageNavigation.class, inputStream).getObject();
} catch (Exception e) {
throw new BindingException(e);
}
}
// ...
{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, 3 months
[JBoss JIRA] (GTNMGMT-60) MOP import resource
by Boubaker Khanfir (JIRA)
[ https://issues.jboss.org/browse/GTNMGMT-60?page=com.atlassian.jira.plugin... ]
Boubaker Khanfir resolved GTNMGMT-60.
-------------------------------------
Resolution: Duplicate Issue
Moved to GTNPORTAL-3267
> MOP import resource
> -------------------
>
> Key: GTNMGMT-60
> URL: https://issues.jboss.org/browse/GTNMGMT-60
> Project: GateIn Management
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.0.Final
> Reporter: Boubaker Khanfir
> Assignee: Nick Scavelli
>
> MOP resource management is based on a custom marshaller/unmarshaller (org.exoplatform.portal.mop.management.binding.xml.*).
> I had used the mop managed resource in a custom case:
> * Create a new site.
> * Add PortalBody in a container.
> * Export site using GateIN management.
> * Re-import exported site.
> => Exception:
> {code}
> Operation exception for operation import-resource and address /mop [org.gatein.management.cli<pool-4-thread-1>]
> org.gatein.management.api.exceptions.OperationException: Exception reading data for import.
> at org.exoplatform.portal.mop.management.operations.MopImportResource.execute(MopImportResource.java:198) ~[exo.portal.component.portal-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
> at org.gatein.management.core.api.controller.SimpleManagementController.execute(SimpleManagementController.java:100) ~[gatein-management-core-1.1.0.Final.jar:1.1.0.Final]
> ...
> Caused by: org.staxnav.StaxNavException: Unexpected element 'page-body' at [row,col]:[167,21]
> at org.gatein.common.xml.stax.navigator.Exceptions.unexpectedElement(Exceptions.java:45) ~[exo.portal.component.common-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
> at org.exoplatform.portal.mop.management.binding.xml.AbstractMarshaller.unmarshalContainer(AbstractMarshaller.java:171) ~[exo.portal.component.portal-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
> at org.exoplatform.portal.mop.management.binding.xml.SiteLayoutMarshaller.unmarshalPortalConfig(SiteLayoutMarshaller.java:216) ~[exo.portal.component.portal-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
> at org.exoplatform.portal.mop.management.binding.xml.SiteLayoutMarshaller.unmarshal(SiteLayoutMarshaller.java:80) ~[exo.portal.component.portal-3.5.x-PLF-SNAPSHOT.jar:3.5.x-PLF-SNAPSHOT]
> ... 40 common frames omitted
> {code}
> To fix this I used the *default* MOP marshaller:
> {code}
> import org.exoplatform.portal.config.model.ModelUnmarshaller;
> // ...
> public PortalConfig unmarshal(InputStream inputStream) throws BindingException {
> try {
> return ModelUnmarshaller.unmarshall(PortalConfig.class, inputStream).getObject();
> } catch (Exception e) {
> throw new BindingException(e);
> }
> }
> //...
> public Page.PageSet unmarshal(InputStream inputStream) throws BindingException {
> try {
> return ModelUnmarshaller.unmarshall(Page.PageSet.class, inputStream).getObject();
> } catch (Exception e) {
> throw new BindingException(e);
> }
> }
> //...
> public PageNavigation unmarshal(InputStream inputStream) throws BindingException {
> try {
> return ModelUnmarshaller.unmarshall(PageNavigation.class, inputStream).getObject();
> } catch (Exception e) {
> throw new BindingException(e);
> }
> }
> // ...
> {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, 3 months
[JBoss JIRA] (GTNPORTAL-3159) Warn when a PortalContainerDef contains a non-existent dependency.
by Vu Viet Phuong (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3159?page=com.atlassian.jira.pl... ]
Work on GTNPORTAL-3159 started by Vu Viet Phuong.
> Warn when a PortalContainerDef contains a non-existent dependency.
> ------------------------------------------------------------------
>
> Key: GTNPORTAL-3159
> URL: https://issues.jboss.org/browse/GTNPORTAL-3159
> Project: GateIn Portal
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Peter Palaga
> Assignee: Vu Viet Phuong
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> This is important in a situation when a developer works on a Portal Extension or custom portal and he includes a non-existent dependency in the configuration of {{org.exoplatform.container.definition.PortalContainerDefinitionPlugin}} in {{configuration.xml}} file.
> Currently, the portal does not complain at all, the resource loading does not work as expected by the developer but he has little chance to track down the problem quickly and effectively. The portal should definitely warn when {{PortalContainerDefinition}} contains a non-existent dependency.
--
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, 3 months
[JBoss JIRA] (GTNPORTAL-3159) Warn when a PortalContainerDef contains a non-existent dependency.
by Vu Viet Phuong (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3159?page=com.atlassian.jira.pl... ]
Vu Viet Phuong reassigned GTNPORTAL-3159:
-----------------------------------------
Assignee: Vu Viet Phuong
> Warn when a PortalContainerDef contains a non-existent dependency.
> ------------------------------------------------------------------
>
> Key: GTNPORTAL-3159
> URL: https://issues.jboss.org/browse/GTNPORTAL-3159
> Project: GateIn Portal
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Peter Palaga
> Assignee: Vu Viet Phuong
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> This is important in a situation when a developer works on a Portal Extension or custom portal and he includes a non-existent dependency in the configuration of {{org.exoplatform.container.definition.PortalContainerDefinitionPlugin}} in {{configuration.xml}} file.
> Currently, the portal does not complain at all, the resource loading does not work as expected by the developer but he has little chance to track down the problem quickly and effectively. The portal should definitely warn when {{PortalContainerDefinition}} contains a non-existent dependency.
--
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, 3 months
[JBoss JIRA] (GTNPORTAL-3107) NullPointerException during Portlet Deployment when there is no <display-name> in web.xml
by Vu Viet Phuong (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3107?focusedWorklogId=12429746&... ]
Vu Viet Phuong logged work on GTNPORTAL-3107:
---------------------------------------------
Author: Vu Viet Phuong
Created on: 18/Sep/13 2:55 AM
Start Date: 18/Sep/13 2:55 AM
Worklog Time Spent: 4 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 1 day)
Time Spent: 4 hours
Worklog Id: (was: 12429746)
> NullPointerException during Portlet Deployment when there is no <display-name> in web.xml
> -----------------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3107
> URL: https://issues.jboss.org/browse/GTNPORTAL-3107
> Project: GateIn Portal
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Peter Palaga
> Assignee: Vu Viet Phuong
> Labels: worked
> Original Estimate: 1 day
> Time Spent: 4 hours
> Remaining Estimate: 0 minutes
>
> I am not sure if this is a bug or feature. Anyway, GateIn does not like WARs which do not have {{<display-name>}} in their {{web.xml}}. I guess the portal should be able to work around the non-availabbility of an explicit <display-name> through working with the default one?
> Steps to reproduce:
> * Take any quickstart from https://github.com/gatein/gatein-portal-quickstart, e.g. simplest-hello-world-portlet
> * remove {{<display-name>}} from {{web.xml}}
> * Compile & deploy
> * Expected: The portal should swallow the portlet app without any error.
> * Current: The portal throws this NPE
> {code}
> [0m[31m09:20:11,195 ERROR [org.exoplatform.web.application.javascript.JavascriptConfigDeployer] (ServerService Thread Pool -- 93) An error occurs while registering 'Javascript in gatein-resources.xml' from the context 'null': java.lang.IllegalArgumentException: The context name cannot be null
> at org.exoplatform.container.definition.PortalContainerConfig.getPortalContainerNames(PortalContainerConfig.java:502) [exo.kernel.container-2.4.3-GA-redhat-1.jar:2.4.3-GA-redhat-1]
> at org.exoplatform.container.PortalContainer.addInitTask(PortalContainer.java:474) [exo.kernel.container-2.4.3-GA-redhat-1.jar:2.4.3-GA-redhat-1]
> at org.exoplatform.web.application.javascript.JavascriptConfigDeployer.add(JavascriptConfigDeployer.java:96) [exo.portal.component.web.resources-3.6.0.Beta02-redhat-1.jar:3.6.0.Beta02-redhat-1]
> at org.exoplatform.web.application.javascript.JavascriptConfigDeployer.onEvent(JavascriptConfigDeployer.java:71) [exo.portal.component.web.resources-3.6.0.Beta02-redhat-1.jar:3.6.0.Beta02-redhat-1]
> at org.gatein.wci.ServletContainer.safeFireEvent(ServletContainer.java:319) [wci-wci-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.ServletContainer.fireEvent(ServletContainer.java:338) [wci-wci-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.ServletContainer.access$400(ServletContainer.java:56) [wci-wci-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.ServletContainer$RegistrationImpl.registerWebApp(ServletContainer.java:462) [wci-wci-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.jboss.JB7ServletContainerContext.start(JB7ServletContainerContext.java:369) [wci-jboss7-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.jboss.JB7ServletContainerContext.lifecycleEvent(JB7ServletContainerContext.java:223) [wci-jboss7-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> 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:471) [rt.jar:1.7.0_19]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_19]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_19]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_19]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_19]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {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, 3 months
[JBoss JIRA] (GTNPORTAL-3107) NullPointerException during Portlet Deployment when there is no <display-name> in web.xml
by Vu Viet Phuong (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3107?page=com.atlassian.jira.pl... ]
Vu Viet Phuong updated GTNPORTAL-3107:
--------------------------------------
Labels: worked (was: )
> NullPointerException during Portlet Deployment when there is no <display-name> in web.xml
> -----------------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3107
> URL: https://issues.jboss.org/browse/GTNPORTAL-3107
> Project: GateIn Portal
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Peter Palaga
> Assignee: Vu Viet Phuong
> Labels: worked
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> I am not sure if this is a bug or feature. Anyway, GateIn does not like WARs which do not have {{<display-name>}} in their {{web.xml}}. I guess the portal should be able to work around the non-availabbility of an explicit <display-name> through working with the default one?
> Steps to reproduce:
> * Take any quickstart from https://github.com/gatein/gatein-portal-quickstart, e.g. simplest-hello-world-portlet
> * remove {{<display-name>}} from {{web.xml}}
> * Compile & deploy
> * Expected: The portal should swallow the portlet app without any error.
> * Current: The portal throws this NPE
> {code}
> [0m[31m09:20:11,195 ERROR [org.exoplatform.web.application.javascript.JavascriptConfigDeployer] (ServerService Thread Pool -- 93) An error occurs while registering 'Javascript in gatein-resources.xml' from the context 'null': java.lang.IllegalArgumentException: The context name cannot be null
> at org.exoplatform.container.definition.PortalContainerConfig.getPortalContainerNames(PortalContainerConfig.java:502) [exo.kernel.container-2.4.3-GA-redhat-1.jar:2.4.3-GA-redhat-1]
> at org.exoplatform.container.PortalContainer.addInitTask(PortalContainer.java:474) [exo.kernel.container-2.4.3-GA-redhat-1.jar:2.4.3-GA-redhat-1]
> at org.exoplatform.web.application.javascript.JavascriptConfigDeployer.add(JavascriptConfigDeployer.java:96) [exo.portal.component.web.resources-3.6.0.Beta02-redhat-1.jar:3.6.0.Beta02-redhat-1]
> at org.exoplatform.web.application.javascript.JavascriptConfigDeployer.onEvent(JavascriptConfigDeployer.java:71) [exo.portal.component.web.resources-3.6.0.Beta02-redhat-1.jar:3.6.0.Beta02-redhat-1]
> at org.gatein.wci.ServletContainer.safeFireEvent(ServletContainer.java:319) [wci-wci-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.ServletContainer.fireEvent(ServletContainer.java:338) [wci-wci-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.ServletContainer.access$400(ServletContainer.java:56) [wci-wci-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.ServletContainer$RegistrationImpl.registerWebApp(ServletContainer.java:462) [wci-wci-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.jboss.JB7ServletContainerContext.start(JB7ServletContainerContext.java:369) [wci-jboss7-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> at org.gatein.wci.jboss.JB7ServletContainerContext.lifecycleEvent(JB7ServletContainerContext.java:223) [wci-jboss7-2.3.1.CR05-redhat-1.jar:2.3.1.CR05-redhat-1]
> 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:471) [rt.jar:1.7.0_19]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_19]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_19]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_19]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_19]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {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, 3 months