DO NOT REPLY [Bug 53112] New: Following asynchronous responses do not contain set response headers

2012-04-20 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53112

 Bug #: 53112
   Summary: Following asynchronous responses do not contain set
response headers
   Product: Tomcat 7
   Version: 7.0.25
  Platform: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: s...@vangen.org
Classification: Unclassified


This problem is related to this issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50753

The first asynchronous request lets you set the response header, and that
response gets parsed correctly on the client side. The following requests in
the same async context does not let you set the response headers, and Tomcat
seem to give some default headers only. In addition, it also switches to
chunked transfer encoding because of missing content length. This results in
errors in clients trying to read the response from a Tomcat context. These
problems does not occur when using Jetty using the same Servlet 3.0 API's.

This problem was discovered while updating the BOSH plugin for the Vysper
project:
https://issues.apache.org/jira/browse/VYSPER-307

The same problem was observed in both Tomcat version 7.0.25 and 7.0.27.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1328227 - in /tomcat/maven-plugin/trunk: tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/DeployOnlyMojo.java tomcat7-maven-plugin/src/main/java/org/apache/tomcat

2012-04-20 Thread olamy 
Author: olamy
Date: Fri Apr 20 07:11:07 2012
New Revision: 1328227

URL: http://svn.apache.org/viewvc?rev=1328227&view=rev
Log:
fix javadoc typo

Modified:

tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/DeployOnlyMojo.java

tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/deploy/DeployOnlyMojo.java

Modified: 
tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/DeployOnlyMojo.java
URL: 
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/DeployOnlyMojo.java?rev=1328227&r1=1328226&r2=1328227&view=diff
==
--- 
tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/DeployOnlyMojo.java
 (original)
+++ 
tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/DeployOnlyMojo.java
 Fri Apr 20 07:11:07 2012
@@ -20,7 +20,7 @@ package org.apache.tomcat.maven.plugin.t
  */
 
 /**
- * Deploy a WAR to Tomcat witjout forking the package lifecycle
+ * Deploy a WAR to Tomcat without forking the package lifecycle
  *
  * @author olamy
  * @version $Id: DeployOnlyMojo.java 12852 2010-10-12 22:04:32Z thragor $

Modified: 
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/deploy/DeployOnlyMojo.java
URL: 
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/deploy/DeployOnlyMojo.java?rev=1328227&r1=1328226&r2=1328227&view=diff
==
--- 
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/deploy/DeployOnlyMojo.java
 (original)
+++ 
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/deploy/DeployOnlyMojo.java
 Fri Apr 20 07:11:07 2012
@@ -20,7 +20,7 @@ package org.apache.tomcat.maven.plugin.t
  */
 
 /**
- * Deploy a WAR to Tomcat witjout forking the package lifecycle
+ * Deploy a WAR to Tomcat without forking the package lifecycle
  *
  * @author olamy
  * @version $Id: DeployOnlyMojo.java 12852 2010-10-12 22:04:32Z thragor $



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 52055] ChunkedInputFilter is not recycled for servlet 3.0 asynchronous request

2012-04-20 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=52055

Sudhan Moghe  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #7 from Sudhan Moghe  2012-04-20 14:01:42 
UTC ---
I am still facing this issue. My test cases are failing randomly when I run my
application with true.
Everything work fine when client is not using chunked encoding. 
Also, everything work fine when run with
false

I have debugged the problem and this bug report helped me in finding root
cause. I found that ChunkedInputFilter is getting reused even when
keepalive=false. And my test cases start failing after that point.
So, we need to recycle it in that case. 

Issue was fixed by modifying the AbstractHttp11Processor file.
Replaced lines #1538 to #1544

if (!keepAlive) {
return SocketState.CLOSED;
} else {
getInputBuffer().nextRequest();
getOutputBuffer().nextRequest();
return SocketState.OPEN;
}
With
getInputBuffer().nextRequest();
if (!keepAlive) {
return SocketState.CLOSED;
} else {
getOutputBuffer().nextRequest();
return SocketState.OPEN;
}

I was testing against 7.0.26. Will test with trunk and submit patch if
required.
We can not recycle output buffer at this stage as it has not completed flushing
data.
Let me know if there is a better place to handle this. Will test it and then
post a patch.

I don't have a simple test case to reproduce the issue.
Let me know what else I can do to help you fix this issue. 

Thanks,
Sudhan

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 52055] ChunkedInputFilter is not recycled for servlet 3.0 asynchronous request

2012-04-20 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=52055

Sudhan Moghe  changed:

   What|Removed |Added

 CC||sudhan.mo...@gmail.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 53081] WebappClassLoader causes java.lang.OutOfMemoryError in findResourceInternal()

2012-04-20 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53081

Christopher Schultz  changed:

   What|Removed |Added

 OS/Version||All

--- Comment #1 from Christopher Schultz  
2012-04-20 15:44:19 UTC ---
Stack trace is:

java.lang.OutOfMemoryError: Java heap space
at
org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:3098)
at
org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:1244)
at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1407)
at
org.springframework.core.io.ClassPathResource.exists(ClassPathResource.java:139)
at
org.springframework.batch.item.file.FlatFileItemReader.doOpen(FlatFileItemReader.java:248)
at
org.springframework.batch.item.support.AbstractItemCountingItemStreamItemReader.open(AbstractItemCountingItemStreamItemReader.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at
org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy30.open(Unknown Source)
at
org.springframework.batch.item.support.CompositeItemStream.open(CompositeItemStream.java:93)
at
org.springframework.batch.core.step.item.ChunkMonitor.open(ChunkMonitor.java:105)
at
org.springframework.batch.item.support.CompositeItemStream.open(CompositeItemStream.java:93)
at
org.springframework.batch.core.step.tasklet.TaskletStep.open(TaskletStep.java:301)
at
org.springframework.batch.core.step.AbstractStep.execute(AbstractStep.java:192)
at
org.springframework.batch.core.job.SimpleStepHandler.handleStep(SimpleStepHandler.java:135)
at
org.springframework.batch.core.job.flow.JobFlowExecutor.executeStep(JobFlowExecutor.java:61)
at
org.springframework.batch.core.job.flow.support.state.StepState.handle(StepState.java:60)
at
org.springframework.batch.core.job.flow.support.SimpleFlow.resume(SimpleFlow.java:144)
at
org.springframework.batch.core.job.flow.support.SimpleFlow.start(SimpleFlow.java:124)
at
org.springframework.batch.core.job.flow.FlowJob.doExecute(FlowJob.java:135)
at
org.springframework.batch.core.job.AbstractJob.execute(AbstractJob.java:281)
at
org.springframework.batch.core.launch.support.SimpleJobLauncher$1.run(SimpleJobLauncher.java:120)
at
org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:48)
 
Line of code in 7.0.x/trunk and trunk is actually 3151:

  byte[] binaryContent = new byte[contentLength];

I would argue that instead of only loading certain types of resources (using
what? magic number or other content-type-sniffing?), WebAppClassLoader could be
configured never to load complete content for resources over a certain size.

I'd be interested to hear why resources are loaded in their entirety in this
way. Another flavor of findResourceInternal(File,String) only creates URI
objects and does not access the disk at all.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Welcome file list in web.xml treats index.jsp different from other filenames

2012-04-20 Thread Christopher Schultz 
To whom it may concern,

On 4/14/12 3:37 PM, Net Dawg wrote:
> To your question as to "what point merging algorithms are not
> followed", please try this inside your application context and you will
> probably see the same:
> 
> 
>  
> 
> 
> This seems to tell Tomcat 7, in plain English, "there are no welcome
> files, don't bother looking for them anywhere" ...

You probably aren't getting a response because you didn't answer the
question. Your opinion of how things should work isn't really relevant,
here. Konstantin asked where Tomcat's behavior violates the servlet spec
and you replied by telling him what you think ought to happen. That's
not an answer, so you're being ignored.

Can you find a place where your "seems to tell" scenario above is
actually supported by language in the servlet specification? If so, tell
us where. If the spec isn't clear on a subject, usually the safest thing
to do is not change anything because users have become reliant on
certain behavior. If and when the spec is clarified, a change will be made.

-chris



signature.asc
Description: OpenPGP digital signature

DO NOT REPLY [Bug 53115] New: catalina.bat run does not work is TEMP contains spaces

2012-04-20 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53115

 Bug #: 53115
   Summary: catalina.bat run does not work is TEMP contains spaces
   Product: Tomcat 7
   Version: 7.0.23
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: eugene.petre...@jetbrains.com
Classification: Unclassified


Under clean Windows XP, under Administrator account. 
Default temp dir is like c:\Documents and Settings\Admin\Local Settings\TEMP

In catalina.bat there is a temp dir check:
if ""%TEMP%"" ==  goto mainEntry

Actually, this command does not work if TEMP contains spaces. 
The right line is:
if ""%TEMP%"" ==  goto mainEntry

i.e. to avoid double quoting

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 53115] catalina.bat run does not work is TEMP contains spaces

2012-04-20 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53115

--- Comment #1 from Konstantin Kolinko  2012-04-20 
18:50:40 UTC ---
It is funny. I have WinXP. The "TEMP" variable is configured as

%USERPROFILE%\Local Settings\Temp

by default for the current user in the setting dialog (Win+Pause), but cmd
shows

> echo %TEMP%
C:\DOCUME~1\username\LOCALS~1\Temp

So the current catalina.bat already works for majority of Windows XP users,
including me.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Welcome file list in web.xml treats index.jsp different from other filenames

2012-04-20 Thread Konstantin Kolinko 
2012/4/20 Christopher Schultz :
> To whom it may concern,
>
> On 4/14/12 3:37 PM, Net Dawg wrote:
>> To your question as to "what point merging algorithms are not
>> followed", please try this inside your application context and you will
>> probably see the same:
>>
>>     
>>      
>>     
>>
>> This seems to tell Tomcat 7, in plain English, "there are no welcome
>> files, don't bother looking for them anywhere" ...
>
> You probably aren't getting a response because you didn't answer the
> question. Your opinion of how things should work isn't really relevant,
> here. Konstantin asked where Tomcat's behavior violates the servlet spec
> and you replied by telling him what you think ought to happen. That's
> not an answer, so you're being ignored.
>
> Can you find a place where your "seems to tell" scenario above is
> actually supported by language in the servlet specification? If so, tell
> us where. If the spec isn't clear on a subject, usually the safest thing
> to do is not change anything because users have become reliant on
> certain behavior. If and when the spec is clarified, a change will be made.
>

1. According to XSD, and as illustrated in Figure 14-9 on page #153
("175 of 230") of Servlet 3.0 Rev.a specification,  welcome-file-list
should contain at least one welcome-file element.

2. welcome-file type is xsd:string and said "contains file name to use
as a default welcome file".

So an empty string formally passes the XSD, but I nowhere see an
explicit saying on how to handle it.  It certainly is not a "file
name", but it passes the restriction of not having leading or trailing
'/'.

The algorithm in ch. 10.10 may work with empty strings (running a
fruitless loop - looking for a resource that is already known to not
exist), but I am not sure that it is a well-defined behaviour.

I'd be nice to have this clarified from the specification team (elsewhere).

3. According to chapter 8.1.6 (page #64, 86/230) of the same spec,
welcome file list defaults to contain index.htm(l) and index.jsp.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1326941 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/ha/session/ java/org/apache/catalina/tribes/tipis/ webapps/docs/

2012-04-20 Thread Konstantin Kolinko 
2012/4/19 Keiichi Fujino :
> 2012/4/19 Konstantin Kolinko :
>>
>> What happens if "repl" variable is true because of "complete" being true?
>> Shouldn't it be
>>    if (diff && (isDirty || complete))
>> ?
>>
>> I do not quite understand the code, but it seems that omitting
>> "complete" here will change its behaviour.
>>
>> E.g. DeltaSession.isDiffable() always returns true, and thus I think
>> the old "if(diff)" block was executed regardless of the value of
>> "complete".
>>
>>
>>>                 ReplicatedMapEntry rentry = 
>>> (ReplicatedMapEntry)entry.getValue();
>>
>> The above local variable could be moved outside this block, to avoid
>> multiple (instanceof) checks above.
>>
>
> Thanks for the review.
> You are right. My fix had changed former behavior.
> I applied your suggestion.
> "if (diff && (isDirty || complete))" block was executed regardless of
> the value of "complete".
>

OK.
After a few days I think there is more to it:

In case when (diffable == false, complete == true, isAccess == true),
I think "complete" has to take priority over "isAccess".

I think that in that case it has to create MSG_BACKUP message. Does
that message replicate session access time?

With the current code it creates MSG_ACCESS, because isAccess is checked first.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Resolving reference to commons-io-*[0-9T].jar file in a property

2012-04-20 Thread Konstantin Kolinko 
cc'ing dev@tomcat.

It is about dependency on  "commons-io-*[0-9T].jar" that caused
jakarta-tomcat-catalina (aka Tomcat 5.5) build on Gump to fail.


2012/4/20 Stefan Bodewig :
> On 2012-04-20, Bill Barker wrote:
>
>> This should be in the next Gump run on vmgump that will start at about
>> 12am GMT. This should fix the older Tomcat projects that want to copy
>> jars from other projects with glob names in the target project.
>
> Great.
>

Thank you, Bill!
The recent build [1] completed successfully.

[1] 
http://vmgump.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html

>> I could try and fix other Builders, but except for Ant, they don't
>> generally set properties on individual jar/output files that are
>> globbed.
>
> Let's leave it at that and patch the remaining builders once we need it.
>

Now that this feature works, I'll update "tomcat-tc7.0.x-validate"
target on Gump today
and will do the same for "tomcat-trunk-validate" tomorrow,
to remove hard-coded checkstyle version number there.

Just warning dev@ in advance in case it breaks.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

asp file and session creation

2012-04-20 Thread gunay arslan 
HI,

as the spec dictates every jsp file that specify session="true"  (this is 
default in tomcat  )  forces a new session to be created, wether or not we are 
using the session inside the jsp file.

the session is triggered for creation at PageContextImpl file, isn't 
meaningfull  to make this session creation on demand ? 
Most of the jsp files are using the session for checking an attribute presence, 
so creating a new session just for get operations  is a wast of memory.
do I miss something ? I am ready to do the development, maybe someone is 
working on this already ? 


best regards,
Gunay Arslan

Re: asp file and session creation

2012-04-20 Thread Konstantin Kolinko 
2012/4/21 gunay arslan :
> HI,
>
> as the spec dictates every jsp file that specify session="true"  (this is 
> default in tomcat  )  forces a new session to be created, wether or not we 
> are using the session inside the jsp file.
>
> the session is triggered for creation at PageContextImpl file, isn't 
> meaningfull  to make this session creation on demand ?

It is not possible, because (by specification) the JSP page (unless it
has session="false")  needs to have local variable named "session"
that can be used from
java fragments (aka scriptlets).

You cannot create a Java variable "on demand".

Note that there is "needsSession" attribute in
PageContextImpl#_initialize(..), which is not always true.


> Most of the jsp files are using the session for checking an attribute 
> presence, so creating a new session just for get operations  is a wast of 
> memory.
> do I miss something ? I am ready to do the development, maybe someone is 
> working on this already ?


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GUMP@vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) failed

2012-04-20 Thread Bill Barker 
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-tc7.0.x-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 8 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc7.0.x-test :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property 
tomcat-dbcp-src.jar.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
commons-daemon.native.src.tgz.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
tomcat-native.tar.gz.
 -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property 
tomcat-dbcp.home.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-7.0.x/output/build/logs



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html
Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 21 mins 54 secs
Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only org.apache.tools.ant.Main 
-Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-21042012.jar 
-Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-21042012-native-src.tar.gz
 
-Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-21042012-native-src.tar.gz
 -Dexamples.sources.skip=true 
-Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar
 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-21042012.jar
 
-Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar
 -Dtest.accesslog=true 
-Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x 
-Dcommons-dbcp.home=/
 srv/gump/public/workspace/commons-dbcp-1.x 
-Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-21042012.jar
 test 
[Working Directory: /srv/gump/public/workspace/tomcat-7.0.x]
CLASSPATH: 
/usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/outp
 
ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-7.
 
0.x/tomcat-deps/tomcat-dbcp-21042012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-21042012.jar:

[GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed

2012-04-20 Thread Bill Barker 
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-trunk-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 5 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-trunk-test :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property 
tomcat-dbcp-src.jar.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
commons-daemon.native.src.tgz.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
tomcat-native.tar.gz.
 -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property 
tomcat-dbcp.home.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-trunk/output/build/logs



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.html
Work Name: build_tomcat-trunk_tomcat-trunk-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 22 mins 29 secs
Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only org.apache.tools.ant.Main 
-Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-21042012.jar 
-Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-21042012-native-src.tar.gz
 
-Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-21042012-native-src.tar.gz
 -Dexamples.sources.skip=true 
-Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar
 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-21042012.jar
 
-Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-src.jar
 -Dtest.accesslog=true 
-Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x 
-Dcommons-dbcp.home=/
 srv/gump/public/workspace/commons-dbcp-1.x 
-Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-21042012.jar
 test 
[Working Directory: /srv/gump/public/workspace/tomcat-trunk]
CLASSPATH: 
/usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-trunk/outp
 
ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-jni.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/packages/eclipse/plugins/org
 
.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-21042012.jar:/srv/gump/public/workspace

Re: asp file and session creation

2012-04-20 Thread gunay arslan 
HI Konstantin,Seems like I could not explain what exactly I was trying to show. A reference implementation of the PageContextImpl is attached, and I tested this with one of our in-house web application.The point is  1) Spec says that a session variable needs to be present: but this creates a  problem for the web applications, as a simple attack to a web application can force creation of dummy sessions, filling the memory. Most of the applications are using some sort of persistent session management, which is another problem, as this increases the processing time , for these dummy sessions.2) Most of the applications do not use the session inside the jsp , so why to create a new session  , before it is needed ?? Maybe we can name the definition LAZY_SESSION_CREATION ?? 3) Most of the applications , do not create a session in the jsp, the session is created  at the servlet level, and just checked for attribute presence at the jsp level.My point is to reduce the number of "useless created sessions",  the same problem was described at http://www.tomcatexpert.com/blog/2011/05/18/crawler-session-manager-valve , showing a simple solution, but this solution does not solve the real problem.

PageContextImpl.java
Description: Binary data
best regards,Gunay ArslanOn Apr 21, 2012, at 1:48 AM, Konstantin Kolinko wrote:2012/4/21 gunay arslan :HI,as the spec dictates every jsp file that specify session="true"  (this is default in tomcat  )  forces a new session to be created, wether or not we are using the session inside the jsp file.the session is triggered for creation at PageContextImpl file, isn't meaningfull  to make this session creation on demand ?It is not possible, because (by specification) the JSP page (unless ithas session="false")  needs to have local variable named "session"that can be used fromjava fragments (aka scriptlets).You cannot create a Java variable "on demand".Note that there is "needsSession" attribute inPageContextImpl#_initialize(..), which is not always true.Most of the jsp files are using the session for checking an attribute presence, so creating a new session just for get operations  is a wast of memory.do I miss something ? I am ready to do the development, maybe someone is working on this already ?Best regards,Konstantin Kolinko-To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.orgFor additional commands, e-mail: dev-h...@tomcat.apache.org