[JBoss JIRA] Created: (GTNMGMT-8) Importing exported site doesn't work on EPP-5.2.0-DEV01
by Tomas Kyjovsky (JIRA)
Importing exported site doesn't work on EPP-5.2.0-DEV01
-------------------------------------------------------
Key: GTNMGMT-8
URL: https://issues.jboss.org/browse/GTNMGMT-8
Project: GateIn Management
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.0.0-Alpha01
Environment: EPP-5.2.0-DEV01
Reporter: Tomas Kyjovsky
Assignee: Nick Scavelli
Importing exported site via the gadget causes:
07:56:21,875 ERROR [[uploadServlet]] Servlet.service() for servlet uploadServlet threw exception
java.lang.NoSuchMethodError: org.exoplatform.portal.pom.data.PortalData.<init>(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/util/List;Ljava/lang/String;Ljava/util/Map;Ljava/lang/String;Lorg/exoplatform/portal/pom/data/ContainerData;)V
at org.gatein.management.portalobjects.binding.impl.site.PortalDataMarshaller.unmarshalPortalData(PortalDataMarshaller.java:309)
at org.gatein.management.portalobjects.binding.impl.site.PortalDataMarshaller.unmarshal(PortalDataMarshaller.java:111)
at org.gatein.management.portalobjects.binding.impl.site.PortalDataMarshaller.unmarshal(PortalDataMarshaller.java:52)
at org.gatein.management.portalobjects.exportimport.impl.ExportImportUtils.importFromZip(ExportImportUtils.java:131)
at org.gatein.management.portalobjects.exportimport.impl.ImportHandlerImpl.createContext(ImportHandlerImpl.java:67)
at org.gatein.management.gadget.server.util.PortalService.importSite(PortalService.java:278)
at org.gatein.management.gadget.server.FileUploadServlet$1.doInContainer(FileUploadServlet.java:173)
at org.gatein.management.gadget.server.FileUploadServlet$1.doInContainer(FileUploadServlet.java:165)
at org.gatein.management.gadget.server.ContainerRequestHandler.doInRequest(ContainerRequestHandler.java:54)
at org.gatein.management.gadget.server.FileUploadServlet.processImport(FileUploadServlet.java:164)
at org.gatein.management.gadget.server.FileUploadServlet.executeAction(FileUploadServlet.java:97)
at gwtupload.server.UploadAction.doPost(UploadAction.java:162)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
at java.lang.Thread.run(Thread.java:619)
Importing the same exported site through the CLI:
(-import.log)
2011-07-12 08:41:03,800 INFO [Importer] Starting import of file portal_staging1_2011-07-12_07-31-24.zip for portal container portal
2011-07-12 08:41:03,933 INFO [Importer] Overwrite set to true, overwriting all data.
2011-07-12 08:41:04,059 ERROR [ImportHandler] Exception during import.
java.lang.UnsupportedOperationException
at org.gatein.management.portalobjects.client.impl.ClientDataStorageImpl.create(ClientDataStorageImpl.java:62)
at org.gatein.management.portalobjects.exportimport.impl.ImportHandlerImpl.importPortalConfig(ImportHandlerImpl.java:98)
at org.gatein.management.portalobjects.exportimport.impl.ImportHandlerImpl.importContext(ImportHandlerImpl.java:77)
at org.gatein.management.portalobjects.client.impl.RestfulPortalObjectsMgmtClient.importContext(RestfulPortalObjectsMgmtClient.java:318)
at org.gatein.management.portalobjects.cli.importer.Importer.doImport(Importer.java:164)
at org.gatein.management.portalobjects.cli.importer.ImportMain.main(ImportMain.java:152)
at org.gatein.management.portalobjects.cli.Main.main(Main.java:50)
2011-07-12 08:41:04,070 INFO [ImportHandler] Rolling back any changes that occurred during import.
2011-07-12 08:41:04,070 INFO [ImportHandler] No portal configs were overwritten during import
2011-07-12 08:41:04,070 INFO [ImportHandler] No portal configs were creating during import
2011-07-12 08:41:04,070 INFO [ImportHandler] No pages were overwritten during import
2011-07-12 08:41:04,070 INFO [ImportHandler] No pages were creating during import
2011-07-12 08:41:04,070 INFO [ImportHandler] No navigations were overwritten during import
2011-07-12 08:41:04,070 INFO [ImportHandler] No navigations were creating during import
2011-07-12 08:41:04,070 INFO [Importer] Import was successful.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[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
13 years, 5 months
[JBoss JIRA] Created: (GTNPORTAL-1953) Make data binding more flexible in UIForm
by Minh Hoang TO (JIRA)
Make data binding more flexible in UIForm
-----------------------------------------
Key: GTNPORTAL-1953
URL: https://issues.jboss.org/browse/GTNPORTAL-1953
Project: GateIn Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: WebUI
Reporter: Minh Hoang TO
Binding data fields of an UIForm instance is actually delegated to an associated instance of BeanDataMapping.
{code}
public void invokeGetBindingBean(Object bean) throws Exception
{
if (beanMapping == null)
{
beanMapping = ReflectionDataMapping.getInstance();
}
beanMapping.mapField(this, bean);
}
public void invokeSetBindingBean(Object bean) throws Exception
{
if (beanMapping == null)
{
beanMapping = ReflectionDataMapping.getInstance();
}
beanMapping.mapBean(bean, this);
}
{code}
Within the current code, it is impossible to set custom BeanDataMapping (unless using reflection). Hence, the real data mapping is always tied to ReflectionDataMapping!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[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
13 years, 5 months