Re: Annotation processing - Geronimo injection
David Jencks wrote: I haven't done any speed measurements yet, have you? It does have an impact. I have added a system property to allow specifying if the instance manager should be used to create tag instances (default to not using it). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
David Jencks wrote: I tend to agree that a new branch is more appropriate. However, earlier versions of the patch had a compatibility layer so the old api could continue to work. I'm happy to add that back in on request. I am examining the patch in detail as part of the new trunk branch (adjusting things like package names), and unfortunately it turns out I still dislike it due to design implications with Jasper. Modern JSPs now uses lots of tags, and especially lots of SimpleTags, which are not pooled. As a result, the InstanceManager design leads to replacing new MySimpleTag() with newInstance(String className) (which creates the instance in a much more expensive way). Maybe adding access to InstanceManager.newInstance(Object instance) would be a solution (in effect making InstanceManager an extension of the old AnnotationProcessor). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On May 24, 2007, at 10:10 AM, Remy Maucherat wrote: David Jencks wrote: I tend to agree that a new branch is more appropriate. However, earlier versions of the patch had a compatibility layer so the old api could continue to work. I'm happy to add that back in on request. I am examining the patch in detail as part of the new trunk branch (adjusting things like package names), and unfortunately it turns out I still dislike it due to design implications with Jasper. Modern JSPs now uses lots of tags, and especially lots of SimpleTags, which are not pooled. As a result, the InstanceManager design leads to replacing new MySimpleTag() with newInstance (String className) (which creates the instance in a much more expensive way). Maybe adding access to InstanceManager.newInstance (Object instance) would be a solution (in effect making InstanceManager an extension of the old AnnotationProcessor). To reorient myself to this these tags can have injected stuff, correct? So it would theoretically be possible to support constructor injection on them, with suitable constructor metadata? Are tags typically created once per jsp instance or once per request (or at some other frequency)? And your objection here is that new Foo(); is sufficiently faster than Class fooClass = cl.loadClass(Foo); Object foo = fooClass.newInstance(); that we should separate the object construction and injection phases? My thoughts at this time are that: - if tags are created once per jsp we're only talking a difference in startup time which is not important - it might be worth eliminating the loadClass call in any case - if tags use injection the cost of looking up the stuff to inject so far dwarfs the time to create the object that the single InstanceManager.newInstance method still makes sense - if a tag doesn't use injection and is created once per request (or more often) then it would be worth measuring the speed difference and possibly modifying the code generator to directly create the tags when there are no injections for it. I haven't done any speed measurements yet, have you? 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]
Re: Annotation processing - Geronimo injection
David Jencks wrote: As far as I know I've addressed all the issues that were raised, but that might have a tenuous relationship to whether I actually did :-). I'd certainly appreciate review by tomcat committers before I completely forget how my patch works :-) The patch could see minor modifications when it is committed, but I am not going to ask you to do them. As for the actual commit, the problem is I don't know if it's appropriate to commit this in 6.0.x rather than in a new branch (at the moment, I would say no, as at least one project uses the API). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On May 17, 2007, at 2:41 AM, Remy Maucherat wrote: David Jencks wrote: As far as I know I've addressed all the issues that were raised, but that might have a tenuous relationship to whether I actually did :-). I'd certainly appreciate review by tomcat committers before I completely forget how my patch works :-) The patch could see minor modifications when it is committed, but I am not going to ask you to do them. As for the actual commit, the problem is I don't know if it's appropriate to commit this in 6.0.x rather than in a new branch (at the moment, I would say no, as at least one project uses the API). I tend to agree that a new branch is more appropriate. However, earlier versions of the patch had a compatibility layer so the old api could continue to work. I'm happy to add that back in on request. 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]
Re: Annotation processing - Geronimo injection
On Apr 12, 2007, at 12:15 PM, Remy Maucherat wrote: David Jencks wrote: https://issues.apache.org/jira/secure/attachment/12355273/ GERONIMO-3010-4.patch In addition, this one combines the InstanceManager interfaces. I think this is a bad idea because it forces jasper to use an interface shared with catalina, which the previous patch does not. This makes catalina marginally more complicated when used as a standalone container for jasper but makes it possible to use jasper outside catalina without any catalina classes. Note also that the previous (3c) patch allows use of tomcat embedded in a container that supplies its own InstanceManager implementation without pulling in any jasper classes at runtime. This has 1 interface, 1 implementation. Thanks for the patch revisions. I will look into adding these features after the next stable release. Rémy Now that 6.0.13 has been released is it a good time to resume this discussion about annotation processing? I have been using David's patch in geronimo's Tomcat assembly for the last several weeks and it has proven to be quite stable. David, do you consider the latest patch to be feature complete as far as where the discussion left off? Have the issues that were raised in this discussion been addressed? Best wishes, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On May 16, 2007, at 1:10 PM, Paul McMahan wrote: On Apr 12, 2007, at 12:15 PM, Remy Maucherat wrote: David Jencks wrote: https://issues.apache.org/jira/secure/attachment/12355273/ GERONIMO-3010-4.patch In addition, this one combines the InstanceManager interfaces. I think this is a bad idea because it forces jasper to use an interface shared with catalina, which the previous patch does not. This makes catalina marginally more complicated when used as a standalone container for jasper but makes it possible to use jasper outside catalina without any catalina classes. Note also that the previous (3c) patch allows use of tomcat embedded in a container that supplies its own InstanceManager implementation without pulling in any jasper classes at runtime. This has 1 interface, 1 implementation. Thanks for the patch revisions. I will look into adding these features after the next stable release. Rémy Now that 6.0.13 has been released is it a good time to resume this discussion about annotation processing? I have been using David's patch in geronimo's Tomcat assembly for the last several weeks and it has proven to be quite stable. David, do you consider the latest patch to be feature complete as far as where the discussion left off? Have the issues that were raised in this discussion been addressed? As far as I know I've addressed all the issues that were raised, but that might have a tenuous relationship to whether I actually did :-). I'd certainly appreciate review by tomcat committers before I completely forget how my patch works :-) thanks david jencks Best wishes, Paul - 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]
Re: Annotation processing - Geronimo injection
David Jencks wrote: https://issues.apache.org/jira/secure/attachment/12355273/GERONIMO-3010-4.patch In addition, this one combines the InstanceManager interfaces. I think this is a bad idea because it forces jasper to use an interface shared with catalina, which the previous patch does not. This makes catalina marginally more complicated when used as a standalone container for jasper but makes it possible to use jasper outside catalina without any catalina classes. Note also that the previous (3c) patch allows use of tomcat embedded in a container that supplies its own InstanceManager implementation without pulling in any jasper classes at runtime. This has 1 interface, 1 implementation. Thanks for the patch revisions. I will look into adding these features after the next stable release. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Apr 12, 2007, at 9:15 AM, Remy Maucherat wrote: David Jencks wrote: https://issues.apache.org/jira/secure/attachment/12355273/ GERONIMO-3010-4.patch In addition, this one combines the InstanceManager interfaces. I think this is a bad idea because it forces jasper to use an interface shared with catalina, which the previous patch does not. This makes catalina marginally more complicated when used as a standalone container for jasper but makes it possible to use jasper outside catalina without any catalina classes. Note also that the previous (3c) patch allows use of tomcat embedded in a container that supplies its own InstanceManager implementation without pulling in any jasper classes at runtime. This has 1 interface, 1 implementation. Thanks for the patch revisions. I will look into adding these features after the next stable release. Excellent, thanks! Would this be shortly after 6.0.11 is out or further in the future? If you have any guess about a date it would be much appreciated. 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]
Re: Annotation processing - Geronimo injection
David Jencks wrote: Excellent, thanks! Would this be shortly after 6.0.11 is out or further in the future? If you have any guess about a date it would be much appreciated. No idea. For example, I thought 6.0.11 would be ok, but it's not. I don't know if I'll commit as is either, since I did not look at the revised patches. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Mar 27, 2007, at 8:31 PM, David Jencks wrote: big snip 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. i've worked on this some more and come up with a patch that I feel more or less comfortable showing to tomcat :-) at https:// issues.apache.org/jira/browse/GERONIMO-3010 or directly https:// issues.apache.org/jira/secure/attachment/12355053/GERONIMO-3010-3a.patch I'm happy to open a bugzilla entry and attach the patch to it as well, but I also need to keep the patch tracked in geronimo until there's more resolution as to its fate. This patch features: -- xml override of annotations. There's even a manual test via a new EnvEntryExample servlet which is present but not entirely integrated into the examples webapp. -- postCreate and preDestroy annotated methods are looked for on all superclasses per spec. -- Improved interface name of InstanceManager rather than LifecycleProvider, thanks David Blevins -- Jasper does not use any Catalina classes, and catalina only uses a jasper class if it creates its own InstanceManager: if you supply an InstanceManager yourself there is no classes dependency of catalina on jasper (although it appears that startup creates a JspServlet in a default web app???). This removes the need for sharing org.apache.AnnotationProcessor between catalina and jasper. -- jasper loads classes more directly, tomcat uses care in figuring out if security precautions are needed and which classloader should be used. Some more improvements are possible, for example the jasper generated classes are loaded twice. I'd rather make sure that the current state doesn't break a lot of the tck before making a lot more changes. Comments? thanks david jencks
Re: Annotation processing - Geronimo injection
David Jencks wrote: i've worked on this some more and come up with a patch that I feel more or less comfortable showing to tomcat :-) at https://issues.apache.org/jira/browse/GERONIMO-3010 or directly https://issues.apache.org/jira/secure/attachment/12355053/GERONIMO-3010-3a.patch Thanks. I'm happy to open a bugzilla entry and attach the patch to it as well, but I also need to keep the patch tracked in geronimo until there's more resolution as to its fate. This patch features: -- xml override of annotations. There's even a manual test via a new EnvEntryExample servlet which is present but not entirely integrated into the examples webapp. -- postCreate and preDestroy annotated methods are looked for on all superclasses per spec. -- Improved interface name of InstanceManager rather than LifecycleProvider, thanks David Blevins Ok. -- Jasper does not use any Catalina classes, and catalina only uses a jasper class if it creates its own InstanceManager: if you supply an InstanceManager yourself there is no classes dependency of catalina on jasper (although it appears that startup creates a JspServlet in a default web app???). This removes the need for sharing org.apache.AnnotationProcessor between catalina and jasper. Submitting this in the patch makes me look at it and consider it, but I much prefer keeping a shared interface between Catalina and Jasper (because otherwise it's pretty obvious one of them becomes dependent on the other; and predictably, the main instance manager extends org.apache.jasper.instanceManagement.InstanceManager). Other smaller problems: - InstanceManagerFactory in Jasper is a bit too convoluted as far as I am concerned - I still don't know if I agree with removing the security checks out of Catalina, merging checks between filters and servlets, etc - Class hierarchy for InstanceManager - meh (although I suppose it perfectly fits your needs, though ...) -- jasper loads classes more directly, tomcat uses care in figuring out if security precautions are needed and which classloader should be used. Some more improvements are possible, for example the jasper generated classes are loaded twice. I'd rather make sure that the current state doesn't break a lot of the tck before making a lot more changes. To be honest, this whole stuff may be 6.next material. We'll see. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Apr 6, 2007, at 2:54 AM, Remy Maucherat wrote: David Jencks wrote: i've worked on this some more and come up with a patch that I feel more or less comfortable showing to tomcat :-) at https:// issues.apache.org/jira/browse/GERONIMO-3010 or directly https:// issues.apache.org/jira/secure/attachment/12355053/ GERONIMO-3010-3a.patch Thanks. I'm happy to open a bugzilla entry and attach the patch to it as well, but I also need to keep the patch tracked in geronimo until there's more resolution as to its fate. This patch features: -- xml override of annotations. There's even a manual test via a new EnvEntryExample servlet which is present but not entirely integrated into the examples webapp. -- postCreate and preDestroy annotated methods are looked for on all superclasses per spec. -- Improved interface name of InstanceManager rather than LifecycleProvider, thanks David Blevins Ok. -- Jasper does not use any Catalina classes, and catalina only uses a jasper class if it creates its own InstanceManager: if you supply an InstanceManager yourself there is no classes dependency of catalina on jasper (although it appears that startup creates a JspServlet in a default web app???). This removes the need for sharing org.apache.AnnotationProcessor between catalina and jasper. Submitting this in the patch makes me look at it and consider it, but I much prefer keeping a shared interface between Catalina and Jasper (because otherwise it's pretty obvious one of them becomes dependent on the other; and predictably, the main instance manager extends org.apache.jasper.instanceManagement.InstanceManager). IIRC everyone who commented on my previous patch complained that I had a shared class between catalina and jasper, so I changed it. If tomcat and jasper were truly independent, with no shared classes at all, you wouldn't be able to run jasper in tomcat without reflection or something that served as a container for both. I think my current implementation makes it clear why, as you note. I very slightly prefer the current implementation because it really does make it possible to run jasper in other servlet containers without any leakage of catalina classes. However I really don't care much, and am happy to go back to a single interface, but I won't put it in the org.apache package. Other smaller problems: - InstanceManagerFactory in Jasper is a bit too convoluted as far as I am concerned I'll see if I can think up a simpler way to do this. - I still don't know if I agree with removing the security checks out of Catalina, merging checks between filters and servlets, etc I think that the security checks and related code are really specific to the tomcat classloader and you shouldn't force them on containers embedding tomcat that use different classloaders. As far as uniformizing the code between servlets, filters, and listeners, I still don't understand the problem. You might well be right, but I'd really appreciate concrete details on why some checks are appropriate for servlets and not listeners or filters. Since all of these objects are only created once (except for single-thread-model servlets, which have all the checks anyway) I don't really see why a slight difference in startup speed would outweigh the simplicity of uniform code and relative ease of understanding of having the object creation policy in one place. - Class hierarchy for InstanceManager - meh (although I suppose it perfectly fits your needs, though ...) I agree... Geronimo implements its own InstanceManagers for tomcat and jasper, so we don't have that problem. I'd be perfectly happy to drop support for AnnotationProcessor entirely, but I kinda doubt you would like it so much :-) -- jasper loads classes more directly, tomcat uses care in figuring out if security precautions are needed and which classloader should be used. Some more improvements are possible, for example the jasper generated classes are loaded twice. I'd rather make sure that the current state doesn't break a lot of the tck before making a lot more changes. To be honest, this whole stuff may be 6.next material. We'll see. 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]
Re: Annotation processing - Geronimo injection
David Jencks wrote: but I won't put it in the org.apache package. There are not too many solutions to this problem, and (unfortunately for you, apparently) I think it's the most appropriate, or least inappropriate if you prefer. I was already aware it was possible to have one interface in Jasper and implement it in Catalina, or one interface in Catalina and use it in Jasper, and it would work ;) - I still don't know if I agree with removing the security checks out of Catalina, merging checks between filters and servlets, etc I think that the security checks and related code are really specific to the tomcat classloader and you shouldn't force them on containers embedding tomcat that use different classloaders. As far as uniformizing the code between servlets, filters, and listeners, I still don't understand the problem. You might well be right, but I'd really appreciate concrete details on why some checks are appropriate for servlets and not listeners or filters. Since all of these objects are only created once (except for single-thread-model servlets, which have all the checks anyway) I don't really see why a slight difference in startup speed would outweigh the simplicity of uniform code and relative ease of understanding of having the object creation policy in one place. I don't know for sure about that, I would have to look at what gets run in each case. Maybe the implementation in the proposed patch is fine. - Class hierarchy for InstanceManager - meh (although I suppose it perfectly fits your needs, though ...) I agree... Geronimo implements its own InstanceManagers for tomcat and jasper, so we don't have that problem. I'd be perfectly happy to drop support for AnnotationProcessor entirely, but I kinda doubt you would like it so much :-) It does not make any difference, really: if the API changes significantly, there's no need to keep the old API and provide fake compatibility, it would not really help IMO. I was complaining about the 2 interfaces + 1 abstract + 2 impls + 1 factory (maybe I forgot some). This is overengineered (for Tomcat at least) IMO. Personally, the thing that I would like would be at most: 1 shared interface, 1 abstract, 1 impl. OTOH, I think I accept the idea of the InstanceManager interface. Overall, thanks for the patch, it gives a very good basis for work (esp if you did test it). To be honest, this whole stuff may be 6.next material. We'll see. thanks! The first decision is to see if the API change is going to be acceptable in 6.0.x. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Apr 6, 2007, at 5:03 AM, Remy Maucherat wrote: David Jencks wrote: but I won't put it in the org.apache package. There are not too many solutions to this problem, and (unfortunately for you, apparently) I think it's the most appropriate, or least inappropriate if you prefer. Just as a note, I'd be great if people didn't put classes directly in the org.apache namespace. If every java project at Apache did that, we'd have a mess real quick. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
David Blevins wrote: On Apr 6, 2007, at 5:03 AM, Remy Maucherat wrote: David Jencks wrote: but I won't put it in the org.apache package. There are not too many solutions to this problem, and (unfortunately for you, apparently) I think it's the most appropriate, or least inappropriate if you prefer. Just as a note, I'd be great if people didn't put classes directly in the org.apache namespace. If every java project at Apache did that, we'd have a mess real quick. I agree with that, it is really a last resort solution. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Mar 25, 2007, at 7:40 PM, Remy Maucherat wrote: David Jencks wrote: I personally think the AnnotationProcessor is a very questionable idea and hope no one uses it. However, it is pretty common now. The point of the adapter is to show that tomcat can still support people who want to integrate via something like AnnotationProcessor. I certainly don't think tomcat should be using a AnnotationProcessor wrapped in a LifecycleProvider. I was basically trying to show that tomcat could work through an interface like LifecycleProvider, and that it would provide uniformity that is currently lacking, not trying to show a great new implementation of the interface. -- a little history and context -- I work on geronimo, and I started by getting annotation/injection support to work on our app client container and jetty integration, using some ideas I cribbed from OpenEjb and Xbean. With all of these projects it was a really natural fit to have an object creation service that, when given a class name, handed you back a fully baked object. The code tended to get simpler and more straightforward. Then I looked at MyFaces and realized that they could also simplify their code by using an object creation service where you say getLifecycleProvider().newInstance(className); rather than continual repetition of Object o = clazz.newInstance(); getAnnotationProcessor().inject(o); getAnnotationProcessor().postConstruct(o); At this point, I don't like the patch much either. I am not convinced by the proposed API (and the idea of an API change in 6.0.x) which is a bit more intrusive (a LifecycleProvider now would have to be given to Jasper for it to work), and how it is better than the continual (but explicit; quotes because it doesn't exactly happen that often) repetition where it does matter (as far as I can tell, not all the objects that may be instantiated may be annotated). AFAICT the objects that can be annotated are servlets, filters, listeners, and tags. The objects that AFAICT can't be annotated at present (unless jasper annotates some of its base classes, such as with postConstruct methods) are compiled jsps and some kind of object that jasper compiles out of tld files. 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. I might be mistaken but I'm pretty sure the current code happily does call the AnnotationProcessor on such classes. It's easy enough for jasper to create its own LifecycleProvider if none is supplied, although my current patch has null checks and alternate code for this circumstance. At least one RI in JEE land (JSF) has independently adopted the same AnnotationProcessor interface that is in use in Tomcat. I see you like the LifecycleProvider API better, but are there really things you cannot do (or are hard to do) with the AnnotationProcessor API ? That would be the bar that would have to be cleared IMO to justify a change. Umm, could you explain how the jsf RI is independent? Of what? To me that would mean they had come up with an interface with the same three methods without having seen any examples of it. If you want to count projects on either side of the fence, I got the idea from OpenEjb, geronimo uses this idea, jetty is compatiible with it, and MyFaces has adopted it after starting with the AnnotationProcessor style interface. 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. They agreed. Then I looked at Tomcat. I found that there was a lot of attention paid to all sorts of things such as security settings and whether the class was in tomcat for servlets, but no such attention paid for filters or listeners. I wondered if this was an oversight I guess I should Tomcat does not ship security sensitive filters and listeners, but has some funny servlets. For sure I will not want to be performing all these expensive checks for all instantiations, such as tags. That certainly makes sense, but I don't see how it relates to the current code in tomcat. From my reading the code that decides whether to perform the extra security stuff (SecurityUtil.isPackageProtectionEnabled()) doesn't depend on whether the object being instantiated is from the tomcat classloader. Therefore I thought it was reasonable to apply the same checks to all
Re: Annotation processing - Geronimo injection
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). 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). 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). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
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]
Re: Annotation processing - Geronimo injection
On Mar 24, 2007, at 10:42 PM, David Jencks wrote: On Mar 24, 2007, at 6:18 PM, Bill Barker wrote: Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/ GERONIMO-3010-1.patch A big huge -1 to the patch. It doesn't really provide anything to Tomcat that it isn't doing already. And to the extent that it is doing things differently, it is only adding complexity resulting in doing a much worse job. You might consider the idea of an object creation and destruction service rather than the current state of the patch which was not really intended for presentation as something to be applied as is to tomcat but as a demonstration that tomcat could be made to work with such a service. I figured that the first step was to investigate whether this was practical with minimal code changes in tomcat, and then think about how to further clean up the tomcat code. I've demonstrated to my own satisfaction that the idea can work, but the code could be simplified a lot. In its current state there is essentially no code that isn't already present in tomcat, although it's arranged slightly differently and is considerably more uniform. However, introducing a catalina dependancy into Jasper is a really huge no-no. Jasper is useful, and used without Tomcat. To break this would require a very good reason, which this patch certainly doesn't provide. How does this differ from the current org.apache.AnnotationProcessor? The only difference I can see is that I used the project namespace. I can't say I understand the thinking behind the package for org.apache.AnnotationProcessor. I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. Ya, I don't much like the name either but those postConstruct and preDestroy methods are often called lifecycle methods. I had to call it something. Any better ideas? ManagedObjectFactory? I might suggest something like InstanceManager. IIUC, you'd have these two methods on it: createInstance(..) destroyInstance(..) Assuming I understand the proposal, the default Tomcat implementation would call through to the AnnotationProcessor and all would stay the same in that regard. Above that though, I could easily imagine someone using that interface in Tomcat to provide an implementation that did instance counting for the Tomcat management console and maybe even sending out JMX notifications on create/destroy. I'm not sure I understand the bits about dependencies between Jasper and Catalina. I grok that Jasper is not to be dependent on Catalina, but I wonder if there are any shared libraries between the two that might be a good home for the proposed interface. Are there any shared Tomcat project libs between Jasper and Catalina or does Jasper pretty much only use third-party libs (libs outside the tomcat project itself)? -David I'd like to get your feedback, this is a chance step for our two communities to work together. There's certainly interest on the geronimo side. Many thanks david jencks Filip - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
David Jencks wrote: I personally think the AnnotationProcessor is a very questionable idea and hope no one uses it. However, it is pretty common now. The point of the adapter is to show that tomcat can still support people who want to integrate via something like AnnotationProcessor. I certainly don't think tomcat should be using a AnnotationProcessor wrapped in a LifecycleProvider. I was basically trying to show that tomcat could work through an interface like LifecycleProvider, and that it would provide uniformity that is currently lacking, not trying to show a great new implementation of the interface. -- a little history and context -- I work on geronimo, and I started by getting annotation/injection support to work on our app client container and jetty integration, using some ideas I cribbed from OpenEjb and Xbean. With all of these projects it was a really natural fit to have an object creation service that, when given a class name, handed you back a fully baked object. The code tended to get simpler and more straightforward. Then I looked at MyFaces and realized that they could also simplify their code by using an object creation service where you say getLifecycleProvider().newInstance(className); rather than continual repetition of Object o = clazz.newInstance(); getAnnotationProcessor().inject(o); getAnnotationProcessor().postConstruct(o); At this point, I don't like the patch much either. I am not convinced by the proposed API (and the idea of an API change in 6.0.x) which is a bit more intrusive (a LifecycleProvider now would have to be given to Jasper for it to work), and how it is better than the continual (but explicit; quotes because it doesn't exactly happen that often) repetition where it does matter (as far as I can tell, not all the objects that may be instantiated may be annotated). At least one RI in JEE land (JSF) has independently adopted the same AnnotationProcessor interface that is in use in Tomcat. I see you like the LifecycleProvider API better, but are there really things you cannot do (or are hard to do) with the AnnotationProcessor API ? That would be the bar that would have to be cleared IMO to justify a change. They agreed. Then I looked at Tomcat. I found that there was a lot of attention paid to all sorts of things such as security settings and whether the class was in tomcat for servlets, but no such attention paid for filters or listeners. I wondered if this was an oversight I guess I should Tomcat does not ship security sensitive filters and listeners, but has some funny servlets. For sure I will not want to be performing all these expensive checks for all instantiations, such as tags. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Annotation processing - Geronimo injection
yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/GERONIMO-3010-1.patch I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. I'd like to get your feedback, this is a chance step for our two communities to work together. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/GERONIMO-3010-1.patch A big huge -1 to the patch. It doesn't really provide anything to Tomcat that it isn't doing already. And to the extent that it is doing things differently, it is only adding complexity resulting in doing a much worse job. However, introducing a catalina dependancy into Jasper is a really huge no-no. Jasper is useful, and used without Tomcat. To break this would require a very good reason, which this patch certainly doesn't provide. I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. I'd like to get your feedback, this is a chance step for our two communities to work together. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
thanks for the feedback, I didn't look closely into the patch to see what it was doing. I'll communicate this to them Filip Bill Barker wrote: Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/GERONIMO-3010-1.patch A big huge -1 to the patch. It doesn't really provide anything to Tomcat that it isn't doing already. And to the extent that it is doing things differently, it is only adding complexity resulting in doing a much worse job. However, introducing a catalina dependancy into Jasper is a really huge no-no. Jasper is useful, and used without Tomcat. To break this would require a very good reason, which this patch certainly doesn't provide. I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. I'd like to get your feedback, this is a chance step for our two communities to work together. Filip - 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]
Re: Annotation processing - Geronimo injection
Hi, Here is my point of view. I like the idea of create a new instance through various kinds of magic to be replaced by nice code that can do the object creation and injection in one step. As I am still new on the code of Tomcat, having all the code concentrated for the object creation and injection is a good idea. I remember to have problem to find out where the filter, servlet... objects were created when I did my first patch on the annotations. But I have no solution to implement it on tomcat. The patch doesn't seems to modify nothing on the catalina side (ContextConfig.java, WebRuleSet.java, WebAnnotationSet.java). Just the jasper side is taken in account. I don't think an adapter between the LifecycleProvider interface and the AnnotationProcessor interface is a good idea. This is one layer more between the code which does the work and the code which requires the work. The adapter has to be maintained. It is more work for us. Cheer's Fabien On 3/24/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/GERONIMO-3010-1.patch I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. I'd like to get your feedback, this is a chance step for our two communities to work together. Filip -- Fabien Carrion () Campagne du ruban ASCII -- Contre les mails en html /\ contre les pieces-jointes Microsoft Web: http://fabien.carrion.free.fr/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
Fabien Carrion wrote: Hi, Here is my point of view. I like the idea of create a new instance through various kinds of magic to be replaced by nice code that can do the object creation and injection in one step. As I am still new on the code of Tomcat, having all the code concentrated for the object creation and injection is a good idea. I remember to have problem to find out where the filter, servlet... objects were created when I did my first patch on the annotations. But I have no solution to implement it on tomcat. I agree, I think what David J was trying to do, replace this with a single piece of code, however wasn't really successful in conveying that message into nice code. There were two goals: 1. Refactor the loadClass and newInstance into a single spot 2. Apply whatever logic you needed when a new instance was created, perhaps even annotion processing The patch doesn't seems to modify nothing on the catalina side (ContextConfig.java, WebRuleSet.java, WebAnnotationSet.java). Just the jasper side is taken in account. Yes, Bill pointed out how an invalid dependency was created, I have communicated this back to David. I don't think an adapter between the LifecycleProvider interface and the AnnotationProcessor interface is a good idea. This is one layer more between the code which does the work and the code which requires the work. The adapter has to be maintained. It is more work for us. True, I sent the feedback, lets see what happens. Filip Cheer's Fabien On 3/24/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/GERONIMO-3010-1.patch I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. I'd like to get your feedback, this is a chance step for our two communities to work together. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
Thanks for your interest!
On Mar 24, 2007, at 9:26 PM, Fabien Carrion wrote:
Hi,
Here is my point of view.
I like the idea of create a new instance through various kinds of
magic to be replaced by nice code that can do the object creation
and injection in one step.
As I am still new on the code of Tomcat, having all the code
concentrated for the object creation and injection is a good idea. I
remember to have problem to find out where the filter, servlet...
objects were created when I did my first patch on the annotations. But
I have no solution to implement it on tomcat.
The patch doesn't seems to modify nothing on the catalina side
(ContextConfig.java, WebRuleSet.java, WebAnnotationSet.java). Just the
jasper side is taken in account.
I don't think an adapter between the LifecycleProvider interface
and the
AnnotationProcessor interface is a good idea. This is one layer more
between the code which does the work and the code which requires the
work. The adapter has to be maintained. It is more work for us.
I personally think the AnnotationProcessor is a very questionable
idea and hope no one uses it. However, it is pretty common now. The
point of the adapter is to show that tomcat can still support people
who want to integrate via something like AnnotationProcessor. I
certainly don't think tomcat should be using a AnnotationProcessor
wrapped in a LifecycleProvider. I was basically trying to show that
tomcat could work through an interface like LifecycleProvider, and
that it would provide uniformity that is currently lacking, not
trying to show a great new implementation of the interface.
-- a little history and context --
I work on geronimo, and I started by getting annotation/injection
support to work on our app client container and jetty integration,
using some ideas I cribbed from OpenEjb and Xbean. With all of these
projects it was a really natural fit to have an object creation
service that, when given a class name, handed you back a fully baked
object. The code tended to get simpler and more straightforward.
Then I looked at MyFaces and realized that they could also simplify
their code by using an object creation service where you say
getLifecycleProvider().newInstance(className);
rather than continual repetition of
Object o = clazz.newInstance();
getAnnotationProcessor().inject(o);
getAnnotationProcessor().postConstruct(o);
They agreed.
Then I looked at Tomcat. I found that there was a lot of attention
paid to all sorts of things such as security settings and whether the
class was in tomcat for servlets, but no such attention paid for
filters or listeners. I wondered if this was an oversight I
guess I should have asked but was kind of busy. So, I wanted to see
if I could get tomcat to work with an object creation service both
standalone and in geronimo. I haven't located any tests for tomcat
standalone so my criterion for tomcat working standalone so far is
it builds. I'm getting good results in geronimo with a geronimo
implementation of LifecycleProvider.
So, if there's interest in pursuing this in tomcat, my idea of a
possible path would be something like:
0. find a better name than LifecycleProvider :-)
1. Modify the code that creates and destroys these managed objects
so there is always a LifecycleProvider present. This eliminates a
lot of if (its there) { do it one way} else {do it another way} code.
2. Write a suitable variety of LifecycleProvider implementations. An
obvious simple one is clazz.newInstance() for newInstance, and {} for
destroyInstance. There can be one with the security code of the
current servlet construction code. There can be one that adapts to
an AnnotationProcessor for those who prefer to provide an
implementation of that interface. And there can be a native tomcat
implementation that does annotations. Of course I think the geronimo
implementation is close to ideal :-) and you're welcome to use it but
it may not suit all the standalone tomcat needs.
3. Make sure its convenient to configure both tomcat and jasper
(independently) with the LifecycleProvider instances of your choice.
Many thanks,
david jencks
Cheer's
Fabien
On 3/24/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
yo,
I've been in touch with the folks at Geronimo.
They use dependency injection, and have a suggestion on how they
would
like the annotation processor to be able to be injected into tomcat
Here is the email
http://marc.info/?l=geronimo-devm=117467149802844w=2
Here is the proposed patch:
https://issues.apache.org/jira/secure/attachment/12354097/
GERONIMO-3010-1.patch
I'd take out the word LifecycleProvider, and replace it with
something
else as it conflicts with our own idea of Lifecycle.
I'd like to get your feedback, this is a chance step for our two
communities to work together.
Filip
--
Fabien Carrion
() Campagne du ruban ASCII --
Re: Annotation processing - Geronimo injection
On Mar 24, 2007, at 6:18 PM, Bill Barker wrote: Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] yo, I've been in touch with the folks at Geronimo. They use dependency injection, and have a suggestion on how they would like the annotation processor to be able to be injected into tomcat Here is the email http://marc.info/?l=geronimo-devm=117467149802844w=2 Here is the proposed patch: https://issues.apache.org/jira/secure/attachment/12354097/ GERONIMO-3010-1.patch A big huge -1 to the patch. It doesn't really provide anything to Tomcat that it isn't doing already. And to the extent that it is doing things differently, it is only adding complexity resulting in doing a much worse job. You might consider the idea of an object creation and destruction service rather than the current state of the patch which was not really intended for presentation as something to be applied as is to tomcat but as a demonstration that tomcat could be made to work with such a service. I figured that the first step was to investigate whether this was practical with minimal code changes in tomcat, and then think about how to further clean up the tomcat code. I've demonstrated to my own satisfaction that the idea can work, but the code could be simplified a lot. In its current state there is essentially no code that isn't already present in tomcat, although it's arranged slightly differently and is considerably more uniform. However, introducing a catalina dependancy into Jasper is a really huge no-no. Jasper is useful, and used without Tomcat. To break this would require a very good reason, which this patch certainly doesn't provide. How does this differ from the current org.apache.AnnotationProcessor? The only difference I can see is that I used the project namespace. I can't say I understand the thinking behind the package for org.apache.AnnotationProcessor. I'd take out the word LifecycleProvider, and replace it with something else as it conflicts with our own idea of Lifecycle. Ya, I don't much like the name either but those postConstruct and preDestroy methods are often called lifecycle methods. I had to call it something. Any better ideas? ManagedObjectFactory? I'd like to get your feedback, this is a chance step for our two communities to work together. There's certainly interest on the geronimo side. Many thanks david jencks Filip - 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]
