If this is true, then it sounds like a bug. So you are saying that A is @EagerLoad, and B has a dependency on A.
B is also instantiated during the eager loading phase, due to some other service C. Service A is not realized in this scenario. Is that the bug you are seeing? On Tue, Aug 20, 2013 at 9:31 AM, Andrey <[email protected]> wrote: > Hello tapestry community, > > We use a lot of tapestry 5 features in our application development and > we've met a problem with @EagerLoad: > > Say we have a service A, its implementation marked as @EagerLoad. > And we have a service B, that requires A (it stores reference to A in its > constructor into the final field for future usage). > > B was initialized somehow during tapestry initialization (e.g. it was > requested by other EagerLoad service), and tapestry has created a proxy for > A. > > But later tapestry has not created instance of A during eager load phase (I > suppose because proxy was already created before). > > Have you met same problems? We use Tapestry 5.3.2, maybe such things were > already solved in next releases of framework? > > p.s. As a workaround we provided A.touch() method, and we touch A through > this method in initialization phase to force instance creation. > > With best regards, > Andrey. > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
