geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Possible for G to directly consume a Tomcat server config w/o changes?
Date Fri, 19 Jun 2009 22:18:55 GMT

On Jun 15, 2009, at 9:11 PM, David Jencks wrote:

>
> On Jun 15, 2009, at 7:05 PM, Ivan wrote:
>
>>
>>
>> 2009/6/16 David Jencks <david_jencks@yahoo.com>
>>
>> On Jun 15, 2009, at 3:16 AM, Ivan wrote:
>>
>>> Hi,
>>>    After reading those Tomcat integration codes, it seems easier  
>>> for those Tomcat users. But maybe much further work need to be  
>>> done due to this change, I just feel that this change is "too  
>>> big" :-)
>>>   From what I see,
>>>   1. Some portlet codes needs to be update, such as we could never  
>>> list connectors via searching GBeans in the kernel.
>>
>> I'm not sure about this.  We actually have 2 independent ways to  
>> configure a tomcat server.  I'm not sure we can afford 2 separate  
>> console implementations to configure both of them.  We should be  
>> able to _list_ connectors by looking for mbeans in the mbean  
>> server.  Adding/removing them would be considerably more  
>> complicated.  We might try something like we have for activemq  
>> where you can edit the plan and restart it.
>>    Ivan :
>>    Yes, I agree that we could look for them in the mebean server,  
>> or directly list them from tomcat internal classes, like what  
>> ActiveMQ now does.
>>    So, do we plan to use the server.xml to maintaine the Tomcat  
>> configurations in the future ? If we use the way what ActiveMQ does  
>> now, many portlets may not be used. For maintaining those  
>> configurations in two places is not a good choice. And it means  
>> that a big change occurs, the user may be used to add/remove  
>> connector via portlet, I wish to keep those portlets, may be we  
>> could change those logic behind the portlet, for example, just  
>> using JAXB to marshall/unmarshall those connector settings to the  
>> server.xml.
>>
>>>   2. In the server.xml, we may need some placeholders to use those  
>>> values in the config-subsitution.xml file
>>
>> I agree with this idea.
>>
>>
>>>   3. Many configurations used in the past could not be used, such  
>>> as HostGBean, ValveGBean ....etc
>>
>> I left the entire set of old gbeans in place so that old style  
>> geronimo plans using these gbeans should continue to work.
>>
>> Ivan :
>>    Let's take HostGBean as an example, it depends on the  
>> EngineGBean, but now  we did not have EngineGBean, for all the  
>> objects are built in those JAXB classes. I have an idea, in those  
>> JAXB classes, create all those GBeans dynamically, or shall we make  
>> those beans are GBeans and JAXB Beans in the same time, not sure if  
>> it works, I have not tried it.
>
> I forgot about putting e.g. HostGBean in application plans.  I think  
> we can do something like I did for IIRC the web context gbean so it  
> can reference either style of server configuration.  If you don't  
> beat me to it I'll try to take a look tomorrow.

I made it so the EngineGBean can either (old way) create an engine or  
(new way) wrap an engine it fishes out of the TomcatServerGBean.  I  
think this should fix at least the HostGBean reference problem.  Are  
there others I don't see yet?


>> 2009-06-15 03:04:35,673 ERROR [ServerLifecycleListener]  
>> createMBeans: MBeanException
>> java.lang.Exception: ManagedBean is not found with MBeanFactory
>>     at  
>> org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java: 
>> 459)
>>     at  
>> org 
>> .apache 
>> .catalina 
>> .mbeans 
>> .ServerLifecycleListener.createMBeans(ServerLifecycleListener.java: 
>> 553)
>>     at  
>> org 
>> .apache 
>> .catalina 
>> .mbeans 
>> .ServerLifecycleListener.createMBeans(ServerLifecycleListener.java: 
>> 277)
>>     at  
>> org 
>> .apache 
>> .catalina 
>> .mbeans 
>> .ServerLifecycleListener 
>> .lifecycleEvent(ServerLifecycleListener.java:129)
>>     at  
>> org 
>> .apache 
>> .catalina 
>> .util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
>>     at  
>> org.apache.catalina.core.StandardServer.start(StandardServer.java: 
>> 703)
>>     at  
>> org 
>> .apache 
>> .geronimo.tomcat.TomcatServerGBean.doStart(TomcatServerGBean.java: 
>> 108)
>>     at  
>> org 
>> .apache 
>> .geronimo 
>> .gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948)

This turned out to be caused by missing mbeans-descriptors.xml files.   
I fixed out tomcat build to have the source files in resources and am  
pushing a new snapshot.  This seems to fix this problem.

thanks
david jencks


Mime
View raw message