geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: [jira] Commented: (GERONIMO-1029) tomcat web log seems to be created with wrong name and isn't found by the web log viewer portlet
Date Thu, 29 Sep 2005 16:14:17 GMT
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
>> joe.bohn@earthlink.net
>>
>> "He is no fool who gives what he cannot keep, to gain what he cannot  
>> lose."   -- Jim Elliot
>>
> 
> 
> 

-- 
Joe Bohn
joe.bohn@earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message