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_jen...@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
