What happens if you then declare:
@ApplicationState
private SomeIntf a;
with no name, and you have two objects of the same type declared
elsewhere, with different names? Which object should "a" be resolved to?
Arguably, if it can't be resolved, tapestry would need to throw an
exception. Fine.
Ideally, we'd be able to recover the generics information, but the
Java implementation of generics makes that very hard to accomplish.
Type erasure and all that.
I think the approach of creating sub-interfaces to "nail down" the
generic types is the best approach.
On Fri, Jun 27, 2008 at 7:08 AM,
I do not have a JIRA account yet. Unfortunately, it seems I can not sign
up right now (always get a "session timed out" error message in the
signup screen). Maybe it has to do with the switching of daylight saving
time, which happens right now. I'll try again later.
Should I create a small example
Please add an issue to JIRA. Although we have unit and integration tests
covering the application state mechanism it is still possible that there is
a bug.
On 10/27/07, Christoph Jaeger <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> after upgrading from 5.0.5 to 5.0.6 (which was not too difficult thanks
What's needed is the equivalent of T4's @InjectStateFlag which
provides a boolean for whether the state already exists or not, just
so you can avoid incidentally createing the ASO.
There simply isn't a way to do this in 5.0.2. ApplicationStateManager
doesn't have the necessary API.
On 2/23/07,
