Hontvári József wrote: > The name of the first class is misleading (maybe Scheduled... would have > been better, it is executing scheduled tasks itself), Resin's scheduler > hasn't been involved in the configuration. But the issue is either the > same or we have two independent issues. If I remove the constructor > initialization by creating an empty constructor and use setter instead > of it, then the CanDI initialization does completes. However, if I add > @Startup annotation, so a class instance is actually created, then I > again receive StackOverflow. > Thanks. I have this fixed for 4.0.4.
-- Scott > > > > Wesley Wu írta: > >> This could be a lazy init problem I think. >> >> The scheduled tasks would be inited before some of other beans which >> the tasks need. >> >> I've met this before. >> >> The workaround: >> Inject the Injector into your task, no other webbeans. >> When the task starts (run()), create webbeans instances via the injector. >> >> -Wesley >> >> 2010/2/11 Hontvári József <[email protected]>: >> >> >>> I reduced the configuration to the minimum. It consists of a circular setter >>> dependency, and then a separate third constructor initialization which >>> refers to one of circular items. Both have to be present, otherwise >>> StackOverflow doesn't happen. I attached a configuration sample and a part >>> of the log file, logged on "finer" level. >>> >>> Scott Ferguson írta: >>> >>> Hontvári József wrote: >>> >>> >>> I receive java.lang.StackOverflowError when Resin tries to read the >>> configuration file: >>> >>> [10-02-10 10:31:56.929] {resin-37} >>> C:/Progra~1/mireka-1.2/conf/mireka.xml:325: com.caucho.confi >>> g.core.ResinIf.init(): java.lang.StackOverflowError >>> >>> I believe there is no circular constructor dependency in the file. To be >>> sure I replaced almost all constructor initialisation blocks with setter >>> initialization. Is there a way to debug this error? There is no stack >>> trace or anything else in the log. >>> >>> >>> >>> Can you send that section of the configuration file? It looks like it's >>> something to do with the <resin:if> like the test EL expression, >>> although it could also be the contents of the if. >>> >>> Also, it's possible that adding a <logger name="" level="finer"/> in the >>> <resin> section will show the stack trace. >>> >>> -- Scott >>> >>> > > > > > _______________________________________________ > resin-interest mailing list > [email protected] > http://maillist.caucho.com/mailman/listinfo/resin-interest > > _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
