Martin, Wouldn't your suggestion ensure that all the action beans and their dependencies (like database connections) get instantiated when the application gets loaded? This is the situation that I am seeking to avoid. If the dependencies are set up right, Spring will make sure that the datasource is instantiated before any other object that depends on it directly or indirectly.
I did a crude little experiment. I replaced the implementation of the method verifyAction() in the class XmlConfigurationProvider in the xwork-2.0.1.jar to always return true. This is the method that checks the action classes to verify that the no-arg constructor is available and public. I am now getting the effect that I was looking for. Not very satisfying, but unless there is some other option out there, it will have to do until the code base is updated. Marco Martin Gainty wrote: > > Marco > > you may have a concurrency problem as by the time the action is invoked > the DataSource bean *should have been* already created > with regards to Spring Beans you can set lazy-init in > ApplicationContext.xml to false to both alloc and instantiate the bean > straight off > <bean id="beanid" class="fullPackageNameOfClass" lazy-init="false" > <property name="dataSource" ref="dataSource"/> > </bean> > > M-- > --------------------------------------------------------------------------- > This e-mail message (including attachments, if any) is intended for the > use of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential and exempt from > disclosure. If you are not the intended recipient, you are notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. > --------------------------------------------------------------------------- > Le présent message électronique (y compris les pièces qui y sont annexées, > le cas échéant) s'adresse au destinataire indiqué et peut contenir des > renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le > destinataire de ce document, nous vous signalons qu'il est strictement > interdit de le diffuser, de le distribuer ou de le reproduire. > ----- Original Message ----- > From: "Marco from Balboa" <[EMAIL PROTECTED]> > To: <user@struts.apache.org> > Sent: Thursday, March 15, 2007 9:28 AM > Subject: Re: Lazy loading actions in Struts 2 > > >> >> Spring generally requires that the no-arg constructor be accessible. It >> ought >> to be unless you explicitly override it in your class and mark it >> private. >> The only time I care about the instantiation of beans at startup is >> during >> development, where a quick application restart is helpful. When I am >> working >> on a piece of functionality, particularly one that involves interaction >> between the actions and the gui, I find myself restarting the application >> fairly frequently. In my case, I have connections to multiple databases >> and >> some other very expensive resources that I am allowing Spring to create >> and >> inject into the action objects. It would be a great timesaver during >> development if only the stuff that I am using gets instantiated. >> >> It looks like your are correct and my only alternatives are to submit at >> JIRA or try to fix it myself. Any other ideas out there? >> >> Thanks, >> >> Marco >> >> >> Dave Newton-4 wrote: >>> >>> --- Marco from Balboa <[EMAIL PROTECTED]> wrote: >>>> I tried following the documentation where they >>>> instruct to place the name of the Spring bean in >>>> class attribute for the action definition in the >>>> struts.xml. I assume this is what you are doing as >>>> well, correct? >>> >>> No :( I wasn't doing that, and when I do I also get >>> the ctor log debug msg. Sorry!!! >>> >>> I guess I've never noticed this because so far I've >>> never had explicit ctors in my Actions. Just out of >>> curiosity, why do you? >>> >>>> Couldn't this verification be done wihtout actually >>>> instatiating the bean and only examining the >>> metadata >>> >>> Probably. >>> >>>> more simply skipped and allow for the problem to >>>> surface when the action is actually called (maybe >>> via >>>> a configuration parameter)? >>> >>> I suppose you could create a JIRA for this. >>> >>> d. >>> >>> >>> >>> >>> ____________________________________________________________________________________ >>> Sucker-punch spam with award-winning protection. >>> Try the free Yahoo! Mail Beta. >>> http://advision.webevents.yahoo.com/mailbeta/features_spam.html >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Lazy-loading-actions-in-Struts-2-tf3404803.html#a9494446 >> Sent from the Struts - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- View this message in context: http://www.nabble.com/Lazy-loading-actions-in-Struts-2-tf3404803.html#a9497636 Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
