RE: JNDI comp namespace - Tomcat Developers Please Read
Hi, Just to close up a few issues, and I am sorry if this email will offend anybody, but I don't apologize for writing it: I responded to one of your messages saying there might be a startup error with one of your contexts causing this behavior. (http://marc.theaimsgroup.com/?l=tomcat-userm=107149495515920w=2) But you never replied to that. Instead, you enter this issue into Bugzilla, and then ask tomcat developers to read your message. Ok, perhaps you have a point, but I didn't want to burden the list anymore; After asking Tomcat developers to chime in I decided to move it over to Bugzilla. I did check what you suggested (actually before you suggested it). I didn't see anything wrong with it. However, that doesn't mean there wasn't; I find the documentation for Tomcat leaves much to be desired, even in books. I have not found any type of instruction on the Context elements, rather just simple declarations of what they are and their attributes. Most of the details I know about these elements have come from trial and error, so I hope you'll forgive me for being inexperienced. autoDeploy has nothing to do with JNDI. Agreed. That is why it is a bug that it does affect it. This issue was confirmed by another developer who privately emailed me about it. Apparently it still exists in Tomcat 5, the developers know about it but have not committed to fixing it, and this other developer cannot upgrade to Tomcat 5 because of it (He is still using Tomcat 3 where autoDeploy does not break JNDI). If you even want someone to look at this, you will need to provide a test case (e.g. WAR files, even if they're small dummy ones that don't do anything) so that we can try to reproduce your bug. Needless to say, we don't have and don't care to have your actual webapps. Just have one servlet that looks up a String via env-entry JNDI or something like that. Ok. Perhaps you have another point where I could have provided a runtime war to illustrate this, however in my first email on this topic I included the code snippet which illustrated this and subsequently server.xml: DataSource ds = (DataSource)initialContext.lookup( java:comp/env/jdbc/mydb ); Finally, even if this were an issue as you describe, it's not major, but minor, as this is a rarely used configuration (multiple Service) in the not-latest (4.1.15) version of a no-longer-developed branch (4.1). First, my philosophy is that if Tomcat is not going to support a release it should not be available on the website as a current release: 4.1.29.zip is available on the same page and section as 5.1.zip and there was not any indication that it was no longer supported, outside of implicitly assuming so. Second, since I can't find any documentation saying that multiple Service tags is not the intended use of Tomcat nor any metrics saying that it is rarely used, I feel perfectly free and right to report it with the severity that it affects me. If a more learned Tomcat developer wants to downgrade it to minor, I have no problem with that, but I don't appreciate getting my chops busted by another user on a list like this. As far as I am concerned, this issue is now closed and I got the information I needed. Thanks to all who productively contributed (Yes, even you Yoav ;)). Thanks and Merry Christmas to all, Tony -Original Message- From: Shapira, Yoav Subject: RE: JNDI comp namespace - Tomcat Developers Please Read Howdy, See, it's messages like these that annoy me. And on a Friday, too. I responded to one of your messages saying there might be a startup error with one of your contexts causing this behavior. (http://marc.theaimsgroup.com/?l=tomcat-userm=107149495515920w=2) But you never replied to that. Instead, you enter this issue into Bugzilla, and then ask tomcat developers to read your message. autoDeploy has nothing to do with JNDI. If you even want someone to look at this, you will need to provide a test case (e.g. WAR files, even if they're small dummy ones that don't do anything) so that we can try to reproduce your bug. Needless to say, we don't have and don't care to have your actual webapps. Just have one servlet that looks up a String via env-entry JNDI or something like that. Finally, even if this were an issue as you describe, it's not major, but minor, as this is a rarely used configuration (multiple Service) in the not-latest (4.1.15) version of a no-longer-developed branch (4.1). Yoav Shapira Millennium ChemInformatics -Original Message- From: Tony Colson [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 3:45 PM To: 'Tomcat Users List'; [EMAIL PROTECTED] Subject: RE: JNDI comp namespace - Tomcat Developers Please Read I have filed this bug with Tomcat under Bugzilla as bug #25508. -Original Message- Sent: Saturday, December 13, 2003 12:09 AM To: 'Tomcat Users List'; [EMAIL PROTECTED] Subject: RE: JNDI comp namespace - Tomcat Developers Please Read I
Re: JNDI comp namespace - Tomcat Developers Please Read
Tony Colson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, Just to close up a few issues, and I am sorry if this email will offend anybody, but I don't apologize for writing it: I responded to one of your messages saying there might be a startup error with one of your contexts causing this behavior. (http://marc.theaimsgroup.com/?l=tomcat-userm=107149495515920w=2) But you never replied to that. Instead, you enter this issue into Bugzilla, and then ask tomcat developers to read your message. Ok, perhaps you have a point, but I didn't want to burden the list anymore; After asking Tomcat developers to chime in I decided to move it over to Bugzilla. I did check what you suggested (actually before you suggested it). I didn't see anything wrong with it. However, that doesn't mean there wasn't; I find the documentation for Tomcat leaves much to be desired, even in books. I have not found any type of instruction on the Context elements, rather just simple declarations of what they are and their attributes. Most of the details I know about these elements have come from trial and error, so I hope you'll forgive me for being inexperienced. autoDeploy has nothing to do with JNDI. Agreed. That is why it is a bug that it does affect it. This issue was confirmed by another developer who privately emailed me about it. Apparently it still exists in Tomcat 5, the developers know about it but have not committed to fixing it, and this other developer cannot upgrade to Tomcat 5 because of it (He is still using Tomcat 3 where autoDeploy does not break JNDI). If you even want someone to look at this, you will need to provide a test case (e.g. WAR files, even if they're small dummy ones that don't do anything) so that we can try to reproduce your bug. Needless to say, we don't have and don't care to have your actual webapps. Just have one servlet that looks up a String via env-entry JNDI or something like that. Ok. Perhaps you have another point where I could have provided a runtime war to illustrate this, however in my first email on this topic I included the code snippet which illustrated this and subsequently server.xml: DataSource ds = (DataSource)initialContext.lookup( java:comp/env/jdbc/mydb ); Finally, even if this were an issue as you describe, it's not major, but minor, as this is a rarely used configuration (multiple Service) in the not-latest (4.1.15) version of a no-longer-developed branch (4.1). First, my philosophy is that if Tomcat is not going to support a release it should not be available on the website as a current release: 4.1.29.zip is available on the same page and section as 5.1.zip and there was not any indication that it was no longer supported, outside of implicitly assuming so. supported != developed. For example: TC 3.3.x is fully supported (i.e. bugs will be fixed), but it isn't really developed at the moment (i.e. new features are unlikely to be added). Second, since I can't find any documentation saying that multiple Service tags is not the intended use of Tomcat nor any metrics saying that it is rarely used, I feel perfectly free and right to report it with the severity that it affects me. If a more learned Tomcat developer wants to downgrade it to minor, I have no problem with that, but I don't appreciate getting my chops busted by another user on a list like this. News flash: Yoav *is* a Tomcat developer. Check the tomcat-dev archives, and you will find plenty of commit messages from him (probably more than you will find for me lately :). As far as I am concerned, this issue is now closed and I got the information I needed. Thanks to all who productively contributed (Yes, even you Yoav ;)). Thanks and Merry Christmas to all, Tony -Original Message- From: Shapira, Yoav Subject: RE: JNDI comp namespace - Tomcat Developers Please Read Howdy, See, it's messages like these that annoy me. And on a Friday, too. I responded to one of your messages saying there might be a startup error with one of your contexts causing this behavior. (http://marc.theaimsgroup.com/?l=tomcat-userm=107149495515920w=2) But you never replied to that. Instead, you enter this issue into Bugzilla, and then ask tomcat developers to read your message. autoDeploy has nothing to do with JNDI. If you even want someone to look at this, you will need to provide a test case (e.g. WAR files, even if they're small dummy ones that don't do anything) so that we can try to reproduce your bug. Needless to say, we don't have and don't care to have your actual webapps. Just have one servlet that looks up a String via env-entry JNDI or something like that. Finally, even if this were an issue as you describe, it's not major, but minor, as this is a rarely used configuration (multiple Service) in the not-latest (4.1.15) version of a no-longer-developed branch (4.1
RE: JNDI comp namespace - Tomcat Developers Please Read
I have filed this bug with Tomcat under Bugzilla as bug #25508.
-Original Message-
Sent: Saturday, December 13, 2003 12:09 AM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace - Tomcat Developers Please Read
I narrowed down the problem a bit more. I found 2 things which look
like they may be bugs.
1) In the first Service tag I had a Engine tag and a Host tag as
seen below:
Service name=XXX
Engine name=Standalone
defaultHost=localhost
debug=0
Host name=localhost debug=0 appBase=webapps
unpackWARs=true autoDeploy=false
Context.../Context
Context.../Context
With Host autoDeploy=true JNDI doesn't work. When I set autoDeploy
to false JNDI works.
2) I had 2 Context tags in the above Service tag. When I commented
out the 2nd Context tag JNDI worked.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 10:31 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace - Tomcat Developers Please Read
As per my suspicion, multiple Service seemed to cause the problem as I
had the JNDI resources defined in the second Service. Removing the
first service temporarily seemed to fix it.
Is this a bug in Tomcat? Or is there something else I need to specify?
I will do some more testing to see if I can't narrow it down further.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 1:23 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace
Hi,
Thanks for the tip. Actually, this is how my server.xml was set up
originally. I changed the resource name to java:comp/env/jdbc/NNT under
the notion that it might create the comp namespace if it saw it in the
xml file.
I am beginning to wonder if the problem is related to the fact that I
have different ports running web apps?
Thanks,
Tony Colson
-Original Message-
From: Altankov Peter [mailto:[EMAIL PROTECTED]
Howdy,Try this setup in your context definition:
Resource name=jdbc/NNT auth=Container
type=javax.sql.DataSource/
ResourceParams name=jdbc/NNT .
After that in the source where u access it go for:
Context ictx = new InitialContext();
if (ictx == null) {
throw new Exception(Boom - No Context);
}
DtataSource ds = (DataSource) ictx.lookup(java:comp/env/jdbc/NNT);
I don't have the time to go into JNDI details, but im pretty sure that
wold work for you
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: 12 2003 ?. 10:48
To: 'Tomcat Users List'
Subject: RE: JNDI comp namespace
As per a suggestion I am posting my server.xml file.
I have several applications on different ports. I am trying to use JNDI
on the NNT application running on port 9000. Do a search for 9000 and
you will be at the Service... tag. Just scroll down to see the
Context and Resource tags to look at my setup. (Also note that I am
trying to use GlobalNamingResources as seen at the top of the file.)
Thanks
Tony
= START SERVER.XML ==
!-- 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 debug=0
!-- Comment these entries out to disable JMX MBeans support --
!-- You may also configure custom components (e.g. Valves/Realms) by
including your own mbean-descriptor file(s), and setting the
descriptors attribute to point to a ';' seperated list of paths
(in the ClassLoader sense) of files to add to the default list.
e.g. descriptors=/com/myfirm/mypackage/mbean-descriptor.xml
--
Listener
className=org.apache.catalina.mbeans.ServerLifecycleListener
debug=0/
Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
debug=0/
!-- 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
/Resource
ResourceParams name=UserDatabase
parameter
namefactory/name
valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value
/parameter
RE: JNDI comp namespace - Tomcat Developers Please Read
Howdy,
See, it's messages like these that annoy me. And on a Friday, too.
I responded to one of your messages saying there might be a startup
error with one of your contexts causing this behavior.
(http://marc.theaimsgroup.com/?l=tomcat-userm=107149495515920w=2) But
you never replied to that. Instead, you enter this issue into Bugzilla,
and then ask tomcat developers to read your message.
autoDeploy has nothing to do with JNDI.
If you even want someone to look at this, you will need to provide a
test case (e.g. WAR files, even if they're small dummy ones that don't
do anything) so that we can try to reproduce your bug. Needless to say,
we don't have and don't care to have your actual webapps. Just have one
servlet that looks up a String via env-entry JNDI or something like
that.
Finally, even if this were an issue as you describe, it's not major, but
minor, as this is a rarely used configuration (multiple Service) in the
not-latest (4.1.15) version of a no-longer-developed branch (4.1).
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 3:45 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace - Tomcat Developers Please Read
I have filed this bug with Tomcat under Bugzilla as bug #25508.
-Original Message-
Sent: Saturday, December 13, 2003 12:09 AM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace - Tomcat Developers Please Read
I narrowed down the problem a bit more. I found 2 things which look
like they may be bugs.
1) In the first Service tag I had a Engine tag and a Host tag as
seen below:
Service name=XXX
Engine name=Standalone
defaultHost=localhost
debug=0
Host name=localhost debug=0 appBase=webapps
unpackWARs=true autoDeploy=false
Context.../Context
Context.../Context
With Host autoDeploy=true JNDI doesn't work. When I set autoDeploy
to false JNDI works.
2) I had 2 Context tags in the above Service tag. When I commented
out the 2nd Context tag JNDI worked.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 10:31 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace - Tomcat Developers Please Read
As per my suspicion, multiple Service seemed to cause the problem as
I
had the JNDI resources defined in the second Service. Removing the
first service temporarily seemed to fix it.
Is this a bug in Tomcat? Or is there something else I need to specify?
I will do some more testing to see if I can't narrow it down further.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 1:23 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace
Hi,
Thanks for the tip. Actually, this is how my server.xml was set up
originally. I changed the resource name to java:comp/env/jdbc/NNT
under
the notion that it might create the comp namespace if it saw it in the
xml file.
I am beginning to wonder if the problem is related to the fact that I
have different ports running web apps?
Thanks,
Tony Colson
-Original Message-
From: Altankov Peter [mailto:[EMAIL PROTECTED]
Howdy,Try this setup in your context definition:
Resource name=jdbc/NNT auth=Container
type=javax.sql.DataSource/
ResourceParams name=jdbc/NNT .
After that in the source where u access it go for:
Context ictx = new InitialContext();
if (ictx == null) {
throw new Exception(Boom - No Context);
}
DtataSource ds = (DataSource) ictx.lookup(java:comp/env/jdbc/NNT);
I don't have the time to go into JNDI details, but im pretty sure that
wold work for you
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: 12 2003 ?. 10:48
To: 'Tomcat Users List'
Subject: RE: JNDI comp namespace
As per a suggestion I am posting my server.xml file.
I have several applications on different ports. I am trying to use
JNDI
on the NNT application running on port 9000. Do a search for 9000
and
you will be at the Service... tag. Just scroll down to see the
Context and Resource tags to look at my setup. (Also note that I
am
trying to use GlobalNamingResources as seen at the top of the file.)
Thanks
Tony
= START SERVER.XML ==
!-- 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 debug=0
!-- Comment
RE: JNDI comp namespace - Tomcat Developers Please Read
Howdy,
You 2nd context probably has deployment problems which prevent JNDI from
working. autoDeploy for the host just appears to break JNDI because it
triggers deployment of your 2nd context.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 13, 2003 3:09 AM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace - Tomcat Developers Please Read
I narrowed down the problem a bit more. I found 2 things which look
like they may be bugs.
1) In the first Service tag I had a Engine tag and a Host tag as
seen below:
Service name=XXX
Engine name=Standalone
defaultHost=localhost
debug=0
Host name=localhost debug=0 appBase=webapps
unpackWARs=true autoDeploy=false
Context.../Context
Context.../Context
With Host autoDeploy=true JNDI doesn't work. When I set autoDeploy
to false JNDI works.
2) I had 2 Context tags in the above Service tag. When I commented
out the 2nd Context tag JNDI worked.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 10:31 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace - Tomcat Developers Please Read
As per my suspicion, multiple Service seemed to cause the problem as
I
had the JNDI resources defined in the second Service. Removing the
first service temporarily seemed to fix it.
Is this a bug in Tomcat? Or is there something else I need to specify?
I will do some more testing to see if I can't narrow it down further.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 1:23 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace
Hi,
Thanks for the tip. Actually, this is how my server.xml was set up
originally. I changed the resource name to java:comp/env/jdbc/NNT
under
the notion that it might create the comp namespace if it saw it in the
xml file.
I am beginning to wonder if the problem is related to the fact that I
have different ports running web apps?
Thanks,
Tony Colson
-Original Message-
From: Altankov Peter [mailto:[EMAIL PROTECTED]
Howdy,Try this setup in your context definition:
Resource name=jdbc/NNT auth=Container
type=javax.sql.DataSource/
ResourceParams name=jdbc/NNT .
After that in the source where u access it go for:
Context ictx = new InitialContext();
if (ictx == null) {
throw new Exception(Boom - No Context);
}
DtataSource ds = (DataSource) ictx.lookup(java:comp/env/jdbc/NNT);
I don't have the time to go into JNDI details, but im pretty sure that
wold work for you
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: 12 2003 ?. 10:48
To: 'Tomcat Users List'
Subject: RE: JNDI comp namespace
As per a suggestion I am posting my server.xml file.
I have several applications on different ports. I am trying to use
JNDI
on the NNT application running on port 9000. Do a search for 9000
and
you will be at the Service... tag. Just scroll down to see the
Context and Resource tags to look at my setup. (Also note that I
am
trying to use GlobalNamingResources as seen at the top of the file.)
Thanks
Tony
= START SERVER.XML ==
!-- 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 debug=0
!-- Comment these entries out to disable JMX MBeans support --
!-- You may also configure custom components (e.g. Valves/Realms) by
including your own mbean-descriptor file(s), and setting the
descriptors attribute to point to a ';' seperated list of
paths
(in the ClassLoader sense) of files to add to the default list.
e.g. descriptors=/com/myfirm/mypackage/mbean-descriptor.xml
--
Listener
className=org.apache.catalina.mbeans.ServerLifecycleListener
debug=0/
Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
debug=0/
!-- 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
RE: JNDI comp namespace - Tomcat Developers Please Read
I narrowed down the problem a bit more. I found 2 things which look
like they may be bugs.
1) In the first Service tag I had a Engine tag and a Host tag as
seen below:
Service name=XXX
Engine name=Standalone
defaultHost=localhost
debug=0
Host name=localhost debug=0 appBase=webapps
unpackWARs=true autoDeploy=false
Context.../Context
Context.../Context
With Host autoDeploy=true JNDI doesn't work. When I set autoDeploy
to false JNDI works.
2) I had 2 Context tags in the above Service tag. When I commented
out the 2nd Context tag JNDI worked.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 10:31 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace - Tomcat Developers Please Read
As per my suspicion, multiple Service seemed to cause the problem as I
had the JNDI resources defined in the second Service. Removing the
first service temporarily seemed to fix it.
Is this a bug in Tomcat? Or is there something else I need to specify?
I will do some more testing to see if I can't narrow it down further.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 1:23 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace
Hi,
Thanks for the tip. Actually, this is how my server.xml was set up
originally. I changed the resource name to java:comp/env/jdbc/NNT under
the notion that it might create the comp namespace if it saw it in the
xml file.
I am beginning to wonder if the problem is related to the fact that I
have different ports running web apps?
Thanks,
Tony Colson
-Original Message-
From: Altankov Peter [mailto:[EMAIL PROTECTED]
Howdy,Try this setup in your context definition:
Resource name=jdbc/NNT auth=Container
type=javax.sql.DataSource/
ResourceParams name=jdbc/NNT .
After that in the source where u access it go for:
Context ictx = new InitialContext();
if (ictx == null) {
throw new Exception(Boom - No Context);
}
DtataSource ds = (DataSource) ictx.lookup(java:comp/env/jdbc/NNT);
I don't have the time to go into JNDI details, but im pretty sure that
wold work for you
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: 12 2003 ?. 10:48
To: 'Tomcat Users List'
Subject: RE: JNDI comp namespace
As per a suggestion I am posting my server.xml file.
I have several applications on different ports. I am trying to use JNDI
on the NNT application running on port 9000. Do a search for 9000 and
you will be at the Service... tag. Just scroll down to see the
Context and Resource tags to look at my setup. (Also note that I am
trying to use GlobalNamingResources as seen at the top of the file.)
Thanks
Tony
= START SERVER.XML ==
!-- 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 debug=0
!-- Comment these entries out to disable JMX MBeans support --
!-- You may also configure custom components (e.g. Valves/Realms) by
including your own mbean-descriptor file(s), and setting the
descriptors attribute to point to a ';' seperated list of paths
(in the ClassLoader sense) of files to add to the default list.
e.g. descriptors=/com/myfirm/mypackage/mbean-descriptor.xml
--
Listener
className=org.apache.catalina.mbeans.ServerLifecycleListener
debug=0/
Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
debug=0/
!-- 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
/Resource
ResourceParams name=UserDatabase
parameter
namefactory/name
valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value
/parameter
parameter
namepathname/name
valueconf/tomcat-users.xml/value
/parameter
/ResourceParams
!-- The PostgreSQL NNT database on horse --
/GlobalNamingResources
!-- A Service is a collection of one or more
RE: JNDI comp namespace - Tomcat Developers Please Read
As per my suspicion, multiple Service seemed to cause the problem as I
had the JNDI resources defined in the second Service. Removing the
first service temporarily seemed to fix it.
Is this a bug in Tomcat? Or is there something else I need to specify?
I will do some more testing to see if I can't narrow it down further.
Tony
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 1:23 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: JNDI comp namespace
Hi,
Thanks for the tip. Actually, this is how my server.xml was set up
originally. I changed the resource name to java:comp/env/jdbc/NNT under
the notion that it might create the comp namespace if it saw it in the
xml file.
I am beginning to wonder if the problem is related to the fact that I
have different ports running web apps?
Thanks,
Tony Colson
-Original Message-
From: Altankov Peter [mailto:[EMAIL PROTECTED]
Howdy,Try this setup in your context definition:
Resource name=jdbc/NNT auth=Container
type=javax.sql.DataSource/
ResourceParams name=jdbc/NNT .
After that in the source where u access it go for:
Context ictx = new InitialContext();
if (ictx == null) {
throw new Exception(Boom - No Context);
}
DtataSource ds = (DataSource) ictx.lookup(java:comp/env/jdbc/NNT);
I don't have the time to go into JNDI details, but im pretty sure that
wold work for you
-Original Message-
From: Tony Colson [mailto:[EMAIL PROTECTED]
Sent: 12 2003 ?. 10:48
To: 'Tomcat Users List'
Subject: RE: JNDI comp namespace
As per a suggestion I am posting my server.xml file.
I have several applications on different ports. I am trying to use JNDI
on the NNT application running on port 9000. Do a search for 9000 and
you will be at the Service... tag. Just scroll down to see the
Context and Resource tags to look at my setup. (Also note that I am
trying to use GlobalNamingResources as seen at the top of the file.)
Thanks
Tony
= START SERVER.XML ==
!-- 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 debug=0
!-- Comment these entries out to disable JMX MBeans support --
!-- You may also configure custom components (e.g. Valves/Realms) by
including your own mbean-descriptor file(s), and setting the
descriptors attribute to point to a ';' seperated list of paths
(in the ClassLoader sense) of files to add to the default list.
e.g. descriptors=/com/myfirm/mypackage/mbean-descriptor.xml
--
Listener
className=org.apache.catalina.mbeans.ServerLifecycleListener
debug=0/
Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
debug=0/
!-- 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
/Resource
ResourceParams name=UserDatabase
parameter
namefactory/name
valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value
/parameter
parameter
namepathname/name
valueconf/tomcat-users.xml/value
/parameter
/ResourceParams
!-- The PostgreSQL NNT database on horse --
/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). Normally, that Container is an Engine,
but this is not required.
Note: A Service is not itself a Container, so you may not
define subcomponents such as Valves or Loggers at this level.
--
!-- Define the Tomcat Stand-Alone Service --
Service name=Tomcat-Standalone
!-- A Connector represents an endpoint by which requests are
received
and responses are returned. Each Connector passes requests on
to the
associated Container (normally an Engine) for processing.
By default, a non-SSL HTTP/1.1 Connector is established on port
8080.
You can also enable an SSL HTTP/1.1 Connector on port 8443 by
following the instructions below and uncommenting the
