DO NOT REPLY [Bug 35460] New: - reporting using FOP /SVG
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35460. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35460 Summary: reporting using FOP /SVG Product: Tomcat 5 Version: 5.0.28 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, i'm not sure if the problem is a bug or an installation mistake, but in any way when i try to send back to browser a pdf stream built on the fly via FOP all work well but the document contain a SVG element. If i do the following is what the browser display : HTTP Status 500 - --- - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception stfn.Filters.BaseFilter.doFilter(BaseFilter.java:52) stfn.Filters.BaseFilter.doFilter(BaseFilter.java:52) root cause java.lang.NoClassDefFoundError org.apache.batik.dom.svg.SAXSVGDocumentFactory.init (SAXSVGDocumentFactory.java:78) org.apache.batik.bridge.DocumentLoader.init(DocumentLoader.java:74) org.apache.batik.bridge.BridgeContext.init(BridgeContext.java:182) org.apache.fop.svg.SVGElement.layout(SVGElement.java:217) org.apache.fop.fo.flow.InstreamForeignObject.layout (InstreamForeignObject.java:251) org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:154) org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:110) org.apache.fop.fo.pagination.PageSequence.makePage (PageSequence.java:400) org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:338) org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:262) org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:223) org.apache.xalan.transformer.ResultTreeHandler.endElement (ResultTreeHandler.java:309) org.apache.xalan.templates.ElemLiteralResult.execute (ElemLiteralResult.java:716) org.apache.xalan.transformer.TransformerImpl.executeChildTemplates (TransformerImpl.java:2339) org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode (TransformerImpl.java:2160) org.apache.xalan.transformer.TransformerImpl.transformNode (TransformerImpl.java:1213) org.apache.xalan.transformer.TransformerImpl.run (TransformerImpl.java:3372) org.apache.xalan.transformer.TransformerHandlerImpl.endDocument (TransformerHandlerImpl.java:433) org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source) org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source) org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source) org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source) org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.di spatch(Unknown Source) org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (Unknown Source) org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) org.apache.xerces.parsers.XMLParser.parse(Unknown Source) org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) org.apache.xalan.transformer.TrAXFilter.parse(TrAXFilter.java:134) org.apache.fop.apps.Driver.render(Driver.java:498) stfn.stampa.pdf.StampaPdf.renderXML(StampaPdf.java:213) stfn.stampa.pdf.StampaPdf.stampa(StampaPdf.java:129) stfn.stampa.pdf.StampaPdf.stampa(StampaPdf.java:116) devmecoil.stampe.pdf.PDFCertificato.init(PDFCertificato.java:43) devmecoil.servlet.commands.Stampa.DisplayOnGet(Stampa.java:20) stfn.Servlet.BaseServlet.doGet(BaseServlet.java:45) javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) stfn.Filters.BaseFilter.doFilter(BaseFilter.java:52) stfn.Filters.BaseFilter.doFilter(BaseFilter.java:52) note The full stack trace of the root cause is available in the Apache Tomcat/5.0.28 logs. --- - Apache Tomcat/5.0.28 Thanks Stefano Migliarini -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug,
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|bugs@httpd.apache.org |tomcat- ||[EMAIL PROTECTED] Component|Other Modules |Native:JK Product|Apache httpd-2.0|Tomcat 5 Version|2.0.54 |5.0.28 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 [EMAIL PROTECTED] changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet and JSP APIs in java repository
Thanks, that was exactly what I needed. Regards. Carlos Sanchez On 6/21/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Ahh. Someone with karma to kakarta-servletapi-5 should probably update that. I don't have that karma ;) Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 21, 2005 1:15 PM To: Tomcat Developers List Subject: RE: Servlet and JSP APIs in java repository Yoav, I did a quick check of servlet-api.jar in Tomcat 5.5.9. In its MANIFEST.MF, the Implementation-Version says 2.4.public_draft. Looks like the implementation.revision property in the build.xml files for both jsr152 and jsr154 still say public_draft. Larry -Original Message- From: Yoav Shapira [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 21, 2005 1:08 PM To: 'Tomcat Developers List' Cc: 'Maven Developers List' Subject: RE: Servlet and JSP APIs in java repository Hi, There's a lot of confusion about the servlet and jsp apis, many projects reference the servlet 2.4 while in Tomcat 5.5 the version included says 2.4.public_draft, so I really don't know if there's available a 2.4 final somewhere. The version that ships with Tomcat 5.5 and all but the very first couple of Tomcat 5.0 releases is Servlet Specification v2.4 final. (And JSP Specification v2.0 final). When you say it says 2.4.public_draft, what precisely do you mean? Is that the name of a file somewhere, a directory, a CVS tag? So this is a request for help, if you could tell us what versions of servlet api exist since 2.3 and jsp apis, where to get them and the license (some Sun APIs can't be redistributed in the repository), then I'll fix the repository. There was Servlet Spec 2.3 and JSP Spec 1.2, which go with Tomcat 4. Then there were a few Servlet Spec 2.4 PFD (Proposed Final Draft) releases, but that's a long time ago. Everything for the past year and several months has been Servlet Spec 2.4 (final) and JSP Spec 2.0 (final). As far as CVS: while both these packages ship with Tomcat, they have their own CVS area. It's the jakarta-servletapi-5 CVS module, and under it you'll find directories for each spec. The binaries (they're actually jars, servlet-api.jar and jsp-api.jar, respectively) in there are for Servlet Spec 2.4 final and JSP Spec 2.0 final. I hope that clarifies things. If not, please let us know how else we can help. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne volunteers?
Cool :) I was useless and failed to give the all-important wiki link to sign up: http://wiki.apache.org/jakarta/ApacheAtJavaOne2005 Ian's signed himself up. Could I get the two of you (Tim/Amy) and anyone else who wants to volunteer to sign up there? I've passed your names onto Geir, I figure he'll take things from here. Hen On 6/17/05, Amy Roh [EMAIL PROTECTED] wrote: Tim Funk wrote: I can sit around for 2 or 3 hours. Me too... Amy -Tim Henri Yandell wrote: Unsure if the Tomcat community saw Geir's email asking for volunteers at JavaOne. The ASF have a booth there (donated to us) if we can get people to man it etc. Given that it's the flagship product, will any Tomcat people be interested in volunteering? I think the idea is to spend 2 or 3 hours sitting at the desk etc, being positive about Tomcat, ASF, Open-Source etc on June 27th-29th. Wish I could convince my bosses to let me head out there :( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
website stops answering requests from time to time
This is a production site. We use Tomcat 4.1. website stops answering requests from time to time Our website is under very high daily volume. Several times a week, no requests are answered. Here is the log exception: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at java.util.HashMap$EntryIterator.next(HashMap.java:824) at java.util.HashMap.writeObject(HashMap.java:976) at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeWriteObject (ObjectStreamClass.java:809) at java.io.ObjectOutputStream.writeSerialData (ObjectOutputStream.java:1296) at java.io.ObjectOutputStream.writeOrdinaryObject (ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.java:278) at org.apache.catalina.session.StandardSession.writeObject (StandardSession.java:1429) at org.apache.catalina.session.StandardSession.writeObjectData (StandardSession.java:852) at org.apache.catalina.session.JDBCStore.save (JDBCStore.java:690) at org.apache.catalina.session.PersistentManagerBase.writeSession (PersistentManagerBase.java: 739) at org.apache.catalina.session.PersistentManagerBase.processMaxIdleBackups (PersistentManagerBase.java :1063) at org.apache.catalina.session.PersistentManagerBase.processPersistenceChecks(PersistentManagerBase.ja va:477) at org.apache.catalina.session.PersistentManagerBase.run (PersistentManagerBase.java:1141) at java.lang.Thread.run(Thread.java:534) Thanks in Advance, inr.. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Servlet and JSP APIs in java repository
Hi, I would also like to know the relashionship between the Apache Geronimo specs version of the servlet API and JSP specifications. For instance, we currently get the Servlet 2.4 API with both Geronimo specs and Tomcat 5.5. Similar for JSP. Are they the same? Which one should be mavenized and used everywhere Servlet adn JSP are needed? Regards to all, Fernando Yoav Shapira wrote: Hi, There's a lot of confusion about the servlet and jsp apis, many projects reference the servlet 2.4 while in Tomcat 5.5 the version included says 2.4.public_draft, so I really don't know if there's available a 2.4 final somewhere. The version that ships with Tomcat 5.5 and all but the very first couple of Tomcat 5.0 releases is Servlet Specification v2.4 final. (And JSP Specification v2.0 final). When you say it says 2.4.public_draft, what precisely do you mean? Is that the name of a file somewhere, a directory, a CVS tag? So this is a request for help, if you could tell us what versions of servlet api exist since 2.3 and jsp apis, where to get them and the license (some Sun APIs can't be redistributed in the repository), then I'll fix the repository. There was Servlet Spec 2.3 and JSP Spec 1.2, which go with Tomcat 4. Then there were a few Servlet Spec 2.4 PFD (Proposed Final Draft) releases, but that's a long time ago. Everything for the past year and several months has been Servlet Spec 2.4 (final) and JSP Spec 2.0 (final). As far as CVS: while both these packages ship with Tomcat, they have their own CVS area. It's the jakarta-servletapi-5 CVS module, and under it you'll find directories for each spec. The binaries (they're actually jars, servlet-api.jar and jsp-api.jar, respectively) in there are for Servlet Spec 2.4 final and JSP Spec 2.0 final. I hope that clarifies things. If not, please let us know how else we can help. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Starting point...
Hi, So basically (from the Servlet end), a JspServlet is initialized, this creates a RuntimeContext. Then, when the service is invoked it looks for some JspServletWrapper already associated with this .jsp in this context. If none exist, it creates JspServletWrapper which is a less servlet-styled Jsp compiler. This wrapper then contains a CompileContext, which presumably does the grunt-work of parsing and compiling the .jsp? Important distinction: JspServlet typically gets created and initialized once, upon webapp startup. Your other things above may be done per-JSP. Is there a book covering this? I don't think so, but I'm not sure. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting point...
Thanks! Well, not a book covering this precisely, but maybe something covering servlets in the large. Just wondernig if there was one that was better than others :) Regards, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Starting point...
Head-First Servlets JSP by Basham, Sierra Bates, O'Reilly, ISBN 0-596-00540-7 is one of the better books I've found on this kind of thing (not sure it would cover exactly this question, but in general I'm talking). I recommend it. It sometimes comes across a bit childish, but it gets the information across in an easy to understand way. In fact, I dare say it was absolutely invaluable to me in understanding constraint-based security. Also, it was all I used to study for the SWCD exam. (I'm not affiliated by the way, this is an objective recommendation) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, June 22, 2005 10:27 am, Yoav Shapira said: Hi, So basically (from the Servlet end), a JspServlet is initialized, this creates a RuntimeContext. Then, when the service is invoked it looks for some JspServletWrapper already associated with this .jsp in this context. If none exist, it creates JspServletWrapper which is a less servlet-styled Jsp compiler. This wrapper then contains a CompileContext, which presumably does the grunt-work of parsing and compiling the .jsp? Important distinction: JspServlet typically gets created and initialized once, upon webapp startup. Your other things above may be done per-JSP. Is there a book covering this? I don't think so, but I'm not sure. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h
I tested yesterday's CVS head for compliance with session ID URL rewriting.
This fails. The jsessionid is lost from the URL.
Derrick
From: [EMAIL PROTECTED]
Reply-To: Tomcat Developers List tomcat-dev@jakarta.apache.org
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/common
jk_uri_worker_map.c jk_uri_worker_map.h
Date: 16 Jun 2005 06:28:38 -
mturk 2005/06/15 23:28:38
Modified:jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h
Log:
Do not modify the provided uri inplace, but rather use the stack buffer
for
that. Also change the map_uri_to_worker to be 'const char'.
Revision ChangesPath
1.56 +17 -12
jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- jk_uri_worker_map.c 18 May 2005 11:09:55 - 1.55
+++ jk_uri_worker_map.c 16 Jun 2005 06:28:38 - 1.56
@@ -411,12 +411,13 @@
const char *map_uri_to_worker(jk_uri_worker_map_t *uw_map,
- char *uri, jk_logger_t *l)
+ const char *uri, jk_logger_t *l)
{
unsigned int i;
char *url_rewrite;
-char rewrite_char = ';';
const char *rv = NULL;
+const char *url = uri;
+char buf[JK_MAX_URI_LEN+1];
JK_TRACE_ENTER(l);
if (!uw_map || !uri) {
@@ -432,10 +433,16 @@
}
url_rewrite = strstr(uri, JK_PATH_SESSION_IDENTIFIER);
if (url_rewrite) {
-rewrite_char = *url_rewrite;
-*url_rewrite = '\0';
+size_t len = url_rewrite - uri;
+if (len JK_MAX_URI_LEN)
+len = JK_MAX_URI_LEN;
+strncpy(buf, uri, len);
+buf[len] = '\0';
+url = buf[0];
+if (JK_IS_DEBUG_LEVEL(l))
+jk_log(l, JK_LOG_DEBUG, Removing Session path '%s' URI
'%s',
+ url_rewrite, url);
}
-
if (uw_map-fname)
uri_worker_map_update(uw_map, l);
if (JK_IS_DEBUG_LEVEL(l))
@@ -456,7 +463,7 @@
if (uwr-match_type MATCH_TYPE_WILDCHAR_PATH) {
const char *wname;
/* Map is already sorted by context_len */
-if (wildchar_match(uri, uwr-context,
+if (wildchar_match(url, uwr-context,
#ifdef WIN32
1
#else
@@ -473,8 +480,8 @@
goto cleanup;
}
}
-else if (JK_STRNCMP(uwr-context, uri, uwr-context_len) == 0)
{
-if (strlen(uri) == uwr-context_len) {
+else if (JK_STRNCMP(uwr-context, url, uwr-context_len) == 0)
{
+if (strlen(url) == uwr-context_len) {
if (JK_IS_DEBUG_LEVEL(l))
jk_log(l, JK_LOG_DEBUG,
Found an exact match %s - %s,
@@ -489,10 +496,8 @@
JK_TRACE_EXIT(l);
cleanup:
-if (url_rewrite)
-*url_rewrite = rewrite_char;
if (rv uw_map-nosize) {
-if (is_nomap_match(uw_map, uri, rv, l)) {
+if (is_nomap_match(uw_map, url, rv, l)) {
if (JK_IS_DEBUG_LEVEL(l))
jk_log(l, JK_LOG_DEBUG,
Denying matching for worker %s by nomatch
rule,
1.20 +3 -2
jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.h
Index: jk_uri_worker_map.h
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.h,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- jk_uri_worker_map.h 26 Apr 2005 15:28:18 - 1.19
+++ jk_uri_worker_map.h 16 Jun 2005 06:28:38 - 1.20
@@ -52,6 +52,7 @@
#define MATCH_TYPE_DISABLED 0x2000
#define MATCH_TYPE_STOPPED 0x4000
+#define JK_MAX_URI_LEN 4095
struct uri_worker_record
{
/* Original uri for logging */
@@ -113,7 +114,7 @@
const char *puri, const char *pworker,
jk_logger_t *l);
const char *map_uri_to_worker(jk_uri_worker_map_t *uw_map,
- char *uri, jk_logger_t *l);
+ const char *uri, jk_logger_t *l);
int uri_worker_map_load(jk_uri_worker_map_t *uw_map,
jk_logger_t *l);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Connector issues
Hi,
we, in Enhydra Development Team, have a little problem with Tomcat 5.5.9
administration.
There are some Connector issues that I want to point out here.
1. In new Enhydra 6.4-1 (based on Tomcat 5.5.9) we are enabling secure SSL HTTP
Connector initialization (default connector configuration present in
'server.xml' configuration file with adaptable port setting). This part is
working great!
But, when we try to administer installed Tomcat through its 'admin' application
(change something in server configuration and commit changes) SSL HTTP
connector configuration gets corrupted. All connector parameters are saved
except 'sslProtocol' attribute setting which is not saved (I presume) because
of its default value (TLS). On server restart (when there is no 'sslProtocol'
parameter defined) SSL HTTP connector is initialized (without any exception -
OK) but isn't functional any more and 'admin application - SSL HTTP Connector -
SSL Protocol' parameter setting is empty.
Tomcat documentation is saying that 'sslProtocol' parameter is not obligate
(default value is TLS) but it's a bit different in practice (must be some bug
in HTTP connector-protocol initialization).
I've tried to find the cause of the problem in Tomcat source code!
It seems that problem can be resolved with simple implementation change in
'org.apache.catalina.connector.Connector' class
/**
* Set the secure connection flag that will be assigned to requests
* received through this connector.
*
* @param secure The new secure connection flag
*/
public void setSecure(boolean secure) {
this.secure = secure;
// additionally set 'secure' ProtocolHandler property trough
IntrospectionUtils class
setProperty(secure, String.valueOf(secure));
}
This code adaptation seems to be working for me. I didn't manage to test this
(my spare time is very limited) heavily but I hope that someone will take some
time to look into this.
2. We (in Enhydra) have 'Enhydra Director' - web server plug-in for Apache,
IIS and IPlanet supporting advanced load balancing, clustering and runtime
administration.
To enable communication between Tomcat and 'Director' we have our own protocol
implementation ('Enhydra Director Protocol').
When we add director-protocol implementation (binary) to Tomcat and (manually)
insert additional (Director) Connector configuration in 'server.xml' file
everything is working (perfect).
But, there is a question of runtime creation and reconfiguration (like for
other HTTP and AJP protocol implementations).
We adapted original Tomcat Admin application (few simple implementation
changes) and 'org.apache.catalina.mbeans.MBeanFactory' (implemented creation of
Director connector) Tomcat class together with 'mbeans-decriptors.xml' file.
Is there a way to enable creation and configuration of custom connector
(protocol) implementations during server runtime in predefined (elegant)
manner?
I don't want to patch original Tomcat binaries!
Regards,
Slobodan Vujasinovic
Enhydra Development Team
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector OutputBuffer.java
jfarcand2005/06/22 09:24:39
Modified:catalina/src/share/org/apache/catalina/connector
OutputBuffer.java
Log:
Fix typo. When the security manager is used, we always needs to execute under
a doPrivileged block.
Revision ChangesPath
1.7 +1 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/OutputBuffer.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- OutputBuffer.java 19 May 2005 14:14:41 - 1.6
+++ OutputBuffer.java 22 Jun 2005 16:24:39 - 1.7
@@ -559,7 +559,7 @@
conv = (C2BConverter) encoders.get(enc);
if (conv == null) {
-if (SecurityUtil.isPackageProtectionEnabled()){
+if (System.getSecurityManager() != null){
try{
conv = (C2BConverter)AccessController.doPrivileged(
new PrivilegedExceptionAction(){
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35472] New: - RequestDispatcher forward doesn't work with custom HttpServletRequest implementation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35472.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35472
Summary: RequestDispatcher forward doesn't work with custom
HttpServletRequest implementation
Product: Tomcat 5
Version: 5.5.9
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Hello there,
we're using an application that uses a custom implementation of
HttpServletRequest to trigger the RequestDispatcher. With an
include call everything works fine but forward doesn't work.
Basically there are two problems:
a) Catalina uses the internal DISPATCHER_TYPE (see Globals.java)
attribute to remember the request state (REQUEST, FORWARD,
INCLUDE, ERROR). This attribute is hardcoded in Catalinas
request.getAttribute implementation and not listed during a
request.getAttributeNames call. A standard Servlet 2.4
application does not know the attribute and therefore can't
copy it to it's own HttpServletRequest. A workaround is
calling the container requests getAttribute as a fallback.
But that's somewhat ugly. As the request implementation just
returns a hardcoded REQUEST if the attribute is null this
would be sufficient for the forward call, too.
See my suggestions and code snippets from
org.apache.catalina.core.ApplicationDispatcher CVS version 1.44 below.
b) unwrapRequest is called once during doInclude inside the
invoke Method. Thats sufficient. doForward calls unwrapRequest
again at the end of the method. Because unwrapRequest only
breaks on instanceof Request and RequestFacade the code
runs through and a ClassCastException occurs at the end.
DISPATCHER_TYPE attribute:
449 : remm 1.19 private void processRequest(ServletRequest request,
450 : ServletResponse response)
451 : throws IOException, ServletException {
452 : jfarcand 1.15
453 : remm 1.19 Integer disInt = (Integer) request.getAttribute
454 : (ApplicationFilterFactory.DISPATCHER_TYPE_ATTR);
455 : if (disInt != null) {
456 : jfarcand 1.15 if (disInt.intValue() !=
ApplicationFilterFactory.ERROR) {
457 : remm 1.19 outerRequest.setAttribute
458 :
(ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
459 : origServletPath);
460 : outerRequest.setAttribute
461 : (ApplicationFilterFactory.DISPATCHER_TYPE_ATTR,
462 : new Integer(ApplicationFilterFactory.FORWARD));
463 : jfarcand 1.15 invoke(outerRequest, response);
464 : } else {
465 : remm 1.19 invoke(outerRequest, response);
466 : jfarcand 1.15 }
467 : remm 1.19 }
468 :
469 : jfarcand 1.15 }
processRequest is called by doForward only.
invoke() is only called if the attribute is not null.
The easiest fix for that would be to set the attribute to FORWARD
and call invoke when the attribute is null also. (same for the
DISPATCHER_REQUEST_PATH_ATTR) The check above is for the ERROR
case, if the attribute does not exist it can't be an error - its
a REQUEST by hardcoded default in org.apache.catalina.connector.Request.
unwrapRequest:
787 : private void unwrapRequest() {
788 :
789 : if (wrapRequest == null)
790 : return;
791 :
792 : ServletRequest previous = null;
793 : ServletRequest current = outerRequest;
794 : while (current != null) {
795 :
796 : // If we run into the container request we are done
797 : if ((current instanceof Request)
798 : || (current instanceof RequestFacade))
799 : break;
800 :
801 : // Remove the current request if it is our wrapper
802 : if (current == wrapRequest) {
803 : ServletRequest next =
804 : ((ServletRequestWrapper) current).getRequest();
805 : if (previous == null)
806 : outerRequest = next;
807 : else
808 : ((ServletRequestWrapper) previous).setRequest
(next);
809 : break;
810 : }
811 :
812 : // Advance to the next request in the chain
813 : previous = current;
814 : current =
DO NOT REPLY [Bug 35472] - RequestDispatcher forward doesn't work with custom HttpServletRequest implementation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35472. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35472 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-06-22 20:08 --- (In reply to comment #0) See line 797 - 799. If 'current' is an instance of HttpServletRequest the request is fully unwrapped. Remember according to Servlet 2.4 SRV 6.2.2 the request attribute can be any descendant of HttpServletRequest. However, SRV 8.2 states that it can only be the original HttpServletRequest, or a descendant of HttpServletRequestWrapper (and in the later case, must wrap the original request). As such, your use case is in violation of the spec. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35473] - Change in StandardManager breaks SimpleTcpReplicationManager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35473. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35473 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Change in StandardManager |Change in StandardManager |breaks |breaks |SimpleTcpReplicationManager |SimpleTcpReplicationManager --- Additional Comments From [EMAIL PROTECTED] 2005-06-22 22:28 --- I think this proves nobody cares about this manager anymore: don't use it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35473] - Change in StandardManager breaks SimpleTcpReplicationManager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35473. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35473 --- Additional Comments From [EMAIL PROTECTED] 2005-06-22 22:59 --- (In reply to comment #1) I think this proves nobody cares about this manager anymore: don't use it. I'm not sure what else to use to get the behavior we need. I tried the DeltaManager but the application we're working on replicating the session does not call setAttribute when it modifies the attribute data, it is modified by reference. I realize this is not a good way to do it but we can't change the application. SimpleTcpReplicationManager replicates after every request which is the behavior we need. Suggestions on a different approach would always be appreciated. If the SimpleTcpReplicationManager should not be used it should be deprecated and documented as such. I have fixed the bug locally and will upload a patch diff to this bug. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35460] - reporting using FOP /SVG
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35460. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35460 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-06-22 23:29 --- If you are not sure this is a bug, you should not be creating a bugzilla issue. For what it is worth, this looks like a configuration issue. Please use an appropriate user mailing list. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: website stops answering requests from time to time
This is a question for the tomcat-user list. Mark Ayyanar Inbamohan wrote: This is a production site. We use Tomcat 4.1. website stops answering requests from time to time Our website is under very high daily volume. Several times a week, no requests are answered. Here is the log exception: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at java.util.HashMap$EntryIterator.next(HashMap.java:824) at java.util.HashMap.writeObject(HashMap.java:976) at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeWriteObject (ObjectStreamClass.java:809) at java.io.ObjectOutputStream.writeSerialData (ObjectOutputStream.java:1296) at java.io.ObjectOutputStream.writeOrdinaryObject (ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.java:278) at org.apache.catalina.session.StandardSession.writeObject (StandardSession.java:1429) at org.apache.catalina.session.StandardSession.writeObjectData (StandardSession.java:852) at org.apache.catalina.session.JDBCStore.save (JDBCStore.java:690) at org.apache.catalina.session.PersistentManagerBase.writeSession (PersistentManagerBase.java: 739) at org.apache.catalina.session.PersistentManagerBase.processMaxIdleBackups (PersistentManagerBase.java :1063) at org.apache.catalina.session.PersistentManagerBase.processPersistenceChecks(PersistentManagerBase.ja va:477) at org.apache.catalina.session.PersistentManagerBase.run (PersistentManagerBase.java:1141) at java.lang.Thread.run(Thread.java:534) Thanks in Advance, inr.. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debugging tomcat itself
I debug Tomcat all the time using Eclipse. I can't see any reason why this would work in Eclipse but not NetBeans. It looks like a configuration problem. Mark Hernan Ochoa wrote: Hi all, I'm trying to debug tomcat itself v5.5.9 using netbeans 4.1 without much luck. I'm able to attach to a running instance of tomcat using JPDA, but then my breakpoints are activated erraticaly, and when they actually break the execution of the program, if I trace to trace the code, it usually ends up in the debugged application continuing its execution, I cannot actually debug this way Did someone try this before? These are the things I did: -compiled tomcat 5.5.9 with a build.properties file containing: compile.debug=on compile.deprecation=off compile.optimize=off debuglevel=lines,vars,source (I added the build.properties file in the root directory of the source distribution, and also inside jakarta-tomcat-5) -I added all .java files into a new netbeans project (I created a new project with the option new project with existing java source files or sthg like that) -I run tomcat using the command /bin/catalina.sh jpda start -I attach to the instance of tomcat running with netbeans -I set the breakpoints by toggling them into the .java source files I added on netbeans. Sometimes I do this from the Files window, and sometimes from the Projects windows. Here I'm not sure what's the right way to go. Any help with this would be much appreciated. If anyone has sucessfully debugged tomcat with another debugger, please let me know also. Thanks in advance. bye! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
