[5.5] compile error -- build.xml
Hi,
Yoav removed the regexp downloadtgz target from build.xml:
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-5/build.xml?r1=1.202r2=1.203diff_format=h
Well, the webapps admin is complaining about the missing
jakarta-regexp-1.3.jar.
Reverting this task helps a lot :).
So adding to download task:
antcall target=downloadgz
param name=sourcefile value=${regexp.loc}/
param name=destfile value=${regexp.jar}/
/antcall
Regards,
MT.
smime.p7s
Description: S/MIME Cryptographic Signature
DO NOT REPLY [Bug 30533] - search dtd with system location in CATALINA_BASE/bin
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=30533. 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=30533 search dtd with system location in CATALINA_BASE/bin --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 07:42 --- To your first question. yes, on .28 the error also occure. The base for the dtd is with start on command box the dir where the startup script is locatet and with service it is winnt\system32 dir. I use a small testcase. One servlet which is calling a class with a sax parser. The stack is follow: java.io.FileNotFoundException: D:\jakarta-tomcat-5.0.28\bin\WebRequests.dtd (Das System kann die angegebene Datei nicht finden) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at java.io.FileInputStream.init(FileInputStream.java:66) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection .java:69) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLCon nection.java:156) at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown So urce) at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(Unknown Source ) at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(Unknown Sourc e) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch( Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un known Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at AllXMLParser.parse(AllXMLParser.java:59) at AllXMLParser.parse(AllXMLParser.java:124) at xml.processRequest(xml.java:47) at xml.doGet(xml.java:71) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv eContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(Standard ContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv eContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv eContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv eContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv eContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:16 0) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ssConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java :577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) For the second hint. I'll read your link. regards Dietmar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30533] - search dtd with system location in CATALINA_BASE/bin
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=30533. 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=30533 search dtd with system location in CATALINA_BASE/bin --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 08:18 --- The Link don't work but I found the information. http://www.saxproject.org/apidoc/org/xml/sax/package-summary.html#package_description Ok. It could be possible that the setting from sax standard features solve the problem. I think resolve-dtd-uris is a good candidate for this problem. But when I set the feature I get follow exception: org.xml.sax.SAXNotRecognizedException: Feature 'http://xml.org/sax/features/reso lve-dtd-uris' is not recognized. at org.apache.xerces.parsers.AbstractSAXParser.setFeature(Unknown Source ) at org.apache.xerces.jaxp.SAXParserImpl.setFeatures(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParserImpl(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.setFeature(Unknown Source ) at AllXMLParser.parse(AllXMLParser.java:55) at AllXMLParser.parse(AllXMLParser.java:130) at xml.processRequest(xml.java:47) at xml.doGet(xml.java:71) The code is: SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setFeature(http://xml.org/sax/features/resolve-dtd-uris,false); factory.setValidating(true); parser = factory.newSAXParser(); Set other features works well. I don't know the version from the underlying xerces impl. but in the doc they speak from SAX2 Standard Feature Flags. regards Dietmar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 tomcat.nsi build.xml
mturk 2004/09/03 01:18:16
Modified:.tomcat.nsi build.xml
Log:
Added dotted version for the installer.
This enables strange versions like 5.5-rc1, etc...
The dotted version has to be a four numbers separated with dots.
Revision ChangesPath
1.55 +2 -2 jakarta-tomcat-5/tomcat.nsi
Index: tomcat.nsi
===
RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- tomcat.nsi2 Sep 2004 13:16:52 - 1.54
+++ tomcat.nsi3 Sep 2004 08:18:15 - 1.55
@@ -19,7 +19,7 @@
VIAddVersionKey ProductVersion @VERSION@
VIAddVersionKey Comments jakarta.apache.org/tomcat
VIAddVersionKey InternalName [EMAIL PROTECTED]@.exe
- VIProductVersion @[EMAIL PROTECTED]
+ VIProductVersion @DOTTEDVER@
!include MUI.nsh
!include StrFunc.nsh
1.208 +2 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.207
retrieving revision 1.208
diff -u -r1.207 -r1.208
--- build.xml 2 Sep 2004 13:16:52 - 1.207
+++ build.xml 3 Sep 2004 08:18:15 - 1.208
@@ -14,6 +14,7 @@
property name=name value=Apache Tomcat /
property name=year value=2004 /
property name=version value=5.5-dev /
+ property name=dottedver value=5.5.0.1 /
property name=project value=jakarta-tomcat /
property name=final.namevalue=${project}-${version} /
property name=final-src.namevalue=${project}-${version}-src /
@@ -1507,6 +1508,7 @@
copy file=${jtc.home}/procrun/bin/tomcat5w.exe
tofile=${tomcat.dist}/bin/tomcat5w.exe /
filter token=VERSION value=${version}/
+filter token=DOTTEDVER value=${dottedver}/
copy file=tomcat.nsi tofile=${tomcat.dist}/tomcat.nsi
filtering=true/
exec dir=${tomcat.dist} executable=${nsis.exe}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[5.5] Using dotted version naming
Hi, I've just bumped on a installer problem caused by the fact hat the current tomcat version has changed to '5.5-dev'. I was wondering if we can adopt some version naming like consisting of 4 digit groups. Something like: A.B.C.D A.B are product major and minor (so 5.5). If the C is odd number the D is build number. If the C is even number it's a release and D is zero if stable, 1 if alpha 2 if beta. So: 5.5.1.1 -- 5.5.1.XX development. 5.5.2.0 - first public stable release. 5.5.3.1 - next dev releases. 5.5.4.0 - 5.5.4 release. (Let's vote). 5.5.4.1 - 5.5.4-alpha release. (Not that stable so voted as alpha). etc... Any comments? MT. smime.p7s Description: S/MIME Cryptographic Signature
[ #BJO-39658-731]: Document
Dette er en automatisk svar-epost i fra Panda Software Norge - Support. Din sak har fått nr: BJO-39658-731 Du vil motta svar på denne epost adressen når vi har fått behandlet saken. Henvis til nummeret ovenfor ved telefonhenvendelser. Ved videre henvendelser om denne saken svarer du på denne e-posten eller sender en ny mail til [EMAIL PROTECTED] med: [#BJO-39658-731] i subjekt/emne feltet. This is an automatic response from Panda Software Norway. Your case has been assigned the following number: BJO-39658-731 You will receive a reply to your question as soon as possible. Further contact regarding this matter should be done by replying to the email(s) received from us, without changing the subject field. --- Panda Software Norge - Support --- [EMAIL PROTECTED] tlf: 62 53 96 80 http://www.pandasoftware.no http://www.pandasoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Using dotted version naming
Mladen Turk wrote: Hi, I've just bumped on a installer problem caused by the fact hat the current tomcat version has changed to '5.5-dev'. I was wondering if we can adopt some version naming like consisting of 4 digit groups. Something like: A.B.C.D A.B are product major and minor (so 5.5). If the C is odd number the D is build number. If the C is even number it's a release and D is zero if stable, 1 if alpha 2 if beta. So: 5.5.1.1 -- 5.5.1.XX development. 5.5.2.0 - first public stable release. 5.5.3.1 - next dev releases. 5.5.4.0 - 5.5.4 release. (Let's vote). 5.5.4.1 - 5.5.4-alpha release. (Not that stable so voted as alpha). etc... Any comments? I don't see any benefits, other that forcing Yoav to recompile the installer all the time ;) (ok, maybe it's not a benefit, poor Yoav) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin build.xml
remm2004/09/03 02:33:06
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve
RemoteHostValveForm.java ValveUtil.java
RemoteAddrValveForm.java
webapps/admin build.xml
Log:
- The core doesn't use regexp anymore, so this shouldn't either.
Revision ChangesPath
1.6 +9 -9
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve/RemoteHostValveForm.java
Index: RemoteHostValveForm.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve/RemoteHostValveForm.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- RemoteHostValveForm.java 27 Feb 2004 14:59:06 - 1.5
+++ RemoteHostValveForm.java 3 Sep 2004 09:33:06 - 1.6
@@ -19,9 +19,9 @@
import java.lang.IllegalArgumentException;
import java.net.InetAddress;
import java.util.List;
+import java.util.regex.Pattern;
import javax.servlet.http.HttpServletRequest;
-import org.apache.regexp.RE;
import org.apache.struts.action.ActionError;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionForm;
@@ -57,12 +57,12 @@
/**
* The set of codeallow/code regular expressions we will evaluate.
*/
-private RE allows[] = new RE[0];
+private Pattern allows[] = new Pattern[0];
/**
* The set of codedeny/code regular expressions we will evaluate.
*/
-private RE denies[] = new RE[0];
+private Pattern denies[] = new Pattern[0];
// - Properties
@@ -195,24 +195,24 @@
}
for (int i = 0; i denies.length; i++) {
-if (denies[i].match(host)) {
+if (denies[i].matcher(host).matches()) {
if (allows.length 1) {
errors.add(deny,
new ActionError(error.denyHost));
}
for (int j = 0; j allows.length; j++) {
-if (!allows[j].match(host)) {
+if (!allows[j].matcher(host).matches()) {
errors.add(deny,
new ActionError(error.denyHost));
}
}
-} else if (denies[i].match(ip)) {
+} else if (denies[i].matcher(ip).matches()) {
if (allows.length 1) {
errors.add(deny,
new ActionError(error.denyHost));
}
for (int j = 0; j allows.length; j++) {
-if (!allows[j].match(ip)) {
+if (!allows[j].matcher(ip).matches()) {
errors.add(deny,
new ActionError(error.denyHost));
}
@@ -227,7 +227,7 @@
}
for (int i = 0; i allows.length; i++) {
-if (allows[i].match(host)) {
+if (allows[i].matcher(host).matches()) {
allowMatch = true;
}
}
1.13 +10 -10
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve/ValveUtil.java
Index: ValveUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve/ValveUtil.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ValveUtil.java10 Jul 2004 06:56:16 - 1.12
+++ ValveUtil.java3 Sep 2004 09:33:06 - 1.13
@@ -21,6 +21,8 @@
import java.util.Iterator;
import java.util.Locale;
import java.io.IOException;
+import java.util.regex.Pattern;
+import java.util.regex.PatternSyntaxException;
import javax.management.Attribute;
import javax.management.MBeanServer;
import javax.management.MBeanServerFactory;
@@ -33,8 +35,6 @@
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
-import org.apache.regexp.RE;
-import org.apache.regexp.RESyntaxException;
import org.apache.struts.Globals;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionError;
@@ -207,14 +207,14 @@
* @exception IllegalArgumentException if one of the patterns has
* invalid syntax
*/
-public static RE[] precalculate(String list)
+public static Pattern[] precalculate(String list)
throws IllegalArgumentException {
if (list == null)
-
DO NOT REPLY [Bug 29182] - Jasper locks jar files when compiling JSPs through Ant
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=29182. 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=29182 Jasper locks jar files when compiling JSPs through Ant --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 10:12 --- Yoav, I don't think the usage of JDT will help here, because this is not a Java compiler issue, as I wrote in my comment on 2004-05-25. The problem occurs in the JSP - servlet translation phase, not in the servlet - class compilation. Specifically, I believe the problem is in method JspC.initClassLoader(...), which creates a new URLClassLoader. Using a different classloader that does not lock jar files (e.g. WebappClassLoader from Catalina) would fix this issue, IMHO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Helen Aldridge/APRA/AU is out of the office.
I will be out of the office starting 03/09/2004 and will not return until 09/09/2004. Dear Member - we are currently on a training conference and will be available on Thursday 9th Sept please call 9426 5200 for any urgent inquries ** This electronic mail, including any attachments, is intended for the addressee only and may contain information that is either confidential or subject to legal professional privilege. Unauthorised reproduction, use or disclosure of the contents of this mail is prohibited. If you have received this mail in error, please delete it from your system immediately and notify APRA Limited at the address below or the email address above. APRA Limited 6-12 Atchison Street St Leonards NSW 2065 **
DO NOT REPLY [Bug 29182] - Jasper locks jar files when compiling JSPs through Ant
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=29182. 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=29182 Jasper locks jar files when compiling JSPs through Ant [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 10:19 --- This is really getting ridiculous. -1 for adding workarounds to address broken implementation in the JVM. (BTW, I never noticed the behavior you describe) Instead, you should ask your employer to fix *their* bug. Please don't reopen this report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30984] - Add an ability to compile JSPs to specified target JVM
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=30984. 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=30984 Add an ability to compile JSPs to specified target JVM [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 10:36 --- Based on mu recent experience, javac params source and target are interrelated. For example, the default source version for the 5.0 RC b63 is 1.5 which implies 1.5 as a target. For example using ant 1.6.2 on j2sdk1.5 (hell, cannot get used to switching to 5.0, either can Sun, I suppose ;) the following javac target=1.4 ... / results in: [javac] javac: target release 1.4 conflicts with default source release 1.5 Providing source attribute to ant's javac task forces compiler to downgrade to 1.4 sources. javac target=1.4 source=1.4 ... / I'd be more than delighted if you could also provide the source parameter in the same manner as you have done with the compilerTargetVM. BTW, I have no idea if this also affects JDT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Kinda Urgent: Huge Temporary Files (2BG) Fill Up Root Partition (mrfxxxxx.tmp files?)
Hello, Someone on the user list recommended I post my question on the developer list. Any help would be greatly appreciated! I've spent about 5 hours researching this myself--including the mailing list archives--and have yet to find any references let alone solutions. There are no references to mrf files that are causing me grief. This posting is my only hope! :) Here's the scoop: Massively HUGE .tmp files grow in this directory: /var/cache/tomcat4/temp Here is an example: -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:21 mrf20758.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:20 mrf20757.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:19 mrf20756.tmp -rw-r--r--1 tomcat4 tomcat4 2272915456 Sep 2 11:19 mrf20744.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:17 mrf20755.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:17 mrf20754.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:16 mrf20753.tmp I don't know what these files are for nor why some of them grow to over 2GB. It's kinda urgent because this kills our server every 24 hours or so. It forces me to stop tomcat, delete the files, then re-start. Sometimes I have to do a kill -9 on the tomcat process because the process is apparently stuck still trying to write yet more bytes to these files! Incidently, we have another server with the same directory, but there are only just a few of these mrf files and they don't grow to be very big--so, it's not a problem on the other server. Also incidently, our Java program uses a lot of memory which causes frequent and long garbage collections. Are these related? Can anyone help? What are these files for? Peter Alvin mobile 719-210-3858 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30984] - Add an ability to compile JSPs to specified target JVM
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=30984. 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=30984 Add an ability to compile JSPs to specified target JVM --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 11:04 --- We're waiting for your patches :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Using dotted version naming
Remy Maucherat wrote: Mladen Turk wrote: I was wondering if we can adopt some version naming like consisting of 4 digit groups. I don't see any benefits, other that forcing Yoav to recompile the installer all the time ;) Well, when rolling out any release, this still has to be done. Whether the name of the release (or interim) build would be 5.5-whatever, the 'ant release' has to be run. Anyhow, IMO it would give more control over tags, naming, etc. Take for example the current 5.0.28. After the release I've found out that the win installer wrongly set the tmpdir (issue already resolved in the HEAD). Since this has nothing to do with the core itself, simply rolling out the 5.0.28.1 would help, cause it's the same release but with the 'patchlevel 1'. It would also offer the option to include the 'critical' updates, without the need for a complete release, so that we could increase the release time frame, but still keep bugfixes. Also having some release voted as stable, will not require another vote just to resolve some bug fix, cause no new features would be added. Right now we are both bugfixing together with the new features been added in the meantime (with it's own bugs :)). Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: [5.5] Using dotted version naming
Mladen Turk wrote: Remy Maucherat wrote: Mladen Turk wrote: I was wondering if we can adopt some version naming like consisting of 4 digit groups. I don't see any benefits, other that forcing Yoav to recompile the installer all the time ;) Well, when rolling out any release, this still has to be done. Whether the name of the release (or interim) build would be 5.5-whatever, the 'ant release' has to be run. Anyhow, IMO it would give more control over tags, naming, etc. Take for example the current 5.0.28. After the release I've found out that the win installer wrongly set the tmpdir (issue already resolved in the HEAD). Since this has nothing to do with the core itself, simply rolling out the 5.0.28.1 would help, cause it's the same release but with the 'patchlevel 1'. It would also offer the option to include the 'critical' updates, without the need for a complete release, so that we could increase the release time frame, but still keep bugfixes. Also having some release voted as stable, will not require another vote just to resolve some bug fix, cause no new features would be added. Right now we are both bugfixing together with the new features been added in the meantime (with it's own bugs :)). Ok, if you really want it, we can switch to a a.b.c.d numbering. I still think it's useless, though. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29182] - Jasper locks jar files when compiling JSPs through Ant
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=29182. 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=29182 Jasper locks jar files when compiling JSPs through Ant --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 11:35 --- Remy, I don't understand what's ridiculous about this - this is a legitimate bug. Let's be constructive, please. -1 for adding workarounds to address broken implementation in the JVM. Doesn't WebappClassLoader already have workarounds to prevent locking jars and to allow redeployment? There is code in Tomcat that bypasses URLConnection, so why apply different measures in this case? Also, I believe Tomcat should strive to work with taday's existing JDKs. FYI, a bug was submitted against JDK, but it was not resolved: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041014 BTW, I never noticed the behavior you describe Are you saying you are not able to reproduce this usign the test case I submitted? One practical real-world situation when this may arise is when you run Ant scripts that compile JSPs in IDEs. IDEs generally run Ant in their own VM; they don't launch a separate one. So any jars that are locked by jspc will not be closed after the Ant build completes. Next time you run ant clean (in your IDE), you hit this bug. And here I am not only talking about NetBeans, Eclipse also does it this way, I believe. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29182] - Jasper locks jar files when compiling JSPs through Ant
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=29182. 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=29182 Jasper locks jar files when compiling JSPs through Ant --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 12:23 --- I maintain my -1. Fixing this yould be *etremely* painful. The WCL is a different solution, for different needs. There are two workarounds: a) fork your compilation in a separate VM. You should also be able to do that by putting the jspc task in a seprate target, and using a java call to run this target. You acknowledge something similar as a solution, but unfortunately, it is not clean enough for you. This kind of answer does annoy me greatly, as well as your insistence at abusing Yoav's time on this issue which should be handled in the JDK. b) use the Jasper internals, which will allow you to provide your own classloader (which I hope, won't lock JARs). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.5] compile error -- build.xml
Hola,
For once, it wasn't me who broke the build ;) Remy removed that and I
think it will be gone again soon, as we've morving away from the
jakarta-regexp dependency in favor of JDK 1.4 java.util.regex.
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Mladen Turk [mailto:[EMAIL PROTECTED]
Sent: Friday, September 03, 2004 3:33 AM
To: Tomcat Developers List
Subject: [5.5] compile error -- build.xml
Hi,
Yoav removed the regexp downloadtgz target from build.xml:
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-
5/build.xml?r1=1.202r2=1.203diff_format=h
Well, the webapps admin is complaining about the missing
jakarta-regexp-1.3.jar.
Reverting this task helps a lot :).
So adding to download task:
antcall target=downloadgz
param name=sourcefile value=${regexp.loc}/
param name=destfile value=${regexp.jar}/
/antcall
Regards,
MT.
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.5] Using dotted version naming
Hola, I'm 0 on it. I think we (and numerous other projects, large and small) have been doing fine with a.b.c, and a.b.c.d is overkill. But if it's automated, and we keep using a.b.c for normal releases and use a.b.c.d only for patches, then it's OK. Yoav Shapira Millennium Research Informatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 7:30 AM To: Tomcat Developers List Subject: Re: [5.5] Using dotted version naming Mladen Turk wrote: Remy Maucherat wrote: Mladen Turk wrote: I was wondering if we can adopt some version naming like consisting of 4 digit groups. I don't see any benefits, other that forcing Yoav to recompile the installer all the time ;) Well, when rolling out any release, this still has to be done. Whether the name of the release (or interim) build would be 5.5-whatever, the 'ant release' has to be run. Anyhow, IMO it would give more control over tags, naming, etc. Take for example the current 5.0.28. After the release I've found out that the win installer wrongly set the tmpdir (issue already resolved in the HEAD). Since this has nothing to do with the core itself, simply rolling out the 5.0.28.1 would help, cause it's the same release but with the 'patchlevel 1'. It would also offer the option to include the 'critical' updates, without the need for a complete release, so that we could increase the release time frame, but still keep bugfixes. Also having some release voted as stable, will not require another vote just to resolve some bug fix, cause no new features would be added. Right now we are both bugfixing together with the new features been added in the meantime (with it's own bugs :)). Ok, if you really want it, we can switch to a a.b.c.d numbering. I still think it's useless, though. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Kinda Urgent: Huge Temporary Files (2BG) Fill Up Root Partition (mrfxxxxx.tmp files?)
Hi, Tomcat doesn't produce these, they must come from one of your apps or you have a funky installation. Yoav Shapira Millennium Research Informatics -Original Message- From: Peter Alvin [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 6:38 AM To: [EMAIL PROTECTED] Subject: Kinda Urgent: Huge Temporary Files (2BG) Fill Up Root Partition (mrfx.tmp files?) Hello, Someone on the user list recommended I post my question on the developer list. Any help would be greatly appreciated! I've spent about 5 hours researching this myself--including the mailing list archives--and have yet to find any references let alone solutions. There are no references to mrf files that are causing me grief. This posting is my only hope! :) Here's the scoop: Massively HUGE .tmp files grow in this directory: /var/cache/tomcat4/temp Here is an example: -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:21 mrf20758.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:20 mrf20757.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:19 mrf20756.tmp -rw-r--r--1 tomcat4 tomcat4 2272915456 Sep 2 11:19 mrf20744.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:17 mrf20755.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:17 mrf20754.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:16 mrf20753.tmp I don't know what these files are for nor why some of them grow to over 2GB. It's kinda urgent because this kills our server every 24 hours or so. It forces me to stop tomcat, delete the files, then re-start. Sometimes I have to do a kill -9 on the tomcat process because the process is apparently stuck still trying to write yet more bytes to these files! Incidently, we have another server with the same directory, but there are only just a few of these mrf files and they don't grow to be very big--so, it's not a problem on the other server. Also incidently, our Java program uses a lot of memory which causes frequent and long garbage collections. Are these related? Can anyone help? What are these files for? Peter Alvin mobile 719-210-3858 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29182] - Jasper locks jar files when compiling JSPs through Ant
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=29182. 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=29182 Jasper locks jar files when compiling JSPs through Ant --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 13:07 --- I agree these are both possible workarounds. However, they are not quite useful for end users of Tomcat: Re. a) This is indeed what we do in NetBeans 4.0. But if we are serious about it, then it should be at least described in http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html Re. b) An end user of Tomcat is not going to write her own classloader. If we know this would help, why not include and use such a classloader in Jasper directly? That way, ALL users will benefit, not just those who are able and willing to write their own classloader. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4543] - RMI fails if tomcat is installed in directory with white space
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=4543. 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=4543 RMI fails if tomcat is installed in directory with white space --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 13:07 --- Why is the resolution WONTFIX? Especially when there is an apparent fix in the comments below? Jamie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4543] - RMI fails if tomcat is installed in directory with white space
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=4543. 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=4543 RMI fails if tomcat is installed in directory with white space --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 13:08 --- Why is the resolution WONTFIX? Especially when there is an apparent fix in the comments below? Jamie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29182] - Jasper locks jar files when compiling JSPs through Ant
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=29182. 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=29182 Jasper locks jar files when compiling JSPs through Ant --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 13:17 --- -1. BTW, you're definitely not a regular user, you're embedding Jasper. It's the same when I'm embedding Eclipse JDT (which is a very good compiler) and providing it with a classloader (while I could choose to not care and feed it my classpath using a higher level - and much simpler - interface), because I have specific needs (and this way, since I assume the compiler would lock its JARs, I remain in control of the locking - to some extent: Windows sucks). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Using dotted version naming
Shapira, Yoav wrote: Hola, I'm 0 on it. I think we (and numerous other projects, large and small) have been doing fine with a.b.c, and a.b.c.d is overkill. But if it's automated, and we keep using a.b.c for normal releases and use a.b.c.d only for patches, then it's OK. You mention if it's automated, but I don't have a clue how to achieve this. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.5] Using dotted version naming
Hi,
I meant automated in the sense that there's something like
property name=dotted.version value=${version}.0 /
in jakarta-tomcat-5/build.xml to provide a good default. So we already have the
automation I mentioned, it's nothing fancy ;)
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Friday, September 03, 2004 9:17 AM
To: Tomcat Developers List
Subject: Re: [5.5] Using dotted version naming
Shapira, Yoav wrote:
Hola,
I'm 0 on it. I think we (and numerous other projects, large and small)
have been doing fine with a.b.c, and a.b.c.d is overkill. But if it's
automated, and we keep using a.b.c for normal releases and use a.b.c.d only
for patches, then it's OK.
You mention if it's automated, but I don't have a clue how to achieve
this.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Using dotted version naming
Shapira, Yoav wrote:
Hi,
I meant automated in the sense that there's something like
property name=dotted.version value=${version}.0 /
in jakarta-tomcat-5/build.xml to provide a good default. So we already have the automation I mentioned, it's nothing fancy ;)
I'm disappointed ;)
I was already having grand plans about how this could represent the
number of commits since the last tag, or something like that.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Using dotted version naming
Shapira, Yoav wrote: Hola, I'm 0 on it. I think we (and numerous other projects, large and small) have been doing fine with a.b.c, and a.b.c.d is overkill. But if it's automated, and we keep using a.b.c for normal releases and use a.b.c.d only for patches, then it's OK. Well, we actually have a single number right now (both 5.0 and 5.5 are fixed numbers). What I'm trying is to differentiate actual bugfxing from new release that adds extra functionality, optimization, etc... Anyhow, I just don't like those non-numeric 'x.x-dev' versions. Anything else is just fine :). Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
RE: [5.5] Using dotted version naming
Hi, The x.x-dev is a placeholder in build.xml. The Release Manager adds version=a.b.c to his/her build.properties when doing a release, thereby overriding the placeholder x.x-dev value. This is a common convention not just for Tomcat, but for almost every open source project I've worked on ;) Does something break if the version is non-numeric? A lot of projects also use the string RC or alpha or beta in the actual version name as well, although we don't do that for Tomcat. Yoav Shapira Millennium Research Informatics -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 10:46 AM To: Tomcat Developers List Subject: Re: [5.5] Using dotted version naming Shapira, Yoav wrote: Hola, I'm 0 on it. I think we (and numerous other projects, large and small) have been doing fine with a.b.c, and a.b.c.d is overkill. But if it's automated, and we keep using a.b.c for normal releases and use a.b.c.d only for patches, then it's OK. Well, we actually have a single number right now (both 5.0 and 5.5 are fixed numbers). What I'm trying is to differentiate actual bugfxing from new release that adds extra functionality, optimization, etc... Anyhow, I just don't like those non-numeric 'x.x-dev' versions. Anything else is just fine :). Regards, MT. This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31043] New: - blank spaces in Tomcat installation directory cause Jakarta connector to fail with IIS
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=31043. 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=31043 blank spaces in Tomcat installation directory cause Jakarta connector to fail with IIS Summary: blank spaces in Tomcat installation directory cause Jakarta connector to fail with IIS Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:AJP AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you want to use jakarta connector with IIS (no matter its version) you must install Jakarta in directories without blanks e.g. c:\jakarta\tomcat If you install Tomcat in its default e.g. c:\Apache Software Soundation\Tomcat 5.0 this will cause connector to fail with IIS (in event viewer you will see the following Error: [jk_isapi_plugin.c (496)]: HttpExtensionProc worker is NULL) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31043] - blank spaces in Tomcat installation directory cause Jakarta connector to fail with IIS
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=31043. 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=31043 blank spaces in Tomcat installation directory cause Jakarta connector to fail with IIS [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Using dotted version naming
Shapira, Yoav wrote: Hi, The x.x-dev is a placeholder in build.xml. The Release Manager adds version=a.b.c to his/her build.properties when doing a release, thereby overriding the placeholder x.x-dev value. This is a common convention not just for Tomcat, but for almost every open source project I've worked on ;) Does something break if the version is non-numeric? A lot of projects also use the string RC or alpha or beta in the actual version name as well, although we don't do that for Tomcat. Yes, NSIS breaks if the version number is not a.b.c.d (which is why Mladen wants that numbering scheme). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Using dotted version naming
Shapira, Yoav wrote: Hi, The x.x-dev is a placeholder in build.xml. The Release Manager adds version=a.b.c to his/her build.properties when doing a release, thereby overriding the placeholder x.x-dev value. This is a common convention not just for Tomcat, but for almost every open source project I've worked on ;) Does something break if the version is non-numeric? A lot of projects also use the string RC or alpha or beta in the actual version name as well, although we don't do that for Tomcat. Well, the RC, alpha, etc... are 'decorated' names. The actual version are generally some numbers. It also breaks the installer too. So I wanted that we adopt some kind of agreement that will stop breaking the build when ever the version gets changed. Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
RE: [5.5] Using dotted version naming
Hi, Ahh, OK, I understand. Can we make the version in build.xml be something like 1.0 then, so that no user can confuse it for the latest build? Yoav Shapira Millennium Research Informatics -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 10:56 AM To: Tomcat Developers List Subject: Re: [5.5] Using dotted version naming Shapira, Yoav wrote: Hi, The x.x-dev is a placeholder in build.xml. The Release Manager adds version=a.b.c to his/her build.properties when doing a release, thereby overriding the placeholder x.x-dev value. This is a common convention not just for Tomcat, but for almost every open source project I've worked on ;) Does something break if the version is non-numeric? A lot of projects also use the string RC or alpha or beta in the actual version name as well, although we don't do that for Tomcat. Well, the RC, alpha, etc... are 'decorated' names. The actual version are generally some numbers. It also breaks the installer too. So I wanted that we adopt some kind of agreement that will stop breaking the build when ever the version gets changed. Regards, MT. This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JMX
Hi, How do you enable remote access to the JMX Server by RMI in Tomcat 4.1.30 ? I'd like to access a custom MBean, which i register to the Tomcat JMX Server in my webapp, via RMI. I asked this question to the user mailing list, but without success. I hope that somebody here will be able to help me. Thanks, Sebastien
5.5.1 on Tuesday
Hi, I propose to cut the 5.5.1 release on Tuesday (September 7th), thereby giving us the weekend to do additional work on it. OK? Yoav Shapira Millennium Research Informatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.1 on Tuesday
Shapira, Yoav wrote: Hi, I propose to cut the 5.5.1 release on Tuesday (September 7th), thereby giving us the weekend to do additional work on it. OK? +1. Other than testing DataSources and tweaking the docs (there are broken links right now, because of the repackaging), I don't have anything to do. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Using dotted version naming
Shapira, Yoav wrote:
Hi,
Ahh, OK, I understand. Can we make the version in build.xml be
something like 1.0 then, so that no user can confuse it for the latest
build?
Well, the property name=version ... in build.xml
also reflects the builded distributions.
For example if the 'dotted=5.5.0.0' the 'version name' would
be 5.5.0-dev and produced release 'jakarta-tomcat-5.5.0-dev'
We can also make something like in
jakarta-tomcat5/build.xml:
property nameversion.majorvalue=5 /
property nameversion.minorvalue=5 /
property nameversion.buildvalue=0 /
property nameversion.patchvalue=0 /
property nameversion.isdevvalue=1 /
property nameversion.number
value=${version.major}.${version.minor}.${version.build}.${version.patch}
/
property nameversion.name
value=${version.major}.${version.minor}.${version.build} /
It would be nice if there is a way to add the 'version.patch' to
the 'version.name' but only if the patch value difers from '0'.
Perhaps even adding '-dev' if isdev is nonzero.
Regards,
MT.
smime.p7s
Description: S/MIME Cryptographic Signature
DO NOT REPLY [Bug 20758] - Memory Leak in Classloader/Manager deploy/undeploy
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=20758. 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=20758 Memory Leak in Classloader/Manager deploy/undeploy --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 16:25 --- I applogize. My previous posting was incorrect and does not reproduce the problem. It grows until the garbage collector hits its first limit. However, I have a new one that definately reproduces the problem. It is related to using ObjectOutputStreams. There are many posting related to using reset() with ObjectOutputStreams which I do. I also have a simple test code that repeatidly writes Object to a file with no problem. However, if put it in a servlet and continualy reload, it leaks. Could it be related to the ClassLoader? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20758] - Memory Leak in Classloader/Manager deploy/undeploy
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=20758. 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=20758 Memory Leak in Classloader/Manager deploy/undeploy --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 16:27 --- Created an attachment (id=12638) Revised BigSingleton, which writes objects to disk. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20758] - Memory Leak in Classloader/Manager deploy/undeploy
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=20758. 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=20758 Memory Leak in Classloader/Manager deploy/undeploy --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 16:28 --- Created an attachment (id=12639) Revised Singleton Servlet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31051] New: - Incorrect instruction in documentation file RUNNING.TXT
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=31051. 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=31051 Incorrect instruction in documentation file RUNNING.TXT Summary: Incorrect instruction in documentation file RUNNING.TXT Product: Tomcat 5 Version: 5.5.0 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] To configure the Tomcat with JDK 1,4 in archive RUNNIN.TXT it says: (2) Place the compat package to jar in Tomcat's server classpath by copying it into the #CATALINA_HOME/server/lib directory. , but the correct is unzip the package in $catalina_home\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31052] New: - org.apache.naming.factory.BeanFactory does not propage root exceptions
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=31052.
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=31052
org.apache.naming.factory.BeanFactory does not propage root exceptions
Summary: org.apache.naming.factory.BeanFactory does not propage
root exceptions
Product: Tomcat 5
Version: 5.0.0
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Only the error messages are propagated in the NamingException:
} catch (java.beans.IntrospectionException ie) {
throw new NamingException(ie.getMessage());
}
Since some exceptions do not have a message associated with it, it is very hard
sometimes to tell what went wrong from the NamingException. So it would be nice
if the actual exception was chained with the NamingException. The change is
small:
} catch (java.lang.IllegalAccessException iae) {
NamingException ex = new new NamingException(iae.getMessage());
ex.setRootCause(iae);
throw ex;
}
Also, there is a call to e.printStackTrace() which probably shouldn't be there.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 RUNNING.txt
yoavs 2004/09/03 10:50:34 Modified:.RUNNING.txt Log: Clarified instructions for installaing the compat distribution. Revision ChangesPath 1.9 +5 -3 jakarta-tomcat-5/RUNNING.txt Index: RUNNING.txt === RCS file: /home/cvs/jakarta-tomcat-5/RUNNING.txt,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- RUNNING.txt 30 Aug 2004 17:27:21 - 1.8 +++ RUNNING.txt 3 Sep 2004 17:50:34 - 1.9 @@ -84,8 +84,10 @@ * Or build this package yourself from the source code: see BUILDING.txt in this directory. -(2) Place the compat package jar in Tomcat's server classpath -by copying it into the $CATALINA_HOME/server/lib directory. +(2) Unzip the package in $CATALINA_HOME. It will place the XML +parser APIs and Xerces implementation in the common/endorsed +directory, and the JMX API jar (jmx.jar from Sun) in the bin +directory. (3) Follow the same directions for starting and stopping the server as if you were using J2SE 5.0. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31051] - Incorrect instruction in documentation file RUNNING.TXT
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=31051. 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=31051 Incorrect instruction in documentation file RUNNING.TXT [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 17:53 --- Ooof, picky people ;) I've fixed it in CVS, thanks for pointing it out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common JkMX.java
Hi, thanks for accepting the authentication patch for the mx4j JMX adapter. Are you going to apply it to the 5.0 branch too? That would be nice. Have a nice weekend Rainer Jung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30984] - Add an ability to compile JSPs to specified target JVM
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=30984. 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=30984 Add an ability to compile JSPs to specified target JVM [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 17:55 --- Yes, this also affects JDT. And please do NOT reopen one issue to ask for something else to be done, even if it's related. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30284] - JPDA Hot code replacement support in classloader
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=30284. 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=30284 JPDA Hot code replacement support in classloader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 17:58 --- This seems to me a like a large project outside the scope of Tomcat, and in the scope of a debugger like OptimizeIt, JProbe, etc. We're going to leave it to them ;) That said, if you have some sort of a Loader implementation that does this, we'll be happy to evaluate it and add it to the distro if there's consensus. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2004/09/03 11:03:56
Modified:catalina/src/share/org/apache/naming/factory
BeanFactory.java
webapps/docs changelog.xml
Log:
Bugzilla 31052.
Revision ChangesPath
1.4 +12 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java
Index: BeanFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BeanFactory.java 26 Jul 2004 15:39:13 - 1.3
+++ BeanFactory.java 3 Sep 2004 18:03:56 - 1.4
@@ -220,13 +220,21 @@
return bean;
} catch (java.beans.IntrospectionException ie) {
-throw new NamingException(ie.getMessage());
+NamingException ne = new NamingException(ie.getMessage());
+ne.setRootCause(ie);
+throw ne;
} catch (java.lang.IllegalAccessException iae) {
-throw new NamingException(iae.getMessage());
+NamingException ne = new NamingException(iae.getMessage());
+ne.setRootCause(iae);
+throw ne;
} catch (java.lang.InstantiationException ie2) {
-throw new NamingException(ie2.getMessage());
+NamingException ne = new NamingException(ie2.getMessage());
+ne.setRootCause(ie2);
+throw ne;
} catch (java.lang.reflect.InvocationTargetException ite) {
-throw new NamingException(ite.getMessage());
+NamingException ne = new NamingException(ite.getMessage());
+ne.setRootCause(ite);
+throw ne;
}
} else {
1.100 +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.99
retrieving revision 1.100
diff -u -r1.99 -r1.100
--- changelog.xml 2 Sep 2004 19:13:38 - 1.99
+++ changelog.xml 3 Sep 2004 18:03:56 - 1.100
@@ -59,6 +59,9 @@
fix
Externalize constant strings defining the location of deployment related
resources. (remm)
/fix
+ fix
+bug31052/bug: BeanFactory swallows root cause of exception. (yoavs)
+ /fix
/changelog
/subsection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2004/09/03 11:06:23
Modified:catalina/src/share/org/apache/naming/factory Tag: TOMCAT_5_0
BeanFactory.java
webapps/docs Tag: TOMCAT_5_0 changelog.xml
Log:
Bugzilla 31052
Revision ChangesPath
No revision
No revision
1.2.2.2 +12 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java
Index: BeanFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- BeanFactory.java 21 Aug 2004 15:50:00 - 1.2.2.1
+++ BeanFactory.java 3 Sep 2004 18:06:23 - 1.2.2.2
@@ -220,13 +220,21 @@
return bean;
} catch (java.beans.IntrospectionException ie) {
-throw new NamingException(ie.getMessage());
+NamingException ne = new NamingException(ie.getMessage());
+ne.setRootCause(ie);
+throw ne;
} catch (java.lang.IllegalAccessException iae) {
-throw new NamingException(iae.getMessage());
+NamingException ne = new NamingException(iae.getMessage());
+ne.setRootause(iae);
+throw ne;
} catch (java.lang.InstantiationException ie2) {
-throw new NamingException(ie2.getMessage());
+NamingException ne = new NamingException(ie2.getMessage());
+ne.setRootCause(ie2);
+throw ne;
} catch (java.lang.reflect.InvocationTargetException ite) {
-throw new NamingException(ite.getMessage());
+NamingException ne = new NamingException(ite.getMessage());
+ne.setRootCause(ite);
+throw ne;
}
} else {
No revision
No revision
1.70.2.30 +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.70.2.29
retrieving revision 1.70.2.30
diff -u -r1.70.2.29 -r1.70.2.30
--- changelog.xml 2 Sep 2004 19:18:07 - 1.70.2.29
+++ changelog.xml 3 Sep 2004 18:06:23 - 1.70.2.30
@@ -60,6 +60,9 @@
fix
bug30415/bug: Directories ending in .war not handled well. (yoavs)
/fix
+ fix
+bug31052/bug: BeanFactory swallows root cause of exception. (yoavs)
+ /fix
/changelog
/subsection
subsection name=Webapps
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31052] - org.apache.naming.factory.BeanFactory does not propage root exceptions
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=31052. 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=31052 org.apache.naming.factory.BeanFactory does not propage root exceptions [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 18:08 --- Now that we require JDK 1.4 where setRootCause is available, this fix is possible, so I've done it in TOMCAT_5_0 and HEAD. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31052] - org.apache.naming.factory.BeanFactory does not propage root exceptions
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=31052. 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=31052 org.apache.naming.factory.BeanFactory does not propage root exceptions --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 18:15 --- Thanks! Btw, the setRootCause() method on NamingException was actually available in 1.3.x (if not before that even). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2004/09/03 11:21:29
Modified:catalina/src/share/org/apache/catalina/core Tag: TOMCAT_5_0
StandardDefaultContext.java
catalina/src/share/org/apache/naming/factory Tag: TOMCAT_5_0
BeanFactory.java
webapps/docs Tag: TOMCAT_5_0 changelog.xml
Log:
Bugzilla 29914, typo fix in BeanFactory
Revision ChangesPath
No revision
No revision
1.15.2.1 +19 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Attic/StandardDefaultContext.java
Index: StandardDefaultContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Attic/StandardDefaultContext.java,v
retrieving revision 1.15
retrieving revision 1.15.2.1
diff -u -r1.15 -r1.15.2.1
--- StandardDefaultContext.java 26 May 2004 15:36:35 - 1.15
+++ StandardDefaultContext.java 3 Sep 2004 18:21:28 - 1.15.2.1
@@ -867,6 +867,14 @@
}
+/**
+ * Get the lifecycle listeners associated with this lifecycle. If this
+ * Lifecycle has no listeners registered, a zero-length array is returned.
+ */
+public LifecycleListener[] findLifecycleListeners() {
+return (LifecycleListener[]) lifecycle.toArray(new
LifecycleListener[lifecycle.size()]);
+}
+
/**
* Return the set of application listener class names configured
@@ -1095,6 +1103,16 @@
}
+/**
+ * Remove a lifecycle event listener from this component.
+ *
+ * @param listener The listener to remove
+ */
+public void removeLifecycleListener(LifecycleListener listener) {
+if((lifecycle != null) (listener != null)) {
+lifecycle.remove(listener);
+}
+}
/**
* Remove the specified application listener class from the set of
No revision
No revision
1.2.2.3 +1 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java
Index: BeanFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java,v
retrieving revision 1.2.2.2
retrieving revision 1.2.2.3
diff -u -r1.2.2.2 -r1.2.2.3
--- BeanFactory.java 3 Sep 2004 18:06:23 - 1.2.2.2
+++ BeanFactory.java 3 Sep 2004 18:21:28 - 1.2.2.3
@@ -225,7 +225,7 @@
throw ne;
} catch (java.lang.IllegalAccessException iae) {
NamingException ne = new NamingException(iae.getMessage());
-ne.setRootause(iae);
+ne.setRootCause(iae);
throw ne;
} catch (java.lang.InstantiationException ie2) {
NamingException ne = new NamingException(ie2.getMessage());
No revision
No revision
1.70.2.31 +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.70.2.30
retrieving revision 1.70.2.31
diff -u -r1.70.2.30 -r1.70.2.31
--- changelog.xml 3 Sep 2004 18:06:23 - 1.70.2.30
+++ changelog.xml 3 Sep 2004 18:21:28 - 1.70.2.31
@@ -63,6 +63,9 @@
fix
bug31052/bug: BeanFactory swallows root cause of exception. (yoavs)
/fix
+ fix
+bug29914/bug: Better lifecycle support for DefaultContext. (yoavs)
+ /fix
/changelog
/subsection
subsection name=Webapps
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29914] - StandardServer.storeConfig() not saved DefaultContext Listeners
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=29914. 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=29914 StandardServer.storeConfig() not saved DefaultContext Listeners [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 18:23 --- OK, patch applied on TOMCAT_5_0 branch. It's not relevant to Tomcat 5.5 (see DefaultContext replacement discussions on tomcat-dev for that). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29895] - context.xml isn't read properly by Manager application.
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=29895. 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=29895 context.xml isn't read properly by Manager application. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 18:40 --- Both folder and war test cases work for me out of the box on 5.0.28. I had to put my JDBC driver jar (ojdbc14.jar in my case, I'm using an Oracle database) in $CATALINA_HOME/common/lib, of course. When I use context.xml inside a WAR, I specify docBase=test.war (or whatever the WAR file name is) rather than a directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common JkMX.java
AFAIK, the 5.0 branch of j-t-c isn't used for anything. - Original Message - From: Rainer Jung [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, September 03, 2004 10:52 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common JkMX.java Hi, thanks for accepting the authentication patch for the mx4j JMX adapter. Are you going to apply it to the 5.0 branch too? That would be nice. Have a nice weekend Rainer Jung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fatal: relocation error: file libapr-0.so.0: symbol __divdi3: referenced symbol not found
Hi to all ... I've install Apache2 and Tomcat5 last versions from the Apache project web page, and they are currently well running standalone in my 64 bits Solaris 9 Box, but now I need to connect them, so I installed the new mod_jk2 connector, with succeeding results at the configure and make steps, following the HOWTO set up JK2 on Solaris 9 using ChannelUnix (AF_UNIX socket) document from http://archives.real-time.com/pipermail/tomcat-users/2002-November/085985.html. I also setup and export the environment variable LD_LIBRARY_PATH=/usr/java/jre/bin and soft-link the libjkjni.so dynamic library file from the $APACHE/module/libjkjni.so to the LD_LIBRARY_PATH so I can avoid this error message: I've configured and make the Apache2 and the JK2 connector in my own box But now, I am facing a problem while starting tomcat This is what I see in my catalina.out log file: 1-Sep-2004 1:46:23 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-9092 1-Sep-2004 1:46:23 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 2007 ms 1-Sep-2004 1:46:23 PM org.apache.catalina.core.StandardService start INFO: Starting service Tomcat-Standalone 1-Sep-2004 1:46:23 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.0.27 1-Sep-2004 1:46:23 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled 1-Sep-2004 1:46:25 PM org.apache.catalina.core.StandardHost getDeployer INFO: Create Host deployer for direct deployment ( non-jmx ) 1-Sep-2004 1:46:25 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-9092 1-Sep-2004 1:46:26 PM org.apache.jk.common.ChannelSocket init INFO: JK2: ajp13 listening on /0.0.0.0:8009 ld.so.1: /usr/java/bin/java: fatal: relocation error: file /usr/local/apache-httpd-2.0.50/lib/libapr-0.so.0: symbol __divdi3: referenced symbol not found I ran the ldd utility on the jni dynamic library libjkjni.so with the following results: ldd libjkjni.so libcrypt_i.so.1 = /usr/lib/libcrypt_i.so.1 libapr-0.so.0 = /usr/local/apache-httpd-2.0.50/lib/libapr-0.so.0 libc.so.1 = /usr/lib/libc.so.1 libgen.so.1 = /usr/lib/libgen.so.1 libsendfile.so.1 = /usr/lib/libsendfile.so.1 librt.so.1 = /usr/lib/librt.so.1 libm.so.1 = /usr/lib/libm.so.1 libsocket.so.1 = /usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libresolv.so.2 = /usr/lib/libresolv.so.2 libpthread.so.1 = /usr/lib/libpthread.so.1 libdl.so.1 = /usr/lib/libdl.so.1 libaio.so.1 = /usr/lib/libaio.so.1 libmd5.so.1 = /usr/lib/libmd5.so.1 libmp.so.2 = /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1 libthread.so.1 = /usr/lib/libthread.so.1 /usr/platform/SUNW,Sun-Fire-V210/lib/libmd5_psr.so.1 I notice that the library suposed to have the problem was there /usr/local/apache-httpd-2.0.50/lib/libapr-0.so.0 so I ran nm utility on it with the following results: nm /usr/local/apache-httpd-2.0.50/lib/libapr-0.so.0 | grep div [337] | 0| 0|FUNC |GLOB |0 |UNDEF |.div [640] | 0| 0|FUNC |GLOB |0 |UNDEF |.udiv [909] | 0| 0|NOTY |GLOB |0 |UNDEF |__divdi3 [938] | 0| 0|NOTY |GLOB |0 |UNDEF |__udivdi3 So it seems that the problem is on the libapr-0.so.0 because there is the variable __divdi3 wich is reporting the relocation error... Then, I ran the ldd utility on the libapr-0.so.0 lib, with the following results: /usr/local/apache-httpd-2.0.50/lib ldd libapr-0.so.0 libsendfile.so.1 = /usr/lib/libsendfile.so.1 librt.so.1 = /usr/lib/librt.so.1 libm.so.1 = /usr/lib/libm.so.1 libsocket.so.1 = /usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libresolv.so.2 = /usr/lib/libresolv.so.2 libpthread.so.1 = /usr/lib/libpthread.so.1 libdl.so.1 = /usr/lib/libdl.so.1 libc.so.1 = /usr/lib/libc.so.1 libaio.so.1 = /usr/lib/libaio.so.1 libmd5.so.1 = /usr/lib/libmd5.so.1 libmp.so.2 = /usr/lib/libmp.so.2 libthread.so.1 = /usr/lib/libthread.so.1 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1 /usr/platform/SUNW,Sun-Fire-V210/lib/libmd5_psr.so.1 Then I skim those libs for the symbol, and don't find it... What does this mean? My problem is definitive related with the libjkjni.so lib, when I add the path of the library to the LD_LIBRARY_PATH I get the error message: ld.so.1: /usr/java/bin/java: fatal: relocation error: file /usr/local/apache-httpd-2.0.50/lib/libapr-0.so.0: symbol __divdi3: referenced symbol not found But, when take this path out of the LD_LIBRARY_PATH the error disappears, but also disappears the AF_SOCKET support of the connector, and got this message: INFO: APR not loaded, disabling jni components: java.io.IOException: java.lang.UnsatisfiedLinkError: no jkjni in java.library.path. Please, any comment from you would be very helpful. Regards Jonathan M. Rengifo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs class-loader-howto.xml realm-howto.xml
yoavs 2004/09/03 14:57:53 Modified:webapps/docs class-loader-howto.xml realm-howto.xml Log: A couple of typo fixes, courtesy of Ed Dodds. Revision ChangesPath 1.13 +1 -1 jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml Index: class-loader-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- class-loader-howto.xml1 Sep 2004 22:04:27 - 1.12 +++ class-loader-howto.xml3 Sep 2004 21:57:53 - 1.13 @@ -203,7 +203,7 @@ instead of delegating before looking. There are exceptions. Classes which are part of the JRE base classes cannot be overriden. For some classes (such as the XML parser components in J2SE 1.4+), the J2SE 1.4 endorsed feature can be -used used +used (see the common classloader definition above). In addition, for the following class patterns, the classloader will always delegate first (and load the class itself if no parent classloader loads it): 1.16 +1 -1 jakarta-tomcat-catalina/webapps/docs/realm-howto.xml Index: realm-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/realm-howto.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- realm-howto.xml 21 Aug 2004 12:39:08 - 1.15 +++ realm-howto.xml 3 Sep 2004 21:57:53 - 1.16 @@ -1372,7 +1372,7 @@ techniques are supported:/p ul liIf you are writing an application that needs to calculate digested -passowrds dynamically, call the static codeDigest()/code method of the +passwords dynamically, call the static codeDigest()/code method of the codeorg.apache.catalina.realm.RealmBase/code class, passing the cleartext password and the digest algorithm name as arguments. This method will return the digested password./li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs class-loader-howto.xml realm-howto.xml
yoavs 2004/09/03 14:58:39 Modified:webapps/docs Tag: TOMCAT_5_0 class-loader-howto.xml realm-howto.xml Log: A couple of typo fixes, courtesy of Ed Dodds. Revision ChangesPath No revision No revision 1.11.2.1 +1 -1 jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml Index: class-loader-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml,v retrieving revision 1.11 retrieving revision 1.11.2.1 diff -u -r1.11 -r1.11.2.1 --- class-loader-howto.xml16 Jun 2004 18:04:39 - 1.11 +++ class-loader-howto.xml3 Sep 2004 21:58:39 - 1.11.2.1 @@ -197,7 +197,7 @@ instead of delegating before looking. There are exceptions. Classes which are part of the JRE base classes cannot be overriden. For some classes (such as the XML parser components in JDK 1.4+), the JDK 1.4 endorsed feature can be -used used +used (see the common classloader definition above). In addition, for the following class patterns, the classloader will always delegate first (and load the class itself if no parent classloader loads it): 1.14.2.2 +1 -1 jakarta-tomcat-catalina/webapps/docs/realm-howto.xml Index: realm-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/realm-howto.xml,v retrieving revision 1.14.2.1 retrieving revision 1.14.2.2 diff -u -r1.14.2.1 -r1.14.2.2 --- realm-howto.xml 21 Aug 2004 15:50:08 - 1.14.2.1 +++ realm-howto.xml 3 Sep 2004 21:58:39 - 1.14.2.2 @@ -1372,7 +1372,7 @@ techniques are supported:/p ul liIf you are writing an application that needs to calculate digested -passowrds dynamically, call the static codeDigest()/code method of the +passwords dynamically, call the static codeDigest()/code method of the codeorg.apache.catalina.realm.RealmBase/code class, passing the cleartext password and the digest algorithm name as arguments. This method will return the digested password./li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SOLVED: Kinda Urgent: Huge Temporary Files (2BG) Fill Up Root Partition (mrfxxxxx.tmp files?)
Thank you so much for your suggestions! The error is indeed in my code, specifically in a MultipartRequest-related class that I downloaded from JavaPro magazine. I never suspected this code because I didn't write it. I guess there is a bug in their code that I now have to investigate that; at least I now know the source of the problem! Peter Alvin mobile 719-210-3858 On Fri, 3 Sep 2004 04:38:22 -0600, Peter Alvin wrote: Hello, Someone on the user list recommended I post my question on the developer list. Any help would be greatly appreciated! I've spent about 5 hours researching this myself--including the mailing list archives--and have yet to find any references let alone solutions. There are no references to mrf files that are causing me grief. This posting is my only hope! :) Here's the scoop: Massively HUGE .tmp files grow in this directory: /var/cache/tomcat4/temp Here is an example: -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:21 mrf20758.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:20 mrf20757.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:19 mrf20756.tmp -rw-r--r--1 tomcat4 tomcat4 2272915456 Sep 2 11:19 mrf20744.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:17 mrf20755.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:17 mrf20754.tmp -rw-r--r--1 tomcat4 tomcat4 0 Sep 2 11:16 mrf20753.tmp I don't know what these files are for nor why some of them grow to over 2GB. It's kinda urgent because this kills our server every 24 hours or so. It forces me to stop tomcat, delete the files, then re-start. Sometimes I have to do a kill -9 on the tomcat process because the process is apparently stuck still trying to write yet more bytes to these files! Incidently, we have another server with the same directory, but there are only just a few of these mrf files and they don't grow to be very big--so, it's not a problem on the other server. Also incidently, our Java program uses a lot of memory which causes frequent and long garbage collections. Are these related? Can anyone help? What are these files for? Peter Alvin mobile 719-210-3858 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
