Major Minor Version issue when using jersey 2.9 with tomcat7 + java8
Resending previous email in plain text: We have a maven project to develop a jersey 2.0 REST service, on Eclipse (kepler) org.glassfish.jersey.containers jersey-container-servlet-core 2.9.1 In conjunction with: - java8 - tomcat7 When deploying the web application (using `$ mvn install && mvn -X tomcat7:redeploy`) we get the below exception: Caused by: java.lang.UnsupportedClassVersionError: org/glassfish/jersey/servlet/init/JerseyServletContainerInitializer : Unsupported major.minor version 51.0 (unable to load class org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2840) 1. I examined the MANIFEST file in the org.glassfish.jersey.containers jar, & (as suspected) it says built on 1.7 JDK 2. Tomcat logs confirm that it uses java8 itself We cannot move back to java8. Is there a way/hack we can get past this error? --- smc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Versioning issue when using jersey 2.9 with tomcat7 + java8
We have a maven project to develop a jersey 2.0 REST service, on Eclipse (kepler) org.glassfish.jersey.containers jersey-container-servlet-core 2.9.1 In conjunction with: - java8 - tomcat7 When deploying the web application (using `$ mvn install && mvn -X tomcat7:redeploy`) we get the below exception: Caused by: java.lang.UnsupportedClassVersionError: org/glassfish/jersey/servlet/init/JerseyServletContainerInitializer : Unsupported major.minor version 51.0 (unable to load class org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2840) 1. I examined the MANIFEST file in the org.glassfish.jersey.containers jar, and (as suspected) it says build on 1.7 JDK 2. Tomcat logs confirm that it uses java8 itself We cannot move back to java8. Is there a way/hack we can get past this error? --- Seshu Madhav Chaturvedula
Re: Two Way authentication - Urgent Help
Already imported your client.p12 into firefox? http://www.utexas.edu/its/help/user-certs/817 Il 16/giu/2014 00:22 Grip In ha scritto: > > Getting > > An error occurred during a connection to localhost:8443. > SSL peer cannot verify your certificate. > (Error code: ssl_error_bad_cert_alert) > > In firefox on windows 7 with tomcat 7 > > Here is what I did as per > http://tomcat.10.x6.nabble.com/tomcat-mutual-authentication-doesn-t-work-td2133404.html#a5018750 > > > 1. "keytool.exe" -genkeypair -keystore tomcat.keystore > > 2. "keytool.exe" -genkeypair -keystore client.keystore > > 3a. "keytool.exe" -exportcert -keystore client.keystore -file client.cert > > 3b. "keytool.exe" -importcert -keystore server.truststore -file client.cert > > 4. "keytool.exe" -importkeystore -srckeystore client.keystore > -srcstoretype jks -destkeystore client.p12 -deststoretype pkcs12 > > "keytool.exe" -list -keystore tomcat.keystore > Enter keystore password: > > Keystore type: JKS > Keystore provider: SUN > > Your keystore contains 1 entry > > mykey, Jun 16, 2014, PrivateKeyEntry, > Certificate fingerprint (SHA1): > E7:5E:F8:1F:BC:24:96:E2:D6:87:BF:3A:94:CD:53:14:C6:0E:A6:A5 > > "keytool.exe" -list -keystore server.truststore > Enter keystore password: > > Keystore type: JKS > Keystore provider: SUN > > Your keystore contains 1 entry > > mykey, Jun 16, 2014, trustedCertEntry, > Certificate fingerprint (SHA1): > 81:C9:BF:20:E9:D8:18:7E:E5:F7:54:B1:68:0B:00:65:DB:13:8E:52 > > > My server.xml enteries are > > keystoreFile="path\tomcat.keystore" keystorePass="tomcat" > truststorefile="path\server.truststore" truststorepass="client" > maxThreads="1500" scheme="https" secure="true" clientAuth="true" > sslProtocol="TLS" /> > > My tomcat user enteries are > > password="null" roles="admin"/> > > > But could not get the resolution > > Please help urgent.
Two Way authentication - Urgent Help
Getting An error occurred during a connection to localhost:8443. SSL peer cannot verify your certificate. (Error code: ssl_error_bad_cert_alert) In firefox on windows 7 with tomcat 7 Here is what I did as per http://tomcat.10.x6.nabble.com/tomcat-mutual-authentication-doesn-t-work-td2133404.html#a5018750 1. "keytool.exe" -genkeypair -keystore tomcat.keystore 2. "keytool.exe" -genkeypair -keystore client.keystore 3a. "keytool.exe" -exportcert -keystore client.keystore -file client.cert 3b. "keytool.exe" -importcert -keystore server.truststore -file client.cert 4. "keytool.exe" -importkeystore -srckeystore client.keystore -srcstoretype jks -destkeystore client.p12 -deststoretype pkcs12 "keytool.exe" -list -keystore tomcat.keystore Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry mykey, Jun 16, 2014, PrivateKeyEntry, Certificate fingerprint (SHA1): E7:5E:F8:1F:BC:24:96:E2:D6:87:BF:3A:94:CD:53:14:C6:0E:A6:A5 "keytool.exe" -list -keystore server.truststore Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry mykey, Jun 16, 2014, trustedCertEntry, Certificate fingerprint (SHA1): 81:C9:BF:20:E9:D8:18:7E:E5:F7:54:B1:68:0B:00:65:DB:13:8E:52 My server.xml enteries are My tomcat user enteries are But could not get the resolution Please help urgent.
Re: Decoded URL set on asynchronous request
2014-06-09 17:38 GMT+04:00 Konstantin Kolinko : > > (...) > > Servlet API javadocs: > http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html > > It does not mention explicitly whether getRequestURL() returns a > non-decoded or decoded URL, > > but as our implementation in o.a.c.connector.Request does > "url.append(getRequestURI());" I would say that it is expected to > return a non-decoded String. > To correct myself here, several notes 1. getRequestURI() returns just what was sent by the client. It is just raw bytes. There is no saying that it is url-encoded. It is just that clients do url-encode it to pass it on the wire. 2. In case of RequestDispatcher.forward(..) the javadoc for getRequestURL() says that it "must reflect the path used to obtain the RequestDispatcher". The "history" section of Servlet 3.1 spec (section A.7.3 page 225/240) mentions when that method was clarified by adding that requirement. There is no such requirement for getRequestURI() method. Should its value be updated on forwards? The implementation in Tomcat does update requestURI on forwards. 3. If getRequestURL() has to perform an url-encoding of forwarded path, it should be noted that url-encoding procedure yields different results depending on the character encoding used to convert chars to their byte codes. The usual convention nowadays is to use UTF-8, though I would say that it would be more correct to ask the Connector for its URIEncoding setting. (So that when browser follows a redirect and sends its next request, the URL has to be correctly parsed by the Connector. I mean that getRequestURL() method is documented as "for creating redirect messages".) In the OP case the trouble was with space characters (%20). > > On the other hand I think ServletContext.getRequestDispatcher() > expects a decoded URI, as it expects a "resource path", not a > %-encoded URI. > > I think it is OK to file an issue into Bugzilla. > Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
