Author: markt
Date: Tue Jul 13 16:02:09 2010
New Revision: 963776

URL: http://svn.apache.org/viewvc?rev=963776&view=rev
Log:
Sign the pom.
Make sure source jar signature doesn't overwrite the non-source jar signature.

Modified:
  tomcat/trunk/res/maven/mvn-pub.xml

Modified: tomcat/trunk/res/maven/mvn-pub.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn-pub.xml?rev=963776&r1=963775&r2=963776&view=diff
==============================================================================
--- tomcat/trunk/res/maven/mvn-pub.xml (original)
+++ tomcat/trunk/res/maven/mvn-pub.xml Tue Jul 13 16:02:09 2010
@@(protected) @@
 <target name="maven-deploy" depends="init-maven">
  <!--cleanup-->
  <delete file="${pom}.tmp"/>
+   <delete file="${pom}.asc"/>
  <delete file="${file}.asc"/>
  <delete file="${src}.asc"/>

@@(protected) @@
    </filterset>
  </copy>
 
-   <!--sign the jar-->
+   <!--sign the jar, the source and the pom -->
  <exec executable="${maven.gpg.exec}" failonerror="true" inputstring="${maven.gpg.passphrase}">
    <arg value="--passphrase-fd"/>
    <arg value="0"/>
@@(protected) @@
    <arg value="-b"/>
    <arg value="${src}"/>
  </exec>
+   <exec executable="${maven.gpg.exec}" failonerror="true" inputstring="${maven.gpg.passphrase}">
+    <arg value="--passphrase-fd"/>
+    <arg value="0"/>
+    <arg value="-a"/>
+    <arg value="-b"/>
+    <arg value="-o"/>
+    <arg value="${pom}.asc"/>
+    <arg value="${pom}.tmp"/>
+   </exec>
 
  <!--deploy it-->
  <artifact:deploy file="${file}">
@@(protected) @@
     </remoteRepository>
     <attach file="${file}.asc" type="jar.asc"/>
     <attach file="${src}" classifier="sources" type="jar"/>
-     <attach file="${src}.asc" type="jar.asc"/>
+     <attach file="${src}.asc" classifier="sources" type="jar.asc"/>
+     <attach file="${pom}.asc" type="pom.asc"/>
  </artifact:deploy>

  <delete file="${pom}.tmp"/>
+   <delete file="${pom}.asc"/>
  <delete file="${file}.asc"/>
  <delete file="${src}.asc"/>
 </target>
@@(protected) @@
 <target name="maven-deploy-nosrc" depends="init-maven">
  <!--cleanup-->
  <delete file="${pom}.tmp"/>
+   <delete file="${pom}.asc"/>
  <delete file="${file}.asc"/>

  <!--replace the version in the pom-->
@@(protected) @@
    </filterset>
  </copy>
   
-   <!--sign the jar-->
+   <!--sign the jar and pom -->
  <exec executable="${maven.gpg.exec}" failonerror="true" inputstring="${maven.gpg.passphrase}">
    <arg value="--passphrase-fd"/>
    <arg value="0"/>
@@(protected) @@
    <arg value="-b"/>
    <arg value="${file}"/>
  </exec>
+   <exec executable="${maven.gpg.exec}" failonerror="true" inputstring="${maven.gpg.passphrase}">
+    <arg value="--passphrase-fd"/>
+    <arg value="0"/>
+    <arg value="-a"/>
+    <arg value="-b"/>
+    <arg value="-o"/>
+    <arg value="${pom}.asc"/>
+    <arg value="${pom}.tmp"/>
+   </exec>
   
  <!--deploy it-->
  <artifact:deploy file="${file}">
@@(protected) @@
     <authentication username="${maven.scp.username}" privateKey="${maven.scp.privateKey}" passphrase="${maven.scp.passphrase}"/>
    </remoteRepository>
  <attach file="${file}.asc" type="jar.asc"/>
+    <attach file="${pom}.asc" type="pom.asc"/>
  </artifact:deploy>

  <delete file="${pom}.tmp"/>
+   <delete file="${pom}.asc"/>
  <delete file="${file}.asc"/>
 </target>

https://issues.apache.org/bugzilla/show_bug.cgi?id=49402

Rainer Jung <rainer.jung@(protected):

      What   |Removed              |Added
----------------------------------------------------------------------------
        Status|NEW                 |RESOLVED
     Resolution|                   |FIXED

--- Comment #1 from Rainer Jung <rainer.jung@(protected) ---
Those artifacts should have been different. The artifacts for 6.0.28 are OK
now.

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=49402

--- Comment #2 from Marc Guillemot <mguillemot@(protected) ---
In fact for 6.0.28 org.apache.tomcat.extras juli still contains the content of
org.apache.tomcat juli.

Is it intentional? This looks strange to 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.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49402

--- Comment #3 from Rainer Jung <rainer.jung@(protected) ---
I definitely don't know enough about maven, but I checked the following places:

In directory
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/tomcat of
the ASF distribution host people.apache.org I find:

$ ls -l extras/juli/6.0.28/juli-6.0.28.jar juli/6.0.28/juli-6.0.28.jar
... 62756 Jul 9 20:46 extras/juli/6.0.28/juli-6.0.28.jar
... 26484 Jul 9 20:45 juli/6.0.28/juli-6.0.28.jar

And on the web I checked:

http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/juli/6.0.28/

juli-6.0.28.jar                   09-Jul-2010 16:45  26K

and

http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/extras/juli/6.0.28/

juli-6.0.28.jar                        09-Jul-2010 16:46  61K

So the 2 jars are different and correct at least at those places. Don't know
your source for the jars or your md5 or similar though :(

Regards,

Rainer

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=49402

--- Comment #4 from Rainer Jung <rainer.jung@(protected) ---
... and the timestamps of the directories on people.apache.org are:

... 12 Jul 11 08:34 extras/juli/6.0.28/
... 12 Jul 11 08:34 juli/6.0.28/

I don't know how long replication takes.

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=49402

--- Comment #5 from Marc Guillemot <mguillemot@(protected) ---
Seems that I haven't been clear in my question. I try again.

http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/extras/juli/6.0.28/juli-6.0.28.jar
contains classes from following packages:
org.apache.juli
org.apache.juli.logging
org.apache.juli.logging.impl

and
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/juli/6.0.28/juli-6.0.28.jar
contains classes from following packages
org.apache.juli
org.apache.juli.logging

This means (as far as I can see, I haven't verified each single class file)
that the classes from packages org.apache.juli and org.apache.juli.logging are
in both jars.
In other words, this means that the second jar is useless when you use the
first one.

Are these duplications intended?

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=49402

--- Comment #6 from Rainer Jung <rainer.jung@(protected) ---
In previous versions of TC 6 the jars in the maven repos were indeeed
*identical*. I assume you really referred to that problem when you wrote
"Exactly (look at the md5) the same juli.jar" in your original report.

The different observation you are now referring to, namely that some classes in
the two jars are identical, is right and that's intended:

The non-extras jar contains a self-contained implementation of Tomcat JULI
logging linking directly to the JDK logging. The extras jars contain an
alternative implementation, namely a repackaged commons-logging. The
repackaging helps in avoiding conflicts with webapp provided commons-logging.

More information is contained in the docs:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html

Regards,

Rainer

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=49402

--- Comment #7 from Marc Guillemot <mguillemot@(protected) ---
Thanks for the explanation.

This packaging choice is a bit strange as a dependency between two jars without
intersection would be a more "natural maven way" but why not...

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=46350

--- Comment #4 from Rainer Jung <rainer.jung@(protected) ---
Source artifacts are now provided for Tomcat 7.
We'll see whether and when this gets backported to TC 6.

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=49591

      Summary: Custom error page always uses Transfer-Encoding:
            chunked
      Product: Tomcat 7
      Version: 7.0.0
      Platform: PC
    OS/Version: Windows XP
       Status: NEW
      Severity: enhancement
      Priority: P2
     Component: Catalina
    AssignedTo: dev@(protected)
    ReportedBy: kmoon@(protected)


Created an attachment (id=25759)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25759)
Small JSP which should easily fit in the output buffer.

When using a small custom error JSP page (which easily fits in the output
buffer, and so would not usually require chunking), error responses always use
chunked encoding, while non-error responses do not.

For example, visiting a missing resource (resulting in a 404) serves the error
page as chunked, while visiting the error page directly (resulting in a 200)
serves the error page without chunking.

Static resources are always served unchunked.

I would like to request that a custom error JSP is not served chunked if it
fits entirely within the output buffer, just like a regular JSP would. While
not a bug, I like to avoid chunked encoding (and the extra flushes involved)
whenever possible.

I initially encountered this issue in 6.0.24, but verified it is still present
in 7.0.0, and the source code seems unchanged in the trunk.

To replicate this issue, I modified the ROOT webapp of a fresh 7.0.0 install as
follows:

1. I added these lines to webapps/ROOT/WEB-INF/web.xml:

<error-page>
  <error-code>404</error-code>
  <location>/404.jsp</location>
</error-page>

2. I added the attached 404.jsp to webapps/ROOT/.

3. I visited http://localhost:8080/404 and received a chunked response.

4. I visited http://localhost:8080/404.jsp and received an unchunked response.

Stepping through the code, I discovered that the issue seems to be caused by a
flushBuffers() call in
org.apache.catalina.core.StandardHostValve.status(Request, Response). The code
looks something like this:

if (custom(request, response, errorPage)) {
   try {
      response.flushBuffer();
   } catch (ClientAbortException e) {
      // Ignore
   } catch (IOException e) {
      container.getLogger().warn("Exception Processing " + errorPage, e);
   }
}

A normal page doesn't flush buffers until finishResponse() occurs, at which
point it can decide to set the content length or use chunked encoding. Flushing
earlier than that triggers chunked encoding (if possible).

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

I had a look at BZ46451. It suggests adding subversion properties to
enable the use of subversion bugtraq. This allows a better integration
of BZ into subversion commit messages and retrieval when looking at svn
logs.

There is a blog here

http://markphip.blogspot.com/2007/01/integrating-subversion-with-your-issue.html

and the spec is here:

http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/issuetrackers.txt

(password guest).

The feature is optional, i.e. you don't have to use it. If you do use it
with subclipse or turtoisesvn it works as follows:

- the subversion clients allows to enter the bugzila id in a separate field

- it adds a final line to the commit message with a configured fixed
content plus inserted issue id (e.g. "BZ %BUGID%" leads to "BZ 45678"
when 45678 is provided as issue id during commit).

- since it knows the formatting of such messages, the client extracts
the id when showing svn log messages and provides links to the correct
BZ issue. The link URL is configurable, e.g.
https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID%.

You can of course support the later feature even when not using the
above mentioned client by using the same formatting when providing a BZ
id in a log message.

Alternatively one can provide a regexp to extract the ID from a log
message. In this case you would provide the id still as part of the
usual log message, even when using subclipse or turtoise.

Multiple issues are always allowed, issue IDs will be separated by commas.

The implementation uses a few properties entered into subversion. The
client searches for the properties from the current working copy
directory up to the root of the working directory (not: the root of the
repository). So adding the properties only to the the trunk directories
should work fine.

There are open issues for viewvc and hudson to suppot the feature too,
but no advances on those feature requests in the last two years.
Nevertheless support from subclipse and turtoise might already make it
useful. At least I would find it useful :) similar to Mark's formatting
addition for svn revision URLs in Bugzilla.

Using it should be transparent, we don't loose anything becaue the info
is added to the svn log message in normal textual form. Of course if
nobody uses it, we don't gain much either. I actually expect the pattern
based feature to be more attractive, something like

\b[bB][zZ]\s*(\d+)\b

would already find a lot of issue numbers in the existing svn log
entries. There is an extended way one can use to be able to actually
find multiple numbers but the expression could evolve over time.

Comments?

Regards,

Rainer

On 13/07/2010 19:57, Rainer Jung wrote:
> I had a look at BZ46451. It suggests adding subversion properties to
> enable the use of subversion bugtraq. This allows a better integration
> of BZ into subversion commit messages and retrieval when looking at svn
> logs.

> Comments?

I was playing with this a while ago here:
http://svn.apache.org/viewvc/tomcat/sandbox/bz-svn/

Feel free to play with the settings there.

I don't recall why I lost interest in this but if you can get it working +1.

Mark

On 13.07.2010 22:11, Mark Thomas wrote:
> On 13/07/2010 19:57, Rainer Jung wrote:
>> I had a look at BZ46451. It suggests adding subversion properties to
>> enable the use of subversion bugtraq. This allows a better integration
>> of BZ into subversion commit messages and retrieval when looking at svn
>> logs.
>
>> Comments?
>
> I was playing with this a while ago here:
> http://svn.apache.org/viewvc/tomcat/sandbox/bz-svn/
>
> Feel free to play with the settings there.
>
> I don't recall why I lost interest in this but if you can get it working +1.

I did a little mining for the trunk log and now have a regexp that seems
to work pretty well. It finds about 1000 bug references (as far as I can
see correctly) and misses about 30, many of those are not direct
references. Those first tests I did using perl and parsing the log output.

For further testing I used turtoisesvn, checked out trunk, and added the
properties to my local repository without committing them. That's
enough, because the properties are looked after only in the working copy.

I used the following properties:

bugtraq:url

https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID%

bugtraq:number

yes

bugtraq:label

BZ

bugtraq:logregex

(^|\W)(issues\.apache\.org\/bugzilla\/show_bug\.cgi\?id=|Buzilla|bugzilla|BZ|bz|pr|PR|bug|Bug|Fix|fix|fix
of|Fix of|fix for|Fix for|patch for|Patch
for|issue|Issue|defect|Defect|fixed|Fixed|^\-?)[\:#\-\s]*(\d{3,})
(\d{3,})

For the last property it is important, that everything except for the
final "(\d{3,})" is in one line, and only this part is on the second line.

When I now look at the log with turtoise I have a new column named "BZ"
containing the IDs if found, even containing multiple ones if there are
multiple references, and if one opens a log entry with such a reference,
the matched part in the log is a hyperlink to the issue.

So: seems to work well. The regexp is maybe a bit complicated, but it
finds most bug references, and at least turtoise still seems to be fast
when showing the log.

Anyone trying with eclipe?

I will wait a bit and if no one opposes, I will commit the properties.
If someone has a problem later, we can easily remove them again.

Keep in mind, that since we are using a regexp, you will still have to
enter the issue ID when preparing a new log message.

Regards,

Rainer

https://issues.apache.org/bugzilla/show_bug.cgi?id=48960

--- Comment #7 from Yair Lenga <yair.lenga@(protected) ---
Created an attachment (id=25760)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25760)
Patch to disable exec by default, new allowExec tag

Patch for three files, created against 6.0.26-src

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=48960

--- Comment #8 from Mark Thomas <markt@(protected) ---
The diff is inverted and the patch is using tabs rather than spaces. I should
eb able to work with that but you might need to fix it.

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=48960

--- Comment #9 from Mark Thomas <markt@(protected) ---
In the end I used the patch a guide and write a new one. Some additional
comments:
- if you do an svn diff against a normal source tree patches usually apply
cleanly
- new features should be documented

The patch has been applied to truck and proposed for 6.0.x

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=48960

--- Comment #10 from Yair Lenga <yair.lenga@(protected) ---
Mark,

Thanks for taking the change. I'll follow you suggestions regarding svn diff
for the next time.

Do I have to submit anything for the change to flow to 7.X ?

Yair

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

https://issues.apache.org/bugzilla/show_bug.cgi?id=48960

--- Comment #11 from Mark Thomas <markt@(protected) ---
Sorry truck should have been trunk and trunk == 7.0.x so it is already there.

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

On 13/07/2010 15:51, Mark Thomas wrote:
> On 13/07/2010 13:43, Mark Thomas wrote:
>> On 13/07/2010 13:12, Gurkan Erdogdu wrote:
>>> Hello Mark;
>>>
>>> Where is the location? Not able to find
>>
>> http://repo2.maven.org/maven2/org/apache/tomcat/
>>
>> It looks like the script we have for generating stuff isn't quite right.
>> Henk runs a script that regularly scans the repo for errors and it
>> picked up quite a few with Tomcat 7. I'll see what I can do to fix them
>> but we might end up with some errors remaining for 7.0.0
>
> I know what went wrong and am currently trying to fix it. I'm using the
> snapshot repo as a test bed since that needs fixing too. It does mean
> that the snapshot repo is going to get deleted and recreated a few times
> in the process. I'll drop another note to the list when it is stable again.

The 7.0 snapshot is now stable. Also using a new version number of 7.0
rather than 7.0.0. That seemed to make more sense for the snapshots
since you end up with 7.0-timestamp

On to fixing the 7.0.0 files...

Mark

Author: markt
Date: Tue Jul 13 21:35:39 2010
New Revision: 963868

URL: http://svn.apache.org/viewvc?rev=963868&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48960
Disable exec by default in SSI and provide an option to enable it for both Servlet and Filter

Modified:
  tomcat/trunk/conf/web.xml
  tomcat/trunk/java/org/apache/catalina/ssi/SSIFilter.java
  tomcat/trunk/java/org/apache/catalina/ssi/SSIProcessor.java
  tomcat/trunk/java/org/apache/catalina/ssi/SSIServlet.java
  tomcat/trunk/webapps/docs/changelog.xml
  tomcat/trunk/webapps/docs/ssi-howto.xml

Modified: tomcat/trunk/conf/web.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/conf/web.xml?rev=963868&r1=963867&r2=963868&view=diff
==============================================================================
--- tomcat/trunk/conf/web.xml (original)
+++ tomcat/trunk/conf/web.xml Tue Jul 13 21:35:39 2010
@@(protected) @@
 <!--                                               -->
 <!--  outputEncoding    The encoding to use for the page that results -->
 <!--               from the SSI processing. [UTF-8]          -->
+ <!--                                               -->
+ <!--  allowExec       Is use of the exec command enabled? [false]   -->

<!--
  <servlet>
@@(protected) @@
 <!--               Should "virtual" paths be interpreted as     -->
 <!--               relative to the context root, instead of     -->
 <!--               the server root? (0=false, 1=true) [0]     -->
+ <!--                                               -->
+ <!--  allowExec       Is use of the exec command enabled? [false]   -->

<!--
  <filter>

Modified: tomcat/trunk/java/org/apache/catalina/ssi/SSIFilter.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ssi/SSIFilter.java?rev=963868&r1=963867&r2=963868&view=diff
==============================================================================
--- tomcat/trunk/java/org/apache/catalina/ssi/SSIFilter.java (original)
+++ tomcat/trunk/java/org/apache/catalina/ssi/SSIFilter.java Tue Jul 13 21:35:39 2010
@@(protected)
 /** default pattern for ssi filter content type matching */
 protected Pattern shtmlRegEx =
     Pattern.compile("text/x-server-parsed-html(;.*)?");
+  /** Allow exec (normally blocked for security) */
+  protected boolean allowExec = false;


  //----------------- Public methods.
@@(protected)
     if (config.getInitParameter("expires") != null)
        expires = Long.valueOf(config.getInitParameter("expires"));

+     allowExec = Boolean.parseBoolean(config.getInitParameter("allowExec"));
+
     if (debug > 0)
        config.getServletContext().log(
             "SSIFilter.init() SSI invoker started with 'debug'=" + debug);
@@(protected)
          new SSIServletExternalResolver(config.getServletContext(), req,
                res, isVirtualWebappRelative, debug, encoding);
        SSIProcessor ssiProcessor = new SSIProcessor(ssiExternalResolver,
-             debug);
+             debug, allowExec);
       
        // prepare readers/writers
        Reader reader =

Modified: tomcat/trunk/java/org/apache/catalina/ssi/SSIProcessor.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ssi/SSIProcessor.java?rev=963868&r1=963867&r2=963868&view=diff
==============================================================================
--- tomcat/trunk/java/org/apache/catalina/ssi/SSIProcessor.java (original)
+++ tomcat/trunk/java/org/apache/catalina/ssi/SSIProcessor.java Tue Jul 13 21:35:39 2010
@@(protected) {
  protected HashMap<String,SSICommand> commands =
     new HashMap<String,SSICommand>();
  protected int debug;
+   protected final boolean allowExec;


-   public SSIProcessor(SSIExternalResolver ssiExternalResolver, int debug) {
+   public SSIProcessor(SSIExternalResolver ssiExternalResolver, int debug,
+        boolean allowExec) {
     this.ssiExternalResolver = ssiExternalResolver;
     this.debug = debug;
+     this.allowExec = allowExec;
     addBuiltinCommands();
  }

@@(protected) {
  protected void addBuiltinCommands() {
     addCommand("config", new SSIConfig());
     addCommand("echo", new SSIEcho());
-     addCommand("exec", new SSIExec());
+     if (allowExec) {
+        addCommand("exec", new SSIExec());
+     }
     addCommand("include", new SSIInclude());
     addCommand("flastmod", new SSIFlastmod());
     addCommand("fsize", new SSIFsize());

Modified: tomcat/trunk/java/org/apache/catalina/ssi/SSIServlet.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ssi/SSIServlet.java?rev=963868&r1=963867&r2=963868&view=diff
==============================================================================
--- tomcat/trunk/java/org/apache/catalina/ssi/SSIServlet.java (original)
+++ tomcat/trunk/java/org/apache/catalina/ssi/SSIServlet.java Tue Jul 13 21:35:39 2010
@@(protected)
  protected String inputEncoding = null;
  /** Output encoding. If not specified, uses platform default */
  protected String outputEncoding = "UTF-8";
+   /** Allow exec (normally blocked for security) */
+   protected boolean allowExec = false;


  //----------------- Public methods.
@@(protected)
     if (getServletConfig().getInitParameter("outputEncoding") != null)
        outputEncoding = getServletConfig().getInitParameter("outputEncoding");
     
+     allowExec = Boolean.parseBoolean(
+           getServletConfig().getInitParameter("allowExec"));
+
     if (debug > 0)
        log("SSIServlet.init() SSI invoker started with 'debug'=" + debug);

@@(protected)
        new SSIServletExternalResolver(getServletContext(), req, res,
             isVirtualWebappRelative, debug, inputEncoding);
     SSIProcessor ssiProcessor = new SSIProcessor(ssiExternalResolver,
-           debug);
+           debug, allowExec);
     PrintWriter printWriter = null;
     StringWriter stringWriter = null;
     if (buffered) {

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=963868&r1=963867&r2=963868&view=diff
==============================================================================
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Tue Jul 13 21:35:39 2010
@@(protected) @@
     <bug>48297</bug>: Correctly initialise handler chain for web services
     resources. (markt)
    </fix>
+    <add>
+     <bug>48960</bug>: Add a new option to the SSI Servlet and SSI Filter to
+     allow the disabling of the <code>exec</code> command. This is now
+     disabled by default. Based on a patch by Yair Lenga. (markt)
+    </add>
    <fix>
     <bug>49030</bug>: When initializing/starting/stopping connectors and
     one of them fails, do not ignore the others. (markt/kkolinko)

Modified: tomcat/trunk/webapps/docs/ssi-howto.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/ssi-howto.xml?rev=963868&r1=963867&r2=963868&view=diff
==============================================================================
--- tomcat/trunk/webapps/docs/ssi-howto.xml (original)
+++ tomcat/trunk/webapps/docs/ssi-howto.xml Tue Jul 13 21:35:39 2010
@@(protected)
the default platform encoding.</li>
<li><strong>outputEncoding</strong> - The encoding to be used for the result
of the SSI processing. Default is UTF-8.</li>
+<li><strong>allowExec</strong> - Is the exec command enabled? Default is
+false.</li>
</ul>
</p>

@@(protected)>
<li><strong>isVirtualWebappRelative</strong> - Should "virtual" SSI directive
paths be interpreted as relative to the context root, instead of the server
root? (0=false, 1=true) Default 0 (false).</li>
+<li><strong>allowExec</strong> - Is the exec command enabled? Default is
+false.</li>
</ul>
</p>

Author: markt
Date: Tue Jul 13 21:38:28 2010
New Revision: 963870

URL: http://svn.apache.org/viewvc?rev=963870&view=rev
Log:
Proposal

Modified:
  tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=963870&r1=963869&r2=963870&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Jul 13 21:38:28 2010
@@(protected):
 http://svn.apache.org/viewvc?rev=963106&view=rev
 +1: markt
 -1:
+
+* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48960
+ Disable exec in SSI by default and provide new option to enable it
+ http://svn.apache.org/viewvc?rev=963868&view=rev
+ +1: markt
+ -1:

2010/7/14 Alexander Shirkov <sgdread@(protected)>:
>
> I really need advice and guidance: where to start my path.
>

Hi, Alexander!

You are welcome. Here are some links:

http://tomcat.apache.org/getinvolved.html

http://tomcat.apache.org/tomcat-7.0-doc/building.html
http://tomcat.apache.org/tomcat-7.0-doc/BUILDING.txt

Best regards,
Konstantin Kolinko

Thanks, Konstantin

I already checked out, and setted up dev environment. Also I've read "How
Apache works" etc. I know, how to do patches, I have a lot of experience
with Tomcat, but mostly as user.

I've seen a lot of Bugzilla entries, but there are a lot of them in
database, so I don't know, where to start. If someone has issues, which can
be handled to novice, please send them to me (I understand, that without app
knowledge I can't do complex works, but I'm ready to do "dirty" jobs as
well). Only exception - official documentation writing (I'm not native
English speaker, so my writing skills are poor).

Kind Regards,
Alexander Shirkov

On 14.07.10 1:57, "Konstantin Kolinko" <knst.kolinko@(protected):

> 2010/7/14 Alexander Shirkov <sgdread@(protected)>:
>>
>> I really need advice and guidance: where to start my path.
>>
>
> Hi, Alexander!
>
> You are welcome. Here are some links:
>
> http://tomcat.apache.org/getinvolved.html
>
> http://tomcat.apache.org/tomcat-7.0-doc/building.html
> http://tomcat.apache.org/tomcat-7.0-doc/BUILDING.txt
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@(protected)
> For additional commands, e-mail: dev-help@(protected)
>

On 14/07/2010 20:38, Alexander Shirkov wrote:
> Thanks, Konstantin
>
> I already checked out, and setted up dev environment. Also I've read "How
> Apache works" etc. I know, how to do patches, I have a lot of experience
> with Tomcat, but mostly as user.
>
> I've seen a lot of Bugzilla entries, but there are a lot of them in
> database, so I don't know, where to start. If someone has issues, which can
> be handled to novice, please send them to me (I understand, that without app
> knowledge I can't do complex works, but I'm ready to do "dirty" jobs as
> well). Only exception - official documentation writing (I'm not native
> English speaker, so my writing skills are poor).

General comments:
- Where appropriate provide patches against the latest 7.0.x code
- Patches should be in diff -u format against the standard source tree
(svn should do this for you)

Here are some to get started along with some comments based on a *very*
quick review of the code:

1. https://issues.apache.org/bugzilla/show_bug.cgi?id=49591
Look in the svn history for the quoted code to see why the call to
response.flushBuffer() was added in the first place. [1] is useful for
this. It may well be there is a good reason for the current behaviour.

2. https://issues.apache.org/bugzilla/show_bug.cgi?id=49589
Could be simple (remove the call(s) that trigger the re-initialisation)
/ could be tricky (the JSP generation code often is).

3. https://issues.apache.org/bugzilla/show_bug.cgi?id=49428
The patch needs work - it doesn't add D: to all the elements. Use the
litmus test suite to check.

4. https://issues.apache.org/bugzilla/show_bug.cgi?id=49165
Could be performance sensitive.

Hope that is enough to get you started. Just ask a question on the dev
list if you need help.

Mark

[1] http://svn.apache.org/viewvc/tomcat/trunk/


>
> Kind Regards,
> Alexander Shirkov
>
> On 14.07.10 1:57, "Konstantin Kolinko" <knst.kolinko@(protected):
>
>> 2010/7/14 Alexander Shirkov <sgdread@(protected)>:
>>>
>>> I really need advice and guidance: where to start my path.
>>>
>>
>> Hi, Alexander!
>>
>> You are welcome. Here are some links:
>>
>> http://tomcat.apache.org/getinvolved.html
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/building.html
>> http://tomcat.apache.org/tomcat-7.0-doc/BUILDING.txt
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@(protected)
>> For additional commands, e-mail: dev-help@(protected)
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@(protected)
> For additional commands, e-mail: dev-help@(protected)
>

Author: kkolinko
Date: Wed Jul 14 06:24:18 2010
New Revision: 963956

URL: http://svn.apache.org/viewvc?rev=963956&view=rev
Log:
vote

Modified:
  tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=963956&r1=963955&r2=963956&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Jul 14 06:24:18 2010
@@(protected):
 classes
 http://svn.apache.org/viewvc?rev=961948&view=rev
 http://svn.apache.org/viewvc?rev=963106&view=rev
- +1: markt
+ +1: markt, kkolinko
 -1:

* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48960
 Disable exec in SSI by default and provide new option to enable it
 http://svn.apache.org/viewvc?rev=963868&view=rev
- +1: markt
+ +1: markt, kkolinko
 -1:

https://issues.apache.org/bugzilla/show_bug.cgi?id=49401

Mark Thomas <markt@(protected):

      What   |Removed              |Added
----------------------------------------------------------------------------
        Status|NEW                 |RESOLVED
     Resolution|                   |WONTFIX

--- Comment #1 from Mark Thomas <markt@(protected) ---
The code runs on context stop. Differentiating between a context stop and a
container stop is going to be tricky and likely to add more complexity than
benefit gained.

For a well behaved web application (that doesn't leak memory on reload) on a
recent JVM there should be no problems with setting:
WebappClassLoader.ENABLE_CLEAR_REFERENCES=false

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

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.

The "PoweredBy" page has been changed by Bruno.
http://wiki.apache.org/tomcat/PoweredBy?action=diff&rev1=261&rev2=262

--------------------------------------------------

{{http://www.metawerx.net/images/logo/logo256smlspc.gif}} [[http://www.metawerx.net/default2.htm|MetaWerx.net]] - Australia's first and largest Java hosting provider

=== SempiHost ===
- {{http://www.sempihost.com.br/images/logo-sempihost.jpg}} [[http://www.sempihost.com.br/|SempiHost - Hospedagem de Sites]] provides webhosting with JSP/Servlets support using Tomcat 5.0, 5.5 and 6.0.
+ {{http://www.sempihost.com.br/images/logo-sempihost.jpg}} [[http://www.sempihost.com.br/|Hospedagem de Sites]] provides webhosting with JSP/Servlets support using Tomcat 5.0, 5.5 and 6.0.

=== MIVITEC GmbH (German Internet Service Provider) ===
{{http://mivitec.de/mirsky-new/mivitec_web.gif}} [[http://www.mivitec.de|MIVITEC GmbH - ISP from Germany / Munich]] - One of the leading business hosting providers in Germany, uses Tomcat and Tomcat clusters for client's sites, CMS systems like OpenCMS and Magnolia etc.

Author: kkolinko
Date: Wed Jul 14 13:54:43 2010
New Revision: 964049

URL: http://svn.apache.org/viewvc?rev=964049&view=rev
Log:
Add myself to the list.

Modified:
  tomcat/trunk/webapps/docs/developers.xml

Modified: tomcat/trunk/webapps/docs/developers.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/developers.xml?rev=964049&r1=964048&r2=964049&view=diff
==============================================================================
--- tomcat/trunk/webapps/docs/developers.xml (original)
+++ tomcat/trunk/webapps/docs/developers.xml Wed Jul 14 13:54:43 2010
@@(protected) @@
    <li>Filip Hanik (fhanik): Clustering, Release Manager</li>
    <li>Jean-Frederic Clere (jfclere): Connectors</li>
    <li>Jim Jagielski (jim): Connectors</li>
+    <li>Konstantin Kolinko (kkolinko): Catalina</li>
    <li>Mark Thomas (markt): CGI, SSI, WebDAV, bug fixing</li>
    <li>Mladen Turk (mturk): Connectors</li>
    <li>Peter Rossbach (pero): Catalina, Clustering, JMX</li>