Hi Scott, Congratulations for the new release. It seems that 3.1.6 release does not have this bug fixed. It's really a stop bug for me and prevents the whole webapp from starting.
-Wesley ----- Original Message ----- From: "Scott Ferguson" <[EMAIL PROTECTED]> To: "General Discussion for the Resin application server" <resin-interest@caucho.com> Sent: Monday, May 05, 2008 9:54 PM Subject: Re: [Resin-interest] <database> config shouldbeinitializedbeforeany singleton beans > > On May 4, 2008, at 8:39 PM, wesley wrote: > >> I've set logging to "finer" and found datasource being initialized >> after >> AmberContainer parsing persistence.xml. >> >> After some tracing, I think the issue is also an order problem. >> >> After resin server initialized, it began to init the webapp, at the >> order >> below: >> >> 1. Look at persistence.xml and try to init an AmberContainer. >> 2. Parse resin-web.xml to init DataSource, JCA connectors, EJBs and >> Singletons. >> >> Note, at the first step method getJtaDataSource() of >> com.caucho.amber.cfg.PersistenceUnitConfig will be >> called. It tried to find a DataSource in JNDI and failed, >> because a DataSource will be available in JNDI until the >> 2nd step finished. > > Ok. This use of PersistenceUnitConfig should be lazy. Resin can > register the PersistenceUnit/PersistenceContext before initializing > the provider. > > thanks, I'd missed that case. http://bugs.caucho.com/view.php?id=2648 > >> I'm using hibernate persistence provider. >> >> Now I'm frustrated. How could we managed to garantee these init >> orders? >> 1. First of all, DataSource in resin-web.xml to make sure a >> DataSource being >> registered. >> 2. persisence.xml to make sure any @PersistenceUnit and >> @PersistenceContext >> injection available. * > > This would be split into two parts: registering the @PersistenceUnit > and a later start() phase. > >> 3. JCA connectors (if any) in resin-web.xml. * >> 4. EJBs in resin-web.xml (if any). Why should EJBs be initialized >> after >> persistence.xml? It may need to inject a @PersistenceUnit. > > EJBs also have a 2-phase init process, so the same idea applies. > > -- Scott > >> 5. Singletons in resin-web.xml. >> * 2 & 3 may be reversed. >> >> Any ideas? >> >> -Wesley >> >> >> ----- Original Message ----- >> From: "Scott Ferguson" <[EMAIL PROTECTED]> >> To: "General Discussion for the Resin application server" >> <resin-interest@caucho.com> >> Sent: Monday, May 05, 2008 6:11 AM >> Subject: Re: [Resin-interest] <database> config should >> beinitializedbeforeany singleton beans >> >> >>> >>> On May 4, 2008, at 1:17 PM, wesley wrote: >>> >>>> Hi Scott, >>>> >>>> Is this issue resolved in snapshot0502? I've tried 0502 snapshot and >>>> found >>>> my singleton beans still throwing the same exception: >>>> >>>> java.lang.UnsupportedOperationException: The user must supply a >>>> JDBC >>>> connection >>>> >>>> I believe that the same problem still exists: DataSource SHOULD be >>>> initialized >>>> and be put in JNDI registry before the singletons try to find it. >>> >>> That should be a different issue. That stack trace is happening at >>> the end of the initialization, so all the data sources would already >>> be initialized. >>> >>> If you set the logging to "finer" do you see the database getting >>> registered? >>> >>> -- Scott >>> >>>> >>>> >>>> stacktrace at web-app initialing phase >>>> ========================================================== >>>> [04:08:57.373] {resin-15} java.lang.UnsupportedOperationException: >>>> The user >>>> must supply a JDBC connection >>>> [04:08:57.373] {resin-15} at >>>> org >>>> .hibernate >>>> .connection >>>> .UserSuppliedConnectionProvider >>>> .getConnection(UserSuppliedConnectionProvider.java:30) >>>> [04:08:57.373] {resin-15} at >>>> org >>>> .hibernate >>>> .jdbc.ConnectionManager.openConnection(ConnectionManager.java:423) >>>> [04:08:57.373] {resin-15} at >>>> org >>>> .hibernate >>>> .jdbc.ConnectionManager.getConnection(ConnectionManager.java:144) >>>> [04:08:57.373] {resin-15} at >>>> org >>>> .hibernate >>>> .jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java: >>>> 139) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1547) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.loader.Loader.doQuery(Loader.java:673) >>>> [04:08:57.373] {resin-15} at >>>> org >>>> .hibernate >>>> .loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java: >>>> 236) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.loader.Loader.doList(Loader.java:2213) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.loader.Loader.list(Loader.java:2099) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378) >>>> [04:08:57.373] {resin-15} at >>>> org >>>> .hibernate >>>> .hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java: >>>> 338) >>>> [04:08:57.373] {resin-15} at >>>> org >>>> .hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java: >>>> 172) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) >>>> [04:08:57.373] {resin-15} at >>>> org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:65) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .buysou >>>> .jpa.PersistenceStrategy.getResultList(PersistenceStrategy.java:584) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .buysou >>>> .stock >>>> .business.stock.GlobalStockCalendar.reload(GlobalStockCalendar.java: >>>> 41) >>>> [04:08:57.373] {resin-15} at >>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> [04:08:57.373] {resin-15} at >>>> sun >>>> .reflect >>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>> [04:08:57.373] {resin-15} at >>>> sun >>>> .reflect >>>> .DelegatingMethodAccessorImpl >>>> .invoke(DelegatingMethodAccessorImpl.java:25) >>>> [04:08:57.373] {resin-15} at >>>> java.lang.reflect.Method.invoke(Method.java:597) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .config.j2ee.PostConstructProgram.inject(PostConstructProgram.java: >>>> 60) >>>> [04:08:57.373] {resin-15} at >>>> com.caucho.webbeans.component.ComponentImpl.init(ComponentImpl.java: >>>> 502) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .webbeans >>>> .component >>>> .SingletonClassComponent.init(SingletonClassComponent.java: >>>> 139) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .webbeans >>>> .component.SingletonClassComponent.get(SingletonClassComponent.java: >>>> 96) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .webbeans >>>> .component.SingletonClassComponent.get(SingletonClassComponent.java: >>>> 81) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .webbeans >>>> .manager.WebBeansContainer.startSingletons(WebBeansContainer.java: >>>> 1079) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .webbeans >>>> .manager.WebBeansContainer.environmentStart(WebBeansContainer.java: >>>> 1059) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .loader.EnvironmentClassLoader.start(EnvironmentClassLoader.java: >>>> 583) >>>> [04:08:57.373] {resin-15} at >>>> com.caucho.server.webapp.WebApp.start(WebApp.java:1835) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .server.deploy.DeployController.startImpl(DeployController.java:667) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .server.deploy.DeployController.restartImpl(DeployController.java: >>>> 630) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .server >>>> .deploy >>>> .StartAutoRedeployAutoStrategy >>>> .alarm(StartAutoRedeployAutoStrategy.java:177) >>>> [04:08:57.373] {resin-15} at >>>> com >>>> .caucho >>>> .server.deploy.DeployController.handleAlarm(DeployController.java: >>>> 789) >>>> [04:08:57.373] {resin-15} at >>>> com.caucho.util.Alarm.handleAlarm(Alarm.java:375) >>>> [04:08:57.373] {resin-15} at com.caucho.util.Alarm.run(Alarm.java: >>>> 345) >>>> [04:08:57.373] {resin-15} at >>>> com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721) >>>> [04:08:57.373] {resin-15} at >>>> com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643) >>>> [04:08:57.373] {resin-15} at java.lang.Thread.run(Thread.java:619) >>>> = >>>> ==================================================================== >>>> >>>> -Wesley >>>> >>>> ----- Original Message ----- >>>> From: "wesley" <[EMAIL PROTECTED]> >>>> To: "General Discussion for the Resin application server" >>>> <resin-interest@caucho.com> >>>> Sent: Wednesday, April 23, 2008 1:51 AM >>>> Subject: Re: [Resin-interest] <database> config should be >>>> initializedbeforeany singleton beans >>>> >>>> >>>>> So singleton beans will also got a lazy load after DataSource, >>>>> right? >>>>> >>>>> Thanks, Scott. >>>>> >>>>> ps. Do you have time to look at my previous post about how to >>>>> config jca >>>>> connection pool max-active-time? >>>>> >>>>> ----- Original Message ----- >>>>> From: "Scott Ferguson" <[EMAIL PROTECTED]> >>>>> To: "General Discussion for the Resin application server" >>>>> <resin-interest@caucho.com> >>>>> Sent: Tuesday, April 22, 2008 10:35 PM >>>>> Subject: Re: [Resin-interest] <database> config should be >>>>> initialized >>>>> beforeany singleton beans >>>>> >>>>> >>>>>> >>>>>> On Apr 22, 2008, at 2:45 AM, wesley wrote: >>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> I'm upgrading snap080331 to snap080417. I found my hibernate >>>>>>> persistence unit not >>>>>>> working, with no jta-data-source configured. >>>>>>> I added 080417 src into my project and traced for a while and >>>>>>> found >>>>>>> the reason. >>>>>> >>>>>> This is something I worked on yesterday. The next snapshot should >>>>>> have the fix. >>>>>> >>>>>> The fix involves making the persistence.xml lookup of the >>>>>> dataSource >>>>>> lazy, so it only occurs using web-app start time, not at >>>>>> persistence.xml start. >>>>>> >>>>>> -- Scott >>>>>> >>>>>>> >>>>>>> >>>>>>> I put an breakpoint at com.caucho.naming.Jndi.bindImpl(...) >>>>>>> line: >>>>>>> 91 >>>>>>> and recorded >>>>>>> the jndi resources registered at order below: >>>>>>> "java:comp/env/jmx/MBeanServer" ... >>>>>>> "java:comp/env/jmx/GlobalMBeanServer" ... >>>>>>> "java:comp/UserTransaction" ... >>>>>>> "java:comp/TransactionManager" ... >>>>>>> "java:/TransactionManager" ... >>>>>>> "java:comp/ThreadPool" >>>>>>> "java:comp/env/caucho/persistent-store" >>>>>>> and then my singleton beans were then initialized, then >>>>>>> "java:comp/env/jdbc/stock" // my <database> config in resin- >>>>>>> web.xml >>>>>>> "java:comp/env/activemq" // my <connection-factory> config >>>>>>> in resin-web.xml >>>>>>> >>>>>>> Some of singleton beans need to access database by inject a >>>>>>> EMF, so >>>>>>> amber start to >>>>>>> load persistence unit. During parsing the persistence.xml, the >>>>>>> xml >>>>>>> config will set the >>>>>>> "jta-data-source" property of the >>>>>>> com.caucho.amber.cfg.PersistenceUnitConfig object >>>>>>> by reflection. Before doing it, it will call JNDI.lookup to find >>>>>>> the >>>>>>> DataSource with name >>>>>>> specified in persistence.xml, of cource nothing found! It was not >>>>>>> registered yet! >>>>>>> >>>>>>> I switched to snapshot080331 binary and still retained some src >>>>>>> of >>>>>>> 080417 (src package: >>>>>>> com.caucho.amber, com.caucho.config, com.caucho.naming) then >>>>>>> traced >>>>>>> it again. >>>>>>> This time I recored the the jndi resources registered at order >>>>>>> below >>>>>>> "java:comp/env/jmx/MBeanServer" ... >>>>>>> "java:comp/env/jmx/GlobalMBeanServer" ... >>>>>>> "java:comp/UserTransaction" ... >>>>>>> "java:comp/TransactionManager" ... >>>>>>> "java:/TransactionManager" ... >>>>>>> "java:comp/ThreadPool" >>>>>>> "java:comp/env/caucho/persistent-store" >>>>>>> "java:comp/env/jdbc/stock" // my <database> config in resin- >>>>>>> web.xml >>>>>>> "java:comp/env/activemq" // my <connection-factory> config >>>>>>> in resin-web.xml >>>>>>> and then my singleton beans were then initialized. >>>>>>> This is the right sequence. >>>>>>> >>>>>>> Though I didnot do further test, I think problem were not >>>>>>> belonged >>>>>>> to the three packages >>>>>>> I retained during the two snapshot version switch. >>>>>>> >>>>>>> Suggestions are appreciated, thanks. >>>>>>> >>>>>>> -Wesley >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> resin-interest mailing list >>>>>>> resin-interest@caucho.com >>>>>>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> resin-interest mailing list >>>>>> resin-interest@caucho.com >>>>>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> resin-interest mailing list >>>>> resin-interest@caucho.com >>>>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> resin-interest mailing list >>>> resin-interest@caucho.com >>>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>> >>> >>> >>> _______________________________________________ >>> resin-interest mailing list >>> resin-interest@caucho.com >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>> >> >> >> >> _______________________________________________ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest > > > > _______________________________________________ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
