Re: New warning at Tomcat Startup
On Fri, Sep 5, 2014 at 12:57 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-09-04 19:55 GMT+04:00 Martin Knoblauch knobis...@gmail.com: It seems it happens between 7.0.42 and 7.0.47. I would bisect, but cannot find any tarballs between those two releases. Those versions have been votes as broken and not released. OK. Fair enough :-) In the meantime I solved the issue: adding absolute-ordering / to WEB-INF/web.xml silenced the warnings. As this is recommended anyway, I am fine with it. From all the jars that we ship, only one has Depends-On lines: jcchart363J.jar. It seems to be notorious for problems and I will check with our product development whether we can remove it completely. Adding it to the skip list in catalina.properties also removes the messages. But yes, the jar contains duplicate Depends-On lines, all in AFAICT separate Name: section (all separated by blank lines). There must be still something added after 7.0.42 that throws the warnings. But that may actually be the right behavior. Who am I to tell :-) Thanks for the support Martin -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
WebSocket strack trace when browser tab closed
When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: Connection reset by peer at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:243) at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:487) at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:441) at org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:324) at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:270) at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:116) at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:54) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:194) at org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:203) at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:92) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:609) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1736) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1695) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Connection reset by peer at org.apache.tomcat.websocket.FutureToSendHandler.get(FutureToSendHandler.java:102) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:238) ... 16 common frames omitted Caused by: java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at sun.nio.ch.IOUtil.write(IOUtil.java:65) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:128) at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:185) at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWriteInternal(NioServletOutputStream.java:94) at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWrite(NioServletOutputStream.java:61) at org.apache.coyote.http11.upgrade.AbstractServletOutputStream.writeInternal(AbstractServletOutputStream.java:153) at org.apache.coyote.http11.upgrade.AbstractServletOutputStream.write(AbstractServletOutputStream.java:121) at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:94) at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:81) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:393) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:287) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:233) ... 16 common frames omitted
Re: web.xml authentication and Tomcat Realm
On Thu, Sep 4, 2014 at 8:02 PM, Dalecki, Janusz jdale...@tycoint.com wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, 5 September 2014 12:03 AM To: Tomcat Users List Subject: Re: web.xml authentication and Tomcat Realm -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Janusz, On 9/4/14 2:30 AM, Dalecki, Janusz wrote: -Original Message- From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] Sent: Thursday, 4 September 2014 3:29 PM To: Tomcat Users List Subject: Re: web.xml authentication and Tomcat Realm On 4. September 2014 05:35:42 MESZ, Dalecki, Janusz jdale...@tycoint.com wrote: Hi, I am just wondering whether somehow I can use web.xml login-config/ to point to the Tomcat JDBC Realm that I am using. Are those two completely disjoint or I can link them together. They are disjoint. web.xml is for the developer who has (almost) no knowledge of the context (environment) in which his application will run. context.xml (or equivalents) is the tool for the administrator to provide that knowledge to the application. It might be silly question, but if I use web.xml login-config element – where do I specify password? I am probably missing something. The Realm takes care of the credentials. For a DataSourceRealm of JDBCRealm, the usernames and passwords are stored in a relational database. For other Realms, the credentials are stored in other places. For instance, if you use a MemoryRealm, the passwords are typically stored in an XML file in CATALINA_BASE/conf/tomcat-users.xml. Using a MemoryRealm isn't really a good idea for a production system for a number of reasons. (Note that using JDBCRealm will give you terrible performance: use a DataSourceRealm instead with a JNDI DataSource.) You really need to read this: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUCHEbAAoJEBzwKT+lPKRYlbsP/jPqVIkl3MhZJdmswWD5AL5y proOErqB/ytVoT2TvvwSb4oXUe0NI/BqmbCCXW7oaExljcw7Dqvtbt+PH0oW5uAu G8BXAq2IhJrfrufz1pDZzxx/zWqlQZ1xTVwlKkdYHknx/0jv4IfwUsMZNwz9OeOa uAJAckflhSPY/qI3/pD9HNoFpZoUS/UEpbmxIeSrjf7jsTJdWI+64xuFXsv6d/1D /NbYpaf+AznqpSuKogjNy/HTb6B1cl8NESJyB+umwxSn7H0bO07GX+CRAzpFpQxt Li48qkFrMMZBvTGtQEZmMw+wyOQ28gQ9lLQFs1h2QAuFCGouoW59jY96NJzSuuu1 cSFGlUNcG4m9oW0zCNlpB0/YD0IODY13QVPPSqVFJhApg6m9uG4os/jb/aMNQ8xo 6Hv6ri2xYGOCC6f/lhaOR7nSdeFEUSin+XHkF1y6xCBNmBSaZMjDbTt2xga134Fl dis1i3zEd7W+EZjiY/jerpRWMGuE9oR1g+PbYbVSnU/Ts+sjqvZflJmtgE+MdJ8a AHPcX0x+8PfPlYBs6yzm0nAHxxqiQdijzzBCwi8KZr7UQPWCtUaHIjmaljUJ+eST 9U3Ue/ePrdyiJm18p7TmfeKI+aDR8g09oadbb9fOKCUz3DyLRH7Qo9uLmBCzZOIt 3LJeFneb/hJ25+opQa7X =fCiU -END PGP SIGNATURE- Hi, Sorry I need to explain my problem more clearly. I have put JDBCRealm configuration with all details in the META-INF folder: Realm className=org.apache.catalina.realm.JDBCRealm driverName=org.postgresql.Driver connectionURL=jdbc:postgresql://localhost:5432/df_Scheduler?user=postgresamp;password=admin userTable=users userNameCol=userName userCredCol=password userRoleTable=user_roles roleNameCol=roleName/ In my web.xml I have login-config element and security constraint as follows: security-constraint web-resource-collection web-resource-nameAdmin/web-resource-name url-pattern/auth/*/url-pattern /web-resource-collection auth-constraint role-nameSYSADMIN/role-name /auth-constraint /security-constraint security-role role-nameSYSADMIN/role-name /security-role login-config auth-methodBASIC/auth-method !--realm-nameAdmin/realm-name-- /login-config I have defined users and passwords as explained in the TOMCAT Realm Configuration – HOW TO. When I ask for a page */auth/* the user/password dialog box pops up and no matter what I type in in user name field and password field and pops up again for ever. What am I doing wrong? 1.) Do you have users defined in the database? Do you have the proper roles assigned to those users? 2.) Do you see any errors listed in the log? Either at startup or when you attempt to login? 3.) For more info, you could try increasing the log level for the org. apache.catalina.realm package. Dan
Re: WebSocket strack trace when browser tab closed
On 05/09/2014 13:46, Rossen Stoyanchev wrote: When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. Tomcat version? Mark java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: Connection reset by peer at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:243) at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:487) at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:441) at org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:324) at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:270) at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:116) at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:54) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:194) at org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:203) at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:92) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:609) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1736) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1695) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Connection reset by peer at org.apache.tomcat.websocket.FutureToSendHandler.get(FutureToSendHandler.java:102) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:238) ... 16 common frames omitted Caused by: java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at sun.nio.ch.IOUtil.write(IOUtil.java:65) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:128) at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:185) at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWriteInternal(NioServletOutputStream.java:94) at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWrite(NioServletOutputStream.java:61) at org.apache.coyote.http11.upgrade.AbstractServletOutputStream.writeInternal(AbstractServletOutputStream.java:153) at org.apache.coyote.http11.upgrade.AbstractServletOutputStream.write(AbstractServletOutputStream.java:121) at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:94) at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:81) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:393) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:287) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:233) ... 16 common frames omitted - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: web.xml authentication and Tomcat Realm
Hey Janusz, On Thu, Sep 4, 2014 at 8:02 PM, Dalecki, Janusz jdale...@tycoint.com wrote: Follow the link Chris provided. It will give you some ideas about how Realms work. (Note that using JDBCRealm will give you terrible performance: use a DataSourceRealm instead with a JNDI DataSource.) You really need to read this: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html - -chris Hi, Sorry I need to explain my problem more clearly. I have put JDBCRealm configuration with all details in the META-INF folder: Realm className=org.apache.catalina.realm.JDBCRealm driverName=org.postgresql.Driver connectionURL=jdbc:postgresql://localhost:5432/df_Scheduler?user=postgresamp;password=admin userTable=users userNameCol=userName userCredCol=password userRoleTable=user_roles roleNameCol=roleName/ Where specifically did you put in this Realm information? Is it YourApp.war/META-INF/context.xml file? What this configuration means is that your users/passwords for authentication and users/roles for authorization are going to be stored in the JDBCRealm, i.e. in your Postgres database called df_Scheduler, more specifically in your users table and in your user_roles table. You can connect to your database and see specifically what users and roles are defined in these tables, e.g. psql -U postgres -W -h localhost df_Scheduler (prompted for password) SELECT userName,password FROM users; Should give you all the users and their passwords, e.g. janusz / mypassword1 john / mypassword2 ... SELECT * FROM user_roles; Should give you all users and their respective roles, one combo per row/record, e.g. janusz TPA_USER janusz TPA_ADMIN janusz SYSADMIN john TPA_USER ... You need to inspect and see that the actual username/password combinations actually exist in the database. In my web.xml I have login-config element and security constraint as follows: security-constraint web-resource-collection web-resource-nameAdmin/web-resource-name url-pattern/auth/*/url-pattern /web-resource-collection auth-constraint role-nameSYSADMIN/role-name /auth-constraint /security-constraint security-role role-nameSYSADMIN/role-name /security-role login-config auth-methodBASIC/auth-method !--realm-nameAdmin/realm-name-- /login-config What this configuration in YourApp.war/WEB-INF/web.xml file does, is that it configures that all requests made to /auth/*, e.g. http://blahblah/YourApp/auth/ So, all these requests will need to know who makes the call (Authorization) and once you login, logged user needs to have SYSADMIN role defined in the Realm. Also, the login-config mandates BASIC login mechanism, i.e. window popup with username/password. So, once you make the first request, your browser will popup authentication window asking you for username and password, it would have said Admin but you commented out the realm-nameAdmin/realm-name in the login-config configuration. Once you submit username/password it will try to authenticate against whatever Realm was setup (I will get to this point later). If the username/password combination does not match, it asks again, and again, and again, until you press ESC, which you will get redirected to 401 (Not Authenticated) page. Next, if the username/password combination was successful, the user is Authenticated, next - it needs to be Authorized, i.e. it needs to be associated with the Role defined in the auth-constraint, e.g. SYSADMIN. So, whoever logged in - they need to have SYSADMIN role in order to get to the resources (/auth/* pages). If they don't have required role - the server would return 403 (Forbidden) page. If they do have the required role - the server would proceed with the request (i.e. happy path). I have defined users and passwords as explained in the TOMCAT Realm Configuration – HOW TO. When I ask for a page */auth/* the user/password dialog box pops up and no matter what I type in in user name field and password field and pops up again for ever. What am I doing wrong? Now, there are two things that could be the reason of the behaviour you described: (1) The realm defined for this application is ignored or not setup properly. The easiest test would be to change the password, and try restarting the server and try logging in again. See if the console/logfile shows any errors. If it does, you will know your Realm configuration is being read. (That's a good thing, you know your configuration is being read!) If you don't observe any errors, and you get the same type of behaviour, that means your realm configuration is being ignored, and you are using the default realm as defined in TOMCAT_HOME/conf/server.xml file, e.g. org.apache.catalina.realm.UserDatabaseRealm with defined resource UserDatabase. Out of the box Tomcat
Re: WebSocket strack trace when browser tab closed
On Fri, Sep 5, 2014 at 9:33 AM, Mark Thomas ma...@apache.org wrote: On 05/09/2014 13:46, Rossen Stoyanchev wrote: When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. Tomcat version? 7.0.54 but also occurs with 8.0.12
Re: WebSocket strack trace when browser tab closed
On 05/09/2014 15:06, Rossen Stoyanchev wrote: On Fri, Sep 5, 2014 at 9:33 AM, Mark Thomas ma...@apache.org wrote: On 05/09/2014 13:46, Rossen Stoyanchev wrote: When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. Tomcat version? 7.0.54 but also occurs with 8.0.12 Thanks. I see what is going on. The IOException is handled but not when it is wrapped with ExecutionException. We should be able to fix that... Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebSocket strack trace when browser tab closed
On 05/09/2014 15:17, Mark Thomas wrote: On 05/09/2014 15:06, Rossen Stoyanchev wrote: On Fri, Sep 5, 2014 at 9:33 AM, Mark Thomas ma...@apache.org wrote: On 05/09/2014 13:46, Rossen Stoyanchev wrote: When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. Tomcat version? 7.0.54 but also occurs with 8.0.12 Thanks. I see what is going on. The IOException is handled but not when it is wrapped with ExecutionException. We should be able to fix that... I take that back. Tomcat is wrapping the ExecutionException in an IOException and is handling the IOException. Tomcat isn't logging this - the Endpoint is in the onError() method. This looks like an application question rather than a Tomcat one. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebSocket strack trace when browser tab closed
On Fri, Sep 5, 2014 at 10:26 AM, Mark Thomas ma...@apache.org wrote: On 05/09/2014 15:17, Mark Thomas wrote: On 05/09/2014 15:06, Rossen Stoyanchev wrote: On Fri, Sep 5, 2014 at 9:33 AM, Mark Thomas ma...@apache.org wrote: On 05/09/2014 13:46, Rossen Stoyanchev wrote: When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. Tomcat version? 7.0.54 but also occurs with 8.0.12 Thanks. I see what is going on. The IOException is handled but not when it is wrapped with ExecutionException. We should be able to fix that... I take that back. Tomcat is wrapping the ExecutionException in an IOException and is handling the IOException. Tomcat isn't logging this - the Endpoint is in the onError() method. This looks like an application question rather than a Tomcat one. Ok, that wasn't immediately obvious. Thanks for the quick response. I'll have a look.
Re: Share point integration
NK V wrote: Hi All I have a requirement where I need to access share point 2013 site in one of the site developed on Tomcat Server. Site on Tomcat server has its own authentication mechanism and share point 2013 is authenticated via LDAP. Any ideas on how to get the share point website into a website running on Tomcat. Any help in this regard is appreciated. As phrased, your question does not make very clear what exactly you want to do, nor how this is a real Tomcat question. Both Tomcat and Sharepoint are webservers, independent of one another. Accessing Sharepoint in Tomcat is a bit confusing. Or is your question more about the authentication ? Again, it's not very clear what you want, and/or what you want from this list. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.UnsatisfiedLinkError in Tomcat 8.0.11 and SPDY [broken tcnative 1.1.x?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 9/4/14 6:20 PM, Konstantin Kolinko wrote: 2014-09-04 20:06 GMT+04:00 rolandl...@web.de: Hello, I have this error configuring SPDY in Tomcat 8.0.11 in RHEL Linux 6.4 (64bit). Everything works fine removing npnHandler attribute for SPDY. Sep 04, 2014 9:30:02 AM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.31 using APR version 1.3.9. Sep 04, 2014 9:30:02 AM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. .. Sep 04, 2014 9:30:55 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [http-apr-xx.xx.xx.xx-443] java.lang.UnsatisfiedLinkError: org.apache.tomcat.jni.SSLExt.setNPN(J[BI)I at org.apache.tomcat.jni.SSLExt.setNPN(Native Method) Your copy of Tomcat-Native library was compiled without NPN support and does not have the above method. It appears that the 1.1 branch of tcnative doesn't have any of the SSLExt.java/sslext.c methods at all: src/sslext.c does not even exist. It looks like this was added in the trunk but nobody ever bothered to back-port it to the 1.1 branch (which is of course what everybody actually uses). It also looks like there are a bunch of functions that are defined when HAVE_OPENSSL is defined, but have no definition otherwise. This means that those other methods would end up throwing UnsatisfiedLinkError if they are called. They all have to do with SSL and therefore make no sense being called under those conditions, but it's always nice to have a method exist when the Java code expects it to exist ;) The obvious solution is to back-port src/sslext.c to the 1.1 branch but I'd like someone who was involved in working on that stuff (Costin; markt only made whitespace changes to make checkstyle happy) to comment before I do it. Roland, would you be willing to patch your tcnative source and re-try? The patch should be trivial (new file). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUChu2AAoJEBzwKT+lPKRYdjUP/0hGzwOyg58oJT/oo3uExEYN jUokpssQIu0e5bXfldErHFZD6q1Dm50Fg8EmONTDEBqaE5UbKEsQ/bi676X2OLA7 a1/9zUQyxQ0ZFkYX0yexI2mVzRWJclDj0pT3f2kvW3LR5hALO37yMyDaAjiSpDoB gEW2yqKEa2Cor6/X6/l92zg30iXcy1LyOCo3JBS30YRyRoKrXACx5aQz+2DyQ9UD SUSgLvq42urEVzOp7eyx0juQ2wjg1s3+rS4YqkGJxh+aQ2zqVglOIzmoA8xB2TiN dwrMdsYNkysPCHPI9rWm1SlZZiRG4Rge83u23Gq0mi/PZbuxeI4ggfa4cghbKpKd nQypwuLenwAp7Y/zTNaTbWShcHOedM2cw5TsBoQFndilrHYYt9xu/nu62cHddkqB qTCTm9PIrWRgJT8SilOqs3RetIeoa3+pBGct6bnKFDthsENxE7bQtfQtDiWil9va 36czpUPtAShz6e63I0AKLptSZR+jj5SIiH/ZnIoHMCL8pzqq/ELaofrB1tYI/eah 36rJ1I00tvfiob8dZ0p5mAuPzK5kr3WwXNW8IkeyYO09hneEfChLfoC3pD+z5G48 5hYmPsHK2gxdSEMeokFa86D56Mbpo6pwwSEj0yhMqE9QT4X2nhob0BMJ/nB8GWeQ uJqotCJsSf2xZsjCTufa =75Ok -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How a script can determine latest version of Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/4/14 2:31 PM, Mark Thomas wrote: On 04/09/2014 19:18, Geoff Meakin wrote: The current version mirrors link might help you eg: http://mirrors.ukfast.co.uk/sites/ftp.apache.org/tomcat/tomcat-7/ There are times (normally just after a release) when multiple versions will show up there. In those cases, one could simply read all versions available and take the biggest number, no? Could our release procedure include popping the released version number into a file somewhere like WEBROOT/version.txt? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUChxgAAoJEBzwKT+lPKRYw4EP/3to43zu14AhVX5hA0BgjQlv sWQrBzmWzKxtmub8qkuiY0gGwjpWzIBnszsmG2qAzFe3sMeLuGHBJbuj5QTGqbeM t1fhY37rz41j+Ot11x2SwpqRd4Fs/+j38yhda5cEYT750H2JJsoP5GamzLfDPDnn w5lblDlEWaFPaNQSBk4PN8xWGxoOgWL9wDa3L52kYKCPUZxN40WjOtEhZCfo3exW RtKn9U/2d7ne8TFg/L4Nl591fi9LA0l1Y0X7EM7amScp7yCS5xAd2uSD1xQpiiII 8NsRjBuOylFQl/gv3udqU/0ck1Y8jsbyWmuuNynERDd7sbuHlHdIgDqhS17V75+w AD5rwXX4CJDmgysBHxxKJgDGx89+aUJSqPW5MgsOn6Km+Gpa4BOveEVSbpHvuWO6 fF2sbq3eDsRS/+tdGt2jAacp+qiC/oPUGgimEWmX4njCzNObH5wTRy8ZySx37M/6 YtxjyJzCuQIbhQrlQ51qCap1YjMAk+vYc5QEsV6POwjEfieUEVX+5k6OKWq9cIOC rcuYf6vRtb63T91KKg0lfJHy+Jk1Hoa5HA/7UYj0ZPA0h/IwVR2yZJ9oQTYkOjH0 R1UjwIe7DnztIr/DTX+URTHfL9nv92ngziCyMQOlBaG8+sTn/5lBYU3ih3ialmOe SNGhmvMP5h121mW/Llay =lkoQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How a script can determine latest version of Tomcat
On 05/09/2014 21:26, Christopher Schultz wrote: Mark, On 9/4/14 2:31 PM, Mark Thomas wrote: On 04/09/2014 19:18, Geoff Meakin wrote: The current version mirrors link might help you eg: http://mirrors.ukfast.co.uk/sites/ftp.apache.org/tomcat/tomcat-7/ There are times (normally just after a release) when multiple versions will show up there. In those cases, one could simply read all versions available and take the biggest number, no? Indeed but that makes the script a little more complicated. Could our release procedure include popping the released version number into a file somewhere like WEBROOT/version.txt? Sure. If the folks here can agree on a file format then it can certainly be created and maintained. Some things to keep in mind: There are typically 3 major versions in development at any one time. Currently it is 6.0.x, 7.0.x and 8.0.x. That will probably increase to 4 for the first few 9.0.x releases. We have RCs, alphas, beta and stable releases. milestone releases have also been discussed. During the early days of a new major version there may well be an older beta release as well as a newer alpha release available (we make the most recent and the most stable recent release so you could have 8.0.1.beta and 8.0.2.alpha) We might release 8.1.x along side 8.0.x for a while (the same goes for any major version). Whatever scheme is devised, it needs to handle all of these possibilities and the few I am sure I have forgotten. -chris - 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: How a script can determine latest version of Tomcat
2014-09-04 22:46 GMT+04:00 Daniel Mikusa dmik...@pivotal.io: On Thu, Sep 4, 2014 at 1:48 PM, David P. Caldwell da...@code.davidpcaldwell.com wrote: I have a small program that downloads and installs an arbitrary version of Tomcat, using the API provided by Apache to select the proper mirror, and so forth. The script currently takes the Tomcat version as an argument. My script provides a default (which in my case is the latest version of Tomcat 7), but I have to manually update that default whenever I notice a new version has been released. What would be the best way for the script itself to determine the latest available version? Obviously I would give points for easy and points for robust, knowing that those two things might be in conflict. I can think of many horrifying ways to do it: * loop through integers starting with the last known version, attempting to download 7.0.x, until getting a 404 * scraping and parsing the HTML at http://archive.apache.org/dist/tomcat/tomcat-7/, which I expect is rather stable I did this recently for Tomcat 8. Here's the command I used, which works on my Mac. LATEST_VERSION=$(curl -s http://tomcat.apache.org/download-80.cgi | grep h3 id=\8.0. | xpath '/h3/text()' 2/dev/null) A slight variation works on Ubuntu if you install xpath. LATEST_VERSION=$(curl -s http://tomcat.apache.org/download-80.cgi | grep h3 id=\8.0. | xpath -e '/h3/text()' 2/dev/null) I'm sure there are other ways to do it, this was just the first one I put together that worked for me. There also exist the following XML file.and the following page http://tomcat.apache.org/doap_Tomcat.rdf http://tomcat.apache.org/whichversion.html So my challenge isn't coming up with *a* way to do it, but coming up with the best way. I would say that download-nn.cgi is the most reliable from the above ones. A version cannot be released without updating the download page. But there are the following concerns: - server generates the page dynamically, (but as a bonus it gives you a list of best mirrors for your IP address) - stability of markup. (I would prefer to parse a download link, instead of h3 header tag) If those are of concern, then the doap_Tomcat.rdf XML file would be a better source of information. Regarding parsing the download page of a mirror (and archive,apache.org is one of those mirrors): - An announcement and tomcat.a.o site update are usually postponed by a day to let the mirrors sync. If you parse the page of a mirror, you may get version number that have already been released to mirrors, but have not yet announced. The version may be absent from other mirrors. - If you parse the page of a mirror and there are several Tomcat versions available (e.g. N and N-1), and your user chooses version N-1. It allows you to download the version N-1 from the mirror instead of archive.a.o site. By the way, do you verify md5 hash or PGP signature of the files downloaded from mirrors? * loop through integers starting with the last known version, attempting to download 7.0.x, until getting a 404 There have been several reports of mirrors that did not respond with proper 404, but instead produced a redirection to some advertisement page. Such behaviour is against ASF mirror policies, and those mirrors have been unlisted y ASF infrastructure team, but it may happen again. Sometimes a MiTM responds with a redirect (e.g. a mobile operator may do so when there are some problems with your account). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
