On Mar 27, 2007, at 10:39 AM, Remy Maucherat wrote:
David Jencks wrote:
compiled jsps
If you read the spec literally, they can't be annotated, but this
is quite arbitrary IMO (as soon as they're mapped in web.xml, they
can).
Doh! Of course you're right. I just haven't seen a jsp with any java
code in it for a while :-). This could be a challenge for deployment
unless you've precompiled your jsps.... I'll have to think about this.
I'm pretty sure that someone who had more than my 2 days
acquaintance with jasper could in a couple of minutes point out
how to avoid using LifecycleProvider or AnnotationProcessor on
generated classes.
Hem, that does look difficult to me.
Umm, could you explain how the jsf RI is "independent"? Of what?
I meant they came up with the same interface without talking to us.
The AnnotationProcessor style can't support constructor dependency
injection or factory methods. These are not envisioned by the
specs but there's nothing preventing their support through
additional metadata. An object creation service can. However,
the main benefit I can see for tomcat is that by swapping which
implementation you use at startup, you can specify the policy for
object instantiation (such as security sensitve, annotation
sensitive, neither, custom.....) without any runtime cost.
Ok. I note the constructor dependency injection (as well as the
future proof destructor dependency injection :D). As I said in my
email, I am not in favor of the unification of all instantiation
checks, as the said checks have a cost and may not be needed (in
particular for tags).
Maybe I haven't been explaining my thinking very well. I suspect
that for a very large percentage of web apps, the expensive checks
are completely unnecessary even for servlets. Furthermore AFAICT its
pretty easy to tell whether or not an app is going to need them
before you start constructing servlets and other components. So, if
the app doesn't need the fancy stuff, you can supply it with a
LifecycleProvider that doesn't do any. If it does, you can supply it
with one that does do the checks.
Furthermore, there's no reason jasper and tomcat have to be using the
same LifecycleProvider at the same time. Jasper can get one free of
checks, tomcat can have one that refuses to load any classes :-).
I still don't understand the point behind the fancy classloading code
or why you insist that it should only apply to servlets. Is there
some other code or documentation I could look at that might help
explain your point of view?
obvious win-win choice for both tomcat and geronimo.
Right now, it's mostly pita-win (it's a significant refactoring) :D
You should IMO offer some incentive as part of this to justify the
refactoring, such as support for web.xml annotation overrides in
standalone Tomcat (as you can see, there's full support for
annotations, but not overriding).
i'll look into this... although I don't see the code involved as
being very connected to what I've been proposing.
thanks
david jencks
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
