Strange behavour of @EagerLoad

[Andrey]

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 Lewis Ship]

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?

Post by Andrey
Hello tapestry community,
We use a lot of tapestry 5 features in our application development and
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!

[phone]
http://howardlewisship.com

[Andrey]

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.

Post by Howard Lewis Ship
If this is true, then it sounds like a bug.
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?

Post by Andrey
Hello tapestry community,
We use a lot of tapestry 5 features in our application development and
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

Post by Andrey
A.
But later tapestry has not created instance of A during eager load phase

(I

Post by Andrey
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!
[phone]
http://howardlewisship.com