exo platform kernel
by Matt Wringe
Where exactly should we be looking for the documentation for exo kernel?
I know there is some in the reference guide, but there is also
documentation on the exoplatform wiki.
All I want to be able to do is to access a service in the portal during
the deployment of an application. But configuration.xml files only
appear to be used when the server is first started, and if I access the
kernel directly in java (ie PortalContainer.getInstance) there doesn't
appear to be any way to guarantee that the dependent service is running
yet.
15 years, 9 months
Re: [gatein-dev] exo platform kernel
by Marko Strukelj
I think you're looking for this:
http://wiki.exoplatform.com/xwiki/bin/view/Kernel/
Although it doesn't give you a very good feel for what's really going on
when jboss is starting up and how kernel services get started.
I'll try to outline what I've learned and refreshed while writing this ...
RootContainer initialization is supposed to occur within
PortalContainerConfigOwner, or GenericHttpListener, or
PortalContainerCreator, as part of portal.war, gatein-sample-ext.war or
start.war). Let's call this a regular kernel startup.
Calling PortalContainer.getInstance() before the regular kernel startup will
automatically trigger RootContainer initialization at the point and within
context it wasn't necessarily intended - the only side-effect of premature
RootContainer initialization I know for now is that MC integration may then
not work if one day we need to use it.
During its initialization, RootContainer reads configuration of its
services. It does this using ConfigurationManagerImpl to scan all
default/deploy/*.ear archives' .jar libraries (lib/*.jar + declared java
modules), default/lib/*.jar files, and default/conf/gatein directory, and
finds all the conf/configuration.xml files.
By the time RootContainer has been fully initialized and started no
PortalContainer has yet been initialized.
When portal.war or gatein-sample-ext.war are deployed they trigger creation
of RootContainer, and register callbacks (called InitTasks) with it, but no
initialization of any PortalContainer yet occurs. These callbacks will be
trigger later.
There is a web application called starter.war, set up in such a way that it
starts after all other gatein web modules. It is this one that finally
triggers the creation of PortalContainers - which processes the previously
registered InitTasks.
Only now does a PortalContainer get created for each portal, during which
portal configuration is scanned (all default/deploy/*.ear archives for
conf/portal/configuration.xml files + conf/configuration.xml within .war
arhive of each portal web app - for portal specific services).
The whole roundabout mechanism is in place in order to support
UnifiedClassLoading that allows for extensions to be deployed just by
dropping them in and overriding any existing resources with new ones.
I think the simplest way to get access to current portal's services would
then be to create a .jar containing conf/portal/configuration.xml where you
register a service that implements Starter interface. You can drop this jar
in gatein.ear/lib. The service will be instantiated and started once for
each portal but long after your web application has already started. From
this service you would then need to push whatever information you need into
your webapp.
Your webapp then needs to have lazy init, and wait with its final
initialization until it gets pushed the info it needs ...
On Mon, Aug 30, 2010 at 8:59 PM, Matt Wringe <mwringe(a)redhat.com> wrote:
Where exactly should we be looking for the documentation for exo kernel?
I know there is some in the reference guide, but there is also
documentation on the exoplatform wiki.
All I want to be able to do is to access a service in the portal during
the deployment of an application. But configuration.xml files only
appear to be used when the server is first started, and if I access the
kernel directly in java (ie PortalContainer.getInstance) there doesn't
appear to be any way to guarantee that the dependent service is running
yet.
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
15 years, 9 months
Re: [gatein-dev] gatein-dev Digest, Vol 11, Issue 10
by MinhHoang To
Indeed, we should internationalize the returned constant
On Sat, Aug 28, 2010 at 11:00 PM, <gatein-dev-request(a)lists.jboss.org>wrote:
> Send gatein-dev mailing list submissions to
> gatein-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/gatein-dev
> or, via email, send a message with subject or body 'help' to
> gatein-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> gatein-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gatein-dev digest..."
>
>
> Today's Topics:
>
> 1. Fwd: [gatein-commits] gatein SVN: r3915 -
>
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component.
> (Christophe Laprun)
> 2. Re: Fwd: [gatein-commits] gatein SVN: r3915 -
>
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component.
> (Trong Tran)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 27 Aug 2010 18:25:46 +0200
> From: Christophe Laprun <claprun(a)redhat.com>
> Subject: [gatein-dev] Fwd: [gatein-commits] gatein SVN: r3915 -
>
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component.
>
> To: gatein-dev(a)lists.jboss.org
> Message-ID: <DE49B992-38B3-4923-BC2D-B59EBE191B3F(a)redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> Shouldn't the following be localizable?
>
> Begin forwarded message:
>
> > From: do-not-reply(a)jboss.org
> > Date: August 24, 2010 6:45:51 PM GMT+02:00
> > To: gatein-commits(a)lists.jboss.org
> > Subject: [gatein-commits] gatein SVN: r3915 -
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component.
> > Reply-To: gatein-commits(a)lists.jboss.org
> >
> > Author: hoang_to
> > Date: 2010-08-24 12:45:50 -0400 (Tue, 24 Aug 2010)
> > New Revision: 3915
> >
> > Modified:
> >
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> > Log:
> > EXOGTN-23: Exceptions are not properly handled in Application Registry
> Service
> >
> > Modified:
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> > ===================================================================
> > ---
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> 2010-08-24 16:32:56 UTC (rev 3914)
> > +++
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> 2010-08-24 16:45:50 UTC (rev 3915)
> > @@ -313,17 +313,38 @@
> >
> > public String getDisplayName()
> > {
> > - return getMetaValue(MetaInfo.DISPLAY_NAME, name_);
> > + try
> > + {
> > + return getMetaValue(MetaInfo.DISPLAY_NAME, name_);
> > + }
> > + catch (Exception ex)
> > + {
> > + return "COULD NOT GET DISPLAY NAME OF THE PORTLET";
> > + }
> > }
> >
> > public String getDescription()
> > {
> > - return getMetaValue(MetaInfo.DESCRIPTION, name_);
> > + try
> > + {
> > + return getMetaValue(MetaInfo.DESCRIPTION, name_);
> > + }
> > + catch (Exception ex)
> > + {
> > + return "COULD NOT GET DESCRIPTION OF THE PORTLET";
> > + }
> > }
> >
> > public PreferencesInfo getPortletPreferences()
> > {
> > - return portletInfo_.getPreferences();
> > + try
> > + {
> > + return portletInfo_.getPreferences();
> > + }
> > + catch (Exception ex)
> > + {
> > + return null;
> > + }
> > }
> >
> > private String getMetaValue(String metaKey, String defaultValue)
> >
> > _______________________________________________
> > gatein-commits mailing list
> > gatein-commits(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/gatein-commits
>
> Cordialement / Best,
> Chris
>
> ==
> Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
> Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein
> Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 27 Aug 2010 23:47:28 +0700
> From: Trong Tran <trongtt(a)gmail.com>
> Subject: Re: [gatein-dev] Fwd: [gatein-commits] gatein SVN: r3915 -
>
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component.
>
> To: Christophe Laprun <claprun(a)redhat.com>
> Cc: gatein-dev <gatein-dev(a)lists.jboss.org>
> Message-ID:
> <AANLkTimFiuO3k+beXQmnR3TjnnoK4m5cc8jiYMhzFAd5(a)mail.gmail.com<AANLkTimFiuO3k%2BbeXQmnR3TjnnoK4m5cc8jiYMhzFAd5(a)mail.gmail.com>
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> it should be indeed
>
> On 27 August 2010 23:25, Christophe Laprun <claprun(a)redhat.com> wrote:
>
> > Shouldn't the following be localizable?
> >
> > Begin forwarded message:
> >
> > > From: do-not-reply(a)jboss.org
> > > Date: August 24, 2010 6:45:51 PM GMT+02:00
> > > To: gatein-commits(a)lists.jboss.org
> > > Subject: [gatein-commits] gatein SVN: r3915 -
> >
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component.
> > > Reply-To: gatein-commits(a)lists.jboss.org
> > >
> > > Author: hoang_to
> > > Date: 2010-08-24 12:45:50 -0400 (Tue, 24 Aug 2010)
> > > New Revision: 3915
> > >
> > > Modified:
> > >
> >
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> > > Log:
> > > EXOGTN-23: Exceptions are not properly handled in Application Registry
> > Service
> > >
> > > Modified:
> >
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> > > ===================================================================
> > > ---
> >
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> > 2010-08-24 16:32:56 UTC (rev 3914)
> > > +++
> >
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> > 2010-08-24 16:45:50 UTC (rev 3915)
> > > @@ -313,17 +313,38 @@
> > >
> > > public String getDisplayName()
> > > {
> > > - return getMetaValue(MetaInfo.DISPLAY_NAME, name_);
> > > + try
> > > + {
> > > + return getMetaValue(MetaInfo.DISPLAY_NAME, name_);
> > > + }
> > > + catch (Exception ex)
> > > + {
> > > + return "COULD NOT GET DISPLAY NAME OF THE PORTLET";
> > > + }
> > > }
> > >
> > > public String getDescription()
> > > {
> > > - return getMetaValue(MetaInfo.DESCRIPTION, name_);
> > > + try
> > > + {
> > > + return getMetaValue(MetaInfo.DESCRIPTION, name_);
> > > + }
> > > + catch (Exception ex)
> > > + {
> > > + return "COULD NOT GET DESCRIPTION OF THE PORTLET";
> > > + }
> > > }
> > >
> > > public PreferencesInfo getPortletPreferences()
> > > {
> > > - return portletInfo_.getPreferences();
> > > + try
> > > + {
> > > + return portletInfo_.getPreferences();
> > > + }
> > > + catch (Exception ex)
> > > + {
> > > + return null;
> > > + }
> > > }
> > >
> > > private String getMetaValue(String metaKey, String defaultValue)
> > >
> > > _______________________________________________
> > > gatein-commits mailing list
> > > gatein-commits(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/gatein-commits
> >
> > Cordialement / Best,
> > Chris
> >
> > ==
> > Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
> > Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein
> > Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
> >
> >
> > _______________________________________________
> > gatein-dev mailing list
> > gatein-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
>
>
>
> --
> Tran The Trong
> eXo Platform SAS
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/gatein-dev/attachments/20100827/2bbbf382...
>
> ------------------------------
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
> End of gatein-dev Digest, Vol 11, Issue 10
> ******************************************
>
--
Minh Hoang TO
eXoPlatform SAS, tang 8, building 18, Thai Ha, Ha Noi
15 years, 9 months
Fwd: [gatein-commits] gatein SVN: r3915 - exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component.
by Christophe Laprun
Shouldn't the following be localizable?
Begin forwarded message:
> From: do-not-reply(a)jboss.org
> Date: August 24, 2010 6:45:51 PM GMT+02:00
> To: gatein-commits(a)lists.jboss.org
> Subject: [gatein-commits] gatein SVN: r3915 - exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component.
> Reply-To: gatein-commits(a)lists.jboss.org
>
> Author: hoang_to
> Date: 2010-08-24 12:45:50 -0400 (Tue, 24 Aug 2010)
> New Revision: 3915
>
> Modified:
> exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> Log:
> EXOGTN-23: Exceptions are not properly handled in Application Registry Service
>
> Modified: exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java
> ===================================================================
> --- exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java 2010-08-24 16:32:56 UTC (rev 3914)
> +++ exo/portal/branches/3.1.x/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIPortletManagement.java 2010-08-24 16:45:50 UTC (rev 3915)
> @@ -313,17 +313,38 @@
>
> public String getDisplayName()
> {
> - return getMetaValue(MetaInfo.DISPLAY_NAME, name_);
> + try
> + {
> + return getMetaValue(MetaInfo.DISPLAY_NAME, name_);
> + }
> + catch (Exception ex)
> + {
> + return "COULD NOT GET DISPLAY NAME OF THE PORTLET";
> + }
> }
>
> public String getDescription()
> {
> - return getMetaValue(MetaInfo.DESCRIPTION, name_);
> + try
> + {
> + return getMetaValue(MetaInfo.DESCRIPTION, name_);
> + }
> + catch (Exception ex)
> + {
> + return "COULD NOT GET DESCRIPTION OF THE PORTLET";
> + }
> }
>
> public PreferencesInfo getPortletPreferences()
> {
> - return portletInfo_.getPreferences();
> + try
> + {
> + return portletInfo_.getPreferences();
> + }
> + catch (Exception ex)
> + {
> + return null;
> + }
> }
>
> private String getMetaValue(String metaKey, String defaultValue)
>
> _______________________________________________
> gatein-commits mailing list
> gatein-commits(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-commits
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
15 years, 10 months
Re: [gatein-dev] An exception during run GateIn
by Trong Tran
( added gatein-dev list to this conversation )
On 27 August 2010 13:40, Boleslaw Dawidowicz <bdawidow(a)redhat.com> wrote:
> Hi,
>
> I would be grateful for any tips on how to reproduce this. I saw this few
> times but it was always related to other issues that I was working on. So
> far the only way in which I can reproduce this is by too long remote
> debugging session but it is quite obvious that it can trigger transaction
> timeout and should break other stuff too. Recently Chris spot this during
> WSRP tests but also could not point any valid way to reproduce.
>
> The thing is that PLIDM internally doesn't manage transaction stuff - this
> is covered either with with JTA or Hibernate transaction and managed around
> portal request. This is applied using
> ComponentRequestLifecycle.startRequest/endRequest method in
> PicketLinkIDMOrganizationServiceImpl and triggered by kernel. There must be
> some disturbance in the request flow or something that breaks active
> transaction happening so it is really hard to track the issue itself as it
> could be also just a side effect of different issue. I guess that I can
> apply extra transaction check in LocalizationFilter as it seems from all
> reports I got that this is the place where it happens most often.
>
> Bolek
>
>
> On Aug 27, 2010, at 6:15 AM, Trong Tran wrote:
>
> > Hi Boleslaw and Marko,
> >
> > During run GateIn trunk recently, we have sometimes got an exception :
> >
> > org.picketlink.idm.common.exception.IdentityException:
> IdentityObjectType[USER] not present in the store.
> > at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2558)
> > at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:648)
> > at
> org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:155)
> > at
> org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426)
> > at
> org.exoplatform.services.organization.idm.UserProfileDAOImpl.findUserProfileByName(UserProfileDAOImpl.java:144)
> > at
> org.exoplatform.portal.application.localization.LocalizationFilter.getUserProfileLocale(LocalizationFilter.java:172)
> > at
> org.exoplatform.portal.application.localization.LocalizationFilter.doFilter(LocalizationFilter.java:137)
> > at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> > at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > at
> org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:73)
> > 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:233)
> > at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> > at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558)
> > at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> > at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> > at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> > at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
> > at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
> > at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
> > at java.lang.Thread.run(Thread.java:637)
> > Caused by: org.hibernate.HibernateException: createCriteria is not valid
> without active transaction
> > at
> org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:338)
> > at $Proxy87.createCriteria(Unknown Source)
> > at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2532)
> > ... 22 more
> >
> > I do not know usecase to persistently get the exception.
> >
> > Apparently this is related to the patch of GTNPORTAL-1355 we have applied
> recently and to usage of PicketLink IDM.
> >
> > Could you have a look to see if there is any idea to fix this ?
> >
> > Thanks
> > --
> > Tran The Trong
> > eXo Platform SAS
>
>
--
Tran The Trong
eXo Platform SAS
15 years, 10 months
Re: [gatein-dev] An exception during run GateIn
by Trong Tran
( added gatein-dev list to this conversation )
On 27 August 2010 11:15, Trong Tran <trong.tran(a)exoplatform.com> wrote:
> Hi Boleslaw and Marko,
>
> During run GateIn trunk recently, we have sometimes got an exception :
>
> *org.picketlink.idm.common.exception.IdentityException:
> IdentityObjectType[USER] not present in the store.*
> * at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2558)
> *
> * at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:648)
> *
> * at
> org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:155)
> *
> * at
> org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426)
> *
> * at
> org.exoplatform.services.organization.idm.UserProfileDAOImpl.findUserProfileByName(UserProfileDAOImpl.java:144)
> *
> * at org.exoplatform.portal.application.localization.
> LocalizationFilter.getUserProfileLocale(LocalizationFilter.java:172)*
> * at
> org.exoplatform.portal.application.localization.LocalizationFilter.doFilter(LocalizationFilter.java:137)
> *
> * at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> *
> * at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> *
> * at
> org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:73)
> *
> * 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:233)
> *
> * at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> *
> * at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558)
> *
> * at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> *
> * at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> *
> * at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> *
> * at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> *
> * at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
> *
> * at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
> *
> * at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)*
> * at java.lang.Thread.run(Thread.java:637)*
> *Caused by: org.hibernate.HibernateException: createCriteria is not valid
> without active transaction*
> * at
> org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:338)
> *
> * at $Proxy87.createCriteria(Unknown Source)*
> * at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2532)
> *
> * ... 22 more*
>
> I do not know usecase to persistently get the exception.
>
> Apparently this is related to the patch of GTNPORTAL-1355 we have applied
> recently and to usage of PicketLink IDM.
>
> Could you have a look to see if there is any idea to fix this ?
>
> Thanks
> --
> Tran The Trong
> eXo Platform SAS
>
--
Tran The Trong
eXo Platform SAS
15 years, 10 months
Re: [gatein-dev] An exception during run GateIn
by Trong Tran
( added gatein-dev list to this conversation )
On 27 August 2010 13:40, Boleslaw Dawidowicz <bdawidow(a)redhat.com> wrote:
> Hi,
>
> I would be grateful for any tips on how to reproduce this. I saw this few
> times but it was always related to other issues that I was working on. So
> far the only way in which I can reproduce this is by too long remote
> debugging session but it is quite obvious that it can trigger transaction
> timeout and should break other stuff too. Recently Chris spot this during
> WSRP tests but also could not point any valid way to reproduce.
>
> The thing is that PLIDM internally doesn't manage transaction stuff - this
> is covered either with with JTA or Hibernate transaction and managed around
> portal request. This is applied using
> ComponentRequestLifecycle.startRequest/endRequest method in
> PicketLinkIDMOrganizationServiceImpl and triggered by kernel. There must be
> some disturbance in the request flow or something that breaks active
> transaction happening so it is really hard to track the issue itself as it
> could be also just a side effect of different issue. I guess that I can
> apply extra transaction check in LocalizationFilter as it seems from all
> reports I got that this is the place where it happens most often.
>
> Bolek
>
>
> On Aug 27, 2010, at 6:15 AM, Trong Tran wrote:
>
> > Hi Boleslaw and Marko,
> >
> > During run GateIn trunk recently, we have sometimes got an exception :
> >
> > org.picketlink.idm.common.exception.IdentityException:
> IdentityObjectType[USER] not present in the store.
> > at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2558)
> > at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:648)
> > at
> org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:155)
> > at
> org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426)
> > at
> org.exoplatform.services.organization.idm.UserProfileDAOImpl.findUserProfileByName(UserProfileDAOImpl.java:144)
> > at
> org.exoplatform.portal.application.localization.LocalizationFilter.getUserProfileLocale(LocalizationFilter.java:172)
> > at
> org.exoplatform.portal.application.localization.LocalizationFilter.doFilter(LocalizationFilter.java:137)
> > at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> > at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> > at
> org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:73)
> > 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:233)
> > at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> > at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558)
> > at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> > at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> > at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> > at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> > at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
> > at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
> > at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
> > at java.lang.Thread.run(Thread.java:637)
> > Caused by: org.hibernate.HibernateException: createCriteria is not valid
> without active transaction
> > at
> org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:338)
> > at $Proxy87.createCriteria(Unknown Source)
> > at
> org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2532)
> > ... 22 more
> >
> > I do not know usecase to persistently get the exception.
> >
> > Apparently this is related to the patch of GTNPORTAL-1355 we have applied
> recently and to usage of PicketLink IDM.
> >
> > Could you have a look to see if there is any idea to fix this ?
> >
> > Thanks
> > --
> > Tran The Trong
> > eXo Platform SAS
>
>
--
Tran The Trong
eXo Platform SAS
15 years, 10 months
PortletContainer and new portlet invoker methods
by Matthew Wringe
Hi,
In order to get the WSRP 2.0 import/export features working we need to
make a few changes to the PortletInvoker to help with this import/export
functionality.
The current invoker doesn't allow for retrieval of portlet state (the
invoker can store it locally) or allow for the retrieval of the actual
portlet ID from a cloned portlet context.
Since each invoker stores this data independently, we need methods added
to the portlet invoker to expose them.
I have created a jira for this task
(https://jira.jboss.org/browse/GTNPC-26) with a patch and test cases.
Right now we are using snapshots of the PC component in the WSRP trunk
which is causing test failures for anyone who is not building PC with
the patches locally.
Is there any objection to committing the patch from GTNPC-26 in PC and
creating a new PC alpha or beta release?
Thanks,
Matt Wringe
15 years, 10 months
