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:

   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.

david jencks