Re: Problem accessing user ID if Apache used to auithenticate
Milt Epstein wrote: > On Thu, 9 Jan 2003, Steve Slatcher wrote: > >> So I have Apache 2 passing on requests to Tomcat 4.1 using jk2. I >> can get Apache to authenicate URLs that are forwarded to Tomcat, but >> the user ID seems to get lost in the process so I cannot access it >> from my JSPs. I have noticed a few references to this in various >> forums but no resolution. I am not sure if I need some addtional >> configuration steps (what I am using is pretty minimal), or is there >> nothing to be done about it short of diving into Apache or Tomcat >> code? > > I'm using Apache 1, Tomcat 4.0, and mod_jk. On my JK connector tag as > defined in server.xml, I had to add the attribute > tomcatAuthentication="false" to get the user ID (via getRemoteUser) to > be available in Tomcat. Don't know if this is an issue with your > (somewhat different) setup. That certainly seems to be an attribute I will need eventually to be aware of, so thanks for pointing it out. For the record though it seemed my original problem was rather due to my Java code (in some way I have not yet got to the bottom of). On simplifiying it ,I managed to get the user id through OK regardless. Guess I just noticed earlier poisting and jumped to conclusions. Cheers Steve Slatcher -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Problem accessing user ID if Apache used to auithenticate
So I have Apache 2 passing on requests to Tomcat 4.1 using jk2. I can get Apache to authenicate URLs that are forwarded to Tomcat, but the user ID seems to get lost in the process so I cannot access it from my JSPs. I have noticed a few references to this in various forums but no resolution. I am not sure if I need some addtional configuration steps (what I am using is pretty minimal), or is there nothing to be done about it short of diving into Apache or Tomcat code? Cheers Steve Slatcher -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Minumum jk2 configuration
More of an attempt to be helpful to others rather than a request for help,
but I'd be interested in hearing any comments
Despite what you can read in
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/confighowto.html
my experience with jk2 (v2.043) was that I needed these lines in my
workers2.properties file:
[shm]
file=${serverRoot}/logs/shm.file
size=1048576
Without them I get "[error] mod_jk child init 1 0" in my Apache error.log.
(I'm using Win2k)
--
Steve Slatcher
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Using JAXB in a Servlet (class loader prob?)
I too have the full version, and Xerces in common/lib, but don't have JDOM in WEB-INF/lib. My guess is it is some classloading weirdness. Something else to wait and see if it is fixed by the later version I think. Many thanks. Extance, Paul wrote: > We are using Tomcat 4.0.6 and JDK 1.4.0 with just use the vanilla > install of tomcat, and we don't put the xerces.jar in the WEB-INF/lib > either, and all this works fine. We use JDOM in the web app, its > probably because the Crimson XML parser is include in 1.4.0, and it > uses that? > > The vanilla install of TC 4.0.6 also puts xerces in common\lib, so > it's maybe using that. > > PS we are using the FULL version of Tomcat not the 'Lite' version for > JDK 1.4.0. > > Hope that helps > > PaulE > > -Original Message- > From: Steve Slatcher [mailto:steve_slatcher@;scientia.com] > Sent: Thursday, October 31, 2002 2:13 AM > To: Tomcat Users List > Subject: Re: Using JAXB in a Servlet (class loader prob?) > > > Thanks for that. If it is a Tomcat bug that has been addressed, I'll > put the issue on the back burner for a while. Can you remember if > you noticed the xerces issue I mentioned? > > Extance, Paul wrote: >> Upgrade to tomcat 4.0.4 - 4.0.6, then you can put the jaxb-rt.jar >> into the WEB-INF/lib directory. I think 4.0.3 has some class loader >> issues with packages that start with java and javax in the WEB- >> INF/lib folders >> >> This solved the problem for us. >> >> PaulE >> >> -Original Message- >> From: Nick Lombard (VSP) [mailto:nick.lombard@;vcontractor.co.za] >> Sent: Wednesday, October 30, 2002 5:05 AM >> To: Tomcat Users List >> Subject: RE: Using JAXB in a Servlet (class loader prob?) >> >> >> Hi Steve >> >> My half a cent comment. >> >> > interested in > >> We are successfully using shared jar files accross applications by >> placing them in the $TOMCAT_HOME/shared/lib directory. >> >> This will help to not use the common/lib directory. >> >> Hope it helps. >> Nick. >> >> -Original Message- >> From: Steve Slatcher [mailto:steve_slatcher@;scientia.com] >> Sent: Wednesday, October 30, 2002 2:54 PM >> To: Tomcat Users List >> Subject: Using JAXB in a Servlet (class loader prob?) >> >> >> Hi all >> >> I have some code that uses JAXB that works fine in a standalone app >> with the jars I expect it to need. When I put the same code in a >> webapp I got a couple of problems initialising the Sevlet (see log >> file below). >> >> I managed to get rid of one problem (javax.xml.bind.JAXBContext) by >> putting a copy of jaxb-api.jar in /common/lib (before it was only in >> app/WEB-INF/lib). >> >> The second problem was solved by copying a xerces.jar into my >> app/WEB-INF/lib directory (as far as I can tell my standalone app did >> not need org.w3c.dom.ls.DocumentLS at all). >> >> Can anone shed more light on this? Specifically I would be >> interested in any ways to avoid using the /common/lib directory. >> >> I'm using Tomcat 4.0.3, JAXB 1.0 beta (currently the latest version), >> and the magic Xerces that came to the rescue was 1.4.4. Despite the >> name of my webapp I am NOT intent on spamming! >> >> Cheers >> >> Steve Slatcher >> >> 2002-10-30 11:33:14 WebappLoader[/spam]: Deploying class repositories >> to work directory C:\jakarta-tomcat-4.0.3\work\localhost\spam >> 2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR >> /WEB-INF/lib/activation.jar to >> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB- >> INF\lib\activation.jar 2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR /WEB- >> INF/lib/dom.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB- >> INF\lib\dom.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR >> /WEB-INF/lib/jax-qname.jar to >> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jax-qname.jar >> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR >> /WEB-INF/lib/jaxb-api.jar to >> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-api.jar >> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR >> /WEB-INF/lib/jaxb-libs.jar to >> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-libs.jar >> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR >> /WEB-INF/lib/jaxb-ri.jar to >> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-ri.jar >> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR >> /WEB-INF/lib/jaxb-xjc.jar to >> C:\jakarta-tom
Re: Using JAXB in a Servlet (class loader prob?)
Thanks for that. If it is a Tomcat bug that has been addressed, I'll put the issue on the back burner for a while. Can you remember if you noticed the xerces issue I mentioned? Extance, Paul wrote: > Upgrade to tomcat 4.0.4 - 4.0.6, then you can put the jaxb-rt.jar > into the WEB-INF/lib directory. I think 4.0.3 has some class loader > issues with packages that start with java and javax in the WEB- > INF/lib folders > > This solved the problem for us. > > PaulE > > -Original Message- > From: Nick Lombard (VSP) [mailto:nick.lombard@;vcontractor.co.za] > Sent: Wednesday, October 30, 2002 5:05 AM > To: Tomcat Users List > Subject: RE: Using JAXB in a Servlet (class loader prob?) > > > Hi Steve > > My half a cent comment. > > interested in > We are successfully using shared jar files accross applications by > placing them in the $TOMCAT_HOME/shared/lib directory. > > This will help to not use the common/lib directory. > > Hope it helps. > Nick. > > -Original Message- > From: Steve Slatcher [mailto:steve_slatcher@;scientia.com] > Sent: Wednesday, October 30, 2002 2:54 PM > To: Tomcat Users List > Subject: Using JAXB in a Servlet (class loader prob?) > > > Hi all > > I have some code that uses JAXB that works fine in a standalone app > with the jars I expect it to need. When I put the same code in a > webapp I got a couple of problems initialising the Sevlet (see log > file below). > > I managed to get rid of one problem (javax.xml.bind.JAXBContext) by > putting a copy of jaxb-api.jar in /common/lib (before it was only in > app/WEB-INF/lib). > > The second problem was solved by copying a xerces.jar into my > app/WEB-INF/lib directory (as far as I can tell my standalone app did > not need org.w3c.dom.ls.DocumentLS at all). > > Can anone shed more light on this? Specifically I would be > interested in any ways to avoid using the /common/lib directory. > > I'm using Tomcat 4.0.3, JAXB 1.0 beta (currently the latest version), > and the magic Xerces that came to the rescue was 1.4.4. Despite the > name of my webapp I am NOT intent on spamming! > > Cheers > > Steve Slatcher > > 2002-10-30 11:33:14 WebappLoader[/spam]: Deploying class repositories > to work directory C:\jakarta-tomcat-4.0.3\work\localhost\spam > 2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/activation.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\activation.jar > 2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR /WEB- > INF/lib/dom.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB- > INF\lib\dom.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/jax-qname.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jax-qname.jar > 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/jaxb-api.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-api.jar > 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/jaxb-libs.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-libs.jar > 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/jaxb-ri.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-ri.jar > 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/jaxb-xjc.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-xjc.jar > 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/jaxp-api.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxp-api.jar > 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/log4j-1.2.6.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\log4j- > 1.2.6.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB- > INF/lib/mail.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB- > INF\lib\mail.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR > /WEB-INF/lib/sax.jar to C:\jakarta-tomcat- > 4.0.3\bin\..\webapps\spam\WEB-INF\lib\sax.jar 2002-10-30 11:33:15 > WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/xercesImpl.jar to > C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\xercesImpl.jar > 2002-10-30 11:33:15 WebappLoader[/spam]: Reloading checks are enabled > for this Context > 2002-10-30 11:33:15 StandardManager[/spam]: Seeding random number > generator class java.security.SecureRandom > 2002-10-30 11:33:15 StandardManager[/spam]: Seeding of random number > generator has been completed > 2002-10-30 11:33:15 ContextConfig[/spam]: Added certificates -> request > attribute Valve > 2002-10-30 11:33:15 StandardWrapper[/spam:Mailer]: Marking servlet > Mailer as unavailable > 2002-10-30 11:33:15
Re: Tomcat Xerces Issue.
Hi Charlie, Which bit of which spec are you referring to? It sounds strange to me that a webapp is not allowed to use any version of any parser it wants to. Steve Slatcher Cox, Charlie wrote: > this was done to enforce the spec. It was added in later and the doc > was probably overlooked. you can open a bug on bugzilla to get this > updated correctly. > > http://nagoya.apache.org/bugzilla/ > > Charlie > >> -Original Message- >> From: Saurabh Arora [mailto:SArora@;novell.com] >> Sent: Wednesday, October 30, 2002 6:29 AM >> To: [EMAIL PROTECTED] >> Subject: Re: Tomcat Xerces Issue. >> >> >> Just to add to previous posting , i was looking at source >> code for v4.1.12 release Build >> >>>>> [EMAIL PROTECTED] 10/30/02 04:54PM >>> >> I have been looking at the webClassLoader Code. I realised >> that the Classloader doesnot allow the Xerces lib to be >> loaded from the WEB-INB/lib . >> >> It prevents the same be filtering the org.apache.xerces package. >> >> It means the documentation that , Application can use >> specific version of Xerces.jar in the ClassLoader HOWTO is wrong. >> >> Why are we forcing users to use only the common\lib \ xerces >> implementations. >> >> >> Saurabh arora >> >> >> >> >> -- >> To unsubscribe, e-mail: > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:tomcat-user-help@;jakarta.apache.org> > > > > -- > To unsubscribe, e-mail: > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:tomcat-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
Using JAXB in a Servlet (class loader prob?)
Hi all I have some code that uses JAXB that works fine in a standalone app with the jars I expect it to need. When I put the same code in a webapp I got a couple of problems initialising the Sevlet (see log file below). I managed to get rid of one problem (javax.xml.bind.JAXBContext) by putting a copy of jaxb-api.jar in /common/lib (before it was only in app/WEB-INF/lib). The second problem was solved by copying a xerces.jar into my app/WEB-INF/lib directory (as far as I can tell my standalone app did not need org.w3c.dom.ls.DocumentLS at all). Can anone shed more light on this? Specifically I would be interested in any ways to avoid using the /common/lib directory. I'm using Tomcat 4.0.3, JAXB 1.0 beta (currently the latest version), and the magic Xerces that came to the rescue was 1.4.4. Despite the name of my webapp I am NOT intent on spamming! Cheers Steve Slatcher 2002-10-30 11:33:14 WebappLoader[/spam]: Deploying class repositories to work directory C:\jakarta-tomcat-4.0.3\work\localhost\spam 2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/activation.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\activation.jar 2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/dom.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\dom.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/jax-qname.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jax-qname.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/jaxb-api.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-api.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/jaxb-libs.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-libs.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/jaxb-ri.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-ri.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/jaxb-xjc.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-xjc.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/jaxp-api.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxp-api.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/log4j-1.2.6.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\log4j-1.2.6.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/mail.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\mail.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/sax.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\sax.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/xercesImpl.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\xercesImpl.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Reloading checks are enabled for this Context 2002-10-30 11:33:15 StandardManager[/spam]: Seeding random number generator class java.security.SecureRandom 2002-10-30 11:33:15 StandardManager[/spam]: Seeding of random number generator has been completed 2002-10-30 11:33:15 ContextConfig[/spam]: Added certificates -> request attribute Valve 2002-10-30 11:33:15 StandardWrapper[/spam:Mailer]: Marking servlet Mailer as unavailable 2002-10-30 11:33:15 StandardContext[/spam]: Servlet /spam threw load() exception javax.servlet.ServletException: Error instantiating servlet class com.scientia.spam.MailerServlet at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:8 93) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java :3266) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3395) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.core.StandardService.start(StandardService.java:388) at org.apache.catalina.core.StandardServer.start(StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) - Root Cause - java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Cl
