anita kulshreshtha wrote:
--- Jeff Genender <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
