DO NOT REPLY [Bug 33419] New: - Impossible lookup the Oracle connection pool DataSource
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=33419. 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=33419 Summary: Impossible lookup the Oracle connection pool DataSource Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] My contexts app.xml contains: Resource name=jdbc/appDS auth=Application type=oracle.jdbc.pool.OracleConnectionPoolDataSource/ ResourceParams name=jdbc/appDS parameter namefactory/name valueoracle.jdbc.pool.OracleDataSourceFactory/value /parameter parameter nameurl/name valuejdbc:oracle:thin:@my.db:1521:sid/value /parameter /ResourceParams Next time, i lookup this resource: Context ctx = new InitialContext(); DataSource ds = (DataSource) ctx.lookup(java:comp/env/jdbc/appDS); And see: javax.naming.NamingException: Cannot create resource instance org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:132) javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) org.apache.naming.NamingContext.lookup(NamingContext.java:792) org.apache.naming.NamingContext.lookup(NamingContext.java:139) org.apache.naming.NamingContext.lookup(NamingContext.java:780) org.apache.naming.NamingContext.lookup(NamingContext.java:139) org.apache.naming.NamingContext.lookup(NamingContext.java:780) org.apache.naming.NamingContext.lookup(NamingContext.java:139) org.apache.naming.NamingContext.lookup(NamingContext.java:780) org.apache.naming.NamingContext.lookup(NamingContext.java:152) org.apache.naming.SelectorContext.lookup(SelectorContext.java:136) javax.naming.InitialContext.lookup(InitialContext.java:351) org.apache.jsp.test_jsp._jspService(org.apache.jsp.test_jsp:48) In method ResourceFactory.getObjectInstance() local variable factoryRefAddr contains null!!! It work at Tomcat 5.0.28, but work not at Tomcat 5.5.7. -- 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]
[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-07022005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-07022005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-07022005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-07022005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-07022005/build/libtool: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2307022005, brutus:brutus-public:2307022005 Gump E-mail Identifier (unique within run) #20. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 12:16 --- The design I have in mind is that the commons-logging implementation for the logger you're using must reside in the same classloader hierarchy as the logger implementation. This is why the -api JAR is used. As java.logging is available in the root classloader, so does its commons-logging impl, and it is located next to it in the classloader hierarchy (from Tomcat perspective; actually, it's one layer above it). Given the size of both projects (a couple hundred of lines of code each, it seems), UGLI is a fork of commons-logging. It demonstrates unwilligness to work with anyone else's API, and willingness to split the logging APIs again. If this is not your intention, then fine, but I need to see positive results. I am not involved in commons-logging development, and thus I view the situation as a user, and care only about the results. BTW, the log4j commons-logging implementation was developed by Costin, Craig, and Robert, with only one really simple patch from Ceki, contributed for commons-logging 1.0.4 (removing the need for a log4j 1.2 compatibility flag). I remember attempts by Ceki to torpedo commons-logging when the project was started, however. So I don't call this contributing to commons-logging, sorry. Do you have any more FUD for us to enjoy ? Basically, I now consider the existence of the log4j API harmful at this point. The loggers implementation, etc, are all good, but I hope you understand that if the thin API layer at the top was standardized, everyone would benefit. -1 for UGLI. -- 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 33419] - Impossible lookup the Oracle connection pool DataSource
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=33419. 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=33419 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 12:59 --- No wonder it worked in 5.0.28 and it doens't anymore for 5.5.7... The resource definition has changed significantly. It should look like this: Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource driverClassName=oracle.jdbc.driver.OracleDriver url=jdbc:oracle:thin:[EMAIL PROTECTED]:1521:mysid username=scott password=tiger maxActive=20 maxIdle=10 maxWait=-1/ For details, please consult tomcat docs. -- 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 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 15:49 --- This is not getting anywhere constructive. -- 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]
cvs commit: jakarta-tomcat-connectors/jk/tools/reports tomcat_trend.pl
glenn 2005/02/07 06:49:55
Modified:jk/tools/reports tomcat_trend.pl
Log:
Fix a date bug
Revision ChangesPath
1.9 +11 -3
jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl
Index: tomcat_trend.pl
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- tomcat_trend.pl 24 Feb 2004 08:42:04 - 1.8
+++ tomcat_trend.pl 7 Feb 2005 14:49:55 - 1.9
@@ -72,6 +72,14 @@
@tail = `tail -1 $archivedir/global.data`;
$startdate = (split /\s+/,$tail[0])[0];
($day, $mon, $year) = (localtime($startdate))[3..5];
+ if ($day == 31) {
+ $day=1;
+ $month++;
+ if ($month 11) {
+ $month=0;
+ $year++;
+ }
+ }
$startdate = timelocal(0,0,0,$day+1,$mon,$year);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/tools/reports tomcat_reports.pl
glenn 2005/02/07 06:53:38 Modified:jk/tools/reports tomcat_reports.pl Log: Improve error reporting if graph plot fails Revision ChangesPath 1.5 +8 -8 jakarta-tomcat-connectors/jk/tools/reports/tomcat_reports.pl Index: tomcat_reports.pl === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/tools/reports/tomcat_reports.pl,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- tomcat_reports.pl 24 Feb 2004 08:42:04 - 1.4 +++ tomcat_reports.pl 7 Feb 2005 14:53:38 - 1.5 @@ -218,7 +218,7 @@ $graph-set_y_axis_font(GD::gdSmallFont); $graph-set_legend_font(GD::gdSmallFont); $gd = $graph-plot([EMAIL PROTECTED]); - die \$gd not defined unless defined $gd; + die Graph Plot Failed: . $graph-error unless defined $gd; open IMG, $outfile or die $!; print IMG $gd-png or die $gd-error; @@ -261,7 +261,7 @@ $graph-set_y_axis_font(GD::gdSmallFont); $graph-set_legend_font(GD::gdSmallFont); $gd = $graph-plot([EMAIL PROTECTED]); - die \$gd not defined unless defined $gd; + die Graph Plot Failed: . $graph-error unless defined $gd; open IMG, $outfile or die $!; print IMG $gd-png or die $gd-error; @@ -301,7 +301,7 @@ $graph-set_y_axis_font(GD::gdSmallFont); $graph-set_legend_font(GD::gdSmallFont); $gd = $graph-plot([EMAIL PROTECTED]); - die \$gd not defined unless defined $gd; + die Graph Plot Failed: . $graph-error unless defined $gd; open IMG, $outfile or die $!; print IMG $gd-png or die $gd-error; @@ -349,7 +349,7 @@ $graph-set_y_axis_font(GD::gdSmallFont); $graph-set_legend_font(GD::gdSmallFont); $gd = $graph-plot([EMAIL PROTECTED]); - die \$gd not defined unless defined $gd; + die Graph Plot Failed: . $graph-error unless defined $gd; open IMG, $outfile or die $!; print IMG $gd-png or die $gd-error; @@ -397,7 +397,7 @@ $graph-set_y_axis_font(GD::gdSmallFont); $graph-set_legend_font(GD::gdSmallFont); $gd = $graph-plot([EMAIL PROTECTED]); - die \$gd not defined unless defined $gd; + die Graph Plot Failed: . $graph-error unless defined $gd; open IMG, $outfile or die $!; print IMG $gd-png or die $gd-error; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat_reports.pl
This should really go to the tomcat-dev@jakarta.apache.org list. I have cc'd the list on this reply. Comments nested below. Regards, Glenn On Mon, Feb 07, 2005 at 03:24:36PM +0100, Finocchiaro, Michael (TSG PLM BusDev EMEA) wrote: Glenn, I saw your name as the author of some Tomcat perl scripts in the jk source bundle. I am not sure of the correct forum to ask this question so I am asking you directly. Very simply, what % options are tomcat_reports.pl and tomcat_trend.pl looking for to create reports? I have tried lots of different stuff but have not been able to get these two tools working - and they seem to be the only way to investigate how Tomcat is handling load. Any hints you can give me? The two error messages I get are (and this is independent of which jk source bundle I try - same result with 1.2.4, 1.2.6 and 1.2.8) - and this is having installed GD and ActiveState Perl so that I should have all the necessary pieces: tomcat_reports.pl: $gd not defined at tomcat_reports.pl line 221. This means the graph plot failed. I have committed a bug fix so that better error reporting happens when this occurs. tomcat_trend.pl: Day '' out of range 1..31 at tomcat_trend.pl line 93 This is a bug and has been fixed in CVS. Both of these bug fixes can be obtained from the HEAD of the jakarta-tomcat-connectors CVS repository. Thanks, Fino Michael J Finocchiaro TSG HPTC EMEA Senior Consultant http://[1]www.hp.com [EMAIL PROTECTED] +33 1 57 62 83 18 : Phone +33 6 72 99 16 08 : Mobile +33 1 42 46 13 54 : Fax References Visible links 1. http://www.hp.com/ 2. mailto:[EMAIL PROTECTED] Hidden links: 3. http://www.hp.com/ Content-Description: Finocchiaro, Michael (HPTC EMEA).vcf -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 16:04 --- The design I have in mind is that the commons-logging implementation for the logger you're using must reside in the same classloader hierarchy as the logger implementation. This is why the -api JAR is used. As java.logging is available in the root classloader, so does its commons-logging impl, and it is located next to it in the classloader hierarchy (from Tomcat perspective; actually, it's one layer above it). Remy, In plain English, you are admitting that JCL's discovery mechanism does not work correctly except for java.util.logging, correct? JCL is supposed to bridge between logging APIs, including log4j. However, in practice it only bridges for java.util.logging and break for other implementations residing outside the JDK. Isn't this the plain truth? Given the above, I don't know how you dare fling accusations at log4j's direction and claim that JCL is problem-free. Moreover, your contempt of a fellow Apache project is shocking. -- 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 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 16:26 --- I don't see where or why I would admit anything. You claim on #19 that this is not constructive, and on #20 you come back for more. This does not make any sense to me, but here's more anyway :) Why I like commons-logging: - When packaged right, it works ok - A huge amount of people are now using its API, therefore enabling unified container wide logging configuration - Logging integration for people who embed Tomcat (as my company is doing) I do not care at all about discovery or whatever as long as it works well enough, and I did not look at the implementation details inside commons-logging either. I would have less contempt for log4j if, for example, it had implemented the java.util.logging API as a layer on top of its own API (and shipped the said layer in its official JAR, of course). I don't think anybody would get hurt by this, and this would be a productive first step towards unification. It would remove the need for commons-logging in the next Tomcat version. We would use java.util.logging, and, most likely, would be shipping a minimal log4j JAR with only a rotatable file logger (obviously, nothing can be decided at this point, and it's merely an idea). So you would get more users, while our default logging setup would be better. BTW, I don't see anything wrong with having contempt of a fellow Apache project. The amount of ASF folks who have written than Tomcat sucked in one way or the other is absolutely staggering ;) Besides, the amount of Apache code is now so huge, with some prjects more or less competing with each other, that I don't see how I could love all of them. And, in log4j, I only actually dislike the log4j API here. -- 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 33419] - Impossible lookup the Oracle connection pool DataSource
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=33419. 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=33419 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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: [VOTE] Proposed API change to the Manager interface
If I read this correctly (big if), the solution could be a security problem. If I were a phisher, I might be able to send you an email with a link to that would redirect you to a tomcat server with the new configuration in question with a special id. If the user were to perform other actions of a confidential nature, the attacker could swoop in and impersonate that session. The phisher could easily be notified that the special session id was used and have a farm of wamr bodies ready to attack. -Tim Remy Maucherat wrote: To address this, I propose simply reusing any session id presented by the client. As an option, this could be done only if emptySessionPath is true. I have tested it, and it works very well, addressing the problem with emptySessionPath=true. I could not think of any security issue this would cause (if the client submits a bogus insecure id, then he'll be the one being impacted), since the undelying session objects would be created and handled as usual. In normal more (emptySessionPath set to false), this would save costly session id generation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
Tim Funk wrote: If I read this correctly (big if), the solution could be a security problem. If I were a phisher, I might be able to send you an email with a link to that would redirect you to a tomcat server with the new configuration in question with a special id. If the user were to perform other actions of a confidential nature, the attacker could swoop in and impersonate that session. The phisher could easily be notified that the special session id was used and have a farm of wamr bodies ready to attack. Yes, this could maybe be used like this (maybe we could simply prevent URL session ids from being used for this purpose, which would likely solve the issue - I hope you can't set a cookie on another host). Obviously, if you're not using cookies for session tracking, then the emptySessionPath attribute is useless anyway, so there's no bug ;) The problem is that I see no other acceptable solution (a global list of session id, which would be unbounded, would be bad, and introduce lots of complexity - the API change might be still needed anyway). What do you think ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_jni_worker.c
mturk 2005/02/07 08:35:16 Modified:jk/native/common jk_jni_worker.c Log: Use const char* as placeholder for getting properties. Revision ChangesPath 1.31 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_jni_worker.c Index: jk_jni_worker.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_jni_worker.c,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- jk_jni_worker.c 6 Feb 2005 09:37:59 - 1.30 +++ jk_jni_worker.c 7 Feb 2005 16:35:15 - 1.31 @@ -344,7 +344,7 @@ jni_worker_t *p; int mem_config = 0; int btype = 0; -char *str_config = NULL; +const char *str_config = NULL; JNIEnv *env; JK_TRACE_ENTER(l); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
Tim Funk wrote:
If I read this correctly (big if), the solution could be a security
problem. If I were a phisher, I might be able to send you an email with
a link to that would redirect you to a tomcat server with the new
configuration in question with a special id. If the user were to perform
other actions of a confidential nature, the attacker could swoop in and
impersonate that session.
The phisher could easily be notified that the special session id was
used and have a farm of wamr bodies ready to attack.
My patch at the moment is attached to the email for more detailed
review. It no longer reuses session ids submitted in the URL (very good
catch).
Rémy
Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java,v
retrieving revision 1.14
diff -u -r1.14 Manager.java
--- jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
7 Sep 2004 20:57:02 - 1.14
+++ jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
7 Feb 2005 16:49:28 -
@@ -257,6 +257,7 @@
*/
public void addPropertyChangeListener(PropertyChangeListener listener);
+
/**
* Get a session from the recycled ones or create a new empty one.
* The PersistentManager manager does not need to create session data
@@ -264,17 +265,22 @@
*/
public Session createEmptySession();
+
/**
* Construct and return a new session object, based on the default
* settings specified by this Manager's properties. The session
- * id will be assigned by this method, and available via the getId()
- * method of the returned session. If a new session cannot be created
- * for any reason, return codenull/code.
- *
+ * id specified will be used as the session id.
+ * If a new session cannot be created for any reason, return
+ * codenull/code.
+ *
+ * @param sessionId The session id which should be used to create the
+ * new session; if codenull/code, the session
+ * id will be assigned by this method, and available via the getId()
+ * method of the returned session.
* @exception IllegalStateException if a new session cannot be
* instantiated for any reason
*/
-public Session createSession();
+public Session createSession(String sessionId);
/**
Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java,v
retrieving revision 1.18
diff -u -r1.18 Request.java
---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java
20 Nov 2004 21:10:47 - 1.18
+++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java
7 Feb 2005 16:49:29 -
@@ -2196,7 +2196,14 @@
(sm.getString(coyoteRequest.sessionCreateCommitted));
}
-session = manager.createSession();
+// Attempt to reuse session id if one was submitted in a cookie
+// Do not reuse the session id if it is from a URL, to prevent possible
+// phishing attacks
+if (isRequestedSessionIdFromCookie()) {
+session = manager.createSession(getRequestedSessionId());
+} else {
+session = manager.createSession(null);
+}
// Creating a new session cookie based on that session
if ((session != null) (getContext() != null)
Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
retrieving revision 1.24
diff -u -r1.24 ApplicationHttpRequest.java
---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
15 Jan 2005 20:31:21 - 1.24
+++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
7 Feb 2005 16:49:29 -
@@ -529,13 +529,8 @@
// Ignore
}
if (localSession == null create) {
-localSession = context.getManager().createEmptySession();
-localSession.setNew(true);
-localSession.setValid(true);
-localSession.setCreationTime(System.currentTimeMillis());
-localSession.setMaxInactiveInterval
-(context.getManager().getMaxInactiveInterval());
-
RE: [VOTE] Proposed API change to the Manager interface
Hi, However, the problem is that I need to modify a method in the top level Manager interface :( public Session createSession() must become: public Session createSession(String sessionId) (if sessionId is null, a new session id will be generated) As the createSession() will no longer be used anywhere, and calling it in old managers would create bad behavior, I propose removing it rather than deprecating it. Why can't createSession() simply call createSession(null) ? That way we could deprecate it and preserve backwards compatibility, at least for a little while. I'm uneasy about simply breaking a major interface, one that's customized often by users. Other than that, and given Tim's catch and your fix, I'm OK with this. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [VOTE] Proposed API change to the Manager interface
Geachte relatie, Het door u gebruikte e-mailadres is niet meer actief. U kunt uw e-mailbericht sturen naar [EMAIL PROTECTED] of dit bericht beantwoorden. Bedankt voor uw medewerking, Met vriendelijke groet, ATP Hypotheken Het Spoor 40 3994 AK Houten Tel. 030 750 25 33 Fax. 030 750 25 88 [EMAIL PROTECTED] -- DIT IS EEN AUTOMATISCH GEGENEREERD E-MAILBERICHT -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
Yoav Shapira wrote: Hi, However, the problem is that I need to modify a method in the top level Manager interface :( public Session createSession() must become: public Session createSession(String sessionId) (if sessionId is null, a new session id will be generated) As the createSession() will no longer be used anywhere, and calling it in old managers would create bad behavior, I propose removing it rather than deprecating it. Why can't createSession() simply call createSession(null) ? That way we could deprecate it and preserve backwards compatibility, at least for a little while. I'm uneasy about simply breaking a major interface, one that's customized often by users. Right, that's what I tried at first. However, session tracking would break in mysterious ways whenever emptySessionPath is used if we did that. So I considered it was better to remove the method to signal some change is needed. That was my idea, but I'm ok with adding back the method in Manager (and ManagerBase) as deprecated if you still think it's better. Other than that, and given Tim's catch and your fix, I'm OK with this. Ok. The adjustment I mentioned in my last email to handle jvmRoute might not be needed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_shm.c jk_shm.h
mturk 2005/02/07 11:06:35
Modified:jk/native/common jk_shm.c jk_shm.h
Log:
Change shared memory API. There will be always one and only shared
memory, so make it's instance static. Also use two types of shared memory
to lower the memory if JkShmFile is not defined in config. The overhed in
that case is 2K for maximum of 512 workers.
Revision ChangesPath
1.7 +132 -119 jakarta-tomcat-connectors/jk/native/common/jk_shm.c
Index: jk_shm.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_shm.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- jk_shm.c 6 Feb 2005 11:30:02 - 1.6
+++ jk_shm.c 7 Feb 2005 19:06:34 - 1.7
@@ -23,66 +23,72 @@
#include jk_pool.h
#include jk_shm.h
-const char shm_signature[] = { JK_SHM_MAGIC };
+/** jk shm header record structure */
+struct jk_shm_h_rec
+{
+/* Shared memory magic JK_SHM_MAGIC */
+charmagic[8];
+int workers;
+int allocated;
+jk_shm_w_rec_t *pr[1];
+jk_shm_w_rec_t rr[1];
+};
+typedef struct jk_shm_h_rec jk_shm_h_rec_t;
+
+/** jk shm structure */
+struct jk_shm
+{
+size_t size;
+const char *filename;
+intfd;
+intattached;
+jk_shm_h_rec_t *hdr;
+};
-#if defined (WIN32) || defined(NETWARE)
+typedef struct jk_shm jk_shm_t;
-/* Simulate file */
-static jk_shm_t *jk_global_shm = NULL;
+static const char shm_signature[] = { JK_SHM_MAGIC };
+static jk_shm_t jk_shmem = { 0, NULL, -1, 0, NULL};;
+
+#if defined (WIN32) || defined(NETWARE)
/* Use plain memory */
-int jk_shm_open(const char *fname, int workers, int dynamic, jk_shm_t *shm)
+int jk_shm_open(const char *fname)
{
-jk_shm_h_rec_t *hdr;
-
-if (jk_global_shm) {
-shm-attached = jk_global_shm-attached;
-shm-size = jk_global_shm-size;
-shm-base = jk_global_shm-base;
-shm-filename = jk_global_shm-filename;
+if (jk_shmem.hdr) {
return 0;
}
-if (workers 1 || workers JK_SHM_MAX_WORKERS)
-workers = JK_SHM_MAX_WORKERS;
-if (dynamic 1 || dynamic JK_SHM_MAX_WORKERS)
-dynamic = JK_SHM_MAX_WORKERS;
-shm-size = sizeof(jk_shm_h_rec_t) + (workers + dynamic) *
sizeof(jk_shm_w_rec_t);
+jk_shmem.size = JK_SHM_ALIGN(sizeof(jk_shm_h_rec_t) +
JK_SHM_MAX_WORKERS * sizeof(jk_shm_w_rec_t));
-shm-base = calloc(1, shm-size);
-if (!shm-base)
+jk_shmem.hdr = (jk_shm_h_rec_t *)calloc(1, jk_shmem.size);
+if (!jk_shmem.hdr)
return -1;
-shm-filename = memory;
-shm-fd = -1;
-shm-attached = 0;
-
-hdr = (jk_shm_h_rec_t *)shm-base;
+jk_shmem.filename = memory;
+jk_shmem.fd = 0;
+jk_shmem.attached = 0;
-memcpy(hdr-magic, shm_signature, 8);
-hdr-workers = workers;
-hdr-dynamic = dynamic;
-
-jk_global_shm = shm;
+memcpy(jk_shmem.hdr-magic, shm_signature, 8);
+jk_shmem.hdr-workers = JK_SHM_MAX_WORKERS;
return 0;
}
-int jk_shm_attach(const char *fname, int workers, int dynamic, jk_shm_t *shm)
+int jk_shm_attach(const char *fname)
{
-if (!jk_shm_open(fname, workers, dynamic, shm)) {
-shm-attached = 1;
+if (!jk_shm_open(fname)) {
+jk_shmem.attached = 1;
return 0;
}
else
return -1;
}
-void jk_shm_close(jk_shm_t *shm)
+void jk_shm_close()
{
-if (shm) {
-if (shm-base)
-free(shm-base);
-shm-base = NULL;
+if (jk_shmem.hdr) {
+free(jk_shmem.hdr);
}
+jk_shmem.hdr = NULL;
}
#else
@@ -102,147 +108,154 @@
#define MAP_FILE(0)
#endif
-static int do_shm_open(const char *fname, int workers, int dynamic,
- jk_shm_t *shm, int attached)
+static int do_shm_open(const char *fname, int attached)
{
+int rc;
int fd;
int flags = O_RDWR;
+void *base;
-shm-size = 0;
-shm-base = NULL;
-
-if (workers 1 || workers JK_SHM_MAX_WORKERS)
-workers = JK_SHM_MAX_WORKERS;
-if (dynamic 1 || dynamic JK_SHM_MAX_WORKERS)
-dynamic = JK_SHM_MAX_WORKERS;
-
-shm-filename = fname;
-shm-attached = attached;
-shm-size = sizeof(jk_shm_h_rec_t) + (workers + dynamic) *
sizeof(jk_shm_w_rec_t);
+if (jk_shmem.hdr)
+jk_shm_close();
+jk_shmem.filename = fname;
+jk_shmem.attached = attached;
/* Use plain memory in case there is no file name */
if (!fname) {
-jk_shm_h_rec_t *hdr;
-shm-base = calloc(1, shm-size);
-if (!shm-base)
+jk_shmem.size =
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
mturk 2005/02/07 11:07:38
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Use new shmem api that uses single instance shared memory.
Revision ChangesPath
1.121 +23 -18jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.120
retrieving revision 1.121
diff -u -r1.120 -r1.121
--- mod_jk.c 6 Feb 2005 13:30:34 - 1.120
+++ mod_jk.c 7 Feb 2005 19:07:38 - 1.121
@@ -190,7 +190,6 @@
static jk_worker_env_t worker_env;
static apr_global_mutex_t *jk_log_lock = NULL;
static char *jk_shm_file = NULL;
-static jk_shm_t jk_shmem = { 0, NULL, -1, NULL, 0};
static int JK_METHOD ws_start_response(jk_ws_service_t *s,
int status,
@@ -1670,10 +1669,11 @@
*/
apr_status_t jk_cleanup_shmem(void *data)
{
-if (jk_shmem.base) {
-jk_shm_close(jk_shmem);
-jk_shmem.base = NULL;
-}
+jk_logger_t *l = data;
+jk_shm_close();
+if (l JK_IS_DEBUG_LEVEL(l))
+ jk_log(l, JK_LOG_DEBUG, Shmem cleanup);
+
return 0;
}
@@ -2248,14 +2248,16 @@
if (mpm_threads 0)
jk_set_worker_def_cache_size(mpm_threads);
-rc = jk_shm_attach(jk_shm_file, 0, 0, jk_shmem);
-if (JK_IS_DEBUG_LEVEL(conf-log))
-jk_log(conf-log, JK_LOG_DEBUG, Attached shm:%s with status %d,
- jk_shmem.filename, rc);
-if (!rc) {
-apr_pool_cleanup_register(pconf, s, jk_cleanup_shmem,
+if ((rc = jk_shm_attach(jk_shm_file)) == 0) {
+if (JK_IS_DEBUG_LEVEL(conf-log))
+jk_log(conf-log, JK_LOG_DEBUG, Attached shm:%s,
+ jk_shm_name());
+apr_pool_cleanup_register(pconf, conf-log, jk_cleanup_shmem,
jk_cleanup_shmem);
}
+else
+jk_log(conf-log, JK_LOG_ERROR, Attachning shm:%s errno=%d,
+ jk_shm_name(), rc);
if (JK_IS_DEBUG_LEVEL(conf-log))
jk_log(conf-log, JK_LOG_DEBUG, Initialized %s,
JK_EXPOSED_VERSION);
@@ -2278,14 +2280,17 @@
/* jk_map_t *init_map = NULL; */
jk_map_t *init_map = conf-worker_properties;
-rc = jk_shm_open(jk_shm_file, 0, 0, jk_shmem);
-if (JK_IS_DEBUG_LEVEL(conf-log))
-jk_log(conf-log, JK_LOG_DEBUG, Initialized shm:%s with status %d,
- jk_shmem.filename, rc);
-if (!rc) {
-apr_pool_cleanup_register(pconf, s, jk_cleanup_shmem,
+;
+if ((rc = jk_shm_open(jk_shm_file)) == 0) {
+if (JK_IS_DEBUG_LEVEL(conf-log))
+jk_log(conf-log, JK_LOG_DEBUG, Initialized shm:%s,
+ jk_shm_name(), rc);
+apr_pool_cleanup_register(pconf, conf-log, jk_cleanup_shmem,
jk_cleanup_shmem);
}
+else
+jk_log(conf-log, JK_LOG_ERROR, Initializing shm:%s errno=%d,
+ jk_shm_name(), rc);
if (!uri_worker_map_alloc((conf-uw_map),
conf-uri_to_context,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
Hi, Right, that's what I tried at first. However, session tracking would break in mysterious ways whenever emptySessionPath is used if we did that. So I considered it was better to remove the method to signal some change is needed. That was my idea, but I'm ok with adding back the method in Manager (and ManagerBase) as deprecated if you still think it's better. Yeah, I still think it's better. Marginally better and obviously not perfect, but still better. If you want to add a comment to the old createSession() version that session tracking might break in mysterious ways if emptySessionPath is used, that's fine too. The important thing is we'll deprecate it and maintain backwards compatibility for at least a few releases / few months, then we can remove it altogether. (And I'll be +1 for that, always preferring a cleaner interface myself) Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33413] - problem accessing ssl website...
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=33413. 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=33413 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 21:23 --- Try reading http://jakarta.apache.org/tomcat/index.html -- 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: SVN migration?
On Feb 5, 2005, at 1:57 PM, Henri Yandell wrote: 1) Eclipse support (nobody has mentioned a different IDE yet) http://subclipse.tigris.org/ -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 8:57 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
Tim Funk wrote:
If I read this correctly (big if), the solution could be a security
problem. If I were a phisher, I might be able to send you an email with
a link to that would redirect you to a tomcat server with the new
configuration in question with a special id. If the user were to perform
other actions of a confidential nature, the attacker could swoop in and
impersonate that session.
The phisher could easily be notified that the special session id was
used and have a farm of wamr bodies ready to attack.
My patch at the moment is attached to the email for more detailed
review. It no longer reuses session ids submitted in the URL (very good
catch).
I'd be happier if this was conditional on emptySessionPath=true (or
otherwise could be disabled). Otherwise I have to trust that the browser
doesn't have some JavaScript and/or IFrame bug that allows a Cookie to be
sent.
Rémy
Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Man
ager.java,v
retrieving revision 1.14
diff -u -r1.14 Manager.java
---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
7 Sep 2004 20:57:02 - 1.14
+++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Manager.java
7 Feb 2005 16:49:28 -
@@ -257,6 +257,7 @@
*/
public void addPropertyChangeListener(PropertyChangeListener
listener);
+
/**
* Get a session from the recycled ones or create a new empty one.
* The PersistentManager manager does not need to create session data
@@ -264,17 +265,22 @@
*/
public Session createEmptySession();
+
/**
* Construct and return a new session object, based on the default
* settings specified by this Manager's properties. The session
- * id will be assigned by this method, and available via the getId()
- * method of the returned session. If a new session cannot be
created
- * for any reason, return codenull/code.
- *
+ * id specified will be used as the session id.
+ * If a new session cannot be created for any reason, return
+ * codenull/code.
+ *
+ * @param sessionId The session id which should be used to create the
+ * new session; if codenull/code, the session
+ * id will be assigned by this method, and available via the getId()
+ * method of the returned session.
* @exception IllegalStateException if a new session cannot be
* instantiated for any reason
*/
-public Session createSession();
+public Session createSession(String sessionId);
/**
Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Req
uest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/con
nector/Request.java,v
retrieving revision 1.18
diff -u -r1.18 Request.java
---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Req
uest.java 20 Nov 2004 21:10:47 - 1.18
+++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Req
uest.java 7 Feb 2005 16:49:29 -
@@ -2196,7 +2196,14 @@
(sm.getString(coyoteRequest.sessionCreateCommitted));
}
-session = manager.createSession();
+// Attempt to reuse session id if one was submitted in a cookie
+// Do not reuse the session id if it is from a URL, to prevent
possible
+// phishing attacks
+if (isRequestedSessionIdFromCookie()) {
+session = manager.createSession(getRequestedSessionId());
+} else {
+session = manager.createSession(null);
+}
// Creating a new session cookie based on that session
if ((session != null) (getContext() != null)
Index:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Applicat
ionHttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cor
e/ApplicationHttpRequest.java,v
retrieving revision 1.24
diff -u -r1.24 ApplicationHttpRequest.java
---
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Applicat
ionHttpRequest.java 15 Jan 2005 20:31:21 - 1.24
+++
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Applicat
ionHttpRequest.java 7 Feb 2005 16:49:29 -
@@ -529,13 +529,8 @@
//
Re: [VOTE] Proposed API change to the Manager interface
Both Cluster Managers (Delta and SimpleTcpReplication) extend ManagerBase but override createSession(). Maybe Filip or Peter can check how to make them long-time compatible with your proposal? Managers extending ManagerBase should work and compile as before with no changes unless they override the createSession method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java
remm2005/02/07 13:56:32
Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java StandardManager.java
catalina/src/share/org/apache/catalina Manager.java
modules/cluster/src/share/org/apache/catalina/cluster/session
DeltaManager.java
catalina/src/share/org/apache/catalina/connector
Request.java
catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java
Log:
- Add new Manager.createSession(sessionId) method, allowing the client to
specify the session id which should be used using a cookie
when using emptySessionPath=true.
- This fixes session tracking when using emptySessionPath=true.
- The old createSession() method is deprecated.
Revision ChangesPath
1.38 +43 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
Index: ManagerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- ManagerBase.java 22 Nov 2004 14:50:23 - 1.37
+++ ManagerBase.java 7 Feb 2005 21:56:32 - 1.38
@@ -730,12 +730,31 @@
* id will be assigned by this method, and available via the getId()
* method of the returned session. If a new session cannot be created
* for any reason, return codenull/code.
- *
+ *
* @exception IllegalStateException if a new session cannot be
* instantiated for any reason
+ * @deprecated
*/
public Session createSession() {
-
+return createSession(null);
+}
+
+
+/**
+ * Construct and return a new session object, based on the default
+ * settings specified by this Manager's properties. The session
+ * id specified will be used as the session id.
+ * If a new session cannot be created for any reason, return
+ * codenull/code.
+ *
+ * @param sessionId The session id which should be used to create the
+ * new session; if codenull/code, a new session id will be
+ * generated
+ * @exception IllegalStateException if a new session cannot be
+ * instantiated for any reason
+ */
+public Session createSession(String sessionId) {
+
// Recycle or create a Session instance
Session session = createEmptySession();
@@ -744,15 +763,33 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+// FIXME: Code to be used in case route replacement is needed
+/*
+} else {
+String jvmRoute = getJvmRoute();
+if (getJvmRoute() != null) {
+String requestJvmRoute = null;
+int index = sessionId.indexOf(.);
+if (index 0) {
+requestJvmRoute = sessionId
+.substring(index + 1, sessionId.length());
+}
+if (requestJvmRoute != null
!requestJvmRoute.equals(jvmRoute)) {
+sessionId = sessionId.substring(0, index) + . +
jvmRoute;
+}
+}
+*/
+}
session.setId(sessionId);
sessionCounter++;
return (session);
}
-
-
+
+
/**
* Get a session from the recycled ones or create a new empty one.
* The PersistentManager manager does not need to create session data
1.28 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java
Index: StandardManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- StandardManager.java 22 Nov 2004 16:35:18 - 1.27
+++ StandardManager.java 7 Feb 2005 21:56:32 - 1.28
@@ -278,7 +278,7 @@
* @exception IllegalStateException if a new session cannot be
* instantiated for any reason
*/
-public Session createSession() {
+public Session createSession(String sessionId) {
if ((maxActiveSessions = 0)
(sessions.size() = maxActiveSessions)) {
@@ -287,7 +287,7 @@
Re: [VOTE] Proposed API change to the Manager interface
Bill Barker wrote: I'd be happier if this was conditional on emptySessionPath=true (or otherwise could be disabled). Otherwise I have to trust that the browser doesn't have some JavaScript and/or IFrame bug that allows a Cookie to be sent. I think it should be safe, but once in a while there's a vulnerability allowing javascript access to the cookie store (in IE ;) ). We can change that later once it is proven to be safe enough. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33368] - swallowOutput causes memory leak
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=33368. 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=33368 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- 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]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 2005/02/07 16:23:58
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Samp for a jsp:element should not include its body.
Revision ChangesPath
1.238 +3 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.237
retrieving revision 1.238
diff -u -r1.237 -r1.238
--- Generator.java9 Sep 2004 14:26:53 - 1.237
+++ Generator.java8 Feb 2005 00:23:58 - 1.238
@@ -1825,6 +1825,9 @@
out.print((String)map.get(attrName));
}
+// Smap should not include the body
+n.setEndJavaLine(out.getJavaLine());
+
// Does the jsp:element have nested tags other than
// jsp:attribute
boolean hasBody = false;
@@ -1851,8 +1854,6 @@
} else {
out.println( + \/\););
}
-
-n.setEndJavaLine(out.getJavaLine());
}
public void visit(Node.TemplateText n) throws JasperException {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat CTS Testing
Since Tomcat is the reference implementation for the Servlet and JSP specification, does anyone have a manual of how to run CTS (Suns J2EE conformance Test Suite) against a standalone Tomcat installation. Thanks ! Punit Duggal _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat CTS testing
Since Tomcat is the reference implementation for the Servlet and JSP specification, does anyone have a manual of how to run CTS (Suns conformance Test Suite) against a standalone Tomcat installation. Thanks ! Punit Duggal _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Containers to expose LogFactory
Dear tomcat developers, I think it might be very beneficial if container exposed log factory e.g public Log getLog(String name) so all classes using context logger can get their own named loggers rather then sharing context's single one. As it stands now, for those classes there is no way to set logging level independently. If those classes created their own named loggers from context log factory they can be configured independently. If we do not use context logger (just typical commons logging pattern) it is not possible to predict where logging output will go as it depends very much on which class loader loaded this class. For example we have many extensions to tomcat which are loaded by server class loader on per context basis. We would love to be able to channel all their output to their respective context's log file rather the the global one but retain ability to have separate channels (loggers) for different components I would appreciate any suggestions Thank you Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Containers to expose LogFactory
HELP! I cant get off this damn list when I email [EMAIL PROTECTED] as instructed. I tried blank subject line and everything. ARR! someone block me. /b - Original Message - From: Roytman, Alex [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Monday, February 07, 2005 7:18 PM Subject: Containers to expose LogFactory Dear tomcat developers, I think it might be very beneficial if container exposed log factory e.g public Log getLog(String name) so all classes using context logger can get their own named loggers rather then sharing context's single one. As it stands now, for those classes there is no way to set logging level independently. If those classes created their own named loggers from context log factory they can be configured independently. If we do not use context logger (just typical commons logging pattern) it is not possible to predict where logging output will go as it depends very much on which class loader loaded this class. For example we have many extensions to tomcat which are loaded by server class loader on per context basis. We would love to be able to channel all their output to their respective context's log file rather the the global one but retain ability to have separate channels (loggers) for different components I would appreciate any suggestions Thank you Alex - 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]
DO NOT REPLY [Bug 33307] - jspInit() method is throwing an NamingException when extracting a factory object from a JNDI context
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=33307. 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=33307 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 08:04 --- Created an attachment (id=14204) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14204action=view) it contains the required configuration(web.xml) as well as the sample application required for reproducing the problem -- 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]
