Tomcat Native binaries repository
Hi, As you might know due to the US export laws we are unable to deliver the binaries that include encryption software on any of our servers. Many Apache projects are suffering from that restriction, so we are not the only one :) Since TomcatNative uses OpenSSL for SLL protocol, delivering binaries would break such policy and probably make problems. Thanks to the courtesy of HEAnet, http://www.heanet.ie (Ireland's National Education and Research Network), and especially Colm MacCárthaigh, we have established an alternate download site: http://ftp.heanet.ie/pub/tomcat/ We have generic SSH username, and committers interested in building binaries can send me their SSH key, so I can send it to Colm. Once again... Many thanks to those guys! Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 tomcat.nsi
remm2005/08/03 01:22:39 Modified:.tomcat.nsi Log: - Update locations for native .dll. Revision ChangesPath 1.81 +3 -3 jakarta-tomcat-5/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v retrieving revision 1.80 retrieving revision 1.81 diff -u -r1.80 -r1.81 --- tomcat.nsi2 Aug 2005 19:08:07 - 1.80 +++ tomcat.nsi3 Aug 2005 08:22:39 - 1.81 @@ -203,11 +203,11 @@ SectionIn 3 - NSISdl::download /TIMEOUT=3 http://blabla/tcnative-1-1.1.0.dll $INSTDIR\bin\tcnative-1.dll + NSISdl::download /TIMEOUT=3 http://ftp.heanet.ie/pub/tomcat/native/1.1.0/binaries/win32/tcnative-1.dll $INSTDIR\bin\tcnative-1.dll Pop $0 StrCmp $0 success success SetDetailsView show -DetailPrint download failed from http://blabla/tcnative-1-1.1.0.dll: $0 +DetailPrint download failed from http://ftp.heanet.ie/pub/tomcat/native/1.1.0/binaries/win32/tcnative-1.dll: $0 success: ClearErrors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Janino - an Alternative to the Eclipse Java compiler
Hi all: I got this link from the Geronimo-dev discussion list, but I haven't tried it out yet: http://www.janino.net/use.html#tomcat_compiler -- Sriram Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35993] New: - 1.4-compat file contains wrong path information
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=35993. 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=35993 Summary: 1.4-compat file contains wrong path information Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I´d installed Tomcat 5.5.9 on my XP machine. For running with JRE 1.4 I had to install the 1.4-compat file: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/setup.html If using a J2SE 1.4 JRE, the compatibility package must be downloaded and expanded inside the folder where Tomcat was installed. -- there is no link to get that package, no link on the download page either (I found it via browsing the archive) expanded inside the folder where Tomcat was installed The archive contains as root director jakarta-tomcat-5.5.9 which is not the directory I had chosen in the installer (c:\tomcat\5.5.9). -- change the directory structure inside the zip from: jakarta-tomcat-5.5.9\LICENSE... , jakarta-tomcat-5.5.9\bin\jmx.jar to : \LICENSE... , bin\jmx.jar -- 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 35993] - 1.4-compat file contains wrong path information
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=35993. 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=35993 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 11:45 --- Nothing to fix 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]
Standart Sessions included in the SSO Session expire
I have a conceptual question wrt the Single Sign On behaviour. Let's assume there are two applications /app1 and /app2, and there is a SSO setup on them both. Now, user logs into the /app1 (which requires authentication) and /app2 (which uses SSO Cookie, no authentication then), and later on makes use of only one of them (say: /app1) for quite a long time, so that this period outlives the session expiry date of the unused application (/app2). Provided that both applications establish their own sessions the one created in the scope of constantly used application (/app1) wouldn't expire, while the second one definitely would. Now the question: As both sessions are gathered into a higher-level SSO session, would it be against the specification if *all* standard sessions were aged (eg. by calling session.access()) on each request containing valid SSO cookie? I suggest that there should be a flag on the SSO Valve, that is org.apache.catalina.authenticator.SingleSignOn allowing users to specify the behaviour. If nobody objects, I could try to provide apropriate patch. cheers, /dd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Standard sessions included in the SSO session expire
I have a conceptual question wrt the Single Sign On behaviour. Let's assume there are two applications /app1 and /app2, and there is a SSO setup on them both. Now, user logs into the /app1 (which requires authentication) and /app2 (which uses SSO Cookie, no authentication then), and later on makes use of only one of them (say: /app1) for quite a long time, so that this period outlives the session expiry date of the unused application (/app2). Provided that both applications establish their own sessions the one created in the scope of constantly used application (/app1) wouldn't expire, while the second one definitely would. Now the question: As both sessions are gathered into a higher-level SSO session, would it be against the specification if *all* standard sessions were aged (eg. by calling session.access()) on each request containing valid SSO cookie? I suggest that there should be a flag on the SSO Valve, that is org.apache.catalina.authenticator.SingleSignOn allowing users to specify the behaviour. If nobody objects, I could try to provide apropriate patch. cheers, /dd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35993] - 1.4-compat file contains wrong path information
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=35993. 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=35993 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 12:05 --- 1. the website 2. the build file -- 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 35993] - 1.4-compat file contains wrong path information
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=35993. 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=35993 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX -- 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: Standart Sessions included in the SSO Session expire
Dominik Drzewiecki wrote: I have a conceptual question wrt the Single Sign On behaviour. Let's assume there are two applications /app1 and /app2, and there is a SSO setup on them both. Now, user logs into the /app1 (which requires authentication) and /app2 (which uses SSO Cookie, no authentication then), and later on makes use of only one of them (say: /app1) for quite a long time, so that this period outlives the session expiry date of the unused application (/app2). Provided that both applications establish their own sessions the one created in the scope of constantly used application (/app1) wouldn't expire, while the second one definitely would. Now the question: As both sessions are gathered into a higher-level SSO session, would it be against the specification if *all* standard sessions were aged (eg. by calling session.access()) on each request containing valid SSO cookie? I suggest that there should be a flag on the SSO Valve, that is org.apache.catalina.authenticator.SingleSignOn allowing users to specify the behaviour. If nobody objects, I could try to provide apropriate patch. The purpose of single sign on is to deal with authentication issues, not modify session lifecycle. Overall, you really need to design your web applications as if they were independent. Of course, it is fine to implement your own custom behavior should you need it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35648] - Using Anonymous Loggers with JULI causes NPE
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=35648. 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=35648 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 14:08 --- My point of reporting this issue was for usage outside of Tomcat and using Anonymous loggers. You could tel me that is is unsupported. With the release of juli that comes with 5.5.9 the error I reported allways happens. I have tested with the new release 5.5.10-alpha and this is solved, so something was changed. You could considering having JULI as a jakarta-commons sub-project, or as a subroject of logging.apache.org. -- 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 35648] - Using Anonymous Loggers with JULI causes NPE
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=35648. 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=35648 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 14:48 --- (In reply to comment #2) My point of reporting this issue was for usage outside of Tomcat and using Anonymous loggers. You could tel me that is is unsupported. With the release of juli that comes with 5.5.9 the error I reported allways happens. I have tested with the new release 5.5.10-alpha and this is solved, so something was changed. You could considering having JULI as a jakarta-commons sub-project, or as a subroject of logging.apache.org. java.util.logging is designed to be pluggable by replacing the the sigleton LogManager, and providing one which is tuned for your application/container/etc. So the (only) LogManager provided is tuned for the Tomcat classloading hierarchy. For other usages, there's of course the possibility of reusing portions of the code, but it would likely be better to use another LogManager with a different behavior. A JULI project elsewhere would be fine, as a collection of: - various LogManager implementations - Handler implementations - also implementations of other accessory components like formatters -- 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: Standart Sessions included in the SSO Session expire
Remy Maucherat [EMAIL PROTECTED] wrote: Dominik Drzewiecki wrote: I have a conceptual question wrt the Single Sign On behaviour. Let's assume there are two applications /app1 and /app2, and there is a SSO setup on them both. Now, user logs into the /app1 (which requires authentication) and /app2 (which uses SSO Cookie, no authentication then), and later on makes use of only one of them (say: /app1) for quite a long time, so that this period outlives the session expiry date of the unused application (/app2). Provided that both applications establish their own sessions the one created in the scope of constantly used application (/app1) wouldn't expire, while the second one definitely would. Now the question: As both sessions are gathered into a higher-level SSO session, would it be against the specification if *all* standard sessions were aged (eg. by calling session.access()) on each request containing valid SSO cookie? I suggest that there should be a flag on the SSO Valve, that is org.apache.catalina.authenticator.SingleSignOn allowing users to specify the behaviour. If nobody objects, I could try to provide apropriate patch. The purpose of single sign on is to deal with authentication issues, not modify session lifecycle. Overall, you really need to design your web applications as if they were independent. The applications are indeed independant. However the current implementation of the SingleSignOn valve *does* modify the session - whenever user logs out of one of the apps (I assume this means the invocation od session.invalidate()) the rest of the sessions gathered under the same SSOid get destroyed too. I just wanted to say that if we destroy sessions of the other applications, we should also keep-them-alive, for the sake of consistency. Just my $.02 Of course, it is fine to implement your own custom behavior should you need it. Of course, I know it ;) I was just wondering if a fix/enhancement to the current behaviour might be required/welcome. cheers, /dd PS. Sorry for posting twice, damn webmail client ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34611] - Logging in servlet/jsp not working via java.util.logging.Logger.global
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=34611.
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=34611
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Additional Comments From [EMAIL PROTECTED] 2005-08-03 16:16 ---
This is also not working in release 5.5.10 alpha release on 24 of July (afetr
the last post in this bug)
Logging with:
% java.util.logging.Logger.getLogger(foo).severe(printed); %
Instead of the logger name named foo, this will be logger under the logger
named org.apache.jsp.${JSP_NAME_HERE} _jspService
Where ${JSP_NAME_HERE} is the name of the JSP where the log fragment is located.
--
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 34611] - Logging in servlet/jsp not working via java.util.logging.Logger.global
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=34611. 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=34611 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 16:26 --- %= java.util.logging.Logger.getLogger(foo).getName() % % java.util.logging.Logger.getLogger(foo).severe(printed); % Please do not reopen the report. -- 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 35901] - jk 1.2.14 - Worker stop action does not hold
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=35901. 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=35901 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |major -- 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 36001] New: - @include file encoding problem
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=36001. 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=36001 Summary: @include file encoding problem Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] If I use %@ include file=foo2.jsp% in foo.jsp, where foo2.jsp contains a different encoded text other than 8859, seems that foo.jsp cannot display the correct text. If I put foo2.jsp literally in foo.jsp without using include directive, everthing works fine. -- 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]
Subversion migration update
Hi all, Just a quick note to keep you updated with my progress with Subversion. jakarta-watchdog and jakarta-watchdog-4.0 should be migrated shortly. As a result of some questions from Henri, the final structure has been modified slightly to make it clearer which tags and branches belong to which major Tomcat version. The performance comparison between CVS and SVN is in the early stages and I will post some results once I have a more complete set. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
