Re: Problem with JNDI environment entry resources
I'm out then. I'm fine with the way tomcat operates and don't feel
anything in the way context xml files are associated with webapps is
ambiguous. It's really simple:
1. If you just want to deploy a webapp and don't need to define any
resources like db pools, just drop the webapp in the webapps folder.
The context xml file is not needed for such a basic deployment. The
context path will be the name of the webapp.
2. If you need resources defined, then create a context xml file named
after the webapp and placed in conf/EngineName/HostName.
3. Only define the docBase attribute of a ...
element if your webapp live's outside the appBase of any of tomcat's
... definitions in server.xml.
I'm sure if you'd like to make changes you could check out the tomcat
source, make your changes, create a patch, and submit your proposal in
Bugzilla for the tomcat committers to take a look at. If you feel the
true problem is in the docs, patches are accepted for that as well.
--David
Paul Pepper wrote:
2008/9/3 David Smith <[EMAIL PROTECTED]>:
There's an implicit association based on the context path. myWebApp.xml in
conf/Catalina/localhost is implicitly associated with the webapp myWebApp in
the webapps directory, whether it be as a .war or expanded folder.
Yes, I agree that the docs read this way. The point under discussion
here was the use of a docBase within server.xml - it's
necessary in order to disambiguate the use of a to a
specific application.
Illegal may be a strong word -- it implies that tomcat will flat out reject
the context when you define a docBase. If there is a docBase attribute
defined, it may be ignored if there's a webapp in the webapps directory
matching the context name (as defined by the *name* of the context xml file
in conf/{Engine Name}/{Host name}, not the path attribute of
I don't understand "may be ignored". Either docBase is ignored in this
situation, or it isn't.
...>). Worse, if the name of your webapp in webapps is
different than the name of the context xml file in conf/{Engine Name}/{Host
name}, you can get a double-deploy. Only one instance of the webapp will
have the additional settings provided by the context xml file though.
I'm afraid I haven't encountered this behaviour described in the docs.
I'd be grateful of a reference to it. Where documentation is missing,
or where further clarity is required (as suggested by repeated
user/developer mistakes), what is the procedure within Apache for
helping make this happen?
Best practice overall is don't specify a docBase attribute unless your
webapp is outside the appBase you are deploying the application to. Some
people have reasons for doing this -- like when they absolutely have to have
the war file named in some specific way that doesn't match the context path.
That suggests that you've encountered cases where it is reasonable for
the docBase and the context's xml file name to differ. However, the
ambiguity in the use of docBase (re. above), and the double deployment
problem that you mention, makes it difficult to solve this problem -
worse if the use of taken away as an option.
If it's agreeable to the guys that have responded so far, then I'd
like to get this discussion onto a thread of its own so that the
subject reflects the discussion and mail headers refer to a specific
topic. If you'd like to continue the discussion about that
we have started here, then please give me a little time to post this
question as another message on this list - referring to this thread in
the archives to avoid repetition.
Also don't define a path attribute unless your ...
element is in server.xml (absolutely NOT recommended).
Agreed!
Thanks,
Paul.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
2008/9/3 David Smith <[EMAIL PROTECTED]>:
> There's an implicit association based on the context path. myWebApp.xml in
> conf/Catalina/localhost is implicitly associated with the webapp myWebApp in
> the webapps directory, whether it be as a .war or expanded folder.
Yes, I agree that the docs read this way. The point under discussion
here was the use of a docBase within server.xml - it's
necessary in order to disambiguate the use of a to a
specific application.
> Illegal may be a strong word -- it implies that tomcat will flat out reject
> the context when you define a docBase. If there is a docBase attribute
> defined, it may be ignored if there's a webapp in the webapps directory
> matching the context name (as defined by the *name* of the context xml file
> in conf/{Engine Name}/{Host name}, not the path attribute of ...>). Worse, if the name of your webapp in webapps is
> different than the name of the context xml file in conf/{Engine Name}/{Host
> name}, you can get a double-deploy. Only one instance of the webapp will
> have the additional settings provided by the context xml file though.
I'm afraid I haven't encountered this behaviour described in the docs.
I'd be grateful of a reference to it. Where documentation is missing,
or where further clarity is required (as suggested by repeated
user/developer mistakes), what is the procedure within Apache for
helping make this happen?
> Best practice overall is don't specify a docBase attribute unless your
> webapp is outside the appBase you are deploying the application to. Some
> people have reasons for doing this -- like when they absolutely have to have
> the war file named in some specific way that doesn't match the context path.
That suggests that you've encountered cases where it is reasonable for
the docBase and the context's xml file name to differ. However, the
ambiguity in the use of docBase (re. above), and the double deployment
problem that you mention, makes it difficult to solve this problem -
worse if the use of taken away as an option.
If it's agreeable to the guys that have responded so far, then I'd
like to get this discussion onto a thread of its own so that the
subject reflects the discussion and mail headers refer to a specific
topic. If you'd like to continue the discussion about that
we have started here, then please give me a little time to post this
question as another message on this list - referring to this thread in
the archives to avoid repetition.
> Also don't define a path attribute unless your ...
> element is in server.xml (absolutely NOT recommended).
Agreed!
Thanks,
Paul.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with JNDI environment entry resources
> From: Paul Pepper [mailto:[EMAIL PROTECTED] > Subject: Re: Problem with JNDI environment entry resources > > Besides, I don't see any other documented way of associating > each application with its associated element within > server.xml. Because you're not supposed to put elements in server.xml anymore; it works (mostly), but it's strongly discouraged. Don't do it. > Then you'd be taking away the only mechanism (that I can see) for > pointing to an application as ROOT, without the inelegant renaming of > applications as ROOT. Odd viewpoint, since naming the default app ROOT is the most straightforward and elegant mechanism I can think of. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
There's an implicit association based on the context path. myWebApp.xml
in conf/Catalina/localhost is implicitly associated with the webapp
myWebApp in the webapps directory, whether it be as a .war or expanded
folder.
Illegal may be a strong word -- it implies that tomcat will flat out
reject the context when you define a docBase. If there is a docBase
attribute defined, it may be ignored if there's a webapp in the webapps
directory matching the context name (as defined by the *name* of the
context xml file in conf/{Engine Name}/{Host name}, not the path
attribute of ). Worse, if the name of your
webapp in webapps is different than the name of the context xml file in
conf/{Engine Name}/{Host name}, you can get a double-deploy. Only one
instance of the webapp will have the additional settings provided by the
context xml file though.
Best practice overall is don't specify a docBase attribute unless your
webapp is outside the appBase you are deploying the application to.
Some people have reasons for doing this -- like when they absolutely
have to have the war file named in some specific way that doesn't match
the context path. Also don't define a path attribute unless your
... element is in server.xml (absolutely NOT
recommended).
--David
Paul Pepper wrote:
I'll have to check the docs again. However, docBase is only legal when the webapp is
stored outside of the
appBase directory. Otherwise, you risk ending up with double deployment.
I don't see docBase described that way in the docs - at this moment
I'm referring to
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html. Besides,
I don't see any other documented way of associating each application
with its associated element within server.xml.
unless I named the application ROOT, which is less than ideal
That is the defined mechanism for specifying the default webapp in current
Tomcat levels.
That's one mechanism for specifying the ROOT application. Referring to
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html, when
using individual context files under
$CATALINA_BASE/conf/[enginename]/[hostname]/:
"The default web application may be defined by using a file called
ROOT.xml."
The filename less the .xml provides the context path (/ in the case of
ROOT) and the element's docBase points to the ROOT
application. This is all in accordance with the current 6.0 docs from
my reading of them.
I'd like to pull this out into a thread of its own on this mailing
list. Maybe we can take this discussion there. This particular problem
is of importance to me, and it would seem also to others judging by
the comments left on the bug report that I referenced in my previous
comment.
Placing elements in server.xml is really only there for compatibility
with older versions of Tomcat. Personally, I'd like to see it made illegal, which
would put an end to many potential configuration errors.
Then you'd be taking away the only mechanism (that I can see) for
pointing to an application as ROOT, without the inelegant renaming of
applications as ROOT.
Paul.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
> I'll have to check the docs again. However, docBase is only legal when the > webapp is stored outside of the > appBase directory. Otherwise, you risk ending up with double deployment. I don't see docBase described that way in the docs - at this moment I'm referring to http://tomcat.apache.org/tomcat-6.0-doc/config/context.html. Besides, I don't see any other documented way of associating each application with its associated element within server.xml. >> unless I named the application ROOT, which is less than ideal > That is the defined mechanism for specifying the default webapp in current > Tomcat levels. That's one mechanism for specifying the ROOT application. Referring to http://tomcat.apache.org/tomcat-6.0-doc/config/context.html, when using individual context files under $CATALINA_BASE/conf/[enginename]/[hostname]/: "The default web application may be defined by using a file called ROOT.xml." The filename less the .xml provides the context path (/ in the case of ROOT) and the element's docBase points to the ROOT application. This is all in accordance with the current 6.0 docs from my reading of them. I'd like to pull this out into a thread of its own on this mailing list. Maybe we can take this discussion there. This particular problem is of importance to me, and it would seem also to others judging by the comments left on the bug report that I referenced in my previous comment. > Placing elements in server.xml is really only there for > compatibility with older versions of Tomcat. Personally, I'd like to see it > made illegal, which would put an end to many potential configuration errors. Then you'd be taking away the only mechanism (that I can see) for pointing to an application as ROOT, without the inelegant renaming of applications as ROOT. Paul. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with JNDI environment entry resources
i havent used JNDI to obtain string values
i use ResourceBundle to obtain the locale specific string value e.g.
myResources.getString("CancelKey");
http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html
anyone
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of Sender. This transmission is of a confidential nature and Sender does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> Date: Wed, 3 Sep 2008 14:42:24 +0100
> From: [EMAIL PROTECTED]
> To: users@tomcat.apache.org
> Subject: Re: Problem with JNDI environment entry resources
>
> Martin,
>
> Thanks for the suggestion, though I think there may have been some
> misunderstanding. I'm attempting to access a simple java.lang.String,
> not a DataSource. elements are used to place String
> resources in an application's environment, not elements,
> AFAIK.
>
> Paul.
>
> 2008/9/3 Martin Gainty <[EMAIL PROTECTED]>:
> >
> > http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
> > /WEB-INF/web.xml contents which contain a jndi reference > xmlns="http://java.sun.com/xml/ns/j2ee";
> >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
> >version="2.4">
> > MySQL Test App
> >
> > DB Connection
> > teststring
> > javax.sql.DataSource
> > Container
> >
> >
> >
> > the lookup to teststring will get you a connection to the DB
> >
> > HTH
> > Martin
> > __
> > Disclaimer and confidentiality note
> > Everything in this e-mail and any attachments relates to the official
> > business of Sender. This transmission is of a confidential nature and
> > Sender does not endorse distribution to any party other than intended
> > recipient. Sender does not necessarily endorse content contained within
> > this transmission.
> >
> >
> >> Date: Wed, 3 Sep 2008 01:01:40 +0100
> >> From: [EMAIL PROTECTED]
> >> To: users@tomcat.apache.org
> >> Subject: Problem with JNDI environment entry resources
> >>
> >> Tomcat 6.0.18
> >> java version "1.6.0_06" (sun-java6-jdk on Ubuntu 8.04 i386)
> >>
> >> I'm attempting to create environment entry resources, of type
> >> java.lang.String, within conf/server.xml and access them from web
> >> applications using JNDI. I've created a bare-bones test web app,
> >> jndistring, with the following conf/server.xml configuration:
> >>
> >> server.xml (snipped):
> >> -
> >>>> appBase="webapps"
> >> unpackWARs="true"
> >> autoDeploy="false"
> >> deployOnStarup="true"
> >> xmlValidation="false"
> >> xmlNamespaceAware="false">
> >>
> >> >> path="jndistring"
> >> useNaming="true">
> >>
> >> >> value="a test value"
> >> type="java.lang.String"
> >> override="false"
> >> />
> >>
> >>
> >>
> >>
> >> For the purpose of this test I've used jsp to access the value of
> >> teststring.
> >>
> >> jndistring.jsp (snipped):
> >>
> >> <%
> >> Context initCtx = new InitialContext();
> >> Context envCtx = (Context) initCtx.lookup("java:comp/env");
> >>
> >> String teststring = (String) envCtx.lookup("teststring");
> >> out.println("teststring: " + teststring);
> >> %>
> >>
> >> Accessing this page throws an exception:
> >> org.apache.jasper.JasperException: An exception occurred processing
> >> JSP page /test.jsp at line 18
> >> 15: Context initCtx = new InitialContext();
> >> 16: Context envCtx = (Context) initCtx.lookup("java:comp/env");
> >> 17:
> >&
RE: Problem with JNDI environment entry resources
> From: Paul Pepper [mailto:[EMAIL PROTECTED] > Subject: Re: Problem with JNDI environment entry resources > > Tomcat 6 docs states that docBase is a valid attribute > in this situation. I'll have to check the docs again. However, docBase is only legal when the webapp is stored outside of the appBase directory. Otherwise, you risk ending up with double deployment. > unless I named the application ROOT, which is less than ideal That is the defined mechanism for specifying the default webapp in current Tomcat levels. > Would folks here, then, be inclined to believe that there is a bug in > using within a server.xml file? Placing elements in server.xml is really only there for compatibility with older versions of Tomcat. Personally, I'd like to see it made illegal, which would put an end to many potential configuration errors. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
Martin,
Thanks for the suggestion, though I think there may have been some
misunderstanding. I'm attempting to access a simple java.lang.String,
not a DataSource. elements are used to place String
resources in an application's environment, not elements,
AFAIK.
Paul.
2008/9/3 Martin Gainty <[EMAIL PROTECTED]>:
>
> http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
> /WEB-INF/web.xml contents which contain a jndi reference xmlns="http://java.sun.com/xml/ns/j2ee";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
>version="2.4">
> MySQL Test App
>
> DB Connection
> teststring
> javax.sql.DataSource
> Container
>
>
>
> the lookup to teststring will get you a connection to the DB
>
> HTH
> Martin
> __
> Disclaimer and confidentiality note
> Everything in this e-mail and any attachments relates to the official
> business of Sender. This transmission is of a confidential nature and Sender
> does not endorse distribution to any party other than intended recipient.
> Sender does not necessarily endorse content contained within this
> transmission.
>
>
>> Date: Wed, 3 Sep 2008 01:01:40 +0100
>> From: [EMAIL PROTECTED]
>> To: users@tomcat.apache.org
>> Subject: Problem with JNDI environment entry resources
>>
>> Tomcat 6.0.18
>> java version "1.6.0_06" (sun-java6-jdk on Ubuntu 8.04 i386)
>>
>> I'm attempting to create environment entry resources, of type
>> java.lang.String, within conf/server.xml and access them from web
>> applications using JNDI. I've created a bare-bones test web app,
>> jndistring, with the following conf/server.xml configuration:
>>
>> server.xml (snipped):
>> -
>> > appBase="webapps"
>> unpackWARs="true"
>> autoDeploy="false"
>> deployOnStarup="true"
>> xmlValidation="false"
>> xmlNamespaceAware="false">
>>
>> > path="jndistring"
>> useNaming="true">
>>
>> > value="a test value"
>> type="java.lang.String"
>> override="false"
>> />
>>
>>
>>
>>
>> For the purpose of this test I've used jsp to access the value of teststring.
>>
>> jndistring.jsp (snipped):
>>
>> <%
>> Context initCtx = new InitialContext();
>> Context envCtx = (Context) initCtx.lookup("java:comp/env");
>>
>> String teststring = (String) envCtx.lookup("teststring");
>> out.println("teststring: " + teststring);
>> %>
>>
>> Accessing this page throws an exception:
>> org.apache.jasper.JasperException: An exception occurred processing
>> JSP page /test.jsp at line 18
>> 15: Context initCtx = new InitialContext();
>> 16: Context envCtx = (Context) initCtx.lookup("java:comp/env");
>> 17:
>> 18: String teststring = (String) envCtx.lookup("teststring");
>> 19: out.println("teststring: " + teststring);
>> 20: %>
>>
>> The top frame of the root cause is shown as:
>> javax.servlet.ServletException: javax.naming.NameNotFoundException:
>> Name teststring is not bound in this Context
>>
>> If I attempt to create an environment entry resource using
>> (and sub-elements) within web.xml, then the resource is
>> created and I can access it!!!
>>
>> I've read the "JNDI resources howto", docs regarding the ,
>> and elements (and others), but don't see
>> that I have missed anything.
>>
>> Can anyone suggest what I might have missed? Has anyone else had
>> similar problems?
>>
>> Thanks,
>>
>> Paul.
>>
>> -
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> _
> Get thousands of games on your PC, your mobile phone, and the web with
> Windows(R).
> http://clk.atdmt.com/MRT/go/108588800/direct/01/
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with JNDI environment entry resources
Thanks Chuck, I just tested this by creating a context element in its own file under conf/Catalina/localhost/jnditest.xml and that worked. (BTW, Tomcat 6 docs states that docBase is a valid attribute in this situation. It is only illegal when the element is defined within META-INF/context.xml.): I had chosen the server.xml approach because I wish to deploy some applications as the default/ROOT, and I haven't had any success in doing that using this approach (unless I named the application ROOT, which is less than ideal). Others have raised a bug report against this particular difficulty, and I recently contributed a comment, but it was dealt with in an unhelpful manner: https://issues.apache.org/bugzilla/show_bug.cgi?id=41746 Well, that's for another question on this mailing list! Would folks here, then, be inclined to believe that there is a bug in using within a server.xml file? - given that I'm using only a slightly changed configuration (the "path" attribute being the only change). I'm hesitant to raise a bug for fear of being flamed again! Thanks, Paul. 2008/9/3 Caldarale, Charles R <[EMAIL PROTECTED]>: >> From: Paul Pepper [mailto:[EMAIL PROTECTED] >> Subject: Problem with JNDI environment entry resources >> >> Can anyone suggest what I might have missed? > > What happens if you follow the (strongly) recommended practice of not putting > elements in server.xml? If you don't want to put the > inside your .war file (understandable), put it in > conf/Catalina/localhost/jndistring.xml, and remove the illegal docBase and > path attributes. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > - > 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]
RE: Problem with JNDI environment entry resources
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
/WEB-INF/web.xml contents which contain a jndi reference http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
version="2.4">
MySQL Test App
DB Connection
teststring
javax.sql.DataSource
Container
the lookup to teststring will get you a connection to the DB
HTH
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of Sender. This transmission is of a confidential nature and Sender does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> Date: Wed, 3 Sep 2008 01:01:40 +0100
> From: [EMAIL PROTECTED]
> To: users@tomcat.apache.org
> Subject: Problem with JNDI environment entry resources
>
> Tomcat 6.0.18
> java version "1.6.0_06" (sun-java6-jdk on Ubuntu 8.04 i386)
>
> I'm attempting to create environment entry resources, of type
> java.lang.String, within conf/server.xml and access them from web
> applications using JNDI. I've created a bare-bones test web app,
> jndistring, with the following conf/server.xml configuration:
>
> server.xml (snipped):
> -
>appBase="webapps"
> unpackWARs="true"
> autoDeploy="false"
> deployOnStarup="true"
> xmlValidation="false"
> xmlNamespaceAware="false">
>
> path="jndistring"
> useNaming="true">
>
> value="a test value"
> type="java.lang.String"
> override="false"
> />
>
>
>
>
> For the purpose of this test I've used jsp to access the value of teststring.
>
> jndistring.jsp (snipped):
>
> <%
> Context initCtx = new InitialContext();
> Context envCtx = (Context) initCtx.lookup("java:comp/env");
>
> String teststring = (String) envCtx.lookup("teststring");
> out.println("teststring: " + teststring);
> %>
>
> Accessing this page throws an exception:
> org.apache.jasper.JasperException: An exception occurred processing
> JSP page /test.jsp at line 18
> 15: Context initCtx = new InitialContext();
> 16: Context envCtx = (Context) initCtx.lookup("java:comp/env");
> 17:
> 18: String teststring = (String) envCtx.lookup("teststring");
> 19: out.println("teststring: " + teststring);
> 20: %>
>
> The top frame of the root cause is shown as:
> javax.servlet.ServletException: javax.naming.NameNotFoundException:
> Name teststring is not bound in this Context
>
> If I attempt to create an environment entry resource using
> (and sub-elements) within web.xml, then the resource is
> created and I can access it!!!
>
> I've read the "JNDI resources howto", docs regarding the ,
> and elements (and others), but don't see
> that I have missed anything.
>
> Can anyone suggest what I might have missed? Has anyone else had
> similar problems?
>
> Thanks,
>
> Paul.
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
_
Get thousands of games on your PC, your mobile phone, and the web with Windows®.
http://clk.atdmt.com/MRT/go/108588800/direct/01/
RE: Problem with JNDI environment entry resources
> From: Paul Pepper [mailto:[EMAIL PROTECTED] > Subject: Problem with JNDI environment entry resources > > Can anyone suggest what I might have missed? What happens if you follow the (strongly) recommended practice of not putting elements in server.xml? If you don't want to put the inside your .war file (understandable), put it in conf/Catalina/localhost/jndistring.xml, and remove the illegal docBase and path attributes. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
