You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik - Dev Lists <de...@hanik.com> on 2007/03/24 16:56:17 UTC
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-dev&m=117467149802844&w=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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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" <de...@hanik.com> wrote in message
> news:46054A21.2090600@hanik.com...
>
>> 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-dev&m=117467149802844&w=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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Blevins <da...@visi.com>.
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" <de...@hanik.com> wrote in message
>> news:46054A21.2090600@hanik.com...
>>> 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-dev&m=117467149802844&w=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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
On Mar 24, 2007, at 6:18 PM, Bill Barker wrote:
>
> "Filip Hanik - Dev Lists" <de...@hanik.com> wrote in message
> news:46054A21.2090600@hanik.com...
>> 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-dev&m=117467149802844&w=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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Bill Barker <wb...@wilshire.com>.
"Filip Hanik - Dev Lists" <de...@hanik.com> wrote in message
news:46054A21.2090600@hanik.com...
> 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-dev&m=117467149802844&w=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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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 <de...@hanik.com> 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-dev&m=117467149802844&w=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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Blevins <da...@visi.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Paul McMahan <pa...@gmail.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
I've come up with a couple more patches that try to address your
concerns:
https://issues.apache.org/jira/secure/attachment/12355259/
GERONIMO-3010-3c.patch
This one eliminates backwards compatibility support for
AnnotationProcessor and eliminates the replaceable aspects of jasper
InstanceManagerFactory, just leaving a static method for obtaining
the InstanceFactory. This is decidedly less flexible than the
previous implementation and now requires jasper to be run in a
container that supplies an InstanceManager. There are still separate
interfaces for InstanceManagers for catalina and jasper. I think
this is a considerably superior design than the next one...
This has 2 interfaces, 1 implementation (in tomcat, there's an unused
impl in jasper, see below).
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.
Both of these include a jasper DefaultInstanceManager that isn't
used, but could be by a project that wants to install jasper with no
annotation support.
I'd like to explore exactly how jasper creates classloaders and
whether its possible to use class reloading features of modern jvms
to eliminate the need to allow replacing the classloader in the
jasper InstanceManager at runtime. Unfortunately I doubt I'll have
time for this in the next month or so.
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. 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 ;)
yes, and I prefer 2 interfaces with the possiblity of supplying
separate implementations. This makes catalina's standalone life
slightly more complicated but jasper's life outside catalina simpler
IMO.
>
>>> - 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.
I could have missed something, but so far I think what I'm proposing
is OK.
>
>>> - 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.
Looking forward to your comments...
>
> Rémy
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
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
Posted by David Jencks <da...@yahoo.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
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
managed classes, not just servlets.
There's also a check for explicitly restricted classes, which again
seemed to me reasonable to apply to all the kinds of stuff.
And finally there's this code the purpose of which is not all that
clear to me:
protected Class loadClass(String className, ClassLoader
classLoader) throws ClassNotFoundException {
if (className.startsWith("org.apache.catalina")) {
return containerClassLoader.loadClass(className);
}
try {
Class clazz = containerClassLoader.loadClass(className);
if (ContainerServlet.class.isAssignableFrom(clazz)) {
return clazz;
}
} catch (Throwable t) {
//ignore
}
return classLoader.loadClass(className);
}
What would happen if it was:
protected Class loadClass(String className, ClassLoader
classLoader) throws ClassNotFoundException {
try {
return classLoader.loadClass(className);
} catch (Throwable t) {
//ignore
}
return containerClassLoader.loadClass(className);
}
?
I was thinking that perhaps with something like the LifecycleProvider
interface tomcat could look at its configuration at startup and
decide which policy for object creation it wanted to use:
- security sensitive
- provided by tomcat- sensitive
- annotation aware
- ... you name it
and instantiate an appropriate factory that implemented that policy.
Then it could enforce the policy without any runtime checks to decide
which policy was in force.
One more time...
To me the benefits to tomcat of this approach are:
1. replace runtime checks with deploy time strategy installation
2. put all the object creation code in one place so its easier to see
if it makes sense
3. provide friendlier interfaces for projects wishing to embed tomcat.
To me (1) is self evidently a good idea and would be enough for me to
adopt the proposal. With regard to (2) I am not all that familiar
with tomcat, and having collected the existing object management code
into the LifecycleProviderToAnnotationProcessorAdapter class in my
patch, it doesn't make much sense to me. I was hoping that someone
more familiar with what is intended could either simplify it or
perhaps comment on the intent. I assume there are some circumstances
in which the more expensive checks involved in classloading are
appropriate, and I'm sure there are plenty in which they are not, so
I would expect that a deploy time strategy choice would make more
sense than continual runtime checks. As for (3).... it would have
been a lot less work for me to simply use the existing tomcat
interfaces, but this proposal looked to me like an obvious win-win
choice for both tomcat and geronimo.
thanks
david jencks
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by David Jencks <da...@yahoo.com>.
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 <de...@hanik.com> 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-dev&m=117467149802844&w=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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Annotation processing - Geronimo injection
Posted by Fabien Carrion <fa...@gmail.com>.
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 <de...@hanik.com> 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-dev&m=117467149802844&w=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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org