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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [CORRECTION] Release Tomcat 4.1.35
Mark Thomas wrote: > Mark Thomas wrote: >> Tomcat 4.1.35 is: >> [X] Stable >> [ ] Beta >> [ ] Alpha I am withdrawing my vote for this release and the release candidate as the build appears to be bad (the wrong mx4j.jar is used). I haven't as yet got to the bottom of why my testing didn't spot this but once I have a fixed, tested build I'll roll 4.1.36 and call for a vote. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r522110 - in /tomcat/container/branches/tc4.1.x: RELEASE-NOTES-4.1.txt build.properties.default
Author: markt
Date: Sat Mar 24 14:50:03 2007
New Revision: 522110
URL: http://svn.apache.org/viewvc?view=rev&rev=522110
Log:
Correct build process to use correct mx4j.jar as a result of packing changes in
mx4j
Modified:
tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt
tomcat/container/branches/tc4.1.x/build.properties.default
Modified: tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt
URL:
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt?view=diff&rev=522110&r1=522109&r2=522110
==
--- tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt (original)
+++ tomcat/container/branches/tc4.1.x/RELEASE-NOTES-4.1.txt Sat Mar 24 14:50:03
2007
@@ -641,10 +641,13 @@
[4.1.35] Admin webapp
Fix APR connector configuration by removing unsupported
- attributes socketBuffer and threadPriority.
+ attributes socketBuffer and threadPriority
[4.1.35] service.bat
- Add tools.jar to classpath so JSPs will compile.
+ Add tools.jar to classpath so JSPs will compile
+
+[4.1.36] mx4j
+ Update build process so correct mx4j jar is used
--
Modified: tomcat/container/branches/tc4.1.x/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/build.properties.default?view=diff&rev=522110&r1=522109&r2=522110
==
--- tomcat/container/branches/tc4.1.x/build.properties.default (original)
+++ tomcat/container/branches/tc4.1.x/build.properties.default Sat Mar 24
14:50:03 2007
@@ -187,7 +187,7 @@
# - Java Management Extensions (JMX), JMX RI 1.0.1 or later or MX4J 1.0 or
later -
jmx.home=${base.path}/mx4j-3.0.2
jmx.lib=${jmx.home}/lib
-jmx.jar=${jmx.lib}/mx4j-jmx.jar
+jmx.jar=${jmx.lib}/mx4j.jar
jmx.license=${jmx.home}/LICENSE.txt
jmx.loc=${base-sourceforge.loc}/mx4j/mx4j-3.0.2.tar.gz
-
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-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r522127 - in /tomcat/site/trunk: docs/security-4.html xdocs/security-4.xml
Author: markt Date: Sat Mar 24 16:33:33 2007 New Revision: 522127 URL: http://svn.apache.org/viewvc?view=rev&rev=522127 Log: Update for cve-2002-1567 Modified: tomcat/site/trunk/docs/security-4.html tomcat/site/trunk/xdocs/security-4.xml Modified: tomcat/site/trunk/docs/security-4.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-4.html?view=diff&rev=522127&r1=522126&r2=522127 == --- tomcat/site/trunk/docs/security-4.html (original) +++ tomcat/site/trunk/docs/security-4.html Sat Mar 24 16:33:33 2007 @@ -341,6 +341,44 @@ + +Fixed in Apache Tomcat 4.1.29 + + + + + + + + + +moderate: Cross-site scripting + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1567";> + CVE-2002-1567 + + +The unmodified requested URL is included in the 404 response header. The + new lines in this URL appear to the client to be the end of the header + section. The remaining part of the URL, including the script elements, is + treated as part of the response body and the client executes the script. + Tomcat now replaces potentially unsafe characters in the response + headers with spaces. + +Affects: 4.1.0-4.1.28 + + + + + + + + + + + + + + Fixed in Apache Tomcat 4.1.0 Modified: tomcat/site/trunk/xdocs/security-4.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-4.xml?view=diff&rev=522127&r1=522126&r2=522127 == --- tomcat/site/trunk/xdocs/security-4.xml (original) +++ tomcat/site/trunk/xdocs/security-4.xml Sat Mar 24 16:33:33 2007 @@ -104,6 +104,21 @@ Affects: 4.0.0-4.0.6, 4.1.0-4.1.31 + +moderate: Cross-site scripting + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1567";> + CVE-2002-1567 + +The unmodified requested URL is included in the 404 response header. The + new lines in this URL appear to the client to be the end of the header + section. The remaining part of the URL, including the script elements, is + treated as part of the response body and the client executes the script. + Tomcat now replaces potentially unsafe characters in the response + headers with spaces. + +Affects: 4.1.0-4.1.28 + + important: Denial of service http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0866";> - 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-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: [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 "" 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-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: [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 "" 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-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r522147 - in /tomcat/site/trunk: docs/security-4.html xdocs/security-4.xml
Author: markt Date: Sat Mar 24 19:19:50 2007 New Revision: 522147 URL: http://svn.apache.org/viewvc?view=rev&rev=522147 Log: Add information on cve-2002-1394 and cve-2002-1148 Modified: tomcat/site/trunk/docs/security-4.html tomcat/site/trunk/xdocs/security-4.xml Modified: tomcat/site/trunk/docs/security-4.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-4.html?view=diff&rev=522147&r1=522146&r2=522147 == --- tomcat/site/trunk/docs/security-4.html (original) +++ tomcat/site/trunk/docs/security-4.html Sat Mar 24 19:19:50 2007 @@ -379,6 +379,80 @@ + +Fixed in Apache Tomcat 4.1.13, 4.0.6 + + + + + + + + + +important: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1394";> + CVE-2002-1394 + + +A specially crafted URL using the invoker servlet in conjunction with the + default servlet can enable an attacker to obtain the source of JSP pages + or, under special circumstances, a static resource that would otherwise + have been protected by a security constraint without the need to be + properly authenticated. This is a variation of + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1148";> + CVE-2002-1148 + + +Affects: 4.0.0-4.0.5, 4.1.0-4.1.12 + + + + + + + + + + + + + + + +Fixed in Apache Tomcat 4.1.12, 4.0.5 + + + + + + + + + +important: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1148";> + CVE-2002-1148 + + +A specially crafted URL using the default servlet can enable an attacker + to obtain the source of JSP pages. + +Affects: 4.0.0-4.0.4, 4.1.0-4.1.11 + + + + + + + + + + + + + + Fixed in Apache Tomcat 4.1.0 Modified: tomcat/site/trunk/xdocs/security-4.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-4.xml?view=diff&rev=522147&r1=522146&r2=522147 == --- tomcat/site/trunk/xdocs/security-4.xml (original) +++ tomcat/site/trunk/xdocs/security-4.xml Sat Mar 24 19:19:50 2007 @@ -119,6 +119,33 @@ Affects: 4.1.0-4.1.28 + +important: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1394";> + CVE-2002-1394 + +A specially crafted URL using the invoker servlet in conjunction with the + default servlet can enable an attacker to obtain the source of JSP pages + or, under special circumstances, a static resource that would otherwise + have been protected by a security constraint without the need to be + properly authenticated. This is a variation of + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1148";> + CVE-2002-1148 + +Affects: 4.0.0-4.0.5, 4.1.0-4.1.12 + + + +important: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1148";> + CVE-2002-1148 + +A specially crafted URL using the default servlet can enable an attacker + to obtain the source of JSP pages. + +Affects: 4.0.0-4.0.4, 4.1.0-4.1.11 + + important: Denial of service http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0866";> - 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 "" 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-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 pi
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-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
