You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Konstantin Ignatyev <kg...@yahoo.com> on 2005/01/17 04:14:23 UTC
Development mode with LESS PAIN???? - pain measurements
That is a nice workaround for a thing that should be
done automatically at framework level. Someone earlier
suggested removing Render time from Tapestry produced
HTML by security reasons, I suggest removing it
because it provides false information about render
time, I did quick and dirty performance estimation
with HttpUnit and filter in front of Tapestry
application:
Request took = 2970 ms at client side, page reports
Render time: ~ 279 ms -->
Request took = 810 ms at client side, page reports
Render time: ~ 112 ms -->
Request took = 726 ms at client side, page reports
Render time: ~ 98 ms -->
Request took = 753 ms at client side, page reports
Render time: ~ 107 ms -->
Request took = 527 ms at client side, page reports
Render time: ~ 95 ms -->
Request took = 668 ms at client side, page reports
Render time: ~ 83 ms -->
Request took = 489 ms at client side, page reports
Render time: ~ 75 ms -->
Request took = 611 ms at client side, page reports
Render time: ~ 79 ms -->
Request took = 490 ms at client side, page reports
Render time: ~ 80 ms -->
Request took = 631 ms at client side, page reports
Render time: ~ 80 ms -->
for the same request server side filter reports:
2381 ms -service=external/PhotoCollection&sp=Sbatik
747 ms -service=external/PhotoCollection&sp=Sbatik
663 ms -service=external/PhotoCollection&sp=Sbatik
681 ms -service=external/PhotoCollection&sp=Sbatik
483 ms -service=external/PhotoCollection&sp=Sbatik
593 ms -service=external/PhotoCollection&sp=Sbatik
435 ms -service=external/PhotoCollection&sp=Sbatik
580 ms -service=external/PhotoCollection&sp=Sbatik
466 ms -service=external/PhotoCollection&sp=Sbatik
602 ms -service=external/PhotoCollection&sp=Sbatik
As we can see Shell reports 8 times smaller rendering
time than it really is.
There is negligible client side processing time:
server side filter reports 602 ms rendering time,
client says 631 ms.
Those measurements are for HTML production only,
getting all the page artifacts like images and css may
take much longer...
client:
public class SitePerformanceTest {
public static void main(String[] args) {
try {
WebConversation wc = new WebConversation();
WebRequest req = new
GetMethodWebRequest("http://localhost:8080/mmerk/app?service=external/PhotoCollection&sp=Sbatik");
long startTime = 0;
WebResponse resp = null;
long end = 0;
for (int i = 0; i < 10; i++) {
startTime = System.currentTimeMillis();
resp = wc.getResponse(req);
end = System.currentTimeMillis();
System.out.println("Request took = " + (end -
startTime) + " ms at client side, page reports " +
getRendering(resp.getText()) );
}
} catch (Exception e) {
e.printStackTrace();
}
}
private static String getRendering(String text) {
RE re = new RE("(Render time:.+)");
re.match(text);
return re.getParen(0);
}
}
server side filter:
public class PerfFilter implements Filter{
public void init(FilterConfig filterConfig) throws
ServletException {
}
public void doFilter(ServletRequest servletRequest,
ServletResponse servletResponse, FilterChain
filterChain) throws IOException, ServletException {
long start = System.currentTimeMillis();
filterChain.doFilter(servletRequest,
servletResponse);
if( servletRequest instanceof HttpServletRequest){
HttpServletRequest r = (HttpServletRequest)
servletRequest;
System.out.println( (
System.currentTimeMillis() - start ) + " ms -" +
r.getQueryString() );
}
}
public void destroy() {
}
}
<filter>
<filter-name>p</filter-name>
<filter-class>com.kgionline.mmerkulova.site.PerfFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>p</filter-name>
<url-pattern>/app</url-pattern>
</filter-mapping>
Suse 9.2 AMD 64 3500+ java 1.4.2_06
--- Richard Lewis-Shell <rl...@mac.com> wrote:
> I never develop Tapestry apps with caching disabled.
> But in every app I
> develop I put a link to trigger the reset service.
> Typically the app
> has a logo, or something common on every page so
> that logo/whatever
> becomes a development-time reset (ie. reload) link.
>
>
=====
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN???? - pain measurements
Posted by kranga <kr...@k2d2.org>.
I always suspected that the time reported by the shell component is
incorrect. In fact, I put a timer code in pageBegin- and pageEnd- render and
saw the same time as what Shell reports. My suspicion therefore is that the
process from when the page finished with the markup writer to when it is
streamed out is slow - something going on there... Howard?
----- Original Message -----
From: "Konstantin Ignatyev" <kg...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Sunday, January 16, 2005 10:14 PM
Subject: Development mode with LESS PAIN???? - pain measurements
> That is a nice workaround for a thing that should be
> done automatically at framework level. Someone earlier
> suggested removing Render time from Tapestry produced
> HTML by security reasons, I suggest removing it
> because it provides false information about render
> time, I did quick and dirty performance estimation
> with HttpUnit and filter in front of Tapestry
> application:
> Request took = 2970 ms at client side, page reports
> Render time: ~ 279 ms -->
> Request took = 810 ms at client side, page reports
> Render time: ~ 112 ms -->
> Request took = 726 ms at client side, page reports
> Render time: ~ 98 ms -->
> Request took = 753 ms at client side, page reports
> Render time: ~ 107 ms -->
> Request took = 527 ms at client side, page reports
> Render time: ~ 95 ms -->
> Request took = 668 ms at client side, page reports
> Render time: ~ 83 ms -->
> Request took = 489 ms at client side, page reports
> Render time: ~ 75 ms -->
> Request took = 611 ms at client side, page reports
> Render time: ~ 79 ms -->
> Request took = 490 ms at client side, page reports
> Render time: ~ 80 ms -->
> Request took = 631 ms at client side, page reports
> Render time: ~ 80 ms -->
> for the same request server side filter reports:
> 2381 ms -service=external/PhotoCollection&sp=Sbatik
> 747 ms -service=external/PhotoCollection&sp=Sbatik
> 663 ms -service=external/PhotoCollection&sp=Sbatik
> 681 ms -service=external/PhotoCollection&sp=Sbatik
> 483 ms -service=external/PhotoCollection&sp=Sbatik
> 593 ms -service=external/PhotoCollection&sp=Sbatik
> 435 ms -service=external/PhotoCollection&sp=Sbatik
> 580 ms -service=external/PhotoCollection&sp=Sbatik
> 466 ms -service=external/PhotoCollection&sp=Sbatik
> 602 ms -service=external/PhotoCollection&sp=Sbatik
>
> As we can see Shell reports 8 times smaller rendering
> time than it really is.
> There is negligible client side processing time:
> server side filter reports 602 ms rendering time,
> client says 631 ms.
>
> Those measurements are for HTML production only,
> getting all the page artifacts like images and css may
> take much longer...
>
> client:
> public class SitePerformanceTest {
>
> public static void main(String[] args) {
> try {
> WebConversation wc = new WebConversation();
> WebRequest req = new
>
GetMethodWebRequest("http://localhost:8080/mmerk/app?service=external/PhotoC
ollection&sp=Sbatik");
> long startTime = 0;
> WebResponse resp = null;
> long end = 0;
> for (int i = 0; i < 10; i++) {
> startTime = System.currentTimeMillis();
> resp = wc.getResponse(req);
> end = System.currentTimeMillis();
> System.out.println("Request took = " + (end -
> startTime) + " ms at client side, page reports " +
> getRendering(resp.getText()) );
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>
> private static String getRendering(String text) {
> RE re = new RE("(Render time:.+)");
> re.match(text);
> return re.getParen(0);
> }
> }
>
>
> server side filter:
> public class PerfFilter implements Filter{
> public void init(FilterConfig filterConfig) throws
> ServletException {
>
> }
>
> public void doFilter(ServletRequest servletRequest,
> ServletResponse servletResponse, FilterChain
> filterChain) throws IOException, ServletException {
> long start = System.currentTimeMillis();
> filterChain.doFilter(servletRequest,
> servletResponse);
> if( servletRequest instanceof HttpServletRequest){
> HttpServletRequest r = (HttpServletRequest)
> servletRequest;
> System.out.println( (
> System.currentTimeMillis() - start ) + " ms -" +
> r.getQueryString() );
> }
> }
>
> public void destroy() {
>
> }
> }
>
> <filter>
> <filter-name>p</filter-name>
>
> <filter-class>com.kgionline.mmerkulova.site.PerfFilter</filter-class>
> </filter>
>
>
> <filter-mapping>
> <filter-name>p</filter-name>
> <url-pattern>/app</url-pattern>
> </filter-mapping>
>
> Suse 9.2 AMD 64 3500+ java 1.4.2_06
>
> --- Richard Lewis-Shell <rl...@mac.com> wrote:
>
> > I never develop Tapestry apps with caching disabled.
> > But in every app I
> > develop I put a link to trigger the reset service.
> > Typically the app
> > has a logo, or something common on every page so
> > that logo/whatever
> > becomes a development-time reset (ie. reload) link.
>
> >
> >
>
>
> =====
> Konstantin Ignatyev
>
>
>
>
> PS: If this is a typical day on planet earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil, add
2,700 tons of CFCs to the stratosphere, and increase their population by
263,000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
a Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN???? - pain measurements
Posted by Vjeran Marcinko <vj...@tis.hr>.
----- Original Message -----
From: "Konstantin Iignatyev" <kg...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Monday, January 17, 2005 5:37 AM
Subject: Re: Development mode with LESS PAIN???? - pain measurements
> Well, it is almost order of magnitude far from real response time, so I
> suggest removing the measurement as misleading. Simplest filter like one
> I used produces far more accurate results and extremely easy to use for
> rough (but accurate) performance measures. I bet there is a place in the
> Tapestry where entire FW response time could be measured without of
> filter use.
+1 from me for rendering complete request time, because I was also the one
who was mislead by this time some months ago, though it was obvious by eye
that my page took much longer to render itself. Never asked on this mailing
list why it was though (now I can see it isn't real processing time).
Just my 2 cents.
-Vjeran
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 14.1.2005
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN???? - pain measurements
Posted by Konstantin Iignatyev <kg...@yahoo.com>.
Howard Lewis Ship wrote:
>The time is inaccurate because the Java clock is inaccurate.
>
C'mon, Java clock is inaccuracy could be in 1-5 ms range, it could not
explain 80 and 602 ms difference
> The time
>measured is the time to render the Shell component ... not the time it
>takes to process the entire response.
>
>The point of it is to allow you to see orders-of-magnitude differences
>between pages.
>
>
Well, it is almost order of magnitude far from real response time, so I
suggest removing the measurement as misleading. Simplest filter like one
I used produces far more accurate results and extremely easy to use for
rough (but accurate) performance measures. I bet there is a place in the
Tapestry where entire FW response time could be measured without of
filter use.
>Can't think of a security issue. What could you possibly do with the time?
>
>
Security is not related to time at all, before in the tread somebody
asked how to remove Rendering time mark from final HTML because it
indicates Tapestry as a framework and his boss considers that as a
security weakness. I simply referred to that question.
>On Sun, 16 Jan 2005 19:14:23 -0800 (PST), Konstantin Ignatyev
><kg...@yahoo.com> wrote:
>
>
>>That is a nice workaround for a thing that should be
>>done automatically at framework level. Someone earlier
>>suggested removing Render time from Tapestry produced
>>HTML by security reasons, I suggest removing it
>>because it provides false information about render
>>time, I did quick and dirty performance estimation
>>with HttpUnit and filter in front of Tapestry
>>application:
>>Request took = 2970 ms at client side, page reports
>>Render time: ~ 279 ms -->
>>Request took = 810 ms at client side, page reports
>>Render time: ~ 112 ms -->
>>Request took = 726 ms at client side, page reports
>>Render time: ~ 98 ms -->
>>Request took = 753 ms at client side, page reports
>>Render time: ~ 107 ms -->
>>Request took = 527 ms at client side, page reports
>>Render time: ~ 95 ms -->
>>Request took = 668 ms at client side, page reports
>>Render time: ~ 83 ms -->
>>Request took = 489 ms at client side, page reports
>>Render time: ~ 75 ms -->
>>Request took = 611 ms at client side, page reports
>>Render time: ~ 79 ms -->
>>Request took = 490 ms at client side, page reports
>>Render time: ~ 80 ms -->
>>Request took = 631 ms at client side, page reports
>>Render time: ~ 80 ms -->
>>for the same request server side filter reports:
>>2381 ms -service=external/PhotoCollection&sp=Sbatik
>>747 ms -service=external/PhotoCollection&sp=Sbatik
>>663 ms -service=external/PhotoCollection&sp=Sbatik
>>681 ms -service=external/PhotoCollection&sp=Sbatik
>>483 ms -service=external/PhotoCollection&sp=Sbatik
>>593 ms -service=external/PhotoCollection&sp=Sbatik
>>435 ms -service=external/PhotoCollection&sp=Sbatik
>>580 ms -service=external/PhotoCollection&sp=Sbatik
>>466 ms -service=external/PhotoCollection&sp=Sbatik
>>602 ms -service=external/PhotoCollection&sp=Sbatik
>>
>>As we can see Shell reports 8 times smaller rendering
>>time than it really is.
>>There is negligible client side processing time:
>>server side filter reports 602 ms rendering time,
>>client says 631 ms.
>>
>>Those measurements are for HTML production only,
>>getting all the page artifacts like images and css may
>>take much longer...
>>
>>client:
>>public class SitePerformanceTest {
>>
>> public static void main(String[] args) {
>> try {
>> WebConversation wc = new WebConversation();
>> WebRequest req = new
>>GetMethodWebRequest("http://localhost:8080/mmerk/app?service=external/PhotoCollection&sp=Sbatik");
>> long startTime = 0;
>> WebResponse resp = null;
>> long end = 0;
>> for (int i = 0; i < 10; i++) {
>> startTime = System.currentTimeMillis();
>> resp = wc.getResponse(req);
>> end = System.currentTimeMillis();
>> System.out.println("Request took = " + (end -
>>startTime) + " ms at client side, page reports " +
>>getRendering(resp.getText()) );
>> }
>> } catch (Exception e) {
>> e.printStackTrace();
>> }
>> }
>>
>> private static String getRendering(String text) {
>> RE re = new RE("(Render time:.+)");
>> re.match(text);
>> return re.getParen(0);
>> }
>>}
>>
>>server side filter:
>>public class PerfFilter implements Filter{
>> public void init(FilterConfig filterConfig) throws
>>ServletException {
>>
>> }
>>
>> public void doFilter(ServletRequest servletRequest,
>>ServletResponse servletResponse, FilterChain
>>filterChain) throws IOException, ServletException {
>> long start = System.currentTimeMillis();
>> filterChain.doFilter(servletRequest,
>>servletResponse);
>> if( servletRequest instanceof HttpServletRequest){
>> HttpServletRequest r = (HttpServletRequest)
>>servletRequest;
>> System.out.println( (
>>System.currentTimeMillis() - start ) + " ms -" +
>>r.getQueryString() );
>> }
>> }
>>
>> public void destroy() {
>>
>> }
>>}
>>
>> <filter>
>> <filter-name>p</filter-name>
>>
>><filter-class>com.kgionline.mmerkulova.site.PerfFilter</filter-class>
>> </filter>
>>
>> <filter-mapping>
>> <filter-name>p</filter-name>
>> <url-pattern>/app</url-pattern>
>> </filter-mapping>
>>
>>Suse 9.2 AMD 64 3500+ java 1.4.2_06
>>
>>--- Richard Lewis-Shell <rl...@mac.com> wrote:
>>
>>
>>
>>>I never develop Tapestry apps with caching disabled.
>>> But in every app I
>>>develop I put a link to trigger the reset service.
>>>Typically the app
>>>has a logo, or something common on every page so
>>>that logo/whatever
>>>becomes a development-time reset (ie. reload) link.
>>>
>>>
>>>
>>>
>>=====
>>Konstantin Ignatyev
>>
>>PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
>>
>>Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN???? - pain measurements
Posted by Howard Lewis Ship <hl...@gmail.com>.
The time is inaccurate because the Java clock is inaccurate. The time
measured is the time to render the Shell component ... not the time it
takes to process the entire response.
The point of it is to allow you to see orders-of-magnitude differences
between pages.
Can't think of a security issue. What could you possibly do with the time?
On Sun, 16 Jan 2005 19:14:23 -0800 (PST), Konstantin Ignatyev
<kg...@yahoo.com> wrote:
> That is a nice workaround for a thing that should be
> done automatically at framework level. Someone earlier
> suggested removing Render time from Tapestry produced
> HTML by security reasons, I suggest removing it
> because it provides false information about render
> time, I did quick and dirty performance estimation
> with HttpUnit and filter in front of Tapestry
> application:
> Request took = 2970 ms at client side, page reports
> Render time: ~ 279 ms -->
> Request took = 810 ms at client side, page reports
> Render time: ~ 112 ms -->
> Request took = 726 ms at client side, page reports
> Render time: ~ 98 ms -->
> Request took = 753 ms at client side, page reports
> Render time: ~ 107 ms -->
> Request took = 527 ms at client side, page reports
> Render time: ~ 95 ms -->
> Request took = 668 ms at client side, page reports
> Render time: ~ 83 ms -->
> Request took = 489 ms at client side, page reports
> Render time: ~ 75 ms -->
> Request took = 611 ms at client side, page reports
> Render time: ~ 79 ms -->
> Request took = 490 ms at client side, page reports
> Render time: ~ 80 ms -->
> Request took = 631 ms at client side, page reports
> Render time: ~ 80 ms -->
> for the same request server side filter reports:
> 2381 ms -service=external/PhotoCollection&sp=Sbatik
> 747 ms -service=external/PhotoCollection&sp=Sbatik
> 663 ms -service=external/PhotoCollection&sp=Sbatik
> 681 ms -service=external/PhotoCollection&sp=Sbatik
> 483 ms -service=external/PhotoCollection&sp=Sbatik
> 593 ms -service=external/PhotoCollection&sp=Sbatik
> 435 ms -service=external/PhotoCollection&sp=Sbatik
> 580 ms -service=external/PhotoCollection&sp=Sbatik
> 466 ms -service=external/PhotoCollection&sp=Sbatik
> 602 ms -service=external/PhotoCollection&sp=Sbatik
>
> As we can see Shell reports 8 times smaller rendering
> time than it really is.
> There is negligible client side processing time:
> server side filter reports 602 ms rendering time,
> client says 631 ms.
>
> Those measurements are for HTML production only,
> getting all the page artifacts like images and css may
> take much longer...
>
> client:
> public class SitePerformanceTest {
>
> public static void main(String[] args) {
> try {
> WebConversation wc = new WebConversation();
> WebRequest req = new
> GetMethodWebRequest("http://localhost:8080/mmerk/app?service=external/PhotoCollection&sp=Sbatik");
> long startTime = 0;
> WebResponse resp = null;
> long end = 0;
> for (int i = 0; i < 10; i++) {
> startTime = System.currentTimeMillis();
> resp = wc.getResponse(req);
> end = System.currentTimeMillis();
> System.out.println("Request took = " + (end -
> startTime) + " ms at client side, page reports " +
> getRendering(resp.getText()) );
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>
> private static String getRendering(String text) {
> RE re = new RE("(Render time:.+)");
> re.match(text);
> return re.getParen(0);
> }
> }
>
> server side filter:
> public class PerfFilter implements Filter{
> public void init(FilterConfig filterConfig) throws
> ServletException {
>
> }
>
> public void doFilter(ServletRequest servletRequest,
> ServletResponse servletResponse, FilterChain
> filterChain) throws IOException, ServletException {
> long start = System.currentTimeMillis();
> filterChain.doFilter(servletRequest,
> servletResponse);
> if( servletRequest instanceof HttpServletRequest){
> HttpServletRequest r = (HttpServletRequest)
> servletRequest;
> System.out.println( (
> System.currentTimeMillis() - start ) + " ms -" +
> r.getQueryString() );
> }
> }
>
> public void destroy() {
>
> }
> }
>
> <filter>
> <filter-name>p</filter-name>
>
> <filter-class>com.kgionline.mmerkulova.site.PerfFilter</filter-class>
> </filter>
>
> <filter-mapping>
> <filter-name>p</filter-name>
> <url-pattern>/app</url-pattern>
> </filter-mapping>
>
> Suse 9.2 AMD 64 3500+ java 1.4.2_06
>
> --- Richard Lewis-Shell <rl...@mac.com> wrote:
>
> > I never develop Tapestry apps with caching disabled.
> > But in every app I
> > develop I put a link to trigger the reset service.
> > Typically the app
> > has a logo, or something common on every page so
> > that logo/whatever
> > becomes a development-time reset (ie. reload) link.
>
> >
> >
>
> =====
> Konstantin Ignatyev
>
> PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org