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
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
EJB Compliance
Is Tomcat 4.1 (or even 5.0) EJB Compliant? If so, is it compliant with the EJB 1.2 or 2.0 specification? I can't seem to find appropriate documentation. Also, in the Tomcat docs under the Context element, it doesn't even mention the Ejb element, but, of course, it is provided in the sample server.xml file. Thanks Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
EJB Compliance
This might be a re-post...sorry if it is... Is Tomcat 4.1 (or even 5.0) EJB Compliant? If so, is it compliant with the EJB 1.1 or 2.0 specification? I can't seem to find appropriate documentation. Also, in the Tomcat docs under the Context element, it doesn't even mention the Ejb element, but, of course, it is provided in the sample server.xml file. Thanks Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
JNDI comp namespace
Dear Tomcat Users, I am using Tomcat 4 and trying to use JNDI to connect to a data source and environment variables. I get the following when trying to access the InitialContext via DataSource ds = (DataSource)initialContext.lookup( java:comp/env/jdbc/mydb ); javax.naming.NameNotFoundException: Name comp is not bound in this Context I have read all the documentation many times and cannot see what I am doing wrong. The server.xml seems to be fine; I can see the appropriate context entries in the tomcat manager application. But for some reason the comp namespace does not seem to get set up; basically Tomcat doesn't do what the documentation says it should. Has anybody encountered this type of situation before and found a solution? Thanks Tony
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 second Connector entry. SSL support requires the following steps (see the SSL Config HOWTO in the Tomcat 4.0 documentation bundle for more detailed instructions): * Download and install JSSE 1.0.2 or later, and put the JAR files into $JAVA_HOME/jre/lib/ext. * Execute: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows) $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix) with a password value of changeit for both the certificate and the keystore itself. By default, DNS lookups are enabled when a web application calls request.getRemoteHost(). This can have an adverse impact on performance, so you can disable it by setting the enableLookups attribute to false. When DNS lookups are disabled, request.getRemoteHost() will return the String version of the IP address of the remote client. -- !-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 useURIValidationHack=false disableUploadTimeout=true / !-- Note : To disable connection timeouts, set connectionTimeout value to -1 -- !-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -- !-- Connector className=org.apache.coyote.tomcat4.CoyoteConnector
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 dont 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 second
Connector
entry. SSL support requires the following steps (see the SSL
Config
HOWTO in the Tomcat 4.0 documentation bundle for more detailed
instructions):
* Download and install JSSE 1.0.2 or later, and put the JAR
files
into $JAVA_HOME/jre/lib/ext.
* Execute:
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
(Windows)
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
(Unix)
with a password value
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
4.1.18 Re-deployment
I need help in figuring out why when I re-deploy an app with Tomcat 4.1.18 I get error 404 - Resource not available. The application works fine. Then when I recompile everything, put it in WEB-INF/classes, bundle it up into a war, and then try to use the application, I get the error. I compile the application with an ant job. I precompile the jsps into classes and create a web.xml file on the fly with all appropriate servlet/jsp mappings. If I restart Tomcat, things work fine. Otherwise there is somewhere in replacing the .class files or something that prevents TOmcat from accessing them. Any ideas would be appreciated. Thanks to anybody in advance, Tony __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hi Jon Re: Pri-Compiled jsp and war files
Hi Jon,
I am having a little problem with the solution you
gave me. The problem is that, unlike the jspc tag
which uses org.apache.jasper.JspC, I cannot include
nested fileset tags to specifically indicate which
jsps to compile and which not to (i.e. I have a
header/footer jsp included in alot of other jsps in
which the converted java code won't compile as a
stand-alone)
The jsp tag allowed me to do this but doesn't allow
the webXmlFragment attribute (which puzzles me since
it also is org.apache.jasper.JspC).
I suppose there are other options like re-arranging my
directory structure, building my own java class/task,
etc, but that all seems kind of extreme. Any ideas?
Thanks,
Tony
--- Jon Eaves [EMAIL PROTECTED] wrote:
Hi Tony,
Here's an Ant task that will do what you want.
Please be aware
that this will delete all the JSP files from the
build directory
as part of the processing.
It also creates a web.xml fragment that represents
all the
servlets (that were the jsp files) that needs to be
included
in the web.xml prior to creating the WAR file.
It runs jasper first, and expects to find the JSP
files in
${web.home} and will output the java files in
${basedir}/gensrc.
These java files are then compiled and put into the
build
directory (where all the servlet files are)
!-- jspc target --
taskdef classname=org.apache.jasper.JspC
name=jasper
classpath refid=compile.classpath /
/taskdef
target name=jspc depends=compile
description=Invoke Jasper JSP compiler
mkdir dir=${basedir}/gensrc /
jasper verbose=0
uriroot=${web.home}
webXmlFragment=${basedir}/web.inc
outputDir=${basedir}/gensrc /
javac
srcdir=${basedir}/gensrc
destdir=${build.home}/WEB-INF/classes
classpath refid=compile.classpath /
/javac
!-- remove any *.jsp files in the build
directory --
delete
fileset dir=${build.home}
includes=**/*.jsp /
/delete
/target
Now, just WAR it up.
target name=dist depends=compile,javadoc
description=Create binary distribution
!-- Copy documentation subdirectories --
mkdir dir=${dist.home}/docs/
copytodir=${dist.home}/docs
fileset dir=${docs.home}/
/copy
!-- Create application JAR file --
jar
jarfile=${dist.home}/${app.name}-${app.version}.war
basedir=${build.home}/
!-- Copy additional files to ${dist.home} as
necessary --
/target
So, this creates the war file.
ant compile jspc dist
Will do all the good things. If you want the actual
build.xml
that does all this, then let me know. If you're
using an IDE
this should give you the general idea, but you're on
your own.
Cheers,
-- jon
Tony Colson wrote:
After reading the documentation I am unclear how
to
package the precompiled jsp pages with a war file
so
that Tomcat will see and use them.
Also, do I need to include the actual jsp files
themselves? When I tried that, Tomcat recompiled
them
anyways and put them in the work directory as
normal.
I am running Tomcat 4.1.18.
Thanks
Tony
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up
now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
Jon Eaves [EMAIL PROTECTED]
http://www.eaves.org/jon/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Hi Jon Re: Pri-Compiled jsp and war files
Hi Jon,
I am having a little problem with the solution you
gave me. The problem is that, unlike the jspc tag
which uses org.apache.jasper.JspC, I cannot include
nested fileset tags to specifically indicate which
jsps to compile and which not to (i.e. I have a
header/footer jsp included in alot of other jsps in
which the converted java code won't compile as a
stand-alone)
The jsp tag allowed me to do this but doesn't allow
the webXmlFragment attribute (which puzzles me since
it also is org.apache.jasper.JspC).
I suppose there are other options like re-arranging my
directory structure, building my own java class/task,
etc, but that all seems kind of extreme. Any ideas?
Thanks,
Tony
--- Jon Eaves [EMAIL PROTECTED] wrote:
Hi Tony,
Here's an Ant task that will do what you want.
Please be aware
that this will delete all the JSP files from the
build directory
as part of the processing.
It also creates a web.xml fragment that represents
all the
servlets (that were the jsp files) that needs to be
included
in the web.xml prior to creating the WAR file.
It runs jasper first, and expects to find the JSP
files in
${web.home} and will output the java files in
${basedir}/gensrc.
These java files are then compiled and put into the
build
directory (where all the servlet files are)
!-- jspc target --
taskdef classname=org.apache.jasper.JspC
name=jasper
classpath refid=compile.classpath /
/taskdef
target name=jspc depends=compile
description=Invoke Jasper JSP compiler
mkdir dir=${basedir}/gensrc /
jasper verbose=0
uriroot=${web.home}
webXmlFragment=${basedir}/web.inc
outputDir=${basedir}/gensrc /
javac
srcdir=${basedir}/gensrc
destdir=${build.home}/WEB-INF/classes
classpath refid=compile.classpath /
/javac
!-- remove any *.jsp files in the build
directory --
delete
fileset dir=${build.home}
includes=**/*.jsp /
/delete
/target
Now, just WAR it up.
target name=dist depends=compile,javadoc
description=Create binary distribution
!-- Copy documentation subdirectories --
mkdir dir=${dist.home}/docs/
copytodir=${dist.home}/docs
fileset dir=${docs.home}/
/copy
!-- Create application JAR file --
jar
jarfile=${dist.home}/${app.name}-${app.version}.war
basedir=${build.home}/
!-- Copy additional files to ${dist.home} as
necessary --
/target
So, this creates the war file.
ant compile jspc dist
Will do all the good things. If you want the actual
build.xml
that does all this, then let me know. If you're
using an IDE
this should give you the general idea, but you're on
your own.
Cheers,
-- jon
Tony Colson wrote:
After reading the documentation I am unclear how
to
package the precompiled jsp pages with a war file
so
that Tomcat will see and use them.
Also, do I need to include the actual jsp files
themselves? When I tried that, Tomcat recompiled
them
anyways and put them in the work directory as
normal.
I am running Tomcat 4.1.18.
Thanks
Tony
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up
now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
Jon Eaves [EMAIL PROTECTED]
http://www.eaves.org/jon/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pri-Compiled jsp and war files
Hi Jon,
Thanks. I think the trick is the webXmlFragment. I
had put my jsps under the
WEB-INF/classes/org/apache/jsp directory but did not
put in the servlet mappings in the web.xml file.
Question: I am rather new to ant programming, but I am
wondering where the attributes came from for your
jasper taskdef? Using the webXmlFragment in the
jspc tag didn't work, even though I thought it would
given that they both used org.apache.jasper.JspC ( and
I presumed webXmlFragment was an attribute of that
class)
Also, there has to be a way to incorporate the web.inc
file automatically into web.xml for automatic builds.
Any ideas on that or do I have to get clever?
Thanks
Tony
--- Jon Eaves [EMAIL PROTECTED] wrote:
Hi Tony,
Here's an Ant task that will do what you want.
Please be aware
that this will delete all the JSP files from the
build directory
as part of the processing.
It also creates a web.xml fragment that represents
all the
servlets (that were the jsp files) that needs to be
included
in the web.xml prior to creating the WAR file.
It runs jasper first, and expects to find the JSP
files in
${web.home} and will output the java files in
${basedir}/gensrc.
These java files are then compiled and put into the
build
directory (where all the servlet files are)
!-- jspc target --
taskdef classname=org.apache.jasper.JspC
name=jasper
classpath refid=compile.classpath /
/taskdef
target name=jspc depends=compile
description=Invoke Jasper JSP compiler
mkdir dir=${basedir}/gensrc /
jasper verbose=0
uriroot=${web.home}
webXmlFragment=${basedir}/web.inc
outputDir=${basedir}/gensrc /
javac
srcdir=${basedir}/gensrc
destdir=${build.home}/WEB-INF/classes
classpath refid=compile.classpath /
/javac
!-- remove any *.jsp files in the build
directory --
delete
fileset dir=${build.home}
includes=**/*.jsp /
/delete
/target
Now, just WAR it up.
target name=dist depends=compile,javadoc
description=Create binary distribution
!-- Copy documentation subdirectories --
mkdir dir=${dist.home}/docs/
copytodir=${dist.home}/docs
fileset dir=${docs.home}/
/copy
!-- Create application JAR file --
jar
jarfile=${dist.home}/${app.name}-${app.version}.war
basedir=${build.home}/
!-- Copy additional files to ${dist.home} as
necessary --
/target
So, this creates the war file.
ant compile jspc dist
Will do all the good things. If you want the actual
build.xml
that does all this, then let me know. If you're
using an IDE
this should give you the general idea, but you're on
your own.
Cheers,
-- jon
Tony Colson wrote:
After reading the documentation I am unclear how
to
package the precompiled jsp pages with a war file
so
that Tomcat will see and use them.
Also, do I need to include the actual jsp files
themselves? When I tried that, Tomcat recompiled
them
anyways and put them in the work directory as
normal.
I am running Tomcat 4.1.18.
Thanks
Tony
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up
now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
Jon Eaves [EMAIL PROTECTED]
http://www.eaves.org/jon/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Pri-Compiled jsp and war files
After reading the documentation I am unclear how to package the precompiled jsp pages with a war file so that Tomcat will see and use them. Also, do I need to include the actual jsp files themselves? When I tried that, Tomcat recompiled them anyways and put them in the work directory as normal. I am running Tomcat 4.1.18. Thanks Tony __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
