DO NOT REPLY [Bug 36534] New: - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
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=36534. 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=36534 Summary: Context relative URLs returned by ServletContext.getResource() for the same path are not equal Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Consider the following servlet snippet: URL main = context.getResource(/WEB-INF/wsdl/hello_literal.wsdl); URL sub = new URL(main, hello.xsd); URL sub1 = context.getResource(/WEB-INF/wsdl/hello.xsd); While sub.toString().equals(sub1.toString()) is TRUE, sub.equals(sub1) returns FALSE, where it should also return TRUE. I noticed the reason sub.equals.(sub1) is FALSE is because their getHost() values are different: sub.getHost() - sub1.getHost() - null Notice that in the case of URL sub = new URL(main, hello.xsd); java.net.URLStreamHandler.parseURL() will set host to , while in the case of URL sub1 = context.getResource(/WEB-INF/wsdl/hello.xsd); which is implemented by org.apache.catalina.core.ApplicationContext.getResource() as follows: return new URL (jndi, null, 0, getJNDIUri(hostName, fullPath), new DirContextURLStreamHandler(resources)); the host component is set to null. Changing return new URL (jndi, null, 0, getJNDIUri(hostName, fullPath), new DirContextURLStreamHandler(resources)); to return new URL (jndi, , 0, getJNDIUri(hostName, fullPath), new DirContextURLStreamHandler(resources)); in ApplicationContext.getResource() fixes the problem. Unfortunately, I am having cvs problems, otherwise i would have committed the fix myself. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34928] New: - Context not identified in error log (context descriptor)
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=34928. 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=34928 Summary: Context not identified in error log (context descriptor) Product: Tomcat 5 Version: 5.5.7 Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Configuration: Apache/2.0.40 (Red Hat Linux) mod_jk 1.2.8 Tomcat 5.5.7 Red Hat Linux 9 j2sdk-1_4_2_07 Multiple virtual hosts are configured via context descriptor files e.g. conf/Catalina/myhostname/ROOT.xml If in any of the multiple context descriptor files an error occurs then it is not directly possible to say who the host is that has the error. If the installation has many hosts then the tracking of the error becomes a nightmare. To test for this bug, create a 0 length context descriptor file for one of multiple virtual hosts. Expected behavior: The error text should identify the host name who the error belongs to. Actual behavior: The following error is printed - without reference to the host name. May 16, 2005 11:53:27 AM org.apache.tomcat.util.digester.Digester fatalError SEVERE: Parse Fatal Error at line -1 column -1: Premature end of file. org.xml.sax.SAXParseException: Premature end of file. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown 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 org.apache.tomcat.util.digester.Digester.parse(Digester.java:1545) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:561) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1169) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:292) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1301) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1561) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1570) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1550) at java.lang.Thread.run(Unknown Source) May 16, 2005 11:53:27 AM org.apache.catalina.startup.HostConfig deployDescriptor SEVERE: Error deploying configuration descriptor ROOT.xml -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34929] New: - Context not identified in error log (application web.xml)
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=34929. 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=34929 Summary: Context not identified in error log (application web.xml) Product: Tomcat 5 Version: 5.5.7 Platform: All OS/Version: other Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Configuration: Apache/2.0.40 (Red Hat Linux) mod_jk 1.2.8 Tomcat 5.5.7 Red Hat Linux 9 j2sdk-1_4_2_07 Multiple virtual hosts are configured via context descriptor files e.g. conf/Catalina/myhostname/ROOT.xml If in any of the multiple web.xml files an error occurs then it is not directly possible to say who the host is that has the error. If the installation has many hosts then the tracking of the error becomes a nightmare. To test for this bug, create an invalid web.xml file for one of multiple virtual hosts, e.g. delete an end tag /param-value within a servlet tag. Expected behavior: The error text should identify the host name who the error belongs to. Actual behavior: The following error is printed - without reference to the host name. May 16, 2005 12:40:24 PM org.apache.tomcat.util.digester.Digester fatalError SEVERE: Parse Fatal Error at line 34 column 108: The element type param-value must be terminated by the matching end-tag /param-value. org.xml.sax.SAXParseException: The element type param-value must be terminated by the matching end-tag /param-value. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 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 org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) at org.apache.catalina.startup.ContextConfig.applicationWebConfig(ContextConfig.java:302) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:959) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:249) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4020) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:590) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1106) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1019) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1011) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:440) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:683) at org.apache.catalina.startup.Catalina.start(Catalina.java:537) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at
DO NOT REPLY [Bug 34164] New: - context attributes not available when servlet's destroy() is called
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=34164.
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=34164
Summary: context attributes not available when servlet's
destroy() is called
Product: Tomcat 5
Version: 5.5.7
Platform: PC
OS/Version: Linux
Status: NEW
Severity: blocker
Priority: P2
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
In Tomcat 5.5.7, the context attributes seem to have been removed before the
method destroy() of the loaded servlets is called. This is not the case with
Tomcat 5.0.28 and I guess that it is wrong because Struts for instance relies on
it to destroy its modules (in
org.apache.struts.action.ActionServlet#destroyModules).
In the case of struts, this causes the plugins not to be notified that they are
destroyed what is against their expected behavior.
A simple servlet illustrates the problem:
public class TestServlet extends HttpServlet
{
public void init() throws ServletException
{
log(In init TestServlet);
getServletContext().setAttribute(test, test);
log(Attribute test: + getServletContext().getAttribute(test));
}
public void destroy()
{
log(In destroy TestServlet);
log(Attribute test: + getServletContext().getAttribute(test));
super.destroy();
}
}
Configured with:
servlet
servlet-nametest/servlet-name
descriptionCustom test/description
servlet-classde.internetzky.test.TestServlet/servlet-class
load-on-startup2/load-on-startup
/servlet
servlet-mapping
servlet-nametest/servlet-name
url-pattern/foo/*/url-pattern
/servlet-mapping
Gives following output in Tomcat 5.5.7:
INFO main org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/test]
- test: In init TestServlet
INFO main org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/test]
- test: Attribute test: test
INFO http-8080-Processor24
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/test] - test: In
destroy TestServlet
INFO http-8080-Processor24
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/test] - test:
Attribute test: null
but in Tomcat 5.0.28:
StandardContext[/test]test: In init TestServlet
StandardContext[/test]test: Attribute test: test
StandardContext[/test]test: In destroy TestServlet
StandardContext[/test]test: Attribute test: test
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33909] New: - Context attributes get nullified before ServletContextListener
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=33909.
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=33909
Summary: Context attributes get nullified before
ServletContextListener
Product: Tomcat 5
Version: 5.5.7
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Servlet JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
It seems that context attributes get nullified before ServletContextListener
I have created a small ServletContextListener and this causes a
NullPointerException on contextDestroyed.
public class ProblemListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent arg0) {
SimpleClass contextObject = new SimpleClass();
arg0.getServletContext().setAttribute(CONTEXT, contextObject);
}
public void contextDestroyed(ServletContextEvent arg0) {
SimpleClass container = (SimpleClass) arg0.getServletContext
().getAttribute(CONTEXT);
container.setFoo(ABC);
arg0.getServletContext().removeAttribute(CONTEXT);
}
}
SimpleClass is a bean that as a getter and setter called Foo and a finalizer
that does System.out.println(FINALIZE THIS);
The sample from Sun (near the bottom of http://java.sun.com/j2ee/tutorial/1_3-
fcs/doc/Servlets4.html) sounds like it should not be null at that point.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33832] New: - context attributes get lost
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=33832. 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=33832 Summary: context attributes get lost Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I use ServletContextListener to start/stop of one internal working thread. In contextInitialized(ServletContextEvent event) the Thread object will be created and started, than registred as an attribute: ServletContext context = event.getServletContext(); MailerThread mailerThread = new MailerThread(...); context.setAttribute(de.mints.interrisk.mail.thread, mailerThread) In contextDestroyed(ServletContextEvent event) the thread must be interrupted: ServletContext context = event.getServletContext(); Thread thread = (Thread)context.getAttribute(de.mints.interrisk.mail.thread); thread.interrupt(); Under Tomcat 5.5.4 it works fine, but under 5.5.7 thread == null. It seems the context's attributes go lost. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33266] New: - Context defined datasources require driver classes placed in common 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=33266. 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=33266 Summary: Context defined datasources require driver classes placed in common classloader Product: Tomcat 5 Version: 5.5.7 Platform: All OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Since it is possible to place a DS definition in a web applications context.xml file, it would be also nice if tomcat was able to create such a datasource without having any jars placed in common/lib. Therefore the webapp classloader should be consulted for driver's classes first. This would provide truly self-contained war archives. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32908] New: - context-param s not available from ServletContextListener contextDestroyed() unless prior call to getInitParameter()
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=32908.
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=32908
Summary: context-param s not available from
ServletContextListener contextDestroyed() unless prior
call to getInitParameter()
Product: Tomcat 5
Version: 5.5.4
Platform: PC
OS/Version: Windows 2000
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
context-param s not available from contextDestroyed() of a
ServletContextListener, unless a prior call has been made to to getInitParameter
().
Calling getInitParameter() triggers the merging of web.xml context-param s and
Tomcat application parameters through ApplicationContext mergeParameters(). If
not called prior to the execution of contextDestroyed(), the context-param s
are lost, as ContextConfig removes them prior to the listener running:
// Removing parameters
String[] parameters = context.findParameters();
for (i = 0; i parameters.length; i++) {
context.removeParameter(parameters[i]);
}
The removal of the merged ApplicationParameter[] s has been commented out in
the same method, so provided the merge has occured, nothing is lost, otherwise
the context-param s are unavailable.
Solution is to also not remove the web.xml parameters during ContextConfig.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32867] New: - context distributable property is not modified during reloading
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=32867. 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=32867 Summary: context distributable property is not modified during reloading Product: Tomcat 5 Version: 5.0.30 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The digester rule only set the distributable property to true when the distributable/ element exists in the application. This is not a big problem but unfortunately, as the context instance is recycled, if you remove the distributable/ property, the context will still hold the previous value (ie the context set as distributable) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31495] New: - Context reload causes ClusterManager to stop operating
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=31495. 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=31495 Context reload causes ClusterManager to stop operating Summary: Context reload causes ClusterManager to stop operating Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina:Cluster AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A functioning clustered application works fine when the tomcat server is initially started. Sessions are replicated, etc. As soon as the context is reloaded on one server, the sessions are no longer replicated between servers. A full tomcat restart is required to restore this functionality. The application and configuration are known to be functional, and the problem does not occur on 5.0.25. The problem only occurs on our 5.0.28 installation. We have downgraded our installation to verify this, and the same functionality that does not work properly on 5.0.28 does in fact work on 5.0.25. There is a thread with the subject of Clustering and session replication in the tomcat-users mailing list, starting on 9/29/2004. All relevant output is below: --Host A catalina.out from context reload-- Sep 29, 2004 3:47:26 PM org.apache.catalina.cluster.session.DeltaManager start WARNING: Manager[/nahrgisdev], requesting session state from org.apache.catalina.cluster.mcast.McastMember[tcp://10.0.0.2:4001, 10.0.0.2,4001, alive=253140]. This operation will timeout if no session state has been received within 60 seconds Sep 29, 2004 3:48:26 PM org.apache.catalina.cluster.session.DeltaManager start SEVERE: Manager[/nahrgisdev], No session state received, timing out. --Host B catalina.out from context reload-- Sep 29, 2004 3:50:16 PM org.apache.catalina.cluster.session.DeltaManager start WARNING: Manager[/nahrgisdev], requesting session state from org.apache.catalina.cluster.mcast.McastMember[tcp://10.0.0.1:4001,10.0.0.1,4001, alive=681060]. This operation will timeout if no session state has been received within 60 seconds Sep 29, 2004 3:50:16 AM org.apache.catalina.cluster.session.DeltaManager start INFO: Manager[/nahrgisdev], session state received in 109 ms. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29671] New: - Context don't start with multiple HTTP 1.1 connectors
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=29671. 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=29671 Context don't start with multiple HTTP 1.1 connectors Summary: Context don't start with multiple HTTP 1.1 connectors Product: Tomcat 5 Version: 5.0.25 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am trying to run Tomcat standalone with 3 Coyote HTTP1.1 connectors defined: HTTP1.1 -- Port 22006 (behind the firewall comms) HTTP1.1 -- Port 22002 (normal HTTP access to hosts/contexts) HTTP1.1 -- Port 22003 (HTTPS bound a single IP for 1 hosts/context) When the server starts, all seems good right up until the end of the Tomcat startup where the following exception is thrown: 2004/06/18 01:47:32 org.apache.coyote.tomcat5.MapperListener init WARNING: Error registering contexts java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at java.util.HashMap$EntryIterator.next(HashMap.java:824) at java.util.HashMap.putAllForCreate(HashMap.java:424) at java.util.HashMap.clone(HashMap.java:656) at mx4j.server.DefaultMBeanRepository.clone (DefaultMBeanRepository.java:56) at mx4j.server.MBeanServerImpl.findMBeansByPattern (MBeanServerImpl.java:1603) at mx4j.server.MBeanServerImpl.queryObjectNames (MBeanServerImpl.java:1568) at mx4j.server.MBeanServerImpl.queryMBeans(MBeanServerImpl.java:1512) at org.apache.coyote.tomcat5.MapperListener.init (MapperListener.java:115) at org.apache.coyote.tomcat5.CoyoteConnector.start (CoyoteConnector.java:1510) at org.apache.catalina.core.StandardService.start (StandardService.java:485) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2298) at org.apache.catalina.startup.Catalina.start(Catalina.java:556) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422) This causes all 3 Coyote Connectors to pause - thus not accpeting ANY requests! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Autoreply: DO NOT REPLY [Bug 29671] New: - Context don't start with multiple HTTP 1.1 connectors
You have received this email for one of two reasons. One is that you or someone with your email address in their address book is infected with an email virus, and this virus was emailed to me. The other reason could be that you legitimately tried to contact me through one of my addresses listed on various web sites, in which case I apologize for the inconvenience. I have had to disable all of my old email addresses because of the threat of viruses. Please contact me at [EMAIL PROTECTED] for more information. This will reach me directly. Dan Cardish webmaster for photoartworld.com domain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28417] New: - Context descriptors in appBase do not get deployed
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=28417. 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=28417 Context descriptors in appBase do not get deployed Summary: Context descriptors in appBase do not get deployed Product: Tomcat 5 Version: 5.0.19 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Context descriptors in host appBase do not load. Start with a standard install of Tomcat 5.0.19. Copy conf/server-minimal.xml to conf/server.xml modify conf/Catalina/localhost/admin.xml. Change docBase to absolute path (in my case: /usr/local/tomcat-5.0.19/server/webapps/admin). Start tomcat and verify that the admin context is loaded. Shutdown tomcat Create a directory somewhere outside the tomcat tree (I used /usr/local/webapps/conf). Move conf/Catalina/localhost/admin.xml to created directory Modify server.xml. Change host's appBase to created directory. Add deployOnStartup=true. Start tomcat. Note that admin context is not loaded. I've tried this with mutiple contexts, not just the admin app. I could never get it to work as described in http://jakarta.apache.org/tomcat/tomcat-5.0-doc/deployer-howto.html#Deploying% 20on%20Tomcat%20startup quote The webapps which are present in the host appBase will be deployed if the host deployOnStartup property is true. The deployment process is the following: The Context XML declarations will be deployed first ... /quote Posted to tomcat-user: http://www.mail-archive.com/tomcat- [EMAIL PROTECTED]/msg124362.html Posted to tomcat-dev: http://www.mail-archive.com/tomcat- [EMAIL PROTECTED]/msg56640.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] New: - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false Summary: Context reloadable=true not working if autodeploy=false Product: Tomcat 5 Version: 5.0.18 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A context will not be reloaded automatically if autodeploy has been activated. This is a problem, because if I *do* activate autodeploy, a wepapp gets deployed twice. Once according to server.xml and once automatically. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27752] New: - context fails if the path contains subdirectories
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=27752. 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=27752 context fails if the path contains subdirectories Summary: context fails if the path contains subdirectories Product: Tomcat 5 Version: 5.0.19 Platform: PC URL: http://localhost:8080/admin/frameset.jsp (web admin GUI) OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The context works OK until I try to 'commit changes' on any setting in the GUI web admin or reboot the server. eg context path for the webapp is /courseCode/startDate the directory URL is file:/public/htmldocs/courseCode/startDate If I press save, commit changes then log out, when I log back in again admin returns the following error: type Status report message Error retrieving attribute debug description The server encountered an internal error (Error retrieving attribute debug) that prevented it from fulfilling this request. Manager then does not show that the context exists. Any requests to the page show This application is not currently available If I reboot the server the context has gone as well. If I use a flat context (eg /courseCode_startDate) it works. This was not a problem in previous versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21659] - LogSetter not created when adding a new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21659. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21659 LogSetter not created when adding a new context [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2004-03-07 07:36 --- The issues here are a bit complex, but hopefully it can be addressed in 3.3.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26969] New: - Context/Resources/allowLinking ignored in webapps/*.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26969. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26969 Context/Resources/allowLinking ignored in webapps/*.xml Summary: Context/Resources/allowLinking ignored in webapps/*.xml Product: Tomcat 4 Version: 4.1.29 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Struggled for a few hours to get symlinks in static resources to work... Finally I noticed that using Resources allowLinking=true/ in a seperate xml- file inside webapps directory does not work. Instead, you will have to move the whole Context -element into server.xml to make it work (and yes, even after that, the reload problem still persists, bug# 21818). I suppose this is something that's causing tons of bug reports about symlinks to mailing lists etc... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26010] New: - context path in server.xml doesn't like _ (underscore) character.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26010. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26010 context path in server.xml doesn't like _ (underscore) character. Summary: context path in server.xml doesn't like _ (underscore) character. Product: Tomcat 5 Version: Nightly Build Platform: PC OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] stdout and logs/localhost_log.[date].txt complain when a context path attribute contains a _ (underscore) character. The webapp still deploys fine. The error messages are annoying, that's all! :-) This generates error messages (in server.xml): Context path=/test_ debug=0 docBase=/stuff/empty/ This doesn't: Context path=/test debug=0 docBase=/stuff/empty/ stdout: == INFO: Processing Context configuration file URL file:/home/juliusdavies/jakarta-tomcat-5/conf/Catalina/localhost/test_.xml 8-Jan-2004 7:06:23 PM org.apache.commons.digester.Digester endElement SEVERE: End event threw exception java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [...] Caused by: java.lang.IllegalStateException: Context path /test_ is already in use at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:833) ... 38 more logs/localhost_log.[date].txt: == 2004-01-08 19:06:23 StandardHost[localhost]: Error deploying application at context path null java.lang.IllegalStateException: Context path /test_ is already in use at org.apache.commons.digester.Digester.createSAXException(Digester.java:2540) * Version jakarta-tomcat-5-bin-20040107 * Tomcat component org.apache.catalina.core.StandardHostDeployer.addChild * Platform PC (Intel Pentium III) * OS Linux 2.4.18 (Debian) * JVM Java HotSpot(TM) Server VM (build 1.4.2-b28, mixed mode) * Web Server Tomcat 5.0 listening on port 8080 * Configuration No change to default except single line: Context path=/test_ debug=0 docBase=/stuff/empty/ ps. Am I seeing things? I noticed that deleting a Context from server.xml doesn't actually remove the webapp from service! The webapp will still deploy on Tomcat's next run. Tomcat seems to use the conf/Catalina/**/*.xml files it creates to accomplish this. I get a feeling that context inside server.xml is sort of deprecated, and that I should just create individual context xml files inside conf/Catalina/ instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25244] New: - Context with path= works, path=/ doesn't
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25244. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25244 Context with path= works, path=/ doesn't Summary: Context with path= works, path=/ doesn't Product: Tomcat 4 Version: 4.1.29 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, when using the Tomcat-Administrator to create a Context, the Admin-App changes an empty path to / which means that the server.xml contains an entry with path=/. That doens't work. I get an error message like there's no context configured to handle this request. If i manually change the entry in the server.xml from path=/ to path= it works. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21659] New: - LogSetter not created when adding a new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21659.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21659
LogSetter not created when adding a new context
Summary: LogSetter not created when adding a new context
Product: Tomcat 3
Version: 3.3.1 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: Webapps
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi,
When I add a new context with the admin webapp, I don't have my
servlet logs.
I have a file apps-myAppli.xml with this content :
?xml version=1.0 encoding=ISO-8859-1?
Server
Host name=myAppli
Context path= docBase=/usr/webapps/myAppli
LogSetter name=myAppli_log
path=logs/myAppli_servlet-${MMdd-HH:mm}.log
verbosityLevel=DEBUG
servletLogger=true/
/Context
/Host
/Server
For example, when I start tomcat, my context doesn't exist.
But, 2 minutes later, I add my new context with the webapps/myAppli.war and with
the file apps-myAppli.xml :
- the logFile myAppli_servlet-20030709-10:25.log is not created so there's no
servlet logs.
It seems that the ContextManager, when it adds a context, doesn't add its
interceptors like ContextXmlReader and LogSetter.
When I restart tomcat, the problem is solved.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21010] - Error creating new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010 Error creating new context [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-06-25 08:26 --- *** Bug 20217 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21010] - Error creating new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010 Error creating new context [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-25 08:29 --- This should have been fixed as part of the deployer refactorings. The context file name should now be decoupled from the path name. In case a context file doesn't exist (so it will be created automatically when saving changes in the admin webapp), '/' will be escaped. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21010] - Error creating new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010 Error creating new context [EMAIL PROTECTED] changed: What|Removed |Added Component|Webapps:Administration |Catalina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21010] New: - Error creating new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010 Error creating new context Summary: Error creating new context Product: Tomcat 5 Version: 5.0.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Error saving (Commit changes) new context with '/' char into his name, for example i need to create /app/bpb context. Workaround: I create /appbpb context and then I modify the path attribute from /appbpb to /app/bpb into the HOME/conf/Catalina/localhost/appbpb.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21010] - Error creating new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010 Error creating new context --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 13:33 --- Well, that's a known issue. None of the chars which aren't allowed in a filename are filtered out at the moment, so ... I think this is the same behavior as with TC 4.1.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21010] - Error creating new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21010 Error creating new context --- Additional Comments From [EMAIL PROTECTED] 2003-06-23 14:05 --- Actually, small correction: this doesn't happen in TC 4.1.x, as it doesn't try to save the context stuff as separate files. I'll slightly refactor things and expose a config file base field at the host level, and add escaping code in StandardContext. This should fix the issue, as well as bug 19607. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18383] New: - context path is set to / instead of
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18383. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18383 context path is set to / instead of Summary: context path is set to / instead of Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] just tried to create a new context inside my test-virtualHost context path field: after commit changes and reloading tomcat it was impossible to delete this context by means of the admin webapp. generated links on index pages are also faulty = they always lead to http://file instead of http://virtualhost/file (html source: relative link shows //file instead of /file) i think the cause of this problem is that the path attribute is set to / inside the server.xml config file. when i changed it manually to path= (tomcat shudown - edit server.xml - start again) the context worked proper it was also possible to remove the context via admin webapp when the path is set to hth cybi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16373] New: - context param from server.xml not read when application stopped and started from tomcat webmanager.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16373 context param from server.xml not read when application stopped and started from tomcat webmanager. Summary: context param from server.xml not read when application stopped and started from tomcat webmanager. Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] getServletContext().getInitParameter(helloworld) is getting the param value from web.xml when done like this context-param param-namehelloworld/param-name param-valueHello World! How are you?/param-value /context-param but when given in server.xml as Context path=/test docBase=.. debug=0 crossContext=true privileged=true reloadable=true Parameter name=helloworld value=Hello World! How are you override=true/ /Context it returns null when app is stopped and started again from Tomcat manager. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
new Context
Hi! sorry for stupid question... =) I'am creating a new Context but JSP applications don't work with exception: description: The server encountered an internal error () that prevented it from fulfilling this request. exception: javax.servlet.ServletException: org/apache/jasper/runtime/HttpJspBase etc... Thanks, Alex -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: new Context
What do you mean creating a new Context? Can you give some code example? ... More parts of the stack trace might help as well. Martin Sasha Prikhod'ko wrote: Hi! sorry for stupid question... =) I'am creating a new Context but JSP applications don't work with exception: description: The server encountered an internal error () that prevented it from fulfilling this request. exception: javax.servlet.ServletException: org/apache/jasper/runtime/HttpJspBase etc... Thanks, Alex -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re[2]: new Context
suggest I did quite primitive thing: created a Context in the Tomcat administration tool server.xml: Context className=org.apache.catalina.core.StandardContext cachingAllowed=true charsetMapperClass=org.apache.catalina.util.CharsetMapper cookies=true crossContext=false debug=0 docBase=R:\GIS\jdocbase mapperClass=org.apache.catalina.core.StandardContextMapper path=/GIS privileged=false reloadable=false swallowOutput=false useNaming=true wrapperClass=org.apache.catalina.core.StandardWrapper /Context But jsp raises exceptions when opening on /GIS ! May be I don't understand right how to configure the java environment? Alex -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: new Context
In your server logs did you find any output along the lines of: WebappLoader[/GIS]: Deploying class repositories to work directory /home/martin/main/sites/mysite/var/tomcat/work/Standalone/localhost/GIS ContextConfig[/GIS]: Missing application web.xml, using defaults only StandardManager[/GIS]: Seeding random number generator class java.security.SecureRandom StandardManager[/GIS]: Seeding of random number generator has been completed StandardWrapper[/GIS:default]: Loading container servlet default StandardWrapper[/GIS:invoker]: Loading container servlet invoker Or are there any noises about /GIS? Martin Sasha Prikhod'ko wrote: suggest I did quite primitive thing: created a Context in the Tomcat administration tool server.xml: Context className=org.apache.catalina.core.StandardContext cachingAllowed=true charsetMapperClass=org.apache.catalina.util.CharsetMapper cookies=true crossContext=false debug=0 docBase=R:\GIS\jdocbase mapperClass=org.apache.catalina.core.StandardContextMapper path=/GIS privileged=false reloadable=false swallowOutput=false useNaming=true wrapperClass=org.apache.catalina.core.StandardWrapper /Context But jsp raises exceptions when opening on /GIS ! May be I don't understand right how to configure the java environment? Alex -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re[2]: new Context
Dear, Martin
No, i see no logs the corresponding directory,
but there are files like mywebprog_jsp.java with:
package org.apache.jsp;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;
import java.util.*;
public class ___a_jsp extends HttpJspBase {
private static java.util.Vector _jspx_includes;
public java.util.List getIncludes() {
return _jspx_includes;
}
public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {
.
and i suspect that TomCat cannot compile it
In your server logs did you find any output along the lines of:
WebappLoader[/GIS]: Deploying class repositories to work directory
/home/martin/main/sites/mysite/var/tomcat/work/Standalone/localhost/GIS
ContextConfig[/GIS]: Missing application web.xml, using defaults only
StandardManager[/GIS]: Seeding random number generator class
java.security.SecureRandom
StandardManager[/GIS]: Seeding of random number generator has been completed
StandardWrapper[/GIS:default]: Loading container servlet default
StandardWrapper[/GIS:invoker]: Loading container servlet invoker
Or are there any noises about /GIS?
Martin
Sasha Prikhod'ko wrote:
suggest I did quite primitive thing:
created a Context in the Tomcat administration tool
server.xml:
Context className=org.apache.catalina.core.StandardContext
cachingAllowed=true
charsetMapperClass=org.apache.catalina.util.CharsetMapper
cookies=true crossContext=false debug=0
docBase=R:\GIS\jdocbase
mapperClass=org.apache.catalina.core.StandardContextMapper
path=/GIS privileged=false reloadable=false
swallowOutput=false useNaming=true
wrapperClass=org.apache.catalina.core.StandardWrapper
/Context
But jsp raises exceptions when opening on /GIS !
May be I don't understand right how to configure the java
environment?
Alex
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 11747] New: - Context level LifeCycleListener does not get invoked if context is defined in a my-context.xml file rather than in server.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11747. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11747 Context level LifeCycleListener does not get invoked if context is defined in a my-context.xml file rather than in server.xml Summary: Context level LifeCycleListener does not get invoked if context is defined in a my-context.xml file rather than in server.xml Product: Tomcat 4 Version: 4.1.9 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Context defined in my-context.xml starts fine everything seems to work except my LifeCycleListener defined in my-context.xml does not get invoked If I move context definition to server.xml it works fine. LifeCycleListener gets called as expected -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9475] New: - Context with path != docBase autodeployment causes double deployment
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9475. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9475 Context with path != docBase autodeployment causes double deployment Summary: Context with path != docBase autodeployment causes double deployment Product: Tomcat 4 Version: 4.0.4 Beta 3 Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] eg. Host ... appbase=webapps unpackWARs=true Context path=/apps docBase=mywebapp / /Host This configuration would deploy both /apps and /mywebapp. /mywebapp would be lacking any resources in the context (instead deployed as a DefaultContext). This is not the behaviour I'd expect - Tomcat should not autodeploy any directories or WAR files where the docBase is already specified. Workaround: remove appBase and specify docBase as an absolute path: Host ... (no appBase) Context path=/apps docBase=/usr/local/tomcat/webapps/mywebapp / /Host -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8418] New: - Context declarations causing war files not to be expanded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8418. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8418 Context declarations causing war files not to be expanded Summary: Context declarations causing war files not to be expanded Product: Tomcat 4 Version: 4.0.1 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When specifying a context in the server.xml file, and placing the application in the webapps directory as a war file, tomcat does not expand it out. Tomcat gives the following error at startup: 2002-04-23 10:01:37 StandardContext[/resourcetracker]: Error initializing resources: Document base /cust/jakarta-tomcat-4.1/webapps/resourcetracker does not exist or is not a readable directory 2002-04-23 10:01:37 StandardContext[/resourcetracker]: Context startup failed due to previous errors 2002-04-23 10:01:37 StandardContext[/resourcetracker]: Exception during cleanup after start failed LifecycleException: Container StandardContext[/resourcetracker] has not been started at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1147) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3440) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3397) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardHost.start(StandardHost.java:612) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:307) at org.apache.catalina.core.StandardService.start(StandardService.java:388) at org.apache.catalina.core.StandardServer.start(StandardServer.java:505) at org.apache.catalina.startup.Catalina.start(Catalina.java:776) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) If instead I remove the context specification from the server.xml file the application war file is expanded at startup and everything proceeds as expected. It appears the expansion handling is not called first when specifying a context under the host tag. The virtual host is defined as follows: !-- Define the default virtual host -- Host name=localhost debug=0 appBase=webapps unpackWARs=true underneath it is the following context tag: Context path=/resourcetracker docBase=resourcetracker debug=0 reloadable=true unpackWARs=true Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_resourcetracker_log. suffix=.txt timestamp=true/ /Context -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6137] New: - Context Administration removes /ROOT instead of the specified context at first remove request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6137. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6137 Context Administration removes /ROOT instead of the specified context at first remove request Summary: Context Administration removes /ROOT instead of the specified context at first remove request Product: Tomcat 3 Version: 3.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using the Tomcat 3.3 Context Administration web interface to remove a context by name (say, context /test) the context /ROOT gets removed instead of the specified one. The following is logged: 2002-01-30 23:48:18 - ContextManager: Removing context DEFAULT:/ROOT 2002-01-30 23:48:18 - Ctx() : Remove mapping On second subsequent request to remove the same context it actually removes it giving out the following 2002-01-30 23:48:28 - ContextManager: Removing context DEFAULT:/test 2002-01-30 23:48:28 - Ctx(/test) : Remove mapping /test 2002-01-30 23:48:28 - Ctx(/test) : Remove mapping /test/test And in the servlet log the expected: test: test: destroy On further requests to add or remove the context it works as expected. However, if the context /ROOT is added then it gets removed again when trying to remove some other context. The context removing via the context list (View All Contexts) works as expected removing the specified context. I have seen this behaviour on Tomcat 3.3a and Tomcat 3.3.1-dev (2002-01-30) (directly out of package, just modifying conf/apps-admin.xml to make admin webapp trusted). The JVM is Sun JDK 1.3.1_02 on Linux. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
