cvs commit: jakarta-tomcat-5 tomcat.nsi

[mturk]

mturk   2005/08/03 23:52:35

  Modified:.tomcat.nsi
  Log:
  Use tomcat vhost from heanet.
  
  Revision  ChangesPath
  1.82  +3 -3  jakarta-tomcat-5/tomcat.nsi
  
  Index: tomcat.nsi
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v
  retrieving revision 1.81
  retrieving revision 1.82
  diff -u -r1.81 -r1.82
  --- tomcat.nsi3 Aug 2005 08:22:39 -   1.81
  +++ tomcat.nsi4 Aug 2005 06:52:35 -   1.82
  @@ -203,11 +203,11 @@
   
 SectionIn 3
   
  -  NSISdl::download /TIMEOUT=3 
http://ftp.heanet.ie/pub/tomcat/native/1.1.0/binaries/win32/tcnative-1.dll 
$INSTDIR\bin\tcnative-1.dll
  +  NSISdl::download /TIMEOUT=3 
http://tomcat.heanet.ie/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://ftp.heanet.ie/pub/tomcat/native/1.1.0/binaries/win32/tcnative-1.dll: $0"
  +DetailPrint "download failed from 
http://tomcat.heanet.ie/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]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityClassLoad.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

billbarker2005/08/03 23:07:46

  Modified:catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
  Log:
  Fix CNFE when starting in a sandbox.
  
  After the last refactoring, the Jk-Java Connector no longer has need of PAs.  If this changes, the method can always be added back.


This reminds me I need to test security more often.

I look in the preload list for HTTP, and I see a few PAs there. One of 
them is:


// End the response status line
if (System.getSecurityManager() != null){
   AccessController.doPrivileged(
new PrivilegedAction(){
public Object run(){
buf[pos++] = Constants.CR;
buf[pos++] = Constants.LF;
return null;
}
}
   );
} else {
buf[pos++] = Constants.CR;
buf[pos++] = Constants.LF;
}

I think this is fairly funny code. The contents of the PA were a bit 
different originally, but I don't see why a PA was ever needed. 
Similarly, the other PA is needed because the HttpMessages is a bundle 
which will need to be loaded, while the loading should be done during 
the init of the connector (like HttpMessages.getMessage(200)).


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Next Release 5.5.11?

[Thorsten Kamann]

Hello,

the current release is 5.5.10-alpha. Are there plans to change this in a 
5.5.10 or make a 5.5.11?
The bug #35894 (http://issues.apache.org/bugzilla/show_bug.cgi?id=35894) Bill 
has resolved today is a stopper, because the Tomcat cannot start with 
SecurityManager enabled.

Thorsten

-- 
Thorsten Kamann
Email: [EMAIL PROTECTED]
ICQ: 40746578
Yahoo: ThorQue

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[billbarker]

billbarker2005/08/03 23:17:07

  Modified:webapps/docs changelog.xml
  Log:
  doc changes
  
  Revision  ChangesPath
  1.351 +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.350
  retrieving revision 1.351
  diff -u -r1.350 -r1.351
  --- changelog.xml 2 Aug 2005 18:12:05 -   1.350
  +++ changelog.xml 4 Aug 2005 06:17:07 -   1.351
  @@ -65,6 +65,9 @@
 
   34794: Update connector documentation to include 
clientAuth attribute. (yoavs)
 
  +  
  +35894: Fix CNFE when starting in a sandbox. (billbarker)
  +  
   
 
 
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35894] - Tomcat does not start with security enabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=35894


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-08-04 08:08 ---
This is fixed now in the CVS and will appear in 5.5.11.

-- 
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-catalina/catalina/src/share/org/apache/catalina/security SecurityClassLoad.java

[billbarker]

billbarker2005/08/03 23:07:46

  Modified:catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
  Log:
  Fix CNFE when starting in a sandbox.
  
  After the last refactoring, the Jk-Java Connector no longer has need of PAs.  
If this changes, the method can always be added back.
  
  Revision  ChangesPath
  1.18  +1 -12 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java
  
  Index: SecurityClassLoad.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- SecurityClassLoad.java24 Jul 2004 07:07:37 -  1.17
  +++ SecurityClassLoad.java4 Aug 2005 06:07:46 -   1.18
  @@ -43,7 +43,6 @@
   loadJavaxPackage(loader);
   loadCoyotePackage(loader);
   loadHttp11Package(loader);
  -loadJkPackage(loader);
   }
   
   
  @@ -198,15 +197,5 @@
"Response$3");
   }
   
  -private final static void loadJkPackage(ClassLoader loader)
  -throws Exception {
  -String basePackage = "org.apache.jk.";
  -loader.loadClass
  -(basePackage +
  - "server.JkCoyoteHandler$1");
  -loader.loadClass
  -(basePackage +
  - "server.JkCoyoteHandler$StatusLinePrivilegedAction");
  -}
   }
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Subversion migration update

[Mark Thomas]

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]

DO NOT REPLY [Bug 36001] New: - @include file encoding problem

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

DO NOT REPLY [Bug 35901] - jk 1.2.14 - Worker stop action does not hold

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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 34611] - Logging in servlet/jsp not working via java.util.logging.Logger.global

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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 34611] - Logging in servlet/jsp not working via java.util.logging.Logger.global

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

Re: Standart Sessions included in the SSO Session expire

[Dominik Drzewiecki]

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 35648] - Using Anonymous Loggers with JULI causes NPE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

DO NOT REPLY [Bug 35648] - Using Anonymous Loggers with JULI causes NPE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

Re: Standart Sessions included in the SSO Session expire

[Remy Maucherat]

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 35993] - 1.4-compat file contains wrong path information

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

DO NOT REPLY [Bug 35993] - 1.4-compat file contains wrong path information

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

Standard sessions included in the SSO session expire

[Dominik Drzewiecki]

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]

Standart Sessions included in the SSO Session expire

[Dominik Drzewiecki]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

DO NOT REPLY [Bug 35993] New: - 1.4-compat file contains wrong path information

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]

Janino - an Alternative to the Eclipse Java compiler

[Sriram N]

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]

cvs commit: jakarta-tomcat-5 tomcat.nsi

[remm]

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]

Tomcat Native binaries repository

[Mladen Turk]

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]