svn commit: r1000718 - /tomcat/trunk/bin/service.bat
Author: mturk Date: Fri Sep 24 06:00:00 2010 New Revision: 1000718 URL: http://svn.apache.org/viewvc?rev=1000718view=rev Log: Fix Bz #49993 by checking the JAVA_HOME/JRE_HOME environment variables Modified: tomcat/trunk/bin/service.bat Modified: tomcat/trunk/bin/service.bat URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/service.bat?rev=1000718r1=1000717r2=1000718view=diff == --- tomcat/trunk/bin/service.bat (original) +++ tomcat/trunk/bin/service.bat Fri Sep 24 06:00:00 2010 @@ -44,12 +44,30 @@ echo The tomcat.exe was not found... echo The CATALINA_HOME environment variable is not defined correctly. echo This environment variable is needed to run this program goto end +:okHome rem Make sure prerequisite environment variables are set -if not %JAVA_HOME% == goto okHome -echo The JAVA_HOME environment variable is not defined +if not %JAVA_HOME% == goto gotJdkHome +if not %JRE_HOME% == goto gotJreHome +echo Neither the JAVA_HOME nor the JRE_HOME environment variable is defined +echo Service will try to guess them from the registry. +goto okJavaHome +:gotJreHome +if not exist %JRE_HOME%\bin\java.exe goto noJavaHome +if not exist %JRE_HOME%\bin\javaw.exe goto noJavaHome +goto okJavaHome +:gotJdkHome +if not exist %JAVA_HOME%\jre\bin\java.exe goto noJavaHome +if not exist %JAVA_HOME%\jre\bin\javaw.exe goto noJavaHome +if not exist %JAVA_HOME%\bin\javac.exe goto noJavaHome +if not %JRE_HOME% == goto okJavaHome +set JRE_HOME=%JAVA_HOME%\jre +goto okJavaHome +:noJavaHome +echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program +echo NB: JAVA_HOME should point to a JDK not a JRE goto end -:okHome +:okJavaHome if not %CATALINA_BASE% == goto gotBase set CATALINA_BASE=%CATALINA_HOME% :gotBase @@ -105,6 +123,7 @@ echo Installing the service '%SERVICE_NA echo Using CATALINA_HOME:%CATALINA_HOME% echo Using CATALINA_BASE:%CATALINA_BASE% echo Using JAVA_HOME:%JAVA_HOME% +echo Using JRE_HOME: %JRE_HOME% rem Use the environment variables as an example rem Each command line option is prefixed with PR_ @@ -114,10 +133,10 @@ set PR_INSTALL=%EXECUTABLE% set PR_LOGPATH=%CATALINA_BASE%\logs set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_BASE%\bin\tomcat-juli.jar;%CATALINA_HOME%\bin\tomcat-juli.jar rem Set the server jvm from JAVA_HOME -set PR_JVM=%JAVA_HOME%\jre\bin\server\jvm.dll +set PR_JVM=%JRE_HOME%\bin\server\jvm.dll if exist %PR_JVM% goto foundJvm rem Set the client jvm from JAVA_HOME -set PR_JVM=%JAVA_HOME%\jre\bin\client\jvm.dll +set PR_JVM=%JRE_HOME%\bin\client\jvm.dll if exist %PR_JVM% goto foundJvm set PR_JVM=auto :foundJvm - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49993] service.bat does not check for JAVA_HOME validity
https://issues.apache.org/bugzilla/show_bug.cgi?id=49993 Mladen Turk mt...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mladen Turk mt...@apache.org 2010-09-24 02:00:31 EDT --- Fixed in the trunk as r 1000718 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49929] AJP APR connector to mod_jk can result in SEND_BODY_CHUNK message after END_RESPONSE message
https://issues.apache.org/bugzilla/show_bug.cgi?id=49929 --- Comment #7 from Mladen Turk mt...@apache.org 2010-09-24 02:51:11 EDT --- I'm still not been able to reproduce the stuff. I don't use jmeter but rather a simple ab which can only hit a single uri, so this might be the reason why its not manifested there. BTW, does it happen only with APR connector, or with JIO as well? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49890] Nio Selector issue on linux platform
https://issues.apache.org/bugzilla/show_bug.cgi?id=49890 Andrey Timofeev andrey.timofe...@gmail.com changed: What|Removed |Added Priority|P3 |P2 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NamingContext Possible Bug
Konstatin, I think that this is not related with ResourceLink elements. When you define global resource link in your Context.xml, Tomcat creates ResourceLinkRef for this entry. Then same scenario exists, it creates object using ResourceLinkFactory and caches it. It is not desirable. Changing (removing caching statements) this does not break anything. I will open an issue. Regards; --Gurkan - Original Message From: Konstantin Kolinko knst.koli...@gmail.com To: Tomcat Developers List dev@tomcat.apache.org Sent: Fri, September 24, 2010 2:36:46 AM Subject: Re: NamingContext Possible Bug 2010/9/21 Gurkan Erdogdu gurkanerdo...@yahoo.com: Hello folks, In NamingContext implementation, if lookup() is a Reference, current implementation caches the result of the NamingManager # getObjectInstance via following statements and changes the type of the entry. In the following lookups, same object is returned. I would like to write ObjectFactory that returns new instance for each time lookup is called on its reference. But with the current implementation, it is not possible to write such an object factory because of aferomentioned sitaution. I think that entry must be stay as Reference instead of changing entry type. WDYT? There was some discussion previously, proposed and vetoed patch and some issue in bugzilla. [1] From some later code review I think that that code is used to handle ResourceLink elements. That is, when you have a global resource in server.xml and a ResourceLink in your context.xml. [2] It would be undesirable to break that. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=47512 [2] http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#context.xml_configuration Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49994] New: NamingContext Possible Bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=49994
Summary: NamingContext Possible Bug
Product: Tomcat 7
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: gurkanerdo...@yahoo.com
In NamingContext implementation, if lookup() is a Reference, current
implementation caches the result of the NamingManager # getObjectInstance via
following statements and changes the type of the entry. In the following
lookups, same object is returned. I would like to write ObjectFactory that
returns new instance for each time lookup is called on its reference. But with
the current implementation, it is not possible to write such an object factory
because of aferomentioned sitaution. I think that entry must be stay as
Reference instead of changing entry type.
NamingContext class:
protected Object lookup(Name name, boolean resolveLinks)
throws NamingException {
.
} else if (entry.type == NamingEntry.REFERENCE) {
try {
Object obj = NamingManager.getObjectInstance
(entry.value, name, this, env);
if (obj != null) {
entry.value = obj;
entry.type = NamingEntry.ENTRY; --- CHANGES type of
the naming entry
}
return obj;
} catch (NamingException e) {
throw e;
} catch (Exception e) {
log.warn(sm.getString
(namingContext.failResolvingReference), e);
throw new NamingException(e.getMessage());
}
}
...
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49994] NamingContext Possible Bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=49994 --- Comment #1 from Gurkan Erdogdu gurkanerdo...@yahoo.com 2010-09-24 08:00:08 EDT --- Comments from David Jencks: For reference, the EE 6 platform spec explains that usually a new instance should be returned on each lookup in section 5.2.4 page 67 Sharing of Environment Entries. The servlet 3.0 spec section 15.2.2 page 174 indicates that this applies to servlet containers that are part of an EE technology-compliant implementation. I guess this means that unless tomcat implements web profile they don't have to support this? It still seems like a good idea to me. thanks david jencks -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1000718 - /tomcat/trunk/bin/service.bat
On 24 September 2010 07:00, mt...@apache.org wrote: Author: mturk Date: Fri Sep 24 06:00:00 2010 New Revision: 1000718 URL: http://svn.apache.org/viewvc?rev=1000718view=rev Log: Fix Bz #49993 by checking the JAVA_HOME/JRE_HOME environment variables Modified: tomcat/trunk/bin/service.bat Modified: tomcat/trunk/bin/service.bat URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/service.bat?rev=1000718r1=1000717r2=1000718view=diff == --- tomcat/trunk/bin/service.bat (original) +++ tomcat/trunk/bin/service.bat Fri Sep 24 06:00:00 2010 @@ -44,12 +44,30 @@ echo The tomcat.exe was not found... echo The CATALINA_HOME environment variable is not defined correctly. echo This environment variable is needed to run this program goto end +:okHome rem Make sure prerequisite environment variables are set -if not %JAVA_HOME% == goto okHome -echo The JAVA_HOME environment variable is not defined +if not %JAVA_HOME% == goto gotJdkHome +if not %JRE_HOME% == goto gotJreHome +echo Neither the JAVA_HOME nor the JRE_HOME environment variable is defined +echo Service will try to guess them from the registry. +goto okJavaHome +:gotJreHome +if not exist %JRE_HOME%\bin\java.exe goto noJavaHome +if not exist %JRE_HOME%\bin\javaw.exe goto noJavaHome +goto okJavaHome +:gotJdkHome +if not exist %JAVA_HOME%\jre\bin\java.exe goto noJavaHome +if not exist %JAVA_HOME%\jre\bin\javaw.exe goto noJavaHome +if not exist %JAVA_HOME%\bin\javac.exe goto noJavaHome +if not %JRE_HOME% == goto okJavaHome +set JRE_HOME=%JAVA_HOME%\jre +goto okJavaHome +:noJavaHome +echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program +echo NB: JAVA_HOME should point to a JDK not a JRE goto end -:okHome +:okJavaHome if not %CATALINA_BASE% == goto gotBase set CATALINA_BASE=%CATALINA_HOME% :gotBase @@ -105,6 +123,7 @@ echo Installing the service '%SERVICE_NA echo Using CATALINA_HOME: %CATALINA_HOME% echo Using CATALINA_BASE: %CATALINA_BASE% echo Using JAVA_HOME: %JAVA_HOME% +echo Using JRE_HOME: %JRE_HOME% rem Use the environment variables as an example rem Each command line option is prefixed with PR_ @@ -114,10 +133,10 @@ set PR_INSTALL=%EXECUTABLE% set PR_LOGPATH=%CATALINA_BASE%\logs set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_BASE%\bin\tomcat-juli.jar;%CATALINA_HOME%\bin\tomcat-juli.jar rem Set the server jvm from JAVA_HOME The above comment looks wrong: s/JAVA_HOME/JRE_HOME/ -set PR_JVM=%JAVA_HOME%\jre\bin\server\jvm.dll +set PR_JVM=%JRE_HOME%\bin\server\jvm.dll if exist %PR_JVM% goto foundJvm rem Set the client jvm from JAVA_HOME Ditto -set PR_JVM=%JAVA_HOME%\jre\bin\client\jvm.dll +set PR_JVM=%JRE_HOME%\bin\client\jvm.dll if exist %PR_JVM% goto foundJvm set PR_JVM=auto :foundJvm - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Code Style.
Mark, On 9/20/2010 6:58 PM, Mark Thomas wrote: On 20/09/2010 15:04, Wesley Acheson wrote: I think some documentation should be created on code style. Actually a bit more than that I think some documentation should be written saying. http://tomcat.apache.org/getinvolved.html As always, patches welcome. But how should the documentation be formatted? ;) -chris signature.asc Description: OpenPGP digital signature
DO NOT REPLY [Bug 48674] Tomcat Virtual Host Manager application doesn't persist newly created virtual hosts
https://issues.apache.org/bugzilla/show_bug.cgi?id=48674 --- Comment #4 from Wesley wesley.ache...@gmail.com 2010-09-24 16:03:43 EDT --- Is this worth continuing with? I know its rough but I'd like to know if its a start again job, or continue from here. Wes -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48674] Tomcat Virtual Host Manager application doesn't persist newly created virtual hosts
https://issues.apache.org/bugzilla/show_bug.cgi?id=48674 --- Comment #5 from Chuck Caldarale chuck.caldar...@unisys.com 2010-09-24 16:16:06 EDT --- (In reply to comment #4) Is this worth continuing with? I know its rough but I'd like to know if its a start again job, or continue from here. I definitely think it's worthwhile. As far as the error handling goes, I'm in agreement with another e-mail that as much as possible, it should appear to be an atomic operation. It might not always be possible to undo an inserted Host from the live Tomcat, but you can at least tell the user what the situation is. - Chuck -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49998] New: ParserController.hasJspRoot() does not detect JSP as using XML syntax if jsp:root namespace declaration uses ' delimiters instead of
https://issues.apache.org/bugzilla/show_bug.cgi?id=49998 Summary: ParserController.hasJspRoot() does not detect JSP as using XML syntax if jsp:root namespace declaration uses ' delimiters instead of Product: Tomcat 6 Version: 6.0.24 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: km...@autonomy.com I have a simple JSP in XML syntax that looks like this: jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0 content goes here /jsp:root This works fine. However, if I use ' instead of for the namespace declaration, it fails to detect that XML syntax is being used, giving a no such action error instead: jsp:root xmlns:jsp='http://java.sun.com/JSP/Page' version='2.0' content goes here /jsp:root Note that the check is skipped and the bug isn't exposed if external information on the JSP syntax is available (for example, from the web.xml, or because the file ends in .jspx). The problem seems to be on line 615 of org.apache.jasper.compiler.ParserController (in hasJspRoot). When trying to find the namespace declaration, the code only looks for a character, and does not consider ' characters. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49999] New: More bugs
https://issues.apache.org/bugzilla/show_bug.cgi?id=4 Summary: More bugs Product: Tomcat 5 Version: 5.5.31 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: wr...@apache.org Due to particularly the efforts of markt, there seem to be an insufficient number of bugs in the Tomcat category. This could easily be remedied with more veto wars on dev@, committing all to inadequate fixes, or simply introducing regressions. Since Tomcat isn't pulling it's weight against bugzilla, it's only proper to award the tomcat project issue 4 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49999] More bugs
https://issues.apache.org/bugzilla/show_bug.cgi?id=4 William A. Rowe Jr. wr...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 49999] New: More bugs
Pardon my language but WTF? please don't respond GIYF. On Fri, Sep 24, 2010 at 11:35 PM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=4 Summary: More bugs Product: Tomcat 5 Version: 5.5.31 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: wr...@apache.org Due to particularly the efforts of markt, there seem to be an insufficient number of bugs in the Tomcat category. This could easily be remedied with more veto wars on dev@, committing all to inadequate fixes, or simply introducing regressions. Since Tomcat isn't pulling it's weight against bugzilla, it's only proper to award the tomcat project issue 4 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: DO NOT REPLY [Bug 49999] New: More bugs
From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Subject: Re: DO NOT REPLY [Bug 4] New: More bugs Pardon my language but WTF? I think Mr Rowe is actually issuing a compliment to the sterling efforts of Mark T, albeit in a somewhat facetious manner. I'm surprised he didn't wait for #5 to make the award... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49999] More bugs
https://issues.apache.org/bugzilla/show_bug.cgi?id=4 --- Comment #1 from William A. Rowe Jr. wr...@apache.org 2010-09-24 17:58:06 EDT --- One additional correction; Although we might credit markt with mopping away many bugzilla issues, but in all fairness, credit or blame for the lack of Tomcat reports lands squarely at the entire Tomcat crew. Pardon the noise, nothing else to read here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 49999] New: More bugs
On 9/24/2010 4:55 PM, Caldarale, Charles R wrote: From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Subject: Re: DO NOT REPLY [Bug 4] New: More bugs Pardon my language but WTF? I think Mr Rowe is actually issuing a compliment to the sterling efforts of Mark T, albeit in a somewhat facetious manner. Correct, but it was a misattribution. markt can be cited as the overachiever in clearing and keeping clear the legacy tomcat bug queue, but the fact that Tomcat didn't pull its weight in incidents can be assigned to all of the Tomcat dev committers - congrats folks. I'm surprised he didn't wait for #5 to make the award... Oh, there is also an issue 5 :) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 49999] New: More bugs
On Fri, Sep 24, 2010 at 11:59 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 9/24/2010 4:55 PM, Caldarale, Charles R wrote: From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Subject: Re: DO NOT REPLY [Bug 4] New: More bugs Pardon my language but WTF? I think Mr Rowe is actually issuing a compliment to the sterling efforts of Mark T, albeit in a somewhat facetious manner. Correct, but it was a misattribution. markt can be cited as the overachiever in clearing and keeping clear the legacy tomcat bug queue, but the fact that Tomcat didn't pull its weight in incidents can be assigned to all of the Tomcat dev committers - congrats folks. I'm surprised he didn't wait for #5 to make the award... Oh, there is also an issue 5 :) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org And the veto wars? and regressions? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: DO NOT REPLY [Bug 49999] New: More bugs
From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Subject: Re: DO NOT REPLY [Bug 4] New: More bugs And the veto wars? and regressions? Haven't seen a veto war in quite a while. There are lots of regressions, but they're most confined to trunk, not anything users would normally see (with some exceptions, of course). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50001] New: Eclipse source files don't belong in project root.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50001 Summary: Eclipse source files don't belong in project root. Product: Tomcat 7 Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Integration AssignedTo: dev@tomcat.apache.org ReportedBy: wesley.ache...@gmail.com Created an attachment (id=26070) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26070) Target for eclipse support in ant. There are a number of eclipse files in the project root. I've moved them to ./res/ide-support/eclipse and updated build.xml to pull these files to project root when ant eclipse. based on this conversation. http://markmail.org/message/pa3slps3o55yebfk -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49955] Building instructions incorrect.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49955 --- Comment #3 from Wesley wesley.ache...@gmail.com 2010-09-24 22:11:55 EDT --- Created an attachment (id=26071) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26071) Patch based on current svn to change to correct main class. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50001] Eclipse source files don't belong in project root.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50001 Wesley wesley.ache...@gmail.com changed: What|Removed |Added Attachment #26070|application/octet-stream|text/plain mime type|| Attachment #26070|0 |1 is patch|| -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
