Strange behavour of @EagerLoad

[Andrey <an...@gmail.com>]

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.

Re: Strange behavour of @EagerLoad

[Andrey <an...@gmail.com>]

Hello Howard,

yes, you are right in that description.

Due to some debugging I've found possible place of bug (again, it's 5.3.2
sources): ModuleImpl.collectEagerLoadServices calls findOrCreate(...,
proxies), and there is a bug: findOrCreate fills proxies argument with new
values only if it does not find service but creates this.

With best regards, Andrey.


2013/8/20 Howard Lewis Ship <hl...@gmail.com>

> 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 <an...@gmail.com> 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
>



-- 
откланиваюсь,
Андрюха

Re: Strange behavour of @EagerLoad

[Howard Lewis Ship <hl...@gmail.com>]

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 <an...@gmail.com> 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