Yup .... I agree that if we continue to support multiple web managers
then we need to enhance/extend the console for this. However, the
multiple containers was a fairly recent addition and the console hasn't
been updated to reflect this (plus I'm not sure if that decision is
final yet).
I think it's questionable if we should ever extend the console to
support multiple web managers even if we continue to support this in G.
- most customers will not run a configuration with multiple web managers
(IMO probably none).
- Reflecting a multiple web manager structure in the console will
complicate the user interface and confuse most of our customers
(assuming I'm correct on the first point above). BTW, I'm still
convinced that if we go down the multiple web manager path we're not
just talking tomcat, jetty, or both ... but rather N number of web
managers (after all, GBeans can certainly support it).
Is it true the unmodified image that the current image that is built for
G still includes both containers? If so, I would assume that most users
would pick it up and initially experiment with it without change. In
that scenario I think it would be best if the console functioned as
expected. So it appears that we either need to:
1) tweak the console for the "most important" web manager (the one it is
running in).
2) enhance the console to support multiple web managers
3) change the default configuration for G to include just one web manager.
4) Permit the ability to run the same application concurrently in any
number of web managers with all references to the manager presumed to be
the "local" manager (ie. the container in which this is application is
executing). This would enable applications such as the console to return
the expected behavior. To do this right I think we would also have to
update the deploy capability to easily be able to deploy an application
to any one of the installed containers and provide some level of
isolation between the applications deployed in different containers so
that a user could update Appl A on container 1 without affecting Appl A
on container 2.
Since #3 is still controversial it think that eliminates it and #2 from
the choices (for the reasons stated earlier). #1 and #4 are somewhat
related. If we tweak an application like the console to reference only
the local container and deploy it to multiple containers then each
instance of the appl could function independently.
So I will continue to look at a solution for #1 until we reach a final
decision on the "out of the box" G image with regard to the number of
concurrent web managers that are pre-configured.
Joe
David Jencks wrote:
There should now be "tomcat only" and "jetty only" sets of config files
in var/config. Does it work properly if you copy config.tomcat.* to
config.*? I would suggest that if you want to support the "both"
configuration you need to display all the WebManagers that are returned
rather than trying to guess which is "more important"
thanks
david jencks
On Sep 29, 2005, at 8:20 AM, Joe Bohn wrote:
It turns out this isn't a problem with tomcat, the web log viewer
portlet, or even really the management interface. However, it is a
bit related to running multiple containers concurrently.
The problem is that when we query the kernel get the WebManagerNames
from within the portlet(s) we get back an array of 2 (tomcat and
jetty). In several places in the console we assume that the
container that we need to reference to provide appropriate
management information (ie. the container in which the console is
currently running) will always be the first entry in the array. Bad
assumption. In my case the console is running in the tomcat
container but we're attempting to manage the jetty container.
So now I just have to come up with a way to detect which WebManager
is the one for the "default" container.
Joe
Joe Bohn wrote:
Thanks for the information Jeff. Right now I'd just like to get it
working with the current log name tomcat. Sometime after that I'll
try to look into supporting various naming formats, multiple log
files, etc...
I think something really strange is going on with my system (or
perhaps the G image itself) regarding the management interface. I
build G with tomcat as the default by running maven -o tomcat from
G\modules\assembly.
This seems to work because when I start the server I see that tomcat
is using port 8080.
8009 0.0.0.0 Tomcat Connector AJP
8080 0.0.0.0 Tomcat Connector HTTP
8090 0.0.0.0 Jetty Connector HTTP
However, then I try to interact with the management implementation
the JettyLogManagerImpl is what is being invoked rather than the
TomcatLogManagerImpl.
Am I doing something wrong when trying to configure for tomcat as
the default? I'll keep looking ....
Joe
Jeff Genender wrote:
Yes...the 0.0.0.0 is from line 208 of the j2ee-tomcat-plan.xml,
which uses the PlanServerHostname from maven.xml (which happens to
be 0.0.0.0):
prefix=${PlanServerHostname}_access_log.
We can change this via configuration. However, keep in mind this
can change since its configurable. Especially when using virtual
hosts, people like to have multiple log files...so they may have
one that says 0.0.0.0_access_log, and one that says foo_access_log,
etc.
IMHO, I don't like the "0.0.0.0" in the access_log name. I prefer
"localhost".
Thanks for looking into this, Joe.
Jeff
Joe Bohn (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-1029?
page=comments#action_12330793 ]
Joe Bohn commented on GERONIMO-1029:
------------------------------------
I created the jira because there are never any records displayed
in the web access log viewer when G is configured using tomcat. I
created it against both tomcat and management because I was not
sure where the problem existed. I thought tomcat might have a
problem because I expected the 0.0.0.0 to be the date in the file
name. However, based upon Jeff'scomments the problem may be in
the management implementation. I'll take a look.
Btw, I did not yet create the jira for multiple log file processing.
tomcat web log seems to be created with wrong name and isn't
found by the web log viewer portlet
-------------------------------------------------------------------
-----------------------------
Key: GERONIMO-1029
URL: http://issues.apache.org/jira/browse/GERONIMO-1029
Project: Geronimo
Type: Bug
Components: management, Tomcat
Versions: 1.0-M5
Environment: all
Reporter: Joe Bohn
Assignee: Jeff Genender
It seems that the log file for the tomcat web container is being
created with an invalid date in the name. ex.
...geronimo\modules\assembly\target\geronimo-1.0-
SNAPSHOT\var\catalina\logs\0.0.0.0_access_log.2005-09-28.txt
Possibly related (or possibly not) is that the management API
cannot find matches when performing a search.
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
