Hello, Julien asked me to rollback the revision 744 Revision: 744 - upgrade to PicketLink IDM (former JBoss Identity) 1.0.0.CR1 - remove separate IDM hibernate config 1/ Many tests were failing since this test : see http://builder.exoplatform.org/hudson/job/gatein-portal-trunk-ci/399/ 2/ Julien does not accept that commits are done with failing tests 3/ A bug in core https://jira.jboss.org/jira/browse/EXOJCR-259 is hidding some informations to understand the failures 4/ The bug to solve should be this stack (according to Julien after is hacked the core component to reveal the real issue -- see EXOJCR-259 <https://jira.jboss.org/jira/browse/EXOJCR-259> for a patch in exo-core, or contact Julien) org.hibernate.HibernateException: No CurrentSessionContext configured! at org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:572) at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.startTransaction(HibernateIdentityStoreSessionImpl.java:77) at org.picketlink.idm.impl.repository.RepositoryIdentityStoreSessionImpl.startTransaction(RepositoryIdentityStoreSessionImpl.java:117) at org.picketlink.idm.impl.api.session.SimpleTransactionImpl.start(SimpleTransactionImpl.java:43) at org.picketlink.idm.impl.api.session.IdentitySessionImpl.beginTransaction(IdentitySessionImpl.java:203) at org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl.startRequest(PicketLinkIDMOrganizationServiceImpl.java:136) at org.exoplatform.services.organization.auth.OrganizationAuthenticatorImpl.begin(OrganizationAuthenticatorImpl.java:143) at org.exoplatform.services.organization.auth.OrganizationAuthenticatorImpl.createIdentity(OrganizationAuthenticatorImpl.java:93) at org.exoplatform.portal.config.TestUserPortalConfigService$UnitTest.execute(TestUserPortalConfigService.java:858) at org.exoplatform.portal.config.TestUserPortalConfigService.testCreateUserPortalConfig(TestUserPortalConfigService.java:279) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:164) at org.exoplatform.test.BasicTestCase.runTest(BasicTestCase.java:68) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Please assume that the GateIn project should have no failing tests when you are commiting (work has been done to hide the known failing ones). This is really important for the GateIn Beta03 release at the end of the week. We are requesting a new release of the JCR for that fix (if possible). Thank you, Dimitri BAELI - eXo Platform SAS _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

Nicolas, We need a new release of JCR modules (starting at least from core). Needed fixes : https://jira.jboss.org/jira/browse/EXOJCR-259 https://jira.jboss.org/jira/browse/EXOJCR-261 Can you tell if that is possible to perform a new release with those fixes ? Or if we can help. Thanks, Dimitri BAELI - eXo Platform SAS On Tue, Nov 24, 2009 at 1:56 AM, Dimitri BAELI <dbaeli(a)gmail.com&gt; wrote: > Hello, > Julien asked me to rollback the revision 744 > >> Revision: 744 >> > - upgrade to PicketLink IDM (former JBoss Identity) 1.0.0.CR1 >> - remove separate IDM hibernate config >> > > 1/ Many tests were failing since this test : see > http://builder.exoplatform.org/hudson/job/gatein-portal-trunk-ci/399/ > 2/ Julien does not accept that commits are done with failing tests > 3/ A bug in core https://jira.jboss.org/jira/browse/EXOJCR-259 is hidding > some informations to understand the failures > 4/ The bug to solve should be this stack (according to Julien after is > hacked the core component to reveal the real issue -- see EXOJCR-259<https://jira.jboss.org/jira/browse/EXOJCR-259>for a patch in exo-core, or contact Julien) > org.hibernate.HibernateException: No CurrentSessionContext configured! > at > org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:572) > at > org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.startTransaction(HibernateIdentityStoreSessionImpl.java:77) > at > org.picketlink.idm.impl.repository.RepositoryIdentityStoreSessionImpl.startTransaction(RepositoryIdentityStoreSessionImpl.java:117) > at > org.picketlink.idm.impl.api.session.SimpleTransactionImpl.start(SimpleTransactionImpl.java:43) > at > org.picketlink.idm.impl.api.session.IdentitySessionImpl.beginTransaction(IdentitySessionImpl.java:203) > at > org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl.startRequest(PicketLinkIDMOrganizationServiceImpl.java:136) > at > org.exoplatform.services.organization.auth.OrganizationAuthenticatorImpl.begin(OrganizationAuthenticatorImpl.java:143) > at > org.exoplatform.services.organization.auth.OrganizationAuthenticatorImpl.createIdentity(OrganizationAuthenticatorImpl.java:93) > at > org.exoplatform.portal.config.TestUserPortalConfigService$UnitTest.execute(TestUserPortalConfigService.java:858) > at > org.exoplatform.portal.config.TestUserPortalConfigService.testCreateUserPortalConfig(TestUserPortalConfigService.java:279) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at org.exoplatform.test.BasicTestCase.runTest(BasicTestCase.java:68) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) > at org.apache.maven.surefire.Surefire.run(Surefire.java:177) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) > > Please assume that the GateIn project should have no failing tests when > you are commiting (work has been done to hide the known failing ones). > This is really important for the GateIn Beta03 release at the end of the > week. > We are requesting a new release of the JCR for that fix (if possible). > > Thank you, > Dimitri BAELI - eXo Platform SAS >

Great thank you, You'll be rewarded in vo..a next time I met you with the team ;-) Dimitri BAELI - eXo Platform SAS On Tue, Nov 24, 2009 at 11:32 AM, Nicolas Filotto <nicolas.filotto(a)exoplatform.com <mailto:nicolas.filotto@exoplatform.com>> wrote: We are working on it, we do our best to release a new version of eXo JCR at worse tomorrow On Tue, Nov 24, 2009 at 11:25 AM, Dimitri BAELI <dbaeli(a)gmail.com <mailto:dbaeli@gmail.com>> wrote: Nicolas, We need a new release of JCR modules (starting at least from core). Needed fixes : https://jira.jboss.org/jira/browse/EXOJCR-259 https://jira.jboss.org/jira/browse/EXOJCR-261 Can you tell if that is possible to perform a new release with those fixes ? Or if we can help. Thanks, Dimitri BAELI - eXo Platform SAS On Tue, Nov 24, 2009 at 1:56 AM, Dimitri BAELI <dbaeli(a)gmail.com <mailto:dbaeli@gmail.com>> wrote: Hello, Julien asked me to rollback the revision 744 Revision: 744 - upgrade to PicketLink IDM (former JBoss Identity) 1.0.0.CR1 - remove separate IDM hibernate config 1/ Many tests were failing since this test : see http://builder.exoplatform.org/hudson/job/gatein-portal-trunk-ci/399/ 2/ Julien does not accept that commits are done with failing tests 3/ A bug in core https://jira.jboss.org/jira/browse/EXOJCR-259 is hidding some informations to understand the failures 4/ The bug to solve should be this stack (according to Julien after is hacked the core component to reveal the real issue -- see EXOJCR-259 <https://jira.jboss.org/jira/browse/EXOJCR-259> for a patch in exo-core, or contact Julien) org.hibernate.HibernateException: No CurrentSessionContext configured! at org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:572) at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.startTransaction(HibernateIdentityStoreSessionImpl.java:77) at org.picketlink.idm.impl.repository.RepositoryIdentityStoreSessionImpl.startTransaction(RepositoryIdentityStoreSessionImpl.java:117) at org.picketlink.idm.impl.api.session.SimpleTransactionImpl.start(SimpleTransactionImpl.java:43) at org.picketlink.idm.impl.api.session.IdentitySessionImpl.beginTransaction(IdentitySessionImpl.java:203) at org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl.startRequest(PicketLinkIDMOrganizationServiceImpl.java:136) at org.exoplatform.services.organization.auth.OrganizationAuthenticatorImpl.begin(OrganizationAuthenticatorImpl.java:143) at org.exoplatform.services.organization.auth.OrganizationAuthenticatorImpl.createIdentity(OrganizationAuthenticatorImpl.java:93) at org.exoplatform.portal.config.TestUserPortalConfigService$UnitTest.execute(TestUserPortalConfigService.java:858) at org.exoplatform.portal.config.TestUserPortalConfigService.testCreateUserPortalConfig(TestUserPortalConfigService.java:279) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:164) at org.exoplatform.test.BasicTestCase.runTest(BasicTestCase.java:68) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Please assume that the GateIn project should have no failing tests when you are commiting (work has been done to hide the known failing ones). This is really important for the GateIn Beta03 release at the end of the week. We are requesting a new release of the JCR for that fix (if possible). Thank you, Dimitri BAELI - eXo Platform SAS -- Nicolas Filotto JCR Product Manager Project Manager eXo Platform SAS nicolas.filotto(a)exoplatform.com <mailto:nicolas.filotto@exoplatform.com> +33 (0)6 31 32 92 19 _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

Hi Thomas, I discussed with Marko last night late about how to improve his work and he agreed to proceed this way. cheers Julien On Nov 24, 2009, at 1:19 PM, Thomas Heute wrote: See Marko's email of the 17th, can we commit this into kernel before it gets released ? It has been month since Marko is trying to get attention on the MC integration with little success so far. Marko's changes aren't changing the way it works or interfering on lifecycle it, it just add a way to inject MC beans into eXo Kernel. Thomas.

I'm late to commit the use of https://svn.jboss.org/repos/gatein/tools/packager (This one seems the latest, and being worked on - not used in packaging/pkg) I'm doing it now Dimitri BAELI - eXo Platform SAS On Tue, Nov 24, 2009 at 2:57 PM, Marko Strukelj <marko.strukelj(a)gmail.com&gt;wrote: > > There are 2 extra things to do: > > 1) Separate mc-integration code in its own module, so that container > module has no dependencies on mc-kernel artifacts. > This will require an additional reflection style invocation in one place, > but should not be a problem to do. > > 2) Add xml file configuration for marking certain components to use > mc-interception even though they are not marked as @InterceptMC > This will allow us to externally configure to mc-intercept components that > are part of exo-kernel and GateIn. We won't annotate these components in > advance. Application developers who want to integrate with their existing > mc-beans components will still use @InterceptMC. XML configuration will > override annotations. > > I'm also working on release part of this. What's the status of exopackage > ATM? > > http://svn.exoplatform.org/projects/utils/exopackage (This one is > actually used in portal packaging/pkg) > https://svn.jboss.org/repos/gatein/portal/trunk/packaging/exopackage(???) > https://svn.jboss.org/repos/gatein/tools/packager (This one seems the > latest, and being worked on - not used in packaging/pkg) > > I have some changes in: > > javascript/eXo/command/exobuild.js > - introduced --integration-test option > > javascript/eXo/server/JbossEar.js > - introduced jbossas specific dependencies - only if --integration-test > option is on > > javascript/eXo/projects/Product.js > - added 'integrationTests' flag to elegantly communicate > --integration-test flag from exobuild.js to JbossEar.js > > I'd like to make a branch so that others can try this. Where would be the > best place? > > Cheers, > > - marko > > > > On Tue, Nov 24, 2009 at 1:27 PM, Julien Viet <julien(a)julienviet.com&gt;wrote: > >> Hi Thomas, >> >> I discussed with Marko last night late about how to improve his work and >> he agreed to proceed this way. >> >> cheers >> >> Julien >> >> On Nov 24, 2009, at 1:19 PM, Thomas Heute wrote: >> >> See Marko's email of the 17th, can we commit this into kernel before it >> gets released ? >> It has been month since Marko is trying to get attention on the MC >> integration with little success so far. >> >> Marko's changes aren't changing the way it works or interfering on >> lifecycle it, it just add a way to inject MC beans into eXo Kernel. >> >> Thomas. >> >> >