[Bug 62626] Tomcat 9.0.10 APR/Native crashes
https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 --- Comment #20 from jan.pfei...@centrum.cz --- Calling NIO2+HTTP/2 stable was quite premature. With this config I get out of memory (5G) every few hours. Strange, peak traffic isnt causing any obvious problem. -- 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: r1838768 - /tomcat/jk/trunk/xdocs/reference/workers.xml
Author: markt Date: Thu Aug 23 21:55:11 2018 New Revision: 1838768 URL: http://svn.apache.org/viewvc?rev=1838768&view=rev Log: Correct status code Modified: tomcat/jk/trunk/xdocs/reference/workers.xml Modified: tomcat/jk/trunk/xdocs/reference/workers.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/reference/workers.xml?rev=1838768&r1=1838767&r2=1838768&view=diff == --- tomcat/jk/trunk/xdocs/reference/workers.xml (original) +++ tomcat/jk/trunk/xdocs/reference/workers.xml Thu Aug 23 21:55:11 2018 @@ -632,10 +632,10 @@ it will try each member in turn a number Before each retry, it will make a pause define by retry_interval directive. Note that this means that, if all workers fail, there will be a total of -number-of-workers * lb.retries * worker.retries requests before a 503 response +number-of-workers * lb.retries * worker.retries requests before a 504 response is returned to the client. So for an lb worker with four members and a default configuration, if all workers fail there will be a total of 16 requests before -a 503 response is returned to the client. +a 504 response is returned to the client. Until version 1.2.16 the default value was 3. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1838767 - in /tomcat/jk/trunk/xdocs: miscellaneous/changelog.xml reference/workers.xml
Author: markt Date: Thu Aug 23 21:53:35 2018 New Revision: 1838767 URL: http://svn.apache.org/viewvc?rev=1838767&view=rev Log: Having read bz 62408 and performed some testing, update the docs to make the behaviour clear. This also re-enforces the need to apply the patch provided for bz 62408 which I hope to do shortly. Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml tomcat/jk/trunk/xdocs/reference/workers.xml Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1838767&r1=1838766&r2=1838767&view=diff == --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Thu Aug 23 21:53:35 2018 @@ -69,6 +69,10 @@ of the current context path, it is impossible to implement this check without valid requests being rejected. (markt) + +Clarify the behvaiour of lb workers when all ajp13 workers fail with +particular reference to the role of the retries attribute. (markt) + Modified: tomcat/jk/trunk/xdocs/reference/workers.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/reference/workers.xml?rev=1838767&r1=1838766&r2=1838767&view=diff == --- tomcat/jk/trunk/xdocs/reference/workers.xml (original) +++ tomcat/jk/trunk/xdocs/reference/workers.xml Thu Aug 23 21:53:35 2018 @@ -628,9 +628,16 @@ This feature has been added in jk 1.2 This directive also exists for normal workers. For those it has a different meaning. If the load balancer can not get a valid member worker or in case of failover, -it will try again a number of times given by retries. +it will try each member in turn a number of times given by retries. Before each retry, it will make a pause define by retry_interval directive. +Note that this means that, if all workers fail, there will be a total of +number-of-workers * lb.retries * worker.retries requests before a 503 response +is returned to the client. So for an lb worker with four members and a default +configuration, if all workers fail there will be a total of 16 requests before +a 503 response is returned to the client. + + Until version 1.2.16 the default value was 3. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60240] Duplicate initialization log entry in mod_jk.log
https://bz.apache.org/bugzilla/show_bug.cgi?id=60240 --- Comment #11 from Rainer Jung --- Aha, the reason seems to be that systemd sets the -D FOREGROUND define at startup. In httpd code that means it won't call apr_proc_detach during() startup in the MPM, and part of apr_proc_detach() is a call to fork(). That's why during "normal" startup there's a second process with a different pid and during "FOREGROUND" startup like the one used by systemd there's no such change. I agree with Mark, that there's no issue observed with the duplicate init so INVALID seems fine to me. -- 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
[Bug 52483] Print JkOptions's options in log file and jkstatus page
https://bz.apache.org/bugzilla/show_bug.cgi?id=52483 --- Comment #4 from Mark Thomas --- NOte that the duplicate was specifically interested in JkStripSession -- 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
[Bug 52483] Print JkOptions's options in log file and jkstatus page
https://bz.apache.org/bugzilla/show_bug.cgi?id=52483 Mark Thomas changed: What|Removed |Added CC||ch...@christopherschultz.ne ||t --- Comment #3 from Mark Thomas --- *** Bug 49063 has been marked as a duplicate of this bug. *** -- 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
[Bug 49063] Please add JkStripSession status in jk-status worker output
https://bz.apache.org/bugzilla/show_bug.cgi?id=49063 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Mark Thomas --- *** This bug has been marked as a duplicate of bug 52483 *** -- 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
[Bug 62408] (New feature) Make configurable the number of retries in case of upstream failures
https://bz.apache.org/bugzilla/show_bug.cgi?id=62408 Mark Thomas changed: What|Removed |Added CC||ryl...@gmail.com --- Comment #1 from Mark Thomas --- *** Bug 48564 has been marked as a duplicate of this bug. *** -- 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
[Bug 48564] Allow to turn off retries for LB worker
https://bz.apache.org/bugzilla/show_bug.cgi?id=48564 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Mark Thomas --- Bug 62408 has a patch that should enable this to be addressed. *** This bug has been marked as a duplicate of bug 62408 *** -- 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
[Bug 60240] Duplicate initialization log entry in mod_jk.log
https://bz.apache.org/bugzilla/show_bug.cgi?id=60240 Mark Thomas changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #10 from Mark Thomas --- I've just tested this with Fedora Workstation 28 and I see the same thing. Apart from the duplicate process ID, the behaviour is identical on Ubuntu. Starting via apachectl on Fedora doesn't help as it has been modified to go via systemctl. I therefore tried httpd -k and saw the PID change as expected. Therefore, this to be a quirk of Fedora / systemctl. Since this does not appear to affect how httpd / mod_jk works I'm closing this as not an issue. -- 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
[Bug 53883] isapi_redirect v 1.2.37 crashes w3wp.exe on the production web servers - faulting module msvcrt.dll
https://bz.apache.org/bugzilla/show_bug.cgi?id=53883 --- Comment #2 from Mark Thomas --- Frank, I know it has been quite a while. Is this still an issue? -- 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
[Bug 53883] isapi_redirect v 1.2.37 crashes w3wp.exe on the production web servers - faulting module msvcrt.dll
https://bz.apache.org/bugzilla/show_bug.cgi?id=53883 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO -- 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
[Bug 53977] 32bits isapi connector cannot work in wow64 mode
https://bz.apache.org/bugzilla/show_bug.cgi?id=53977 Mark Thomas changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- Windows Server 2003 is no longer supported. In terms of Server 2008 I can confirm that this works. I configured IIS to with the 64-bit DLL and confirmed it work. I then switched to the 32-bit DLL and confirmed that a 500 error was received when making a request I'd expect to be handled by the DLL (as expected). I then followed these instructions to switch the application pool to 32-bit: https://blogs.msdn.microsoft.com/rakkimk/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes/ Requests to Tomcat (via the 32-bit DLL) then worked. -- 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
[GitHub] tomcat pull request #117: Enhance the CATALINA_BASE documentation
Github user m-czernek commented on a diff in the pull request: https://github.com/apache/tomcat/pull/117#discussion_r212238007 --- Diff: webapps/docs/introduction.xml --- @@ -89,6 +80,122 @@ same as $CATALINA_HOME. + + Throughout the documentation, there are references to the two following +properties: + + +CATALINA_HOME: Represents the root of your Tomcat +installation, for example /home/tomcat/apache-tomcat-9.0.10 +or C:\Program Files\apache-tomcat-9.0.10. + + +CATALINA_BASE: Represents the root of a runtime +configuration of a specific Tomcat instance. If you want to have +multiple Tomcat instances on one machine, use the CATALINA_BASE +property. + + + + +If you set the properties to different locations, the CATALINA_HOME location +contains static sources, such as .jar files, or binary files. +The CATALINA_BASE location contains configuration files, log files, deployed +applications, and other runtime requirements. + + + + By default, CATALINA_HOME and CATALINA_BASE point to the same directory. + Set CATALINA_BASE manually when you require running multiple Tomcat + instances on one machine. Doing so provides the following benefits: + + + +Easier management of upgrading to a newer version of Tomcat. Because all +instances with single CATALINA_HOME location share one set of +.jar files and binary files, you can easily upgrade the files +to newer version and have the change propagated to all Tomcat instances +using the same CATALIA_HOME directory. + + +Avoiding duplication of the same static .jar files. + + +The possibility to share certain settings, for example the setenv shell +or bat script file (depending on your operating system). + + + + + + Before you start using CATALINA_BASE, create the directory you want to use + as CATALINA_BASE for the particular Tomcat instance. At minimum, it must + contain: + +conf/server.xml +conf/web.xml + + That includes the conf directory. Otherwise, Tomcat may + fail to start. + + + Additionally, it may also contain the following: + --- End diff -- Thank you for your thorough review and my apologies for the delay in implementing it. I think what you said does make sense. I have implemented your feedback, just please check whether what I wrote is indeed correct. I provided the "order of lookup" note for directories where it made sense. Not sure there is any lookup going on in logs, for example (Imho that's rather scope than lookup, while for lib, lookup makes sense to me). What do you think? --- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
--- Comment #16 from Guido Jäkel ---
(In reply to Mark Thomas from comment #15)
> Please stop changing the resolution of this issue. The correct resolution is
> WONTFIX.
Sorry, but I don't change it by intention.
(In reply to Guido Jäkel from comment #8)
> If you think (or even know), this CAN and is valid -- e.g. for some other
> part of the URL than the path elements section, THEN my suggestion may be
> extended to have the "syntactical knowledge" to act only on path elements.
I examine the code at apache-2.0/mod_jk.c::init_ws_service() , where
commmon/jk_url.c::jk_canonenc() is called: The stringbuffer passed here to
encode consist of the pure path section only, the other URI elements like the
query sting or host name part are separate. Therefore, there is no need to
implement a syntactical knowledge of the URI parts into jk_cononenc() at the
moment -- it will act on the path and a '%2F' appear here, it must be the
result of a "encoded slash". And this is either enabled by AllowEncodedSlashes
or rejected upstream before.
It is also used once just here (and in the same matter for iis and netscape)
and in the case that
[...]
case JK_OPT_FWDURICOMPATUNPARSED:
s->req_uri = r->unparsed_uri;
if (s->req_uri != NULL) {
char *query_str = strchr(s->req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
}
break;
case JK_OPT_FWDURICOMPAT:
s->req_uri = r->uri;
break;
case JK_OPT_FWDURIPROXY:
size = 3 * (int)strlen(r->uri) + 1;
s->req_uri = apr_palloc(r->pool, size);
jk_canonenc(r->uri, s->req_uri, size); <--
break;
case JK_OPT_FWDURIESCAPED:
s->req_uri = ap_escape_uri(r->pool, r->uri);
break;
default:
return JK_FALSE;
}
[...]
In this case, the '%2F' is intentional allowed (keeping in mind the potential
directory traversal issue of a buggy backend). And the task of this patch is to
prevent mod_jk from breaking this from '%2F' into '%252F' by replacing the
first percent char of by '%25'
A remaining question is: What's about the sequence '%252F' in the path section
of an incoming URL. This issue pointed out by Mark is in fact an unresolved,
but IMHO not in the scope of the mod_jk part but in the httpd parser.
I agree with Mark that the semantic of this literal should represent an encoded
followed by . And not an encoded slash. But
the starting '%25' is decoded by the upstrem parser to an '%' and from that,
jk_canonenc() get a '%2F'. Without the patch, this would be encoded into
'%252F' again. With the patch, it would left as '%2F', and the semantics
changes.
Said that, I think the upstream parser in addition SHOULD NOT decode a '%25' if
'AllowEncodedSlashes' is enabled. Because then jk_canonenc gets a '%252F' and
the patch might be extended to leave '%25' untouched, too.
Grüße
Guido
--
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
[Bug 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 Mark Thomas changed: What|Removed |Added Resolution|FIXED |WONTFIX --- Comment #15 from Mark Thomas --- Please stop changing the resolution of this issue. The correct resolution is WONTFIX. -- 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
[Bug 62626] Tomcat 9.0.10 APR/Native crashes
https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 --- Comment #19 from jan.pfei...@centrum.cz --- It doesn't take long to crash. I can confirm RECYCLE_FACADES did not help. Currently I am running stable config NIO2 + HTTP/2 + Java 10. Let me know if you will need any further assistance. -- 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
[Bug 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 --- Comment #14 from Rainer Jung --- (In reply to Mark Thomas from comment #9) > What you are asking for is logically impossible. If mod_jk sees the sequence > "%2F" it has no way to determine if this is the result of decoding "%252F" > or not decoding "%2F". Therefore it cannot correctly reverse the encoding. It might become too complex, but httpd copies the original URI to r->unparsed_uri and I think that one isn't decoded in any way. So we could in theory check, whether there's a "%25" or "%25F" or "%25f" sequence in the original URI. e.g. if there's no "%25" it seems we should be safe in terms of double decoding, if there's no "%25f" or "%25F" we should at least be safe of double decoding a slash. There can be some holes in this attempt, e.g. a RewriteRule might change the URL and introduce "%25" (or "%25F" or "%25f") in the rewritten decoded URL, which will not change the original unparsed_uri, but the one we need to jk_canonenc(). So the bahavior to check unparsed_uri and rely on it might need to be an optional one, off by default. Is this a direction we should try? Or do we open a new the directory traversal problem here? -- 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
[Bug 62650] New: ampersand entity in jspx
https://bz.apache.org/bugzilla/show_bug.cgi?id=62650 Bug ID: 62650 Summary: ampersand entity in jspx Product: Tomcat 9 Version: unspecified Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: tomas.j...@partner.commerzsystems.com Target Milestone: - In jspx The & entity is incorrectly processed and leads to XML Parsing Error: not well-formed example.jspx http://www.w3.org/1999/xhtml"; xmlns:jsp="http://java.sun.com/JSP/Page"; > http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"/> ampersand example Ampersand example & here it is & and also here -- 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
[Bug 62626] Tomcat 9.0.10 APR/Native crashes
https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 --- Comment #18 from jan.pfei...@centrum.cz --- (In reply to Christopher Schultz from comment #16) Its like observing black hole for me but i've came to some conslusions > > But why is it not crashing on Java 8? 1. I have tried org.apache.catalina.connector.RECYCLE_FACADES=true parameter before and left it enabled. But I am quite sure it crashed at least once with parameter enabled. I've disabled it again. 2. HTTP/2. As I mentioned before I didnt know it is possible to have it working with Java 8. So I run it only with HTTP11. I have enabled HTTP/2 on Java 8 yesterday and got three crashes till now. 3. AND/OR "malevolent" traffic. There was some strange access logs for the images. Now its is clear it is related to HTTP/2. As it ceased with HTTP1 and reappeared again now with HTTP/2. It seems some bots have problems with HTTP/2, requesting the same images over and over again and terminating connection in some "bad" way. Last crash log (Java 8 + HTTP/2 RECYCLE_FACADES=false) --- T H R E A D --- Current thread (0x24278800): JavaThread "https-openssl-apr-443-exec-39" daemon [_thread_in_native, id=52448, stack(0x2d85,0x2d95)] siginfo: ExceptionCode=0xc005, writing address 0x01a0 Registers: RAX=0x, RBX=0x2c5a69a0, RCX=0x0001801ccca0, RDX=0xfff0 RSP=0x2d94e190, RBP=0x0009, RSI=0x0017, RDI=0x R8 =0x0006, R9 =0x004b, R10=0x0007, R11=0x R12=0x2c4971c6, R13=0x299b21c0, R14=0x, R15=0x RIP=0x0001800e0a8f, EFLAGS=0x00010286 Top of Stack: (sp=0x2d94e190) 0x2d94e190: 2c5a69a0 0008 0x2d94e1a0: 2c5a69a0 299b21c0 0x2d94e1b0: 0x2d94e1c0: 71f2 0x2d94e1d0: 00170009 0009 0x2d94e1e0: 20c47220 7132cb5d 0x2d94e1f0: 2240cd00 713b0b22 0x2d94e200: 24278800 20c47220 0x2d94e210: 22df4640 0x2d94e220: 2181135f529d 0001800e0075 0x2d94e230: 2d94e370 20c47220 0x2d94e240: 2d94e318 0009 0x2d94e250: 20c47220 0009 0x2d94e260: 2c5a69a0 0001800e5c2e 0x2d94e270: 0x2d94e280: 1fa3da90 24278800 Instructions: (pc=0x0001800e0a8f) 0x0001800e0a6f: f6 41 70 08 75 08 48 8b cb e8 d3 64 00 00 42 8d 0x0001800e0a7f: 04 37 e9 de f7 ff ff 33 ff 48 8b 83 80 00 00 00 0x0001800e0a8f: 44 89 b0 a0 01 00 00 8b c7 e9 c7 f7 ff ff ba 9e 0x0001800e0a9f: 00 00 00 4c 8d 0d a7 c7 0e 00 b9 14 00 00 00 44 Register to memory mapping: RAX=0x is an unknown value RBX=0x2c5a69a0 is an unknown value RCX=0x0001801ccca0 is an unknown value RDX=0xfff0 is an unknown value RSP=0x2d94e190 is pointing into the stack for thread: 0x24278800 RBP=0x0009 is an unknown value RSI=0x0017 is an unknown value RDI=0x is an unknown value R8 =0x0006 is an unknown value R9 =0x004b is an unknown value R10=0x0007 is an unknown value R11=0x is an unknown value R12=0x2c4971c6 is an unknown value R13=0x299b21c0 is an unknown value R14=0x is an unknown value R15=0x is an unknown value Stack: [0x2d85,0x2d95], sp=0x2d94e190, free space=1016k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [tcnative-1.dll+0xe0a8f] C [tcnative-1.dll+0xe5c2e] C [tcnative-1.dll+0x104bc] C [tcnative-1.dll+0x56ff] C 0x02cbc5a5 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 7660 org.apache.tomcat.jni.Socket.sendb(JLjava/nio/ByteBuffer;II)I (0 bytes) @ 0x02cbc51f [0x02cbc4c0+0x5f] J 12795 C2 org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.doWrite(ZLjava/nio/ByteBuffer;)V (242 bytes) @ 0x043caef0 [0x043cac80+0x270] J 15975 C2 org.apache.coyote.http2.Http2UpgradeHandler.writeBody(Lorg/apache/coyote/http2/Stream;Ljava/nio/ByteBuffer;IZ)V (218 bytes) @ 0x03c10ba0 [0x03c10680+0x520] J 12532 C2 java.io.BufferedOutputStream.write([BII)V (67 bytes) @ 0x04301c3c [0x04300940+0x12fc] J 18229 C2 com.m2000.shop.controllers.DefaultController.image(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljavax/servlet/http/HttpServletResponse;Ljavax/servlet/http/HttpServletRequest;)V (1129 bytes) @ 0x0535b604 [0x05358ac0+0x2b44]
