TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored
Hi, Using Tomcat 5.5.12 and my servlet context fragment: reloadable="false" crossContext="true"> prefix="localhost_gridsphere_log." suffix=".txt" timestamp="true"/> doesn't seem to work-- I get this message in my logfile: WARNING: A docBase /Users/novotny/Jakarta/tomcat-5.5.12/webapps/gridsphere ins ide the host appBase has been specified, and will be ignored Navigating to localhost:8080/portal gives me a 403 This worked before, I'm wondering if this is a known bug or if there is now a new way to configure the web app? Thanks, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored
Hi Yoav and Chuck, Thanks for your help. I have taken out the Logger element and I still get the same error. Let me explain better what I'm trying to do and maybe you can suggest the correct configuration. Our portal is deployed to Tomcat as well as a context fragment, gridsphere.xml to the $CATALINA_HOME/conf/Catalina/localhost/ directory. The context now looks like: reloadable="false" crossContext="true"/> If they access http://localhost:8080/gridsphere it all works fine. However, what instructions can I give our users if they wish to change the URL to be something like http://localhost:8080/portal I don't want them to have to rename the actual deployed web application WAR file or directory. Thats what I thought the path and docBase were used for. Thanks very much, Jason Caldarale, Charles R wrote: From: Jason Novotny [mailto:[EMAIL PROTECTED] Subject: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored Using Tomcat 5.5.12 and my servlet context fragment: reloadable="false" crossContext="true"> prefix="localhost_gridsphere_log." suffix=".txt" timestamp="true"/> Please read the doc on the element, especially with regards to the path and docBase attributes: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html Things have changed since 5.0. In summary, you can not use a path attribute unless your tag is in server.xml, and this is strongly discouraged. The preferred location for is in META-INF/context.xml within your webapp; alternatively, it can be placed in conf/Catalina//.xml (where is usually localhost). The docBase attribute should only be used if the webapp is not in Tomcat's webapps directory. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored
Yoav Shapira wrote:
Hi,
Slight juxtaposition of your message:
This certainly seems a lot more limited than the way it worked in TC
5.0. I wonder if I need to file this as a bug or a feature enhancement.
If you have any ideas, I'd love to hear them.
second step that I don't want to do since some of the web app code
internally uses a hardcoded gridsphere web app name).
Idea: Don't hard-code the app name, use ServletContext.getContextName
as needed instead.
Great idea-- where can I find this method
ServletContext.getContextName? It appears non-existent. There is a
method ServletContext.getServletContextName() but that returns the
description as defined in the web.xml and there is a
ServletConfig.getServletName() but that returns the servlet name, I need
a method that will give me the web application name programatically.
Previously I've used getServletPath("") and parse out the last file
separation character but it seems kind of hackish.
Suggestion: Don't file this as a bug or feature enhancement, it's not
likely to change, as many of us see this as an improvement in
enforcement and convention over 5.0.
Hmm, can you tell me where this convention is defined anywhere? This
is not just a problem for my portal but a few others out there that have
presented instructions that no longer work. If say three portal projects
including Pluto and Jetspeed claim this is a problem can it be
considered a bug?
Thanks, Jason
Yoav
On 12/19/05, Jason Novotny <[EMAIL PROTECTED]> wrote:
Hi Yoav,
I tried the context without the Logger element and unfortunately it
still does not work. Based on some other responses I received it seems
there are only two options to modify the context of my webapp from
http://localhost:8080/gridsphere to http://localhost:8080/portal:
1) copy "gridsphere.xml" containing my context fragment to "portal.xml"
AND rename the webapplication from "gridsphere" to "portal". (It's the
2) Create a context like this:
where the web application is then moved outside of the Tomcat webapps/
directory. I don't want to do this either since for the same reasons as
1, I reference some files using the hardcoded gridsphere web app directory.
Thanks for your time, Jason
Yoav Shapira wrote:
Hi,
Loggers are gone and invalid in 5.5. A similar context.xml fragment
without the Logger sub-element works fine for me in 5.5.12.
Yoav
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
weird AJP errors with Tomcat 5.5.12
Hi, Looking at the log files of Tomcat 5.5.12, I see some pretty strange errors, I've never seen before: Does anyone know what this means? Jan 31, 2006 5:16:09 PM org.apache.jk.common.MsgAjp processHeader SEVERE: BAD packet signature 32896 Jan 31, 2006 5:16:11 PM org.apache.jk.common.ChannelSocket receive WARNING: can't read body, waited #259 Jan 31, 2006 5:16:11 PM org.apache.jk.common.ChannelSocket processConnection WARNING: Closing ajp connection -1 Jan 31, 2006 5:16:14 PM org.apache.jk.common.MsgAjp processHeader SEVERE: BAD packet signature 18245 Jan 31, 2006 5:16:14 PM org.apache.jk.common.ChannelSocket processConnection SEVERE: Error, processing connection java.lang.IndexOutOfBoundsException at java.io.BufferedInputStream.read(BufferedInputStream.java:306) at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:597) at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:554) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:662) Thanks, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
valueUnbound does not get called
Hi, I'm writing a portlet that stuffs some data in the session. I put debug staements in the valueBound and valueUnbound methods of my object which implements the HttpSessionBindingListener. I see that the valueBound method is getting invoked, however valueUnbound does not get invoked when the session is invalidated. For fun, I tried doing the same thing in the portal webapp (the primary webapp which all requests must go thru) and it all works fine. It looks like the bug is caused when the portal dispatches to the other portlet web application via the cross context dispatch mechanism. I see the same session is being shared between the portal and the other portlet web apps, but I just can't see why the valueUnbound would not get invoked. Looks like a bug and was wondering if any of the tomcat developers had any idea what is going on. Thanks, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using manager webapp programatically
Hi,
I have a webapp (a portal) that sets the crossContext="true" and so
can accesss other webapps in Tomcat. My goal is to do an include() on
the manager webapp to show the deployed applications. Here is my code:
doGet(HttpServletRequest req, HttpServletResponse res) throws
IOException, ServletException {
ServletContext context = ctx.getContext("/manager");
context.getRequestDispatcher("/list").include(req, res);
}
Unfortunately I get the following:
FAIL - Unknown command /portal
I looked at the source code of the manager app and I see it has this line:
String command = request.getPathInfo();
if (command == null)
command = request.getServletPath();
So it looks like request.getPathInfo() is returning null so then it uses
the getServletPath which returns my servlet path that is doing the
dispatching, "portal" and not "/list" as I desire. Is that expected
behaavior?
I finally "hacked" something together, where I have to pass in my own
implementation of HttpServletRequest object in the include(), where the
getPathInfo returns a hardcoded "/list"-- it works but is a terrible
hack. I'm wondering if there is a better way-- or maybe the manager
webapp could be altered so that instead of doing request.getPathInfo it
could do some kind of request.getParameter().. in which case the manager
webapp would be invoked by doing /manager?command=list instead of
/manager/list
Thanks, Jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: using manager webapp programatically
Cool-- I'm new to JMX, can you provide any sample snippet code or
place to look in order to use the Tomcat JMX stuff?
Thanks a bunch, Jason
Yoav Shapira wrote:
Hi,
I don't have time to delve deeply into looking at the manager app
request path info code right now, but a quick suggestion: if I were to
do anything building on top of the manager / admin webapp
functionality, I wouldn't do it via request includes, and I would
instead build on top of the JMX stuff exposed by Tomcat. That should
not only be easier, but more portable because your app and the manager
app wouldn't have to run on the same instance of Tomcat (which you do
when you rely on crossContext).
Yoav
On 10/9/06, Jason Novotny <[EMAIL PROTECTED]> wrote:
Hi,
I have a webapp (a portal) that sets the crossContext="true" and so
can accesss other webapps in Tomcat. My goal is to do an include() on
the manager webapp to show the deployed applications. Here is my code:
doGet(HttpServletRequest req, HttpServletResponse res) throws
IOException, ServletException {
ServletContext context = ctx.getContext("/manager");
context.getRequestDispatcher("/list").include(req, res);
}
Unfortunately I get the following:
FAIL - Unknown command /portal
I looked at the source code of the manager app and I see it has this
line:
String command = request.getPathInfo();
if (command == null)
command = request.getServletPath();
So it looks like request.getPathInfo() is returning null so then it uses
the getServletPath which returns my servlet path that is doing the
dispatching, "portal" and not "/list" as I desire. Is that expected
behaavior?
I finally "hacked" something together, where I have to pass in my own
implementation of HttpServletRequest object in the include(), where the
getPathInfo returns a hardcoded "/list"-- it works but is a terrible
hack. I'm wondering if there is a better way-- or maybe the manager
webapp could be altered so that instead of doing request.getPathInfo it
could do some kind of request.getParameter().. in which case the manager
webapp would be invoked by doing /manager?command=list instead of
/manager/list
Thanks, Jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
