We do use JNDI, however every web app still needs to have the classes
available and I need some way to get the services into JNDI at startup.  I
don't want to have each web app do it.

I haven't looked at JavaEE or 2.5 spec however resource injection sounds
nice.

I think I'll look at Dave's suggestion with LifecycleListener interface.
This could be the easiest way for now.

Thanks

Mike Wannamaker

-----Original Message-----
From: Avi Deitcher [mailto:[EMAIL PROTECTED] 
Sent: July 18, 2006 10:19 AM
To: Tomcat Users List
Subject: Re: Tomcat Not An App Server

Mike,

Have you thought of wrapping the connection to the container? If you
look at the interaction between any webapp and its container, there are
just a few key interaction points: servletcontext/filtercontext,
servletrequest, servletresponse, session, a few others. You can fairly
extend or wrap any of those, so that the webapp only gets /your
/versions, which provide the necessary services.

I know of a number of large enterprises that have done exactly that. I
run a small consulting, mostly focused on general operations and
technology (as opposed to specializing in middleware), but I have
considered getting into this space to advise around this.

The process is essentially as follows:
- determine exactly which services these applications expect, abstracted
from their container, and how they expect to get them
- map out all the interaction points between the app and its container
(see above)
- wrap what is necessary and provide interfaces

A slightly simpler way to do this, but requires some work in the webapps
themselves, is to make all the services available via JNDI, and let the
apps look up what they need from the JNDI. They then become abstract
from the container, and the middleware manager can put in place what
they need in JNDI, which has to be available in any Web container. This
becomes even easier in JavaEE and Servlet Spec 2.5, where resource
injection will be available.

Avi

Mike Wannamaker wrote:

>I'll try to be a little more specific.
>
>We have many groups within our company.  Portal (Ottawa Office), Document
>Management (Toronto Office), Collaboration (UK Office), Workflow (Toronto
>Office), BI-Reporting (Kingston Office)...
>
>All these different applications have web pieces as well as their own
server
>pieces possibly.  Meaning a few are just plain web apps, some have server
>components as well.
>
>All these components will be built on top of our core services.  Meaning
>that our core services will handle certain aspects for applications to
>abstract away the application server we are on JBoss, WebLogic etc, and to
>provide certain services that all will use/need. 
>
>One of these services obviously will be deployment of these applications
>into our core services layer.  Other services will be user authentication,
>component messaging, configuration of applications, logging for
>applications, a cluster wide locking service, cluster wide singleton
>service, Database Access Layer, Common Scheduler service, a job/task
>executor service which manages resources within the system, a mobility
>messaging service, as well as a common web UI library and common
>administration layer.
>
>We also have a services layer that these other groups will write services
>and plug into it in order to start their services.  
>
>I already have this working on our own app server, as well as JBoss. 
>
>However, we would also like to support possibly straight Tomcat no app
>server.  But to do that I need the same idea that JBoss provides, a way to
>start up something before starting the web apps.  I thought possibly
>something added to the server.xml to get another component to start.
>
>I don't want to have to change the individual web apps because remember
they
>aren't supposed to know what they are running on.  And I also need to have
>these classes available for all web applications on the tomcat server so I
>can't load them within a separate web app because Tomcat ClassLoading won't
>allow you to get at the classes then.
>
>So basically I have a class
>
>public class CoreServicesTomcat extends ???????TomcatSomethingOrOther
>{
>       public void start()
>       {
>               RealCoreServices.start();
>       }
>
>       public void stop();
>       {
>               RealCoreServices.stop();
>       }
>}
>
>I hope this clarifies things.
>
>Mike Wannamaker
>
>-----Original Message-----
>From: Timothy Collett [mailto:[EMAIL PROTECTED] 
>Sent: July 17, 2006 4:14 PM
>To: Tomcat Users List
>Subject: Re: Tomcat Not An App Server
>
>On Jul 17, 2006, at 4:06 PM, Martin Gainty wrote:
>
>  
>
>>commons/lib is for CATALINA specific implementations as well as any  
>>jar'ed versions of new Jasper compiler(s)
>>http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html
>>    
>>
>
>I was given the impression that it was more generally the place to  
>put anything that is required by the container itself, as well as the  
>webapps.
>
>  
>
>>Can you provide a quick overview of the desired outcome for this  
>>effort
>>    
>>
>
>The desired outcome is to have something that can start up as soon as  
>Tomcat is started, rather than on the first client request, and not  
>be attached to any particular webapp.  At least, that's how I see it.
>
>But, as I've said before, I'm relatively new at this, and am willing  
>to be contradicted, as long as I'm also educated ;-)
>
>Timothy Collett
>
>--
>
>Stay the patient course
>Of little worth is your ire
>The network is down
>~haiku~
>
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>---------------------------------------------------------------------
>To start a new topic, e-mail: users@tomcat.apache.org
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>  
>

-- 
______________________________
Avi Deitcher
[EMAIL PROTECTED]




---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to