Re: Tomcat Maven and Axis 1.5.1 problem
A little googling produces this result: http://www.jarvana.com/jarvana/view/org/apache/axis2/axis2-kernel/1.1.1/axis2-kernel-1.1.1.jar!/org/apache/axis2/transport/local/LocalTransportSender.class?classDetails=ok I suspect that your set of Axis jars are from different versions of Axis - maybe 1.5.1 kernel does not have this class anymore. Winzip will easily confirm this.. Regards Ron - Original Message - From: srd.pl srolek2...@yahoo.com To: users@tomcat.apache.org Sent: Friday, October 29, 2010 8:25 PM Subject: Re: Tomcat Maven and Axis 1.5.1 problem Thanks for the contribution. I have posted on the axis list but no response and I'm running out of time :/ If you can take a look at a list of the .jar files my webservice has: activation-1.1.jar ant-1.7.0.jar ant-launcher-1.7.0.jar antlr-2.7.6.jar apache-maven-2.0.9.jar asm-3.1.jar asm-attrs-1.5.3.jar axiom-api-1.2.8.jar axiom-dom-1.2.8.jar axiom-impl-1.2.8.jar axis-wsdl4j-1.5.1.jar axis2-1.5.1.jar axis2-adb-1.5.1.jar axis2-adb-codegen-1.5.1.jar axis2-codegen-1.5.1.jar axis2-kernel-1.5.1.jar axis2-wsdl2code-maven-plugin-1.5.1.jar axis2-xmlbeans-1.5.1.jar cglib-nodep-2.2.jar classworlds-1.1-alpha-2.jar commons-cli-1.0.jar commons-codec-1.2.jar commons-collections-3.2.1.jar commons-fileupload-1.2.jar commons-httpclient-3.1.jar commons-io-1.4.jar commons-logging-1.1.1.jar dom4j-1.6.1.jar doxia-sink-api-1.0-alpha-10.jar ehcache-1.2.3.jar geronimo-activation_1.1_spec-1.0.1.jar geronimo-javamail_1.4_spec-1.2.jar geronimo-javamail_1.4_spec-1.6.jar geronimo-jta_1.1_spec-1.1.jar geronimo-stax-api_1.0_spec-1.0.1.jar geronimo-ws-metadata_2.0_spec-1.1.2.jar hibernate-3.2.7.ga.jar jaxb-api-2.2.1.jar jaxb-impl-2.2.1.1.jar jaxen-1.1.1.jar jdom-1.0.jar jersey-bundle-1.3.jar jersey-client-1.3.jar jersey-core-1.3.jar jersey-multipart-1.3.jar jsch-0.1.27.jar jsr311-api-1.1.1.jar jtidy-4aug2000r7-dev.jar log4j-1.2.14.jar mail-1.4.jar maven-artifact-2.0.8.jar maven-artifact-manager-2.0.7.jar maven-core-2.0.9.jar maven-error-diagnostics-2.0.9.jar maven-model-2.0.7.jar maven-monitor-2.0.9.jar maven-plugin-api-2.0.7.jar maven-plugin-descriptor-2.0.9.jar maven-plugin-parameter-documenter-2.0.9.jar maven-plugin-registry-2.0.7.jar maven-profile-2.0.7.jar maven-project-2.0.7.jar maven-reporting-api-2.0.9.jar maven-repository-metadata-2.0.7.jar maven-settings-2.0.7.jar maven-toolchain-2.0.9.jar maven-wadl-plugin-1.3.jar mimepull-1.4.jar neethi-2.0.4.jar plexus-container-default-1.0-alpha-9-stable-1.jar plexus-interactivity-api-1.0-alpha-4.jar plexus-utils-1.4.9.jar servlet-api-2.3.jar slf4j-api-1.5.11.jar slf4j-log4j12-1.5.11.jar slide-webdavlib-2.1.jar stax-api-1.0-2.jar wagon-file-1.0-beta-2.jar wagon-http-lightweight-1.0-beta-2.jar wagon-http-shared-1.0-beta-2.jar wagon-provider-api-1.0-beta-2.jar wagon-ssh-1.0-beta-2.jar wagon-ssh-common-1.0-beta-2.jar wagon-ssh-external-1.0-beta-2.jar wagon-webdav-1.0-beta-2.jar woden-api-1.0M8.jar woden-impl-dom-1.0M8.jar wsdl4j-1.6.2.jar wstx-asl-3.2.4.jar xalan-2.7.0.jar xercesImpl-2.6.1.jar xml-apis-1.0.b2.jar xml-apis-1.3.04.jar xml-im-exporter-1.1.jar xmlbeans-2.3.0.jar xmlParserAPIs-2.6.0.jar XmlSchema-1.4.3.jar And this is my pom.xml file: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdcom.mywebapp/groupId artifactIdWebApp/artifactId packagingwar/packaging nameWebApplication for Axis 2/name version0.1/version dependencies dependency groupIdorg.apache.tomcat/groupId artifactIdcatalina/artifactId version6.0.29/version scopetest/scope /dependency dependency groupIdorg.apache.tomcat/groupId artifactIdcoyote/artifactId version6.0.29/version scopetest/scope /dependency dependency groupIdorg.apache.tomcat/groupId artifactIdjasper/artifactId version6.0.29/version scopetest/scope /dependency dependency groupIdorg.apache.axis2/groupId artifactIdaxis2-adb-codegen/artifactId version1.5.1/version /dependency dependency groupIdorg.apache.axis2/groupId artifactIdaxis2-wsdl2code-maven-plugin/artifactId version1.5.1/version /dependency dependency groupIdcom.sun.jersey.contribs/groupId artifactIdjersey-multipart/artifactId version1.3/version !--version1.0.1/version-- /dependency dependency groupIdcom.sun.jersey/groupId artifactIdjersey-client/artifactId version1.3/version !--version1.0.1/version-- /dependency dependency groupIdcom.sun.jersey/groupId artifactIdjersey-bundle/artifactId version1.3/version !--version1.0.1/version-- /dependency dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId version1.1.1/version !--version1.0.4/version-- /dependency dependency groupIdcommons-collections/groupId artifactIdcommons-collections/artifactId version3.2.1/version !--version3.1/version-- /dependency
RE: Tomcat Maven and Axis 1.5.1 problem
Hi I do not think so to use MAVEN *.jar in Tomcat Lib... I presume these are for used for Deployment / Undeployment of AXIS application mounted on Tomcat and NOT for Run time With regards karthik maven-artifact-2.0.8.jar maven-artifact-manager-2.0.7.jar maven-core-2.0.9.jar maven-error-diagnostics-2.0.9.jar maven-model-2.0.7.jar maven-monitor-2.0.9.jar maven-plugin-api-2.0.7.jar maven-plugin-descriptor-2.0.9.jar maven-plugin-parameter-documenter-2.0.9.jar maven-plugin-registry-2.0.7.jar maven-profile-2.0.7.jar maven-project-2.0.7.jar maven-reporting-api-2.0.9.jar maven-repository-metadata-2.0.7.jar maven-settings-2.0.7.jar maven-toolchain-2.0.9.jar maven-wadl-plugin-1.3.jar -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Saturday, October 30, 2010 6:21 PM To: Tomcat Users List Subject: RE: Tomcat Maven and Axis 1.5.1 problem to solve will need web.xml all .jsp *.wsdl all java files Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sat, 30 Oct 2010 10:56:14 +0100 From: p...@pidster.com To: users@tomcat.apache.org Subject: Re: Tomcat Maven and Axis 1.5.1 problem On 29/10/2010 08:25, srd.pl wrote: Thanks for the contribution. I have posted on the axis list but no response and I'm running out of time :/ If you can take a look at a list of the .jar files my webservice has: Do you have all of these jars in the web app? If so, why? Do you really need all of the ant AND maven jars in your webapp? You have two lots of JavaMail JAF (the first jar below and the geronimo jars. Duplicate jars may lead to problems and is unnecessary. It's impossible to know what's wrong with your application, based on the information you've provided so far. p activation-1.1.jar ant-1.7.0.jar ant-launcher-1.7.0.jar antlr-2.7.6.jar apache-maven-2.0.9.jar asm-3.1.jar asm-attrs-1.5.3.jar axiom-api-1.2.8.jar axiom-dom-1.2.8.jar axiom-impl-1.2.8.jar axis-wsdl4j-1.5.1.jar axis2-1.5.1.jar axis2-adb-1.5.1.jar axis2-adb-codegen-1.5.1.jar axis2-codegen-1.5.1.jar axis2-kernel-1.5.1.jar axis2-wsdl2code-maven-plugin-1.5.1.jar axis2-xmlbeans-1.5.1.jar cglib-nodep-2.2.jar classworlds-1.1-alpha-2.jar commons-cli-1.0.jar commons-codec-1.2.jar commons-collections-3.2.1.jar commons-fileupload-1.2.jar commons-httpclient-3.1.jar commons-io-1.4.jar commons-logging-1.1.1.jar dom4j-1.6.1.jar doxia-sink-api-1.0-alpha-10.jar ehcache-1.2.3.jar geronimo-activation_1.1_spec-1.0.1.jar geronimo-javamail_1.4_spec-1.2.jar geronimo-javamail_1.4_spec-1.6.jar geronimo-jta_1.1_spec-1.1.jar geronimo-stax-api_1.0_spec-1.0.1.jar geronimo-ws-metadata_2.0_spec-1.1.2.jar hibernate-3.2.7.ga.jar jaxb-api-2.2.1.jar jaxb-impl-2.2.1.1.jar jaxen-1.1.1.jar jdom-1.0.jar jersey-bundle-1.3.jar jersey-client-1.3.jar jersey-core-1.3.jar jersey-multipart-1.3.jar jsch-0.1.27.jar jsr311-api-1.1.1.jar jtidy-4aug2000r7-dev.jar log4j-1.2.14.jar mail-1.4.jar maven-artifact-2.0.8.jar maven-artifact-manager-2.0.7.jar maven-core-2.0.9.jar maven-error-diagnostics-2.0.9.jar maven-model-2.0.7.jar maven-monitor-2.0.9.jar maven-plugin-api-2.0.7.jar maven-plugin-descriptor-2.0.9.jar maven-plugin-parameter-documenter-2.0.9.jar maven-plugin-registry-2.0.7.jar maven-profile-2.0.7.jar maven-project-2.0.7.jar maven-reporting-api-2.0.9.jar maven-repository-metadata-2.0.7.jar maven-settings-2.0.7.jar maven-toolchain-2.0.9.jar maven-wadl-plugin-1.3.jar mimepull-1.4.jar neethi-2.0.4.jar plexus-container-default-1.0-alpha-9-stable-1.jar plexus-interactivity-api-1.0-alpha-4.jar plexus-utils-1.4.9.jar servlet-api-2.3.jar slf4j-api-1.5.11.jar slf4j-log4j12-1.5.11.jar slide-webdavlib-2.1.jar stax-api-1.0-2.jar wagon-file-1.0-beta-2.jar wagon-http-lightweight-1.0-beta-2.jar wagon-http-shared-1.0-beta-2.jar wagon-provider-api-1.0-beta-2.jar
[ANN] Apache Tomcat Connectors 1.2.31 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat Connectors 1.2.31 stable. Apache Tomcat Connectors 1.2.31 concentrates mainly on bug fixes. Please refer to the change log for the list of changes: http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html Downloads: http://tomcat.apache.org/download-connectors.cgi Please note that syncing the release to the download mirrors might take up to 48 hours. Thank you -- The Apache Tomcat Team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/29/2010 10:04 AM, Mark Thomas wrote: On 29/10/2010 14:53, Ronald Klop wrote: If you have a webapp where users log in you can use there login/password to login on the database. A little bit inconvenient for the DBA but you don't have passwords on your servers. It isn't quite that clear cut. There are some trade-offs to make with this approach (and I'm not sure I like them). 1. The user's password has to be available in plain text. That prevents you from storing digested passwords in the realm. This can be avoided by using a random key created during webapp startup (and persisted across re-deploys, but not undeploy/deploy) to encrypt all the passwords during runtime. That key might still be discoverable using the techniques you've already described (reflection, etc.). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO0MsACgkQ9CaO5/Lv0PAcqACgvWB5P4lsdOlIGwN8t4fY+S93 TgEAn2109aeRK0pGMAarSECByf1IiHS5 =101I -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darryl, On 10/29/2010 9:19 AM, Darryl Lewis wrote: Are you serious? Why do we bother with SSL then? Lets just send everything in clear text... You might be misunderstanding the way that SSL works if you think these two are comparable. A simple database credential system using a username and password is much different than SSL, which uses asymmetric keys to negotiate a symmetric key during the handshake. The symmetric key (analogous to the username/password pair above) is always sent via an encrypted channel and never plaintext. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO0XgACgkQ9CaO5/Lv0PDB9QCgv0qNLPwg50bpK+OWh11Gq5Qh 1AUAn3mP4Rt6YFao3CXsde+62z/rFoZP =lTNZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: BackupManager vs DeltaManager
On Fri, Oct 29, 2010 at 1:51 PM, Pid p...@pidster.com wrote:
On 29/10/2010 11:17, Ossi wrote:
Hi!
Should BackupManager work well with any number of nodes?
Yes.
And with large clusters it should work even better than DeltaManager?
Yes. *Should*.
We have large production clusters (10+) nodes and we have evaluated if we
can use BackupManager.
In test cluster of 6 nodes it didn't work too well: much higher request
latency, with logs full of following errors:
2010-09-24 14:17:34,536 ERROR [tomcat-processor-53]
(org.apache.catalina.tribes.tipis.AbstractReplicatedMap) Unable to
replicate
out data for a LazyReplicatedMap.get
operationorg.apache.catalina.tribes.ChannelException: Operation has timed
out(3000 ms.).; Faulty members:tcp://{10, 1, 8, 219}:4200;
It's timing out for some reason. You could try increasing the timeout.
Yes, I noticed that. However it is using same configs that with DeltaManager
and we didn't get
those same errors with that.
What could be reason for those timeouts? How to know what
operation could be causing the timeout? Like is that on
initialization/starting phase (so, it couldn't connect
at all) or I something in replication just taking a lot of time.
I'll test this with different timeouts.
Does this occur on all cluster members, or just a few?
Sorry, I don't remember it has been awhile when we did those test and
apparently the logs are gone.
Gotta check this when I test this next time.
p
at
org.apache.catalina.tribes.transport.nio.ParallelNioSender.sendMessage(ParallelNioSender.java:97)
at
org.apache.catalina.tribes.transport.nio.PooledParallelSender.sendMessage(PooledParallelSender.java:53)
at
org.apache.catalina.tribes.transport.ReplicationTransmitter.sendMessage(ReplicationTransmitter.java:80)
at
org.apache.catalina.tribes.group.ChannelCoordinator.sendMessage(ChannelCoordinator.java:78)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:75)
at
org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.sendMessage(MessageDispatchInterceptor.java:73)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:75)
at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.sendMessage(TcpFailureDetector.java:87)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:75)
at
org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:216)
at
org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:175)
at
org.apache.catalina.tribes.group.RpcChannel.send(RpcChannel.java:89)
at
org.apache.catalina.tribes.tipis.AbstractReplicatedMap.get(AbstractReplicatedMap.java:844)
at
org.apache.catalina.session.ManagerBase.findSession(ManagerBase.java:887)
at
org.apache.catalina.connector.Request.doGetSession(Request.java:2363)
at
org.apache.catalina.connector.Request.getSession(Request.java:2098)
at
org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
com.sulake.habboweb.util.TomcatSessionFixationPreventerFilter$RequestWrapper.getSession(TomcatSessionFixationPreventerFilter.java:72)
.
Yes, I know that documentation says: Downside of the BackupManager: not
quite as battle tested as the delta manager. Maybe this is it. :)
Regards,
Ossi
Re: running tomcat6 under a different user than root (debian)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daryl, On 10/30/2010 5:11 PM, Darryl Lewis wrote: That's why we encrypt passwords in unix, or haven't you looked at etc/passwd lately? Are you going to tell me that is complete nonsense? The credentialing mechanism is the keyboard and the user's fingers, not a file on the filesystem. What you're suggesting here is that /etc/passwd is the same as conf/server.xml when in reality /etc/passwd is analogous to the password database maintained by the db. According to your 'argument' that is 'security by obscurity'. You better break that to the GNU crowd gently. The GNU crowd did not develop the /etc/passwd standard. Having a username and password in clear text allows another account to be compromised. Yes, it does. Nobody is arguing that. What we're saying is that, given these requirements, security is not possible. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO1H8ACgkQ9CaO5/Lv0PBNGgCeNh8ztnnpdMIh1M6ctUH3hld+ KM0AnAnQ9myujfrFPba8RcmD85OcYvkA =JV6U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RV: Session Context variables architecture problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 10/28/2010 5:36 PM, Pid wrote: I would suggest that you created a class which periodically updated all the values by selecting the data in the DB and storing the result in the Context. Implementing a ServletContextListener will give you access to the ServletContext and two methods, for app startup shutdown, which you can use to start the periodic process, and properly stop it (very important). You may consider using a Timer, or something from the java.util.concurrent package. I would be even lazier (pun intended): record the last-accessed-time of the data in the Context as well, and perform a re-fetch whenever that time is too old (or missing entirely). That avoids the headache of managing another thread on the server (how many questions do we get about still-running threads on app shutdown?) and does not refresh the values from the database unless they are actually requested by code (and therefore doesn't do speculative fetches that might not be required at all). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO1hcACgkQ9CaO5/Lv0PBuKQCePhvYb/rpMHOdUbNRdnJXu6Ud aWEAn0F8AZcBVBw7KtKkwtGzluualYS6 =ur/V -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat6.0.29 on debian lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph, On 10/29/2010 4:51 AM, Christoph Kukulies wrote: I ran a tomcat 5.5 on an older debian formerly and after an upgrade to 5.0.6 (debian lenny) Wait, what? You upgraded from 5.5 to 5.0? That sounds like a downgrade to me. Anyway, to come to the point, I downloaded the tomcat 6.0.29 tar ball and installed it under /opt/tomcat, This is a much better idea than using either 5.0 or 5.5. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO10UACgkQ9CaO5/Lv0PCAgACfUSHxKbS43n9jffseLSRmD/Nc NUkAnRDerr9AZH6gMG+GIu4VChXZtBsO =uzts -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security of WEB-INF content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, On 10/29/2010 7:57 AM, Mark Thomas wrote: On 29/10/2010 12:30, Haledor wow wrote: Hi, I have read in various forums that there are situations where the content of WEB-INF can be accessed. Some people say that it is good practice to hide sensitive files in WEB-INF and some say it might not be... I am using Tomcat 6.0 and I am worried someone could access some of my sensitive files located inside the WEB-INF folder. Could you explain to me whether this is possible or not. Nothing under WEB-INF is directly accessible to a user. Requests to http://host:port/app/WEB-INF/... will always be rejected. If Tomcat is being used behind a web server such as Apache httpd, then the web server can be used to subvert the security provided by Tomcat. For example, a naive configuration might be: httpd.conf: DocumentRoot /var/www/my-webapp JkMount /*.jsp worker my-webapp.xml: Context docBase=/var/www/my-webapp / If a request comes in for /WEB-INF/web.xml, Apache httpd will happily serve that file off the disk while the same request to Tomcat would fail. There are many solutions to this problem, including: 1. Not using a fronting web server 2. Setting DocumentRoot != docBase 3. Adding Limit directives to httpd.conf to specifically exclude WEB-INF and other sensitive areas 4. Making WEB-INF and other sensitive areas unreadable by the httpd process 5. Use a more general (or additional) JkMount directives, like JkMount /*.jsp worker JkMount /WEB-INF/* worker ... though if you have a JkMount for /WEB-INF/, you may as well do #3 or #4 above. I highly favor #1 and #2 above, though your environment may necessitate some of the other options. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO2LYACgkQ9CaO5/Lv0PBW0QCgg5q/Lizid5o3U/9rIaFEeMC1 nCoAniiFNjRYMKdtdl3ljYfICBEB3V0r =oDBU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat6.0.29 on debian lenny
On 11/1/2010 11:05 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph, On 10/29/2010 4:51 AM, Christoph Kukulies wrote: I ran a tomcat 5.5 on an older debian formerly and after an upgrade to 5.0.6 (debian lenny) Wait, what? You upgraded from 5.5 to 5.0? That sounds like a downgrade to me. I imagine he means Debian 5.0.6, which is the latest release of Lenny. Anyway, to come to the point, I downloaded the tomcat 6.0.29 tar ball and installed it under /opt/tomcat, This is a much better idea than using either 5.0 or 5.5. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO10UACgkQ9CaO5/Lv0PCAgACfUSHxKbS43n9jffseLSRmD/Nc NUkAnRDerr9AZH6gMG+GIu4VChXZtBsO =uzts -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 LifecycleBase.init
I have some unit test code that mocks a lot of Tomcat classes so that I can test a Tomcat Valve (code in http://waffle.codeplex.com). Switching to Tomcat 7 is giving me some grief. I used to be able to do this: SimpleContext ctx = new SimpleContext(); // my class Realm realm = new SimpleRealm(); // an empty realm ctx.setRealm(realm); _somevalve.setContainer(ctx); // valve container _somevalve.start(); Now I am getting this java.lang.NullPointerException at org.apache.catalina.mbeans.MBeanUtils.getContainerKeyProperties(MBeanUtils.java:1698) at org.apache.catalina.valves.ValveBase.getObjectNameKeyProperties(ValveBase.java:281) at org.apache.catalina.util.LifecycleMBeanBase.initInternal(LifecycleMBeanBase.java:61) at org.apache.catalina.valves.ValveBase.initInternal(ValveBase.java:223) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:100) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:131) at waffle.apache.NegotiateAuthenticatorTests.setUp(NegotiateAuthenticatorTests.java:44) at junit.framework.TestCase.runBare(TestCase.java:128) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) The problem is in MBeanUtils that assumes that a valid container object is passed into it (from ValveBase.getObjectNameKeyProperties). I tried to walk this code and I don't understand how I am supposed to setup container (and possible its parent(s)) to not get this exception. What am I missing? Any help is appreciated, Thx dB. dB. @ dblock.orghttp://www.dblock.org/ Moscow|Geneva|Seattle|New York
RE: Tomcat 7 LifecycleBase.init
Sorry for the noise. Once I got the right source code, it was pretty easy to track under a debugger. I needed to implement Context.getName(), getPath, an Engine and a Pipeline. _authenticator = new NegotiateAuthenticator(); SimpleContext ctx = new SimpleContext(); Realm realm = new SimpleRealm(); ctx.setRealm(realm); SimpleEngine engine = new SimpleEngine(); ctx.setParent(engine); SimplePipeline pipeline = new SimplePipeline(); engine.setPipeline(pipeline); ctx.setPipeline(pipeline); _authenticator.setContainer(ctx); _authenticator.start(); It would be nice if Tomcat's code was a bit more defensive in terms of nulls. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: dB. [mailto:dbl...@dblock.org] Sent: Monday, November 01, 2010 11:51 AM To: Tomcat Users List (users@tomcat.apache.org) Subject: Tomcat 7 LifecycleBase.init I have some unit test code that mocks a lot of Tomcat classes so that I can test a Tomcat Valve (code in http://waffle.codeplex.com). Switching to Tomcat 7 is giving me some grief. I used to be able to do this: SimpleContext ctx = new SimpleContext(); // my class Realm realm = new SimpleRealm(); // an empty realm ctx.setRealm(realm); _somevalve.setContainer(ctx); // valve container _somevalve.start(); Now I am getting this java.lang.NullPointerException at org.apache.catalina.mbeans.MBeanUtils.getContainerKeyProperties(MBeanUtils.java:1698) at org.apache.catalina.valves.ValveBase.getObjectNameKeyProperties(ValveBase.java:281) at org.apache.catalina.util.LifecycleMBeanBase.initInternal(LifecycleMBeanBase.java:61) at org.apache.catalina.valves.ValveBase.initInternal(ValveBase.java:223) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:100) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:131) at waffle.apache.NegotiateAuthenticatorTests.setUp(NegotiateAuthenticatorTests.java:44) at junit.framework.TestCase.runBare(TestCase.java:128) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) The problem is in MBeanUtils that assumes that a valid container object is passed into it (from ValveBase.getObjectNameKeyProperties). I tried to walk this code and I don't understand how I am supposed to setup container (and possible its parent(s)) to not get this exception. What am I missing? Any help is appreciated, Thx dB. dB. @ dblock.orghttp://www.dblock.org/ Moscow|Geneva|Seattle|New York - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Access log timing details
Hello, I'm trying to debug some performance issues, and see discrepancies from the time reported by HttpClient and Tomcat's access log. This is for post requests (I'm running Tomcat 6.0.18 just in case). Does the time reported in the access log include the entire session, including the time it took to upload the post request, or is it only the response time once the request and payload are fully received? I've looked around but no luck finding details on the response times. Thanks for any info! Alex Quezada - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 LifecycleBase.init
On 01/11/2010 12:34, dB. wrote: Sorry for the noise. Once I got the right source code, it was pretty easy to track under a debugger. I needed to implement Context.getName(), getPath, an Engine and a Pipeline. _authenticator = new NegotiateAuthenticator(); SimpleContext ctx = new SimpleContext(); Realm realm = new SimpleRealm(); ctx.setRealm(realm); SimpleEngine engine = new SimpleEngine(); ctx.setParent(engine); SimplePipeline pipeline = new SimplePipeline(); engine.setPipeline(pipeline); ctx.setPipeline(pipeline); _authenticator.setContainer(ctx); _authenticator.start(); It would be nice if Tomcat's code was a bit more defensive in terms of nulls. Fair point. http://svn.apache.org/viewvc?rev=1029755view=rev should help. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Java update from Apple broke Tomcat
Hi, While I run production on Linux servers, I do my development on my iMac. Last week, I ran the most recent Apple Java upgrade , and now Tomcat (which is a critical part of my development environment) won't start up. I get the error: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) at org.apache.catalina.startup.Bootstrap.initClassLoaders(Bootstrap.java:92) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:207) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:391) Other details: java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode) Tomcat version: 6.0.18 and 6.0.29 both fail to start, throwing the same exception From the error, it appears that things are missing from the update (or at least one field is). Has anyone else seen this? Is there a known work-around? Thanks, Rob Tanner Linfield College
Re: Access log timing details
Its the time the Valve starts processing until the valve has finished processing. Vague heh? So this means that Tomcat will need to do the following first before timing starts - Accept the connection - Receive the 1st line of the request, and probably the headers such as Host - From there - Tomcat now knows where to send the request and can create/invoke the Valve chain and the AccessLogValve can start its timing - Then AccessLogValve records as its end time when the valve is finished its processing (which is after your servlet/jsp is already done since it wraps it). So (if I am correct) it may be possible that the OS could be buffering some bytes waiting to go out which could also cause a time difference. -Tim On 11/1/2010 12:48 PM, Alex Quezada wrote: Hello, I'm trying to debug some performance issues, and see discrepancies from the time reported by HttpClient and Tomcat's access log. This is for post requests (I'm running Tomcat 6.0.18 just in case). Does the time reported in the access log include the entire session, including the time it took to upload the post request, or is it only the response time once the request and payload are fully received? I've looked around but no luck finding details on the response times. Thanks for any info! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java update from Apple broke Tomcat
There's a Mac mini in our QA shop that is running this version of Java with Tomcat 6.0.26 and testing my app without a problem. On Mon, Nov 1, 2010 at 1:55 PM, Rob Tanner rtan...@linfield.edu wrote: Hi, While I run production on Linux servers, I do my development on my iMac. Last week, I ran the most recent Apple Java upgrade , and now Tomcat (which is a critical part of my development environment) won't start up. I get the error: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) at org.apache.catalina.startup.Bootstrap.initClassLoaders(Bootstrap.java:92) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:207) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:391) Other details: java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode) Tomcat version: 6.0.18 and 6.0.29 ‹ both fail to start, throwing the same exception From the error, it appears that things are missing from the update (or at least one field is). Has anyone else seen this? Is there a known work-around? Thanks, Rob Tanner Linfield College -- Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be --Christopher Marlowe, *Doctor Faustus* (v, 121-24)
Re: Java update from Apple broke Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 11/1/2010 1:55 PM, Rob Tanner wrote: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) You can check the code here: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_29/java/org/apache/catalina/startup/Bootstrap.java There is only one instance of IS_DIR in that file. IS_DIR is a protected static member of the ClassLoaderFactory class in the same package. An upgrade of only Java should not have caused this error. Are you working with more than one version of Tomcat at the same time by any chance? How do you start Tomcat? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzPISIACgkQ9CaO5/Lv0PBqIwCfbLkz/3vKSz/Dp/SbAp9x0ePB x0oAnR3nMqHn4oAi9AnGYHswuqQg8xMf =X/Cp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Access log timing details
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex, On 11/1/2010 12:48 PM, Alex Quezada wrote: I'm trying to debug some performance issues, and see discrepancies from the time reported by HttpClient and Tomcat's access log. This is for post requests (I'm running Tomcat 6.0.18 just in case). Does the time reported in the access log include the entire session, including the time it took to upload the post request, or is it only the response time once the request and payload are fully received? I've looked around but no luck finding details on the response times. A bit more info might be helpful, including: 1. The size of POST request you are making 2. The physical network layout (localhost connection versus intercontinental) 3. Some numbers you are trying to reconcile As Tim points out, the TCP negotiation and part of the HTTP conversation will occur 100% before the AccessValve timing starts, so HttpClient's total-time-to-send will likely include that overhead. Give us some time discrepancies and maybe we can comment. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzPIisACgkQ9CaO5/Lv0PCLhgCfVapu1s5rHBTKMJGXeT/h6exu aRYAn1r4PevQvXW1THjl12qTDhaaOWWG =wb5p -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat6.0.29 on debian lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 11/1/2010 11:16 AM, David kerber wrote: On 11/1/2010 11:05 AM, Christopher Schultz wrote: Christoph, On 10/29/2010 4:51 AM, Christoph Kukulies wrote: I ran a tomcat 5.5 on an older debian formerly and after an upgrade to 5.0.6 (debian lenny) Wait, what? You upgraded from 5.5 to 5.0? That sounds like a downgrade to me. I imagine he means Debian 5.0.6, which is the latest release of Lenny. D'oh. Thanks for reading more clearly than I. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzPIroACgkQ9CaO5/Lv0PAVagCfcS7OElLKQShJz315/forLFK9 ClQAoJPhPAbrIDNuS8UQWezP39aR/25N =PVwE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java update from Apple broke Tomcat
Chris, Normally, I let Eclipse start and stop Tomcat for me. It only knows about 6.0.18 and that's the only version I have on my workstation until this morning when I downloaded 6.0.29 to see if there was any possibility that I could have corrupted my existing server. I left 6.0.29 with its default configuration. I tried starting both 6.0.18 and 6.0.29 (not at the same time of course) simply via the bin/catalina.sh shell script and both version fail identically with the same IS_DIR exception ~ Rob On 11/1/10 1:20 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 11/1/2010 1:55 PM, Rob Tanner wrote: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) You can check the code here: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_29/java/org/apa che/catalina/startup/Bootstrap.java There is only one instance of IS_DIR in that file. IS_DIR is a protected static member of the ClassLoaderFactory class in the same package. An upgrade of only Java should not have caused this error. Are you working with more than one version of Tomcat at the same time by any chance? How do you start Tomcat? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzPISIACgkQ9CaO5/Lv0PBqIwCfbLkz/3vKSz/Dp/SbAp9x0ePB x0oAnR3nMqHn4oAi9AnGYHswuqQg8xMf =X/Cp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Java update from Apple broke Tomcat
From: Rob Tanner [mailto:rtan...@linfield.edu] Subject: Re: Java update from Apple broke Tomcat I tried starting both 6.0.18 and 6.0.29 (not at the same time of course) simply via the bin/catalina.sh shell script and both version fail identically with the same IS_DIR exception Can you tell when the script runs what is being set for the classpath? If you have a CLASSPATH environment variable, get rid of it - it should never be used these days. (The Tomcat scripts should be ignoring it, but...) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ISAPI Redirector Work-Flow
I am trying to understand how the ISAPI Redirector functions at an overview level but deeper than this: The request comes into IIS where the ISAPI Redirector filter sends the servlet and JSP requests to the Tomcat server. I know the redirector works with AJP13 to redirect requests to the Tomcat container. What I want to know is HOW that is done. Is it a redirected HTTP request, a 301 redirect or is it a port-to-port connection between the AJP13 processor and the defined instance in the workers.properties file? As this properties file defines the host name of the server holding the Tomcat instance, this can be on a different server than the IIS server, correct? Then does AJP13 'connect' directly to the defined server (localhost in all the examples I have seen) and the defined port (8009 in the same examples)? If you know of a diagram that shows how this works, please share the link to that resouce. /prefont face=monospacesize=-3brThe information transmitted is intended only for the person or entity to which it is addressed and brmay contain confidential and/or privileged material. If the reader of this message is not the intendedbrrecipient, you are hereby notified that your access is unauthorized, and any review, dissemination,brdistribution or copying of this message including any attachments is strictly prohibited. If you are notbrthe intended recipient, please contact the sender and delete the material from any computer.brpre
Re: Java update from Apple broke Tomcat
On 01/11/2010 17:55, Rob Tanner wrote: Hi, While I run production on Linux servers, I do my development on my iMac. Last week, I ran the most recent Apple Java upgrade , and now Tomcat (which is a critical part of my development environment) won't start up. I get the error: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) at org.apache.catalina.startup.Bootstrap.initClassLoaders(Bootstrap.java:92) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:207) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:391) Other details: java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode) Tomcat version: 6.0.18 and 6.0.29 ‹ both fail to start, throwing the same exception From the error, it appears that things are missing from the update (or at least one field is). Has anyone else seen this? Is there a known work-around? I updated too. Works just fine for me, on various 6.0.x and 7.0 trunk. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: ISAPI Redirector Work-Flow
On 01/11/2010 21:48, Richard G Curry wrote: I am trying to understand how the ISAPI Redirector functions at an overview level but deeper than this: The request comes into IIS where the ISAPI Redirector filter sends the servlet and JSP requests to the Tomcat server. I know the redirector works with AJP13 to redirect requests to the Tomcat container. What I want to know is HOW that is done. Is it a redirected HTTP request, a 301 redirect or is it a port-to-port connection between the AJP13 processor and the defined instance in the workers.properties file? It's not a redirect. The request data is converted to the AJP13 binary protocol which is received by an AJP connector in Tomcat. As this properties file defines the host name of the server holding the Tomcat instance, this can be on a different server than the IIS server, correct? Yes. Then does AJP13 'connect' directly to the defined server (localhost in all the examples I have seen) and the defined port (8009 in the same examples)? The connector opens multiple connections to the Tomcat server. If you know of a diagram that shows how this works, please share the link to that resouce. I don't sorry. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: Java update from Apple broke Tomcat
Did you check you classpath? ___ «¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤» ___ Rick Curry Common Services - Software Development E2 - 066, MS 5210 972-431-9178 (Voice) 972-585-7585 (Pager) To send a (short) Text Message to my Pager: 9725857...@page.metrocall.com -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 01, 2010 5:28 PM To: Tomcat Users List Subject: Re: Java update from Apple broke Tomcat On 01/11/2010 17:55, Rob Tanner wrote: Hi, While I run production on Linux servers, I do my development on my iMac. Last week, I ran the most recent Apple Java upgrade , and now Tomcat (which is a critical part of my development environment) won't start up. I get the error: Nov 1, 2010 8:58:54 AM org.apache.catalina.startup.Bootstrap initClassLoaders SEVERE: Class loader creation threw exception java.lang.NoSuchFieldError: IS_DIR at org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:167) at org.apache.catalina.startup.Bootstrap.initClassLoaders(Bootstrap.java:92) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:207) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:391) Other details: java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode) Tomcat version: 6.0.18 and 6.0.29 both fail to start, throwing the same exception From the error, it appears that things are missing from the update (or at least one field is). Has anyone else seen this? Is there a known work-around? I updated too. Works just fine for me, on various 6.0.x and 7.0 trunk. p The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ISAPI Redirector Work-Flow
Thank you for this, I appreciate your time. ___ «¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤» ___ Rick Curry Common Services - Software Development E2 - 066, MS 5210 972-431-9178 (Voice) 972-585-7585 (Pager) To send a (short) Text Message to my Pager: 9725857...@page.metrocall.com -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 01, 2010 5:40 PM To: Tomcat Users List Subject: Re: ISAPI Redirector Work-Flow On 01/11/2010 21:48, Richard G Curry wrote: I am trying to understand how the ISAPI Redirector functions at an overview level but deeper than this: The request comes into IIS where the ISAPI Redirector filter sends the servlet and JSP requests to the Tomcat server. I know the redirector works with AJP13 to redirect requests to the Tomcat container. What I want to know is HOW that is done. Is it a redirected HTTP request, a 301 redirect or is it a port-to-port connection between the AJP13 processor and the defined instance in the workers.properties file? It's not a redirect. The request data is converted to the AJP13 binary protocol which is received by an AJP connector in Tomcat. As this properties file defines the host name of the server holding the Tomcat instance, this can be on a different server than the IIS server, correct? Yes. Then does AJP13 'connect' directly to the defined server (localhost in all the examples I have seen) and the defined port (8009 in the same examples)? The connector opens multiple connections to the Tomcat server. If you know of a diagram that shows how this works, please share the link to that resouce. I don't sorry. p The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
