Re: Possible for G to directly consume a Tomcat server config w/o changes?
2009/6/23 David Jencks david_jen...@yahoo.com On Jun 22, 2009, at 9:27 PM, Ivan wrote: After checking the current changes to the realm, in the past, we will set the geronimo-admin for the Engine, which means that all the web-apps belong to the Engine will use the realm setting from its parent if no setting is set for those web-apps. Currently, the realm for the Engine is remained for Tomcat's default setting, which uses users.xml. So far, I did not see any effect to our existing console applications, I am not sure whether we need to recover it. IMO, keep the current way is better. Any comment ? Unless I've forgotten something only the jacc realms that are specifically configured for a particular application hook into the geronimo security system. So I don't expect anyone to use any other realms, and what the default realm is doesn't make a lot of difference. thanks david jencks Ivan 2009/6/22 Ivan xhh...@gmail.com 2009/6/22 David Jencks david_jen...@yahoo.com On Jun 21, 2009, at 10:20 PM, Ivan wrote: 2009/6/22 David Jencks david_jen...@yahoo.com On Jun 19, 2009, at 9:18 PM, Ivan wrote: Currently, what I can see are 1. Recover those configurations that we used for Tomcat in the server.xml For connectors, I may have done most of this in my work for (3) could use some checking. I'd also like to see if I can make the tomcat connectors use our thread pool -- a new feature I've wanted for years :-) 2. Update the console codes, and decide whether we need to keep the functions like add/remove connectors. If keep, the way we do it is to add/remove ConnectorGBean or to marshall/remarshall server.xml. Hi, David, do you still work on this ? 3. Make those settings in the server.xml not hardcoded. I implemented this here, not sure if I'll get it committed today or tomorrow I committed this in rev 787153. I exposed the replacement code the local attribute manager uses. I'm thinking of modifying the activemq integration to use this method instead of spring property substitution. Native support from Geronimo for the subsitution is better, for ActiveMQ integration, IIRC, maybe a bit extra work needs, for i add some extra properties to the property configuration, which are not contained in the config-substitution. 4. Recover those GBeans that console/other components used, such as AccessLogValve etc. Maybe the AccessLogValve can fish its valve out of the server like the engine gbean now does? I will try to do it, Valve is a bit different with the Engine, for it has no name attribute, and Engine/Host all could hold to a list of them. My way is to use the seq to identify it, like what it is done by its object name. Looking forward to seeing this! DONE with At revision: 787174. BTW, I guess that we also need to look at the realm setting for Tomcat. thanks david jencks thanks david jencks I would like to work at parts of them, if we have decided to import this feature in 2.2. And I suggest that we open a JIRA for each of them, so that we could track them clearly. Thanks ! Ivan 2009/6/20 David Jencks david_jen...@yahoo.com After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re-evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/configurations that just run on Geronimo, the better off we are... --kevan -- Ivan -- Ivan -- Ivan -- Ivan -- Ivan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 21, 2009, at 10:20 PM, Ivan wrote: 2009/6/22 David Jencks david_jen...@yahoo.com On Jun 19, 2009, at 9:18 PM, Ivan wrote: Currently, what I can see are 1. Recover those configurations that we used for Tomcat in the server.xml For connectors, I may have done most of this in my work for (3) could use some checking. I'd also like to see if I can make the tomcat connectors use our thread pool -- a new feature I've wanted for years :-) 2. Update the console codes, and decide whether we need to keep the functions like add/remove connectors. If keep, the way we do it is to add/remove ConnectorGBean or to marshall/remarshall server.xml. 3. Make those settings in the server.xml not hardcoded. I implemented this here, not sure if I'll get it committed today or tomorrow I committed this in rev 787153. I exposed the replacement code the local attribute manager uses. I'm thinking of modifying the activemq integration to use this method instead of spring property substitution. 4. Recover those GBeans that console/other components used, such as AccessLogValve etc. Maybe the AccessLogValve can fish its valve out of the server like the engine gbean now does? I will try to do it, Valve is a bit different with the Engine, for it has no name attribute, and Engine/Host all could hold to a list of them. My way is to use the seq to identify it, like what it is done by its object name. Looking forward to seeing this! thanks david jencks thanks david jencks I would like to work at parts of them, if we have decided to import this feature in 2.2. And I suggest that we open a JIRA for each of them, so that we could track them clearly. Thanks ! Ivan 2009/6/20 David Jencks david_jen...@yahoo.com After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re- evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/ configurations that just run on Geronimo, the better off we are... --kevan -- Ivan -- Ivan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
2009/6/22 David Jencks david_jen...@yahoo.com On Jun 21, 2009, at 10:20 PM, Ivan wrote: 2009/6/22 David Jencks david_jen...@yahoo.com On Jun 19, 2009, at 9:18 PM, Ivan wrote: Currently, what I can see are 1. Recover those configurations that we used for Tomcat in the server.xml For connectors, I may have done most of this in my work for (3) could use some checking. I'd also like to see if I can make the tomcat connectors use our thread pool -- a new feature I've wanted for years :-) 2. Update the console codes, and decide whether we need to keep the functions like add/remove connectors. If keep, the way we do it is to add/remove ConnectorGBean or to marshall/remarshall server.xml. 3. Make those settings in the server.xml not hardcoded. I implemented this here, not sure if I'll get it committed today or tomorrow I committed this in rev 787153. I exposed the replacement code the local attribute manager uses. I'm thinking of modifying the activemq integration to use this method instead of spring property substitution. Native support from Geronimo for the subsitution is better, for ActiveMQ integration, IIRC, maybe a bit extra work needs, for i add some extra properties to the property configuration, which are not contained in the config-substitution. 4. Recover those GBeans that console/other components used, such as AccessLogValve etc. Maybe the AccessLogValve can fish its valve out of the server like the engine gbean now does? I will try to do it, Valve is a bit different with the Engine, for it has no name attribute, and Engine/Host all could hold to a list of them. My way is to use the seq to identify it, like what it is done by its object name. Looking forward to seeing this! DONE with At revision: 787174. BTW, I guess that we also need to look at the realm setting for Tomcat. thanks david jencks thanks david jencks I would like to work at parts of them, if we have decided to import this feature in 2.2. And I suggest that we open a JIRA for each of them, so that we could track them clearly. Thanks ! Ivan 2009/6/20 David Jencks david_jen...@yahoo.com After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re-evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/configurations that just run on Geronimo, the better off we are... --kevan -- Ivan -- Ivan -- Ivan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
After checking the current changes to the realm, in the past, we will set the geronimo-admin for the Engine, which means that all the web-apps belong to the Engine will use the realm setting from its parent if no setting is set for those web-apps. Currently, the realm for the Engine is remained for Tomcat's default setting, which uses users.xml. So far, I did not see any effect to our existing console applications, I am not sure whether we need to recover it. IMO, keep the current way is better. Any comment ? Ivan 2009/6/22 Ivan xhh...@gmail.com 2009/6/22 David Jencks david_jen...@yahoo.com On Jun 21, 2009, at 10:20 PM, Ivan wrote: 2009/6/22 David Jencks david_jen...@yahoo.com On Jun 19, 2009, at 9:18 PM, Ivan wrote: Currently, what I can see are 1. Recover those configurations that we used for Tomcat in the server.xml For connectors, I may have done most of this in my work for (3) could use some checking. I'd also like to see if I can make the tomcat connectors use our thread pool -- a new feature I've wanted for years :-) 2. Update the console codes, and decide whether we need to keep the functions like add/remove connectors. If keep, the way we do it is to add/remove ConnectorGBean or to marshall/remarshall server.xml. 3. Make those settings in the server.xml not hardcoded. I implemented this here, not sure if I'll get it committed today or tomorrow I committed this in rev 787153. I exposed the replacement code the local attribute manager uses. I'm thinking of modifying the activemq integration to use this method instead of spring property substitution. Native support from Geronimo for the subsitution is better, for ActiveMQ integration, IIRC, maybe a bit extra work needs, for i add some extra properties to the property configuration, which are not contained in the config-substitution. 4. Recover those GBeans that console/other components used, such as AccessLogValve etc. Maybe the AccessLogValve can fish its valve out of the server like the engine gbean now does? I will try to do it, Valve is a bit different with the Engine, for it has no name attribute, and Engine/Host all could hold to a list of them. My way is to use the seq to identify it, like what it is done by its object name. Looking forward to seeing this! DONE with At revision: 787174. BTW, I guess that we also need to look at the realm setting for Tomcat. thanks david jencks thanks david jencks I would like to work at parts of them, if we have decided to import this feature in 2.2. And I suggest that we open a JIRA for each of them, so that we could track them clearly. Thanks ! Ivan 2009/6/20 David Jencks david_jen...@yahoo.com After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re-evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/configurations that just run on Geronimo, the better off we are... --kevan -- Ivan -- Ivan -- Ivan -- Ivan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 22, 2009, at 9:27 PM, Ivan wrote: After checking the current changes to the realm, in the past, we will set the geronimo-admin for the Engine, which means that all the web-apps belong to the Engine will use the realm setting from its parent if no setting is set for those web-apps. Currently, the realm for the Engine is remained for Tomcat's default setting, which uses users.xml. So far, I did not see any effect to our existing console applications, I am not sure whether we need to recover it. IMO, keep the current way is better. Any comment ? Unless I've forgotten something only the jacc realms that are specifically configured for a particular application hook into the geronimo security system. So I don't expect anyone to use any other realms, and what the default realm is doesn't make a lot of difference. thanks david jencks Ivan 2009/6/22 Ivan xhh...@gmail.com 2009/6/22 David Jencks david_jen...@yahoo.com On Jun 21, 2009, at 10:20 PM, Ivan wrote: 2009/6/22 David Jencks david_jen...@yahoo.com On Jun 19, 2009, at 9:18 PM, Ivan wrote: Currently, what I can see are 1. Recover those configurations that we used for Tomcat in the server.xml For connectors, I may have done most of this in my work for (3) could use some checking. I'd also like to see if I can make the tomcat connectors use our thread pool -- a new feature I've wanted for years :-) 2. Update the console codes, and decide whether we need to keep the functions like add/remove connectors. If keep, the way we do it is to add/remove ConnectorGBean or to marshall/remarshall server.xml. 3. Make those settings in the server.xml not hardcoded. I implemented this here, not sure if I'll get it committed today or tomorrow I committed this in rev 787153. I exposed the replacement code the local attribute manager uses. I'm thinking of modifying the activemq integration to use this method instead of spring property substitution. Native support from Geronimo for the subsitution is better, for ActiveMQ integration, IIRC, maybe a bit extra work needs, for i add some extra properties to the property configuration, which are not contained in the config-substitution. 4. Recover those GBeans that console/other components used, such as AccessLogValve etc. Maybe the AccessLogValve can fish its valve out of the server like the engine gbean now does? I will try to do it, Valve is a bit different with the Engine, for it has no name attribute, and Engine/Host all could hold to a list of them. My way is to use the seq to identify it, like what it is done by its object name. Looking forward to seeing this! DONE with At revision: 787174. BTW, I guess that we also need to look at the realm setting for Tomcat. thanks david jencks thanks david jencks I would like to work at parts of them, if we have decided to import this feature in 2.2. And I suggest that we open a JIRA for each of them, so that we could track them clearly. Thanks ! Ivan 2009/6/20 David Jencks david_jen...@yahoo.com After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re- evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/ configurations that just run on Geronimo, the better off we are... --kevan -- Ivan -- Ivan -- Ivan -- Ivan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 19, 2009, at 9:18 PM, Ivan wrote: Currently, what I can see are 1. Recover those configurations that we used for Tomcat in the server.xml For connectors, I may have done most of this in my work for (3) could use some checking. I'd also like to see if I can make the tomcat connectors use our thread pool -- a new feature I've wanted for years :-) 2. Update the console codes, and decide whether we need to keep the functions like add/remove connectors. If keep, the way we do it is to add/remove ConnectorGBean or to marshall/remarshall server.xml. 3. Make those settings in the server.xml not hardcoded. I implemented this here, not sure if I'll get it committed today or tomorrow 4. Recover those GBeans that console/other components used, such as AccessLogValve etc. Maybe the AccessLogValve can fish its valve out of the server like the engine gbean now does? thanks david jencks I would like to work at parts of them, if we have decided to import this feature in 2.2. And I suggest that we open a JIRA for each of them, so that we could track them clearly. Thanks ! Ivan 2009/6/20 David Jencks david_jen...@yahoo.com After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re- evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/ configurations that just run on Geronimo, the better off we are... --kevan -- Ivan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
2009/6/22 David Jencks david_jen...@yahoo.com On Jun 19, 2009, at 9:18 PM, Ivan wrote: Currently, what I can see are 1. Recover those configurations that we used for Tomcat in the server.xml For connectors, I may have done most of this in my work for (3) could use some checking. I'd also like to see if I can make the tomcat connectors use our thread pool -- a new feature I've wanted for years :-) 2. Update the console codes, and decide whether we need to keep the functions like add/remove connectors. If keep, the way we do it is to add/remove ConnectorGBean or to marshall/remarshall server.xml. 3. Make those settings in the server.xml not hardcoded. I implemented this here, not sure if I'll get it committed today or tomorrow 4. Recover those GBeans that console/other components used, such as AccessLogValve etc. Maybe the AccessLogValve can fish its valve out of the server like the engine gbean now does? I will try to do it, Valve is a bit different with the Engine, for it has no name attribute, and Engine/Host all could hold to a list of them. My way is to use the seq to identify it, like what it is done by its object name. thanks david jencks I would like to work at parts of them, if we have decided to import this feature in 2.2. And I suggest that we open a JIRA for each of them, so that we could track them clearly. Thanks ! Ivan 2009/6/20 David Jencks david_jen...@yahoo.com After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re-evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/configurations that just run on Geronimo, the better off we are... --kevan -- Ivan -- Ivan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re-evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/configurations that just run on Geronimo, the better off we are... --kevan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re-evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/configurations that just run on Geronimo, the better off we are... --kevan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
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
Re: Possible for G to directly consume a Tomcat server config w/o changes?
After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re-evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/ configurations that just run on Geronimo, the better off we are... --kevan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
Currently, what I can see are 1. Recover those configurations that we used for Tomcat in the server.xml 2. Update the console codes, and decide whether we need to keep the functions like add/remove connectors. If keep, the way we do it is to add/remove ConnectorGBean or to marshall/remarshall server.xml. 3. Make those settings in the server.xml not hardcoded. 4. Recover those GBeans that console/other components used, such as AccessLogValve etc. I would like to work at parts of them, if we have decided to import this feature in 2.2. And I suggest that we open a JIRA for each of them, so that we could track them clearly. Thanks ! Ivan 2009/6/20 David Jencks david_jen...@yahoo.com After fixing the HostGBean in web app plan problem I don't have a very clear idea of what's missing here. If one of you do could you please list in detail what needs to be done? thanks david jencks On Jun 19, 2009, at 8:51 AM, Ivan wrote: It is easy to add the SSL connector, the things that Jack concens is that, how do the changes affect other components, I think. Ivan 2009/6/19 Kevan Miller kevan.mil...@gmail.com On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: Looks like this is going be a piece of non-trivial work. Considering that we are going for a 2.2 release, should we re-evaluate whether this feature should be in 2.2? My gut feeling is no. We should really stablize the code and resovle TCK issues. If it's *hard* to add the SSL connector configuration, then something is clearly wrong. Personally, I'd be pretty interested in seeing this type of support in 2.2. The more Tomcat apps/configurations that just run on Geronimo, the better off we are... --kevan -- Ivan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 14, 2009, at 8:30 PM, Ivan wrote: In which snapshot site, I could find the tomcat build ? I have checked the people, not found. https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/ This is in the apache 6 pom... are you having trouble accessing it from china? Then I tried to build them on my local machine, some errors occured, is there any option that I could set ? (I just run 'mvn install') Don't build the archetype directly run ./build-archetype.sh. It only works on unix like systems. did you check out this? https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-6.0.18 For the tomcat-archetype, it said that org.eclipse.jdt:core:jar: 3.2.3.v_686_R32x could not be found that's odd, I thought my local nexus found it in maven central repo but it's not there now. I'll update it to 3.3.0-v_771 For the tomcat-parent-6.0.18, it said --- /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/core/DefaultInstanceManager.java:[42,20] package javax.xml.ws does not exist I was compiling on java 6. I'll add geronimo-jaxws_2.1_spec Thanks for trying it out, let me know if there are more problems! david jencks /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/session/StandardSession.java:[47,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/session/StandardSessionFacade.java:[26,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/session/StandardSession.java:[268,21] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/session/StandardSessionFacade.java:[104,11] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/core/StandardWrapper.java:[43,21] [deprecation] javax.servlet.SingleThreadModel in javax.servlet has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/coyote/Response.java:[477,43] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/connector/Response.java:[756,47] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/connector/Connector.java:[1012,36] [deprecation] encode(java.lang.String) in java.net.URLEncoder has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/core/DefaultInstanceManager.java:[263,53] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/core/DefaultInstanceManager.java:[264,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/core/DefaultInstanceManager.java:[265,44] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/core/DefaultInstanceManager.java:[295,54] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/core/DefaultInstanceManager.java:[296,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/catalina/core/DefaultInstanceManager.java:[297,45] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/jk/common/JniHandler.java:[170,30] [deprecation] MsgContext() in org.apache.jk.core.MsgContext has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/ org/apache/jk/common/JniHandler.java:[171,23] [deprecation] MsgAjp() in org.apache.jk.common.MsgAjp has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/
Re: Possible for G to directly consume a Tomcat server config w/o changes?
See, I got those artifacts from that url, So do we need to add this url to the pom.xml of Geronimo's root folder. I found that it is comment out in that file ? Thanks ! Ivan 2009/6/15 David Jencks david_jen...@yahoo.com On Jun 14, 2009, at 8:30 PM, Ivan wrote: In which snapshot site, I could find the tomcat build ? I have checked the people, not found. https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/ This is in the apache 6 pom... are you having trouble accessing it from china? Then I tried to build them on my local machine, some errors occured, is there any option that I could set ? (I just run 'mvn install') Don't build the archetype directly run ./build-archetype.sh. It only works on unix like systems. did you check out this? https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-6.0.18 For the tomcat-archetype, it said that org.eclipse.jdt:core:jar:3.2.3.v_686_R32x could not be found that's odd, I thought my local nexus found it in maven central repo but it's not there now. I'll update it to 3.3.0-v_771 For the tomcat-parent-6.0.18, it said --- /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[42,20] package javax.xml.ws does not exist I was compiling on java 6. I'll add geronimo-jaxws_2.1_spec Thanks for trying it out, let me know if there are more problems! david jencks /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSession.java:[47,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSessionFacade.java:[26,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSession.java:[268,21] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSessionFacade.java:[104,11] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/StandardWrapper.java:[43,21] [deprecation] javax.servlet.SingleThreadModel in javax.servlet has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/coyote/Response.java:[477,43] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/connector/Response.java:[756,47] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/connector/Connector.java:[1012,36] [deprecation] encode(java.lang.String) in java.net.URLEncoder has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[263,53] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[264,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[265,44] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[295,54] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[296,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[297,45] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/jk/common/JniHandler.java:[170,30] [deprecation] MsgContext() in org.apache.jk.core.MsgContext has been deprecated
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 14, 2009, at 11:15 PM, Ivan wrote: See, I got those artifacts from that url, which artifacts from which url? So do we need to add this url to the pom.xml of Geronimo's root folder. I found that it is comment out in that file ? Which url? the apache nexus snapshot repo is already in the apache 6 root pom. It looks like some of the links on the index page at http://repository.apache.org/snapshots don't work but typing in more of a url seems to get to the right content. thanks david jencks Thanks ! Ivan 2009/6/15 David Jencks david_jen...@yahoo.com On Jun 14, 2009, at 8:30 PM, Ivan wrote: In which snapshot site, I could find the tomcat build ? I have checked the people, not found. https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/ This is in the apache 6 pom... are you having trouble accessing it from china? Then I tried to build them on my local machine, some errors occured, is there any option that I could set ? (I just run 'mvn install') Don't build the archetype directly run ./build-archetype.sh. It only works on unix like systems. did you check out this? https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-6.0.18 For the tomcat-archetype, it said that org.eclipse.jdt:core:jar: 3.2.3.v_686_R32x could not be found that's odd, I thought my local nexus found it in maven central repo but it's not there now. I'll update it to 3.3.0-v_771 For the tomcat-parent-6.0.18, it said --- /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/core/DefaultInstanceManager.java:[42,20] package javax.xml.ws does not exist I was compiling on java 6. I'll add geronimo-jaxws_2.1_spec Thanks for trying it out, let me know if there are more problems! david jencks /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/session/StandardSession.java:[47,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/session/StandardSessionFacade.java:[26,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/session/StandardSession.java:[268,21] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/session/StandardSessionFacade.java: [104,11] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/core/StandardWrapper.java:[43,21] [deprecation] javax.servlet.SingleThreadModel in javax.servlet has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/coyote/Response.java:[477,43] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/connector/Response.java:[756,47] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/connector/Connector.java:[1012,36] [deprecation] encode(java.lang.String) in java.net.URLEncoder has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/core/DefaultInstanceManager.java:[263,53] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/core/DefaultInstanceManager.java:[264,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/core/DefaultInstanceManager.java:[265,44] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/core/DefaultInstanceManager.java:[295,54] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/core/DefaultInstanceManager.java:[296,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/ java/org/apache/catalina/core/DefaultInstanceManager.java:[297,45] cannot find symbol symbol
Re: Possible for G to directly consume a Tomcat server config w/o changes?
Tomcat-ext from https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/ . I added the url https://repository.apache.org/content/repositories/snapshotshttps://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/to my local pom.xml, then I could build the whole Geronimo server. By the way, the server failed to start, I am trying to find why. Thanks ! Ivan 2009/6/15 David Jencks david_jen...@yahoo.com On Jun 14, 2009, at 11:15 PM, Ivan wrote: See, I got those artifacts from that url, which artifacts from which url? So do we need to add this url to the pom.xml of Geronimo's root folder. I found that it is comment out in that file ? Which url? the apache nexus snapshot repo is already in the apache 6 root pom. It looks like some of the links on the index page at http://repository.apache.org/snapshots don't work but typing in more of a url seems to get to the right content. thanks david jencks Thanks ! Ivan 2009/6/15 David Jencks david_jen...@yahoo.com On Jun 14, 2009, at 8:30 PM, Ivan wrote: In which snapshot site, I could find the tomcat build ? I have checked the people, not found. https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/ This is in the apache 6 pom... are you having trouble accessing it from china? Then I tried to build them on my local machine, some errors occured, is there any option that I could set ? (I just run 'mvn install') Don't build the archetype directly run ./build-archetype.sh. It only works on unix like systems. did you check out this? https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-6.0.18 For the tomcat-archetype, it said that org.eclipse.jdt:core:jar:3.2.3.v_686_R32x could not be found that's odd, I thought my local nexus found it in maven central repo but it's not there now. I'll update it to 3.3.0-v_771 For the tomcat-parent-6.0.18, it said --- /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[42,20] package javax.xml.ws does not exist I was compiling on java 6. I'll add geronimo-jaxws_2.1_spec Thanks for trying it out, let me know if there are more problems! david jencks /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSession.java:[47,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSessionFacade.java:[26,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSession.java:[268,21] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSessionFacade.java:[104,11] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/StandardWrapper.java:[43,21] [deprecation] javax.servlet.SingleThreadModel in javax.servlet has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/coyote/Response.java:[477,43] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/connector/Response.java:[756,47] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/connector/Connector.java:[1012,36] [deprecation] encode(java.lang.String) in java.net.URLEncoder has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[263,53] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[264,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[265,44] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[295,54] cannot find symbol symbol : class WebServiceRef location: class
Re: Possible for G to directly consume a Tomcat server config w/o changes?
I pushed a snapshot of our new tomcat build earlier today and just committed the server.xml changes to trunk. With a little luck I won't have made the build significantly more broken. thanks david jencks On Jun 12, 2009, at 11:21 AM, David Jencks wrote: On Jun 12, 2009, at 10:51 AM, Kevan Miller wrote: On Jun 5, 2009, at 3:00 AM, David Jencks wrote: On Jun 3, 2009, at 10:35 PM, Kevan Miller wrote: On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/ context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... I have enough working now so I can run the admin console on a server set up this way. I haven't looked at any files other than server.xml yet. Some like tomcat-users.xml are for a security realm we aren't going to use or, probably, support using. Not sure about the others. Cool. Can you point me to the code? I'm hoping to get it checked in today. I have a bunch of stuff intertwined locally so this involves figuring out where to put our tomcat build in svn and pushing a snapshot for it first. I still don't have a good idea where in svn to put builds of other projects. I guess I'll use external and we can move it if anyone has a better idea. thanks david jencks --kevan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
In which snapshot site, I could find the tomcat build ? I have checked the people, not found. Then I tried to build them on my local machine, some errors occured, is there any option that I could set ? (I just run 'mvn install') For the tomcat-archetype, it said that org.eclipse.jdt:core:jar:3.2.3.v_686_R32x could not be found For the tomcat-parent-6.0.18, it said --- /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[42,20] package javax.xml.ws does not exist /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSession.java:[47,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSessionFacade.java:[26,26] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSession.java:[268,21] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/session/StandardSessionFacade.java:[104,11] [deprecation] javax.servlet.http.HttpSessionContext in javax.servlet.http has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/StandardWrapper.java:[43,21] [deprecation] javax.servlet.SingleThreadModel in javax.servlet has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/coyote/Response.java:[477,43] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/connector/Response.java:[756,47] [deprecation] isSpace(char) in java.lang.Character has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/connector/Connector.java:[1012,36] [deprecation] encode(java.lang.String) in java.net.URLEncoder has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[263,53] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[264,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[265,44] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[295,54] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[296,20] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DefaultInstanceManager.java:[297,45] cannot find symbol symbol : class WebServiceRef location: class org.apache.catalina.core.DefaultInstanceManager /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/jk/common/JniHandler.java:[170,30] [deprecation] MsgContext() in org.apache.jk.core.MsgContext has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/jk/common/JniHandler.java:[171,23] [deprecation] MsgAjp() in org.apache.jk.common.MsgAjp has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DummyResponse.java:[122,16] [deprecation] setStatus(int,java.lang.String) in javax.servlet.http.HttpServletResponse has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DummyResponse.java:[111,18] [deprecation] encodeRedirectUrl(java.lang.String) in javax.servlet.http.HttpServletResponse has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DummyResponse.java:[113,18] [deprecation] encodeUrl(java.lang.String) in javax.servlet.http.HttpServletResponse has been deprecated /home/xuhaihong/external/tomcat-parent-6.0.18/catalina/src/main/java/org/apache/catalina/core/DummyRequest.java:[258,19] [deprecation] isRequestedSessionIdFromUrl() in javax.servlet.http.HttpServletRequest has been
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 5, 2009, at 3:00 AM, David Jencks wrote: On Jun 3, 2009, at 10:35 PM, Kevan Miller wrote: On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/ context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... I have enough working now so I can run the admin console on a server set up this way. I haven't looked at any files other than server.xml yet. Some like tomcat-users.xml are for a security realm we aren't going to use or, probably, support using. Not sure about the others. Cool. Can you point me to the code? --kevan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 12, 2009, at 10:51 AM, Kevan Miller wrote: On Jun 5, 2009, at 3:00 AM, David Jencks wrote: On Jun 3, 2009, at 10:35 PM, Kevan Miller wrote: On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/ context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... I have enough working now so I can run the admin console on a server set up this way. I haven't looked at any files other than server.xml yet. Some like tomcat-users.xml are for a security realm we aren't going to use or, probably, support using. Not sure about the others. Cool. Can you point me to the code? I'm hoping to get it checked in today. I have a bunch of stuff intertwined locally so this involves figuring out where to put our tomcat build in svn and pushing a snapshot for it first. I still don't have a good idea where in svn to put builds of other projects. I guess I'll use external and we can move it if anyone has a better idea. thanks david jencks --kevan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 3, 2009, at 11:47 PM, Ivan wrote: I remember that in server.xml, datasouce could be defined. While importing the xml file, shall we also need to create rar configuration for them? I doubt it. I'm currently thinking that we will keep letting geronimo construct all of the jndi context for the web app. thanks david jencks Ivan 2009/6/4 Kevan Miller kevan.mil...@gmail.com On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/ context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... --kevan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 3, 2009, at 10:35 PM, Kevan Miller wrote: On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/ context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... I have enough working now so I can run the admin console on a server set up this way. I haven't looked at any files other than server.xml yet. Some like tomcat-users.xml are for a security realm we aren't going to use or, probably, support using. Not sure about the others. thanks david jencks --kevan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
I remember that in server.xml, datasouce could be defined. While importing the xml file, shall we also need to create rar configuration for them? Ivan 2009/6/4 Kevan Miller kevan.mil...@gmail.com On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... --kevan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/ context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... --kevan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On May 19, 2009, at 3:09 PM, David Jencks wrote: On May 19, 2009, at 12:42 PM, Bill Stoddard wrote: Lin Sun wrote: One quick way would be allow users to start a tomcat server from a geronimo tomcat javaee5 assembly or little G tomcat assembly(say geronimo.sh start tomcatOnly=true). It is possible to just launch the tomcat server, and read the configuration files (conf/ server.xml, etc) and start a tomcat server from a geronimo tomcat assembly, by using the Catalina.java provided by tomcat. But this server/app would have no relationship with geronimo, other than using the jars provided by the geronimo tomcat assembly. The deployed app would be tracked only by tomcat, and not by geronimo. We should be able to achieve this without adding any new jars. If we need more than that, I can for seen the following issues that need investigation - 1. We'll have to provide better server integration with tomcat and be able to read the server configuration from tomcat's server configuration files, along with using config.xml configurations. This would be an absolute minimal requirement. Would this be really difficult? 2. We'll have to migrate user's app automatically for the user, when the user's app is a bit complicated that contains any need to require a geronimo-web.xml This is where things get more interesting lots of permutations and edge cases to consider. I'm not enough of a tomcat expert to know exactly what information a server.xml contains so I'm not quite sure how much the following makes sense. I think I would approach this by building a namespace aware builder that can interpret documents following the server.xml schema and construct the entire tomcat server from it. In other words, instead of starting with our current tomcat6 plugin, the builder would construct a replacement for it from the server.xml. If server.xml contains info on apps that are deployed in the tomcat instance, this could perhaps hook into or extend the current TomcatModuleBuilder to also set up plugins for each web app involved. The first part here might not be too hard. IMO if we treat the server.xml as a geronimo plan that would be acceptable. I'd recommend trying jaxb rather than using xmlbeans. I don't know how practical this would turn out to be but it's worth starting with. I personally think this is too large an addition to plan to get into 2.2. However if a motivated person shows up with something working before we solve the other problems I think we could consider it. 2.2 is already so much later than we had planned I don't want to hold it up for any new features after the other problems have been solved. I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. thanks david jencks thanks david jencks Lin On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard wgstodd...@gmail.com wrote: I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/ zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On May 19, 2009, at 8:17 PM, Lin Sun wrote: I am not a tomcat expert either... :-) I think we could also try the following approach: 1. figure out how to read tomcat server.xml like you described. Tomcat is using 2. at the G server startup, transform data in tomcat server.xml into G config.xml, if there is change to server.xml since last time server started. I think coming up for the mapping could be hard as configuring some features like valve or cluster requires documentation, time and experience. Also, there could be some functions/configurations in server.xml that we don't support in G yet. I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. thanks david jencks Lin On Tue, May 19, 2009 at 6:09 PM, David Jencks david_jen...@yahoo.com wrote: I'm not enough of a tomcat expert to know exactly what information a server.xml contains so I'm not quite sure how much the following makes sense. I think I would approach this by building a namespace aware builder that can interpret documents following the server.xml schema and construct the entire tomcat server from it. In other words, instead of starting with our current tomcat6 plugin, the builder would construct a replacement for it from the server.xml. If server.xml contains info on apps that are deployed in the tomcat instance, this could perhaps hook into or extend the current TomcatModuleBuilder to also set up plugins for each web app involved. The first part here might not be too hard. IMO if we treat the server.xml as a geronimo plan that would be acceptable. I'd recommend trying jaxb rather than using xmlbeans. I don't know how practical this would turn out to be but it's worth starting with. I personally think this is too large an addition to plan to get into 2.2. However if a motivated person shows up with something working before we solve the other problems I think we could consider it. 2.2 is already so much later than we had planned I don't want to hold it up for any new features after the other problems have been solved. thanks david jencks Lin On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard wgstodd...@gmail.com wrote: I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/ zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
Re: Possible for G to directly consume a Tomcat server config w/o changes?
One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin
Re: Possible for G to directly consume a Tomcat server config w/o changes?
I guess that what David means is that writing a deployer for server.xml, then in the builder class, construct those tomcat server gbeans, and add those gbeans to the tomcat plugin section in the config.xml. So that we could imitate a totally same tomcat environment for those tomcat-ready applications. Right ? Ivan 2009/5/20 Lin Sun linsun@gmail.com One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On May 20, 2009, at 7:44 AM, Ivan wrote: I guess that what David means is that writing a deployer for server.xml, then in the builder class, construct those tomcat server gbeans, and add those gbeans to the tomcat plugin section in the config.xml. So that we could imitate a totally same tomcat environment for those tomcat-ready applications. Not exactly. Right now we supply one preconfigured tomcat server in the tomcat plugin. You can deploy more if you want, and your app can choose which one to use with the (IIRC) web-container element in its plan. You can also use artifact-aliases to get one you deploy to replace the standard one. I'm suggesting writing a builder, maybe tomcat-server-builder, for server.xml files that produces plugins that are similar to the tomcat plugin. What happens to these plugins is a separate question. I'd assume most people would want to replace the supplied tomcat plugin with the one built out of their server.xml file but this is not an essential part of what I'm suggesting. thanks david jencks Right ? Ivan 2009/5/20 Lin Sun linsun@gmail.com One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
Agree that we won't contain this in G 2.2, but it might be a candidate feature for futher release like JEE6 Web Profile. Importing Tomcat server configs is relatively easier than importing Tomcat applications. If we consider an application which uses Struts, Hibernate, Spring, AXIS2 etc. (which is quite common), things becomes much complex. Still, doable, but not a trivial work. -Jack 2009/5/20 Ivan xhh...@gmail.com I guess that what David means is that writing a deployer for server.xml, then in the builder class, construct those tomcat server gbeans, and add those gbeans to the tomcat plugin section in the config.xml. So that we could imitate a totally same tomcat environment for those tomcat-ready applications. Right ? Ivan 2009/5/20 Lin Sun linsun@gmail.com One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
One option is to have an import tool, with which a user simply specifies Tomcat's config dir and import the configurations and even the deployed applications to Geronimo. Technical doable, but there are many details to deal with, like resources, reamls, JAR version conflicts, etc. etc. It won't be a trivial work to write such a tool. -Jack 2009/5/19 Bill Stoddard wgstodd...@gmail.com I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
Re: Possible for G to directly consume a Tomcat server config w/o changes?
One quick way would be allow users to start a tomcat server from a geronimo tomcat javaee5 assembly or little G tomcat assembly(say geronimo.sh start tomcatOnly=true). It is possible to just launch the tomcat server, and read the configuration files (conf/server.xml, etc) and start a tomcat server from a geronimo tomcat assembly, by using the Catalina.java provided by tomcat. But this server/app would have no relationship with geronimo, other than using the jars provided by the geronimo tomcat assembly. The deployed app would be tracked only by tomcat, and not by geronimo. We should be able to achieve this without adding any new jars. If we need more than that, I can for seen the following issues that need investigation - 1. We'll have to provide better server integration with tomcat and be able to read the server configuration from tomcat's server configuration files, along with using config.xml configurations. 2. We'll have to migrate user's app automatically for the user, when the user's app is a bit complicated that contains any need to require a geronimo-web.xml Lin On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard wgstodd...@gmail.com wrote: I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
Re: Possible for G to directly consume a Tomcat server config w/o changes?
I am not a tomcat expert either... :-) I think we could also try the following approach: 1. figure out how to read tomcat server.xml like you described. Tomcat is using 2. at the G server startup, transform data in tomcat server.xml into G config.xml, if there is change to server.xml since last time server started. I think coming up for the mapping could be hard as configuring some features like valve or cluster requires documentation, time and experience. Also, there could be some functions/configurations in server.xml that we don't support in G yet. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Lin On Tue, May 19, 2009 at 6:09 PM, David Jencks david_jen...@yahoo.com wrote: I'm not enough of a tomcat expert to know exactly what information a server.xml contains so I'm not quite sure how much the following makes sense. I think I would approach this by building a namespace aware builder that can interpret documents following the server.xml schema and construct the entire tomcat server from it. In other words, instead of starting with our current tomcat6 plugin, the builder would construct a replacement for it from the server.xml. If server.xml contains info on apps that are deployed in the tomcat instance, this could perhaps hook into or extend the current TomcatModuleBuilder to also set up plugins for each web app involved. The first part here might not be too hard. IMO if we treat the server.xml as a geronimo plan that would be acceptable. I'd recommend trying jaxb rather than using xmlbeans. I don't know how practical this would turn out to be but it's worth starting with. I personally think this is too large an addition to plan to get into 2.2. However if a motivated person shows up with something working before we solve the other problems I think we could consider it. 2.2 is already so much later than we had planned I don't want to hold it up for any new features after the other problems have been solved. thanks david jencks Lin On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard wgstodd...@gmail.com wrote: I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
Possible for G to directly consume a Tomcat server config w/o changes?
I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
