Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <420D120F.6050303@apache.org>
Date: Fri, 11 Feb 2005 13:14:07 -0700
From: Jeff Genender <jgenender@apache.org>
Reply-To: jgenender@apache.org
Organization: Apache Geronimo
User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: A Tomcat deployment  question
References: <20050211135756.26097.qmail@web20626.mail.yahoo.com>
In-Reply-To: <20050211135756.26097.qmail@web20626.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


anita kulshreshtha wrote:
> --- Jeff Genender <jgenender@apache.org> wrote:
> 
> 
>>
>>anita kulshreshtha wrote:
>>
>>>Jeff,
>>>    why do we need to use the
>>
>>TomcatModuleBuilder(TMB)
>>
>>>in j2ee-deployer-plan.xml ? 
>>
>>Actually, I just left it in there because A) There
>>is a Jetty Webbuilder 
>>version in there, and also for the sake of
>>consistency.  I haven't tried 
>>to remove it from the j2ee-deployer-plan.xml.  Its
>>definately worth a 
>>try and see what happens. If any of the Jetty guys
>>want to chime in on 
>>this, it would definately be appreciated.
> 
> 
>    j2ee-deployer-plan.xml is used to build
> deployer.jar, which is used to build DebugConsole and
> many other apps in the applications dir. I think we
> should leave these alone until tomcat is fully tested.
> To run DebugConsole using jetty and deploy apps on
> tomcat, RuntimeDeployer can be used as described
> earlier. It is a bit messy. but works!

Agreed.

> 
>>Are you actually able to
>>
>>>run apps on Tomcat using the current TMB?
>>
>>Simple apps should be fine.  When I mean simple, I
>>mean with no security 
>>and are standard servlet/JSP applications. The
>>Tomcat object integration 
>>now supports just about everything including root
>>component contexts, 
>>geronimo user transactions, JACC, and JAAS,
>>security/policy contexts, 
>>and custom geronimo web application contexts.  When
>>I say object 
>>integration, I mean the code and objects to hook
>>into Tomcat have been 
>>written and somewhat unit tested.
>>
>>The major bridge for total integration is finishing
>>the builder. The 
>>builder currently does not pass on the security
>>objects.  The TMB needs 
>>alot of work yet to get this integrated.  I
>>understand Jacek is 
>>currently working on this.
>>
>>The following is missing and is left for Tomcat to
>>be fully integrated 
>>for deployment:
>>
>>1) The TMB needs to set up the appropriate objects. 
>>A majority of the 
>>Jetty builder can be used.  However, a large
>>stumbling block is getting 
>>access to the Tomcat web class loader to build up
>>the component context. 
>>  Jetty creates this up front.  Tomcat creates this
>>internally from its 
>>own StandardContext, so its done "after-the fact",
>>far beyond the 
>>builder's execution.  Its actually done when
>>registering the TWAC with 
>>the container.  Some hooks need to be implemented to
>>retrieve this 
>>during the TomcatWebAppContext creation.  Its
>>doable, but it needs to be 
>>carefully thought through.  The place to probably
>>hook into this is in 
>>the TWAC.setContextProperties(), which was meant to
>>catch the Tomcat's 
>>StandardContext after the container creates it, but
>>before the web app 
>>accepts connections.
> 
> 
> I think we need to decide if tomcat is going to lose
> its identity completely inside Geroinimo, or to what
> extent it can pop its head up. 

I honestly do not think it lose its identity at all.  Tomcat is its own 
living-breathing engine, and we are just hooking into it.  The Embedded 
Tomcat object that we are using was made to do exactly this, embed the 
engine into external containers.  The Tomcat engine provided for hooks 
throughout the API to integrate with other app servers, and plugs into 
Geronimo surpisingly well.  Where it may lose its Tomcat-ishness is 
integrating the server.xml file into our plans.

> In the former case we would put all user jars in the
> repo using <dependency> like jetty. This would
> essentially flatten the tomcat classloader hierarchy.
> By this I mean that common, shared etc dir will have
> no meaning. A jetty like webapp classloader will work
> in this case.

Unfortunately this is not as easy as you explained it.  Tomcat manages 
its own class loader and is actually a small obstacle for Tomcat being 
able to utilize the Jetty builder at this point.  The Jetty builder 
creates the jetty web class loader, where in Tomcat-land, the Tomcat 
StandardContext takes care of this, and manages its lifecycle, etc. So 
the jetty like webapp classloader would not work.

>     In the later case we will need to provide common,
> shared dirs in catalina_home (var/catalina). In this
> case we will need to get access to tomcat's
> classloader. 

This is doable, and as we get developing the Tomcat builder, we will get 
access to the Tomcat class loader.  We have no choice but to obtain the 
Tomcat class loader for creating the component context.

We also need to think about the meaning
> of autodeploy/redeploy. If people are using tomcat
> because they are familiar with it, then we must
> support this. However here will be limit to this, for
> example they cannot(?) use tomcat's security.

We should be able to use Tomcat's security.  Its just a matter of 
declaring the proper realm.  The realm model supports pluggable security 
components, so this should work fine.

>           Please comment
> TIA
> Anita


> 
>>2) The concept of a server.xml file needs to be
>>supported for the Tomcat 
>>container.  In order to allow people to run thier
>>web apps, we must 
>>support custom Valves and Realms at the container,
>>host, and context 
>>levels.  This is normally declared in a server.xml
>>file, however, we 
>>could allow for this type of declaration to be
>>implemented in the plans 
>>somehow.  We need to kick around the appropriate
>>place for this.  In any 
>>case, this would eventually be a required add-on to
>>the TMB.
>>
>>3) It would be nice to have the servlets be
>>GBeanized, like Jetty. 
>>Although this is not a requirement to get Tomcat
>>integrated, it would be 
>>a nice-to-have for consistency sake.
>>
>>IMHO, once we get that builder completed, Tomcat
>>should be considered 
>>fully integrated.
>>
>>Jeff
>>
>>
>>>TIA
>>>Anita
>>>
>>>--- Jeff Genender <jgenender@apache.org> wrote:
>>>
>>>
>>>
>>>>Anita,
>>>>
>>>>I think this is now rectified for you.
>>>>
>>>>First there was a bug in the TomcatModuleBuilder
>>>>that failed on schema 
>>>>validation.  I fixed that and the DebugConfig will
>>>>be built properly 
>>>>during the assembly build for tomcat.
>>>>
>>>>However, there is now an additional
>>>>comment/un-comment you must do 
>>>>before building assembly if you want to run
>>
>>Tomcat. 
>>
>>>>You need to edit 
>>>>the j2ee-runtime-deployer-plan.xml as well as the
>>>>j2ee-deployer-plan.xml.
>>>>
>>>>I added a commented-out Tomcat section in the 
>>>>j2ee-runtime-deployer-plan.xml.  You need to
>>>>uncomment that, then 
>>>>comment out the WebBuilder for Jetty right below
>>
>>it.
>>
>>>>I added a comment 
>>>>there describing this as well.
>>>>
>>>>I will try to get this in the Wiki shortly.
>>>>
>>>>After this, it should be alot less painful to get
>>>>Tomcat running.
>>>>
>>>>Let us know how this works for you.
>>>>
>>>>Jeff
>>>>
>>>>anita kulshreshtha wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>    I am doing the following -
>>>>>1. Do a regular build.
>>>>>2.start the server by starting DebugConsole,
>>>>>RuntimeDeployer and Tomcat.
>>>>>3. From another window modify the RuntimeDeployer
>>>>>configuration to accept TomcatModuleBuilder as
>>>>>WebBuilder using 
>>>>>java -jar bin\deployer.jar
>>>>>..\plan\j2ee-runtime-deployer-plan.xml
>>>>>4.  A ^C saves this RuntimeDeployer in the
>>>>
>>>>persistent
>>>>
>>>>
>>>>>store in another location. 
>>>>>5  Now when I restart the server as in 2 , I can
>>>>
>>>>run
>>>>
>>>>
>>>>>DebugConsole as well as deploy wars For tomcat
>>>>
>>>>using
>>>>
>>>>
>>>>>java -jar bin\deployer.jar. I do this to test
>>>>>TomcatModuleBuilder. 
>>>>>   Is there a better way to accomplish this? 
>>>>>Jacek, How do you run TomcatModuleBuilder ? 
>>>>>
>>>>>TIA
>>>>>Anita
>>>>>
>>>>>
>>>>>		
>>>>>__________________________________ 
>>>>>Do you Yahoo!? 
>>>>>Yahoo! Mail - 250MB free storage. Do more. Manage
>>>>
>>>>less. 
>>>>
>>>>
>>>>>http://info.mail.yahoo.com/mail_250
>>>>
>>>>-- 
>>>>Jeff Genender
>>>>http://geronimo.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>		
>>>__________________________________ 
>>>Do you Yahoo!? 
>>>Yahoo! Mail - Helps protect you from nasty
>>
>>viruses. 
>>
>>>http://promotions.yahoo.com/new_mail
>>
>>-- 
>>Jeff Genender
>>
> 
> === message truncated ===
> 
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - now with 250MB free storage. Learn more.
> http://info.mail.yahoo.com/mail_250

-- 
Jeff Genender
http://geronimo.apache.org