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_jencks@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 <wgstoddard@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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>