Re: Add Context Path, Tomcat 5.5.7

2005-04-08 Thread P T
Scott,

I feel your pain -- I just finished sorting out that whole thing
myself. One thing I'd definitely recommend doing is installing the
admin tool for tomcat 5 and using it to change something trivial in
your server.xml file. When it gets done making the change it strips
out all the comments as a side effect and makes the file *much*
cleaner and, in my opinion, more readable. As for your question:
if the resource is to be used for multiple applications, you could put
it in the server.xml... if not (and I'm going to presume that's the
case for you -- let me know if not) then you're much better off using
your application-specific WEB-INF\web.xml and META-INF\context.xml
files like so:


your application docbase\META-INF\context.xml would look something like:
Context path=/Foo 
 docBase=C:/Foo 
 debug=1 reloadable=true
  Resource
  auth=Container
  name=jdbc/aNameForYourDBresource
  type=javax.sql.DataSource
  password=Foo
  driverClassName=oracle.jdbc.driver.OracleDriver 
  maxIdle=3
  maxWait=5000
  username=Foo
  url=jdbc:oracle:thin:@Foo:1521:Foo
  maxActive=15/
  WatchedResourceWEB-INF/web.xml/WatchedResource
  WatchedResourceMETA-INF/context.xml/WatchedResource
/Context

and your your application docbaseWEB-INF\web.xml would then
reference the resource defined in the context above (the res-ref-name
should match the resource name)

?xml version=1.0 encoding=ISO-8859-1?

!DOCTYPE web-app 
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN 
http://java.sun.com/dtd/web-app_2_3.dtd;

web-app

   display-nameYour app's name/display-name
  description
  Slices, dices and makes fresh canned spam!
   /description

   resource-ref
  descriptionDescription of Datasource/description
  res-ref-namejdbc/aNameForYourDBresource/res-ref-name
  res-typejavax.sql.DataSource/res-type
  res-authContainer/res-auth
   /resource-ref
/web-app

It's helpful to think of the individual application context.xml files
being 'included' as context entries in the server.xml file (almost
like an @include, except implicit).

Hope that helps! Let me know if I can clarify anything.

Cheers,
Patrick Thomas

(PS - remember to install the jakarta commons and pooling jars
mentioned in the dbcp documentation.)

On Apr 8, 2005 11:13 AM, David Smith [EMAIL PROTECTED] wrote:
 Hi.
 
 Take a look at this for where to put Context elements:
 http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html
 
 This is new with Tomcat 5.0 and is continued in Tomcat 5.5
 
 --David
 
 Scott Purcell wrote:
 
 Hello,
 
 I am following the information here to add DBCP to my application.
 http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jndi-datasource-examples-howto.html
 
 I am reading to add the Context path=/DBTest ... from the above docs. The 
 instructions say to .
 
 Configure the JNDI DataSource in Tomcat by adding a declaration for your 
 resource to $CATALINA_HOME/conf/server.xml.
 
 Add this in between the /Context tag of the examples context and the 
 /Host tag closing the localhost definition.
 
 
 
 So cool, I opened up the server.xml, but do not see any existing context or 
 host tags in it. Here is my server.xml file. Does anyone know where I put 
 the Context for the DBCP stuff? Thanks,
 
 '!-- Example Server Configuration File --
 !-- Note that component elements are nested corresponding to their
  parent-child relationships with each other --
 
 !-- A Server is a singleton element that represents the entire JVM,
  which may contain one or more Service instances.  The Server
  listens for a shutdown command on the indicated port.
 
  Note:  A Server is not itself a Container, so you may not
  define subcomponents such as Valves or Loggers at this level.
  --
 
 Server port=8005 shutdown=SHUTDOWN
 
   !-- Comment these entries out to disable JMX MBeans support used for the
administration web application --
   Listener className=org.apache.catalina.mbeans.ServerLifecycleListener /
   Listener 
  className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /
   Listener 
  className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/
 
   !-- Global JNDI resources --
   GlobalNamingResources
 
 !-- Test entry for demonstration purposes --
 Environment name=simpleValue type=java.lang.Integer value=30/
 
 !-- Editable user database that can also be used by
  UserDatabaseRealm to authenticate users --
 Resource name=UserDatabase auth=Container
   type=org.apache.catalina.UserDatabase
description=User database that can be updated and saved
factory=org.apache.catalina.users.MemoryUserDatabaseFactory
   pathname=conf/tomcat-users.xml /
 
   /GlobalNamingResources
 
   !-- A Service is a collection of one or more Connectors that share
a single Container (and therefore the web applications visible
within that Container).  

using a docBase outside $catalina.home ?

2005-03-29 Thread P T
Hi all,

I've checked the archives and google, but come up dry on this. I know
that with 5.5 we're no longer supposed to put contexts for individual
applications in server.xml, but none of the 'proper' ways have worked.

I've got source for an application that we're working on in
c:\share\MyAppName, and the context in
{$Catalina.home}\conf\Catalina\localhost\MyAppName.xml

MyAppName.xml contains exactly: 
Context path=/MyAppName docBase=c:\share\PMScheduler debug=0
reloadable=true/

I then start tomcat and access the /manager utility and it shows
/MyAppName in the Applications display and indicates 'false' under the
Running column. Attempting to start it produces FAIL - Application at
context path /MyAppName could not be started and no other info. The
/MyAppName folder exists but is empty.

I've also tried the method with context file in the docbase (
c:\share\PMScheduler\META-INF\context.xml ) and specifying it to the
/manager app as:
Context Path (optional): /MyAppName
XML Configuration file URL: file:C:/share/PMScheduler/META-INF/context.xml   
WAR or Directory URL:  file:C:/share/PMScheduler

This produces the same result. (Although I note that even where it
says the context is optional, it still requires it... it's not the
issue at hand, but anyone else noticing that?)

I'm stumped -- I can't imagine that the only way to work with unWAR-ed
files is to put them inside tomcats directory structure. While we're
developing it seems silly to have to reWAR the whole thing every time
we make a change to the source. Tomcat 3.3 could handle this I know --
is this just functionality that was lost along the way?

Cheers,
Patrick Thomas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RESOLVED - using a docBase outside $catalina.home ?

2005-03-29 Thread P T
putting a foo.xml file into conf\Catalina\localhost eventually
worked... not exactly sure why it's working, but thanks for the input
all.

~PST

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]