date:20130708

[jira] [Commented] (MTOMCAT-230) CLONE - Plugin uploads WAR file twice

2013-07-08 Thread Rainer Jung (JIRA)


[ 
https://issues.apache.org/jira/browse/MTOMCAT-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701837#comment-13701837
 ] 

Rainer Jung commented on MTOMCAT-230:
-

OK, your workers.properties are pretty minimal but shouldn't pose problems. A 
more production ready config can ba found in the mod_jk source download or in 
subversion under

http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/workers.properties?view=co

and

http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/httpd-jk.conf?view=co

At least "recovery_options" should be considered.

You are using the peruser MPM, not sure what implications that could have.

apache2/access_log

127.0.0.1 - - [08/Jul/2013:11:46:41 +0700] "PUT 
/manager/text/deploy?path=%2F&update=true HTTP/1.1" 401 2474
127.0.0.1 - - [08/Jul/2013:11:46:42 +0700] "PUT 
/manager/text/deploy?path=%2F&update=true HTTP/1.1" 200 90

The first request with status code 401 needed an authorization which was then 
passed in the second request. So from the apache point of view there was only 
one "real" request (the second one, the first one was rejected).

apache/mod_jk.log


[Mon Jul 08 11:45:12.052 2013] [10703:139858959705920] [error] 
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name 
'ajp13' in uri map post processing.

This indicates, that somewhere else in your config (not presented to us), you 
configured a forwarding via a worker named "ajp13" (or unnamed), which is not 
present in your workers.properties. That shouldn't be related to the double 
upload though.

The next lines indicate, that there is more config you didn't show 
(JkRequestLogFormat):

[Mon Jul 08 11:46:42.023 2013] worker1 localhost 0.414589
[Mon Jul 08 11:46:58.403 2013] worker1 localhost 16.366236

Apart from these comments I don't see anything special here, no indication, 
that mod_jk does a double post. You could check the Tomcat access log file.

> CLONE - Plugin uploads WAR file twice
> -
>
> Key: MTOMCAT-230
> URL: https://issues.apache.org/jira/browse/MTOMCAT-230
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>  Components: tomcat6
>Affects Versions: 2.0
> Environment: Win7/64, Maven 3.0.4
>Reporter: Stanislav Grushevskiy
>Assignee: Olivier Lamy (*$^¨%`£)
>
> To reproduce this issue you need to install apache and mod_jk and deploy 
> application to apache, mod_jk, tomcat.
> If you deploy just to tomcat you will not reproduce it.
> This situation is reproduced in tomcat 6, 7.
> When I deploy my WAR using maven, the target war (exact the same one) is 
> being uploaded to the server twice. Can someone explain that?
> I am using this on my module:
> {code}clean install org.apache.tomcat.maven:tomcat6-maven-plugin:2.0:redeploy 
> {code}
> From the Log file
> {code =xml}
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ mobile-server ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [mobile-server] in 
> [C:\develope\mobile\mobile-server\target\mobile-server]
> [INFO] Processing war project
> [INFO] Copying webapp resources 
> [C:\develope\mobile\mobile-server\src\main\webapp]
> [INFO] Webapp assembled in [241 msecs]
> [INFO] Building war: C:\develope\mobile\mobile-server\target\mobile-server.war
> [INFO] 
> [INFO] <<< tomcat6-maven-plugin:2.0:redeploy (default-cli) @ mobile-server <<<
> [INFO] 
> [INFO] --- tomcat6-maven-plugin:2.0:redeploy (default-cli) @ mobile-server 
> ---
> [INFO] Deploying war to http://myserver.eu/pra-mobile-server  
> Uploading: 
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> Uploaded: 
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true 
> (12678 KB at 49.3 KB/sec)
> Uploading: 
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> Uploaded: 
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> {code}
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> 
> eu.company.prj.pramobile
> mobile-parent
> ../mobile-parent/pom.xml
> 1.0-SNAPSHOT
> 
> mobile-server
> war
> mobile server
> 
> 1.1.2
> 
> 
> 
> com.springsource.repository.libs-milestone
> SpringSource Enterprise Bundle Repository - libs
> http://repo.springsource.org/libs-milestone/
> 
>  
> 
> 
> ${project.groupId}
> mobile-test
> ${project.version}
> test
> 
> 
> ${project.groupId}
> mobile-common
> ${project.version}
> 
> 
> 
> org.springframework
> spring-asm
> ${version.spring}
> 
> 
> org.springframework
>

Re: Jasper improvements/XML handling

2013-07-08 Thread Mark Thomas

On 08/07/2013 06:38, Jeremy Boynes wrote:
> On Jun 25, 2013, at 10:44 PM, Jeremy Boynes 
> wrote:
> 
>> I have been thinking about improvements to Jasper as well around
>> better support for Servlet 3.0 concepts. One area would be
>> decoupling it from Tomcat, bootstrapping using an SCI as hinted in
>> ContextConfig.

It was the intention of the Servlet EG that this should be possible.
There are a number of areas where changes are required to make this
work. I think you have identified the main ones.

>> I'd also be interested in improving the Ant task as
>> well, such as support for pre-compiling a separate package that
>> would be treated as a web fragment (including web.xml-less
>> pre-compilation, generating a web-fragment.xml rather than a
>> web.xml snippet or potentially eliminating the XML entirely if the
>> generated code can be annotated with @WebServlet).

My preference would be for the web-fragment.xml approach as I prefer
having just a single file to look at when debugging.

> I started on this and ended up with two patches that are converging.
> For 55166 (which started out somewhere different), I have a patch to
> update local entity handling in Catalina's XML parsing; for 53737, I
> started to have Jasper's translator rely only on the ServletContext
> and not need to parse merged web.xml XML passed as a ServletContext
> attribute. These are converging in a few areas.

Small, incremental changes are the way to go rather than one big patch.
The larger the patch the less likely it is to get applied.

I'd suggest getting the 55166 issues fixed first, then start looking at
the larger problem of making Jasper rely solely on the Servlet API.

> Jasper's descriptor parser (used for web.xml and TLDs) can only
> validate DTD-based documents. I opened 55212 about adding it. Such a
> fix could benefit from using the same resolver and cached copies that
> Catalina does. This is less of an issue if Jasper uses the
> ServletContext as it could rely on the container to parse/validate
> web.xml. It would still be needed if we wanted JspC to validate files
> standalone but there is a separate ant task that can do that.

Jasper and Catalina need to share the same web.xml parsing and merging
code. Violetta started on this before she was a committer but the work
stalled primarily because of the size of patch which in turn was due to
the re-factoring required. The first step is to get the parsing and
merging into a package that can be shared by Jasper and Catalina. That
is far easier for a committer to do as they can use the refactoring
tools in an IDE rather than having to generate a huge patch and then
wait for a committer to find the time to review it.

> Another area of convergence is in parsing TLDs: currently both
> Catalina and Jasper do it, differently.

A lot of the code is identical with large comments to keep the two
implementations in sync.

> I believe Catalina only reads
> them to detect the Listeners they define and if that's the case we
> could perhaps add a SCI to Jasper that handled all TLD functionality
> including registering the listeners programmatically (at least that's
> what Servlet 8.3 implies).

Agreed.

> That would remove Catalina's dependency
> on web-jsptaglibrary*.xsd and on TLD-related classes. To support
> validation though we would need to add the XSD-based validation in
> Jasper.

This is beginning to get far enough away from where the code is right
now that I'd suggest just noting the issue and come back to it when the
other changes are complete.

> Finally, Jasper parses these documents first into DOM and the into
> its own version based on TreeNode (this is separate from the parse
> tree used for actual JSPs). Jasper already depends on tomcat-util for
> the JarScanner so could potentially use Digester for this in the same
> way Catalina does. It would simplify the fragment merge logic in JspC
> if it could reuse what was in Catalina's WebXml (something I'm
> hacking around in 53737 right now).  Alternatively, we could still
> eliminate the intermediary DOM and TreeNode forms and use SAX or StAX
> to parse directly into Jasper's objects - especially for TLDs where
> it is using the spec's classes (TagLibraryInfo and TagInfo) as the
> model.

Again, I think this is looking too far ahead.

> I'm planning on merging these two patches and pressing on with a
> converged solution, but probably won't be able to do much until next
> weekend.

I very much doubt that a single patch that did everything above would
ever get applied. Small incremental changes are the way to do this. I
think you've identified the key issues and the right order in which to
address them. Lets move forward but one small step at a time.

Mark

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

[jira] [Commented] (MTOMCAT-230) CLONE - Plugin uploads WAR file twice

2013-07-08 Thread Stanislav Grushevskiy (JIRA)


[ 
https://issues.apache.org/jira/browse/MTOMCAT-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701853#comment-13701853
 ] 

Stanislav Grushevskiy commented on MTOMCAT-230:
---

tomcat/access_log

127.0.0.1 - - [08/Jul/2013:11:46:41 +0700] "PUT 
/manager/text/deploy?path=%2F&update=true HTTP/1.1" 401 2474
127.0.0.1 - tomcat [08/Jul/2013:11:46:58 +0700] "PUT 
/manager/text/deploy?path=%2F&update=true HTTP/1.1" 200 90



full jk_workers.properties

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# Note that the distributed version of this file requires modification
# before it is usable.
#
# Reference documentation: 
http://tomcat.apache.org/connectors-doc/reference/workers.html
#
# As a general note, the characters $( and ) are used internally to define
# macros. Do not use them in your own configuration!!!
#
# Whenever you see a set of lines such as:
# x=value
# y=$(x)\something
#
# the final value for y will be value\something

# Define two status worker:
# - jk-status for read-only use
# - jk-manager for read/write use
worker.list=jk-status
worker.jk-status.type=status
worker.jk-status.read_only=true

worker.list=jk-manager
worker.jk-manager.type=status

# We define a load balancer worker
# with name "balancer"
worker.list=balancer
worker.balancer.type=lb
# error_escalation_time: seconds, default = recover_time/2 (=30)
# Determines, how fast a detected error should switch from
# local error state to global error state
# Since: 1.2.28
worker.balancer.error_escalation_time=0

# - max_reply_timeouts: number, default=0
#   If there are to many reply timeouts, a worker
#   is put into the error state, i.e. it will become
#   unavailable for all sessions residing on the respective
#   Tomcat. The number of tolerated reply timeouts is
#   configured with max_reply_timeouts. The number of
#   timeouts occuring is divided by 2 once a minute and the
#   resulting counter is compared against max_reply_timeouts.
#   If you set max_reply_timeouts to N and the errors are
#   occuring equally distributed over time, you will
#   tolerate N/2 errors per minute. If they occur in a burst
#   you will tolerate N errors.
#   Since: 1.2.24
worker.balancer.max_reply_timeouts=10



# Now we add members to the load balancer
# First member is "node1", most
# attributes are inherited from the
# template "worker.template".
worker.balancer.balance_workers=node1
worker.node1.reference=worker.template
worker.node1.host=localhost
worker.node1.port=8109
# Activation allows to configure
# whether this node should actually be used
# A: active (use node fully)
# D: disabled (only use, if sticky session needs this node)
# S: stopped (do not use)
#   Since: 1.2.19
worker.node1.activation=A

# Second member is "node2", most
# attributes are inherited from the
# template "worker.template".
worker.balancer.balance_workers=node2
worker.node2.reference=worker.template
worker.node2.host=localhost
worker.node2.port=8209
# Activation allows to configure
# whether this node should actually be used
# A: active (use node fully)
# D: disabled (only use, if sticky session needs this node)
# S: stopped (do not use)
#   Since: 1.2.19
worker.node2.activation=A

# Finally we put the parameters
# which should apply to all our ajp13
# workers into the referenced template
# - Type is ajp13
worker.template.type=ajp13

# - socket_connect_timeout: milliseconds, default=0
#   Since: 1.2.27
worker.template.socket_connect_timeout=5000

# - socket_keepalive: boolean, default=false
#   Should we send TCP keepalive packets
#   when connection is idle (socket option)?
worker.template.socket_keepalive=true

# - ping_mode: Character, default=none
#   When should we use cping/cpong connection probing?
#   C = directly after establishing a new connection
#   P = directly before sending each request
#   I = in regular intervals for idle connections
#   using the watchdog thread
#   A = all of the above
#   Since: 1.2.27
worker.template.ping_mode=A

# - ping_timeout: milliseconds, default=1
#   Wait timeout for cpong after cping
#   Can be overwritten for modes C and P
#   Using connect_timeout and prepost_timeout.
#   Since: 1.2.27
worker.template.ping_ti

[jira] [Commented] (MTOMCAT-230) CLONE - Plugin uploads WAR file twice

2013-07-08 Thread Stanislav Grushevskiy (JIRA)

[
https://issues.apache.org/jira/browse/MTOMCAT-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701854#comment-13701854
]

Stanislav Grushevskiy commented on MTOMCAT-230:
---

mod_jk.conf

LoadModule jk_modulemodules/mod_jk.so

###
### Where to find workers.properties
###
# JkWorkersFile specify the location where mod_jk will find
# the workers definitions.
JkWorkersFile /etc/apache2/jk-workers.properties

###
### Where to put mod_jk logs
###
# specify the location where mod_jk is going to place its log file.
JkLogFile /var/log/apache2/mod_jk.log

###
### Set the jk log level [debug/error/info]
###
# info log will contains standard mod_jk activity (default).
# error log will contains also error reports.
# debug log will contains all informations on mod_jk activity
JkLogLevel info

###
### Select the log format
###
# JkLogStampFormat will configure the date/time format found
# on mod_jk logfile. Using the strftime() format string it's
# set by default to "[%a %b %d %H:%M:%S %Y]"
#JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

###
### JkOptions indicate to send SSL KEY SIZE,
###
# The directive JkOptions allow you to set many forwarding
# options which will enable (+) or disable (-) following option.
#
#
# JkOptions ForwardKeySize , you ask mod_jk, when using ajp13, to
# forward also the SSL Key Size as required by Servlet API 2.3.
# This flag shouldn't be set when servlet engine is Tomcat 3.2.x
# (on by default).
#
#
# JkOptions ForwardURICompat , you told mod_jk to send the URI to
# Tomcat normally, which is less spec compliant but mod_rewrite
# compatible, use it for compatibility with Tomcat 3.2.x engines
# (on by default).
#
#
# JkOptions ForwardURICompatUnparsed , the forwarded URI is unparsed,
# it's spec compliant but broke mod_rewrite.
#
#
# JkOptions ForwardURIEscaped , the forwarded URI is escaped and
# Tomcat (since 3.3 rc2) will do the decoding part.
#
#
# JkOptions ForwardDirectories is used in conjunction with Directory-
# Index directive of Apache web server. As such mod_dir should be
# available to Apache, statically or dynamically (DSO)
#
# When DirectoryIndex is configured, Apache will create sub-requests
# for each of the local-url's specified in the directive, to determine
# if there is a local file that matches (this is done by stat-ing the file).
#
# If ForwardDirectories is set to false (default) and Apache doesn't
# find any files that match, Apache will serve the content of the
# directory (if directive Options specifies Indexes for that directory)
# or a 403 Forbidden response (if directive Options doesn't specify
# Indexes for that directory).
#
# If ForwardDirectories is set to true and Apache doesn't find any
# files that match, the request will be forwarded to Tomcat for
# resolution. This is used in cases when Apache cannot see the index
# files on the file system for various reasons: Tomcat is running on
# a different machine, the JSP file has been precompiled etc.
#
# Note that locally visible files will take precedence over the ones
# visible only to Tomcat (i.e. if Apache can see the file, that's
# the one that's going to get served). This is important if there is
# more then one type of file that Tomcat normally serves - for
# instance Velocity pages and JSP pages.
#
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

###
### JkEnvVar forward environment vars
###
# The directive JkEnvVar allow you to forward an environment vars
# from Apache server to Tomcat engine.
#
#JkEnvVar SSL_CLIENT_V_START

###
### JkRequestLogFormat set the request format
###
# JkRequestLogFormat will configure the format of mod_jk individual
# request logging. Request logging is configured and enabled on a
# per virtual host basis. To enable request logging for a virtual
# host just add a JkRequestLogFormat config. The syntax of the
# format string is similiar to the Apache LogFormat command, here
# is a list of the available request log format options:
#
# Options Description
# %bBytes sent, excluding HTTP headers (CLF format)
# %BBytes sent, excluding HTTP headers
# %HThe request protocol
# %mThe request method
# %pThe canonical Port of the server serving the request
# %qThe query string (prepended with a ? if a query string exists,
otherwise an empty string)
# %rFirst line of request
# %sRequest HTTP status code
# %TRequest duration, elapsed time to handle request in seconds '.'
micro seconds
# %UThe URL path requested, not including any query string.
# %vThe canonical ServerName of the server serving the request
# %VThe server name according to the UseCanonicalName setting
# %wTomcat worker name
#
JkRequestLogFormat "%w %V %T"

52 matches

Mail list logo