RE: Undefined symbol with native 1.1.33 and RHEL5
> Jesse, > > On 6/4/15 12:49 PM, Christopher Schultz wrote: > > Jesse, > > > > On 6/4/15 11:43 AM, Jesse Defer wrote: > >> I am getting the following error from native on Tomcat startup: > >> /usr/local/java/latest7/bin/java: symbol lookup error: > >> /usr/local/apr/lib/libtcnative-1.so.0.1.33: undefined symbol: > >> SSL_CTX_clear_extra_chain_certs > > > >> SSL_CTX_clear_extra_chain_certs does not appear to be part of the > >> RHEL5 distributed OpenSSL 0.9.8. There are no compile > >> warnings/errors from native, > > > >> RHEL5.11 Tomcat 6.0.44 APR 1.5.1 > > > >> Have the OpenSSL version requirements changed? > > > > Are you sure your compile-time and run-time versions of OpenSSL are > > the same? > > > > I'm having trouble finding minimum-version information about > > SSL_CTX_clear_extra_chain_certs. Can you check in openssl.h (and > > whatever else it includes on your system) to see if that function is > > defined? > > > > On my Mac, I've got 0.9.8zd plus 1.0.1j and 1.0.2a. Only the 1.0.1 and > > 1.0.2 versions have that function defined, but it's actually a macro > > pointing to SSL_CTX_ctrl with some default parameters. > > > > So I'm surprised that you're seeing > > SSL_CTX_clear_extra_chain_certs being called a "symbol", since the > > compiler should be replacing it with something else. Well, if it's not > > defined at all, it might assume it's a function with no prototype and > > just assume that at runtime things will work-out. > > Looks like not. > > > > Re-check your compiler logs: I think you'll find a warning about an > > unresolved symbol. Probably with the linker, too. But it will only be > > a warning, depending upon the compiler flags. > > > > sslutils:245 uses that macro: > > > > SSL_CTX_clear_extra_chain_certs(ctx); > > > > Perhaps we need to add a version-check around that, and then define > > the macro as OpenSSL does if necessary. > > > > Can you add a Bugzilla issue for this? Feel free to reference this > > mailing list thread. > > > > -chris > > In the meantime, can you throw this into tcnative.h at the bottom, and re- > build everything? > > #define SSL_CTX_clear_extra_chain_certs(ctx) \ > SSL_CTX_ctrl(ctx,SSL_CTRL_CLEAR_EXTRA_CHAIN_CERTS,0,NULL) > > See if that works for you. > > - -chris It compiled and it doesn't throw the missing symbol errors anymore. Everything seems to work but I will continue to test. I had to add (pulled from openssl 1.0.1): #define SSL_CTRL_CLEAR_EXTRA_CHAIN_CERTS 83 Jesse
Re: systemd tomcat script for Linux EL7
That looks OK, but I would suggest the following. Put all the real stuff in a standard bash script with 3 parameters start, stop, restart- pretty much like the OLD system 5 way fo doing things.This has the advantage of allowing you to add other things you might want to add AND executing the script as root is pretty obvious. (I needed to add starting an LibreOffice server and a few other daemons to get that going). Embed the catalina start stop in that script.The just make the systemd script VERY SIMPLY call your standard above start/stop script. e.g. my script name is S95tomcat and the systemd entry is trivial. here is tomcat.service: [Unit] Description=The Jakarta Apache/Tomcat Server After=network.target [Service] Type=forking ExecStart=/local/bin/S95tomcat start ExecReload=/local/bin/S95tomcat restart ExecStop=/local/bin/S95tomcat stop [Install] WantedBy=multi-user.target On Thursday, June 4, 2015 9:31 PM, Dale Ogilvie wrote: Hi all, I am trying to put together a systemd script for an install of the current binary release tomcat7. Follows my current best effort, cobbled together from the (RH)EL7 packaged version and some googling... I am trying to use the unadulterated tomcat up/down scripts from the binary release. Any suggestions as to how this might be improved? I'm not sure if I am using the right service type here, based on what catalina.sh is doing under the hood. That said, it seems to work. Thanks Dale follows apache-tomcat.service # Systemd unit file for apache-tomcat # [Unit] Description=Apache Tomcat Web Application Container After=syslog.target network.target [Service] Type=forking PIDFile=/var/run/apache-tomcat/apache-tomcat.pid ExecStart=/opt/apache-tomcat/bin/startup.sh ExecStop=/opt/apache-tomcat/bin/shutdown.sh SuccessExitStatus=0 User=apache-tomcat Group=apache-tomcat [Install] WantedBy=multi-user.target * follows setenv.sh commented out sections removed # Where your java installation lives JAVA_HOME="/usr/java/latest" # Where your tomcat installation lives CATALINA_BASE="/opt/apache-tomcat" CATALINA_HOME="/opt/apache-tomcat" CATALINA_OUT="/var/log/apache-tomcat/catalina.out" JASPER_HOME="/opt/apache-tomcat" CATALINA_TMPDIR="/opt/apache-tomcat/temp" CATALINA_OPTS="-Xms1G -Xmx2G" # What user should run tomcat TOMCAT_USER="apache-tomcat" # Run tomcat under the Java Security Manager SECURITY_MANAGER="false" # Time to wait in seconds, before killing process SHUTDOWN_WAIT="90" # Whether to annoy the user with "attempting to shut down" messages or not SHUTDOWN_VERBOSE="false" # Set the TOMCAT_PID location CATALINA_PID="/var/run/apache-tomcat/apache-tomcat.pid" # Connector port is 8080 for this tomcat instance CONNECTOR_PORT="8080" - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Included CDI-enabled Servlet Fails with ContextNotActiveException: WELD-001303
Hi, I have a servlet that uses CDI beans. I am using weld 2.2.12.Final as the CDI implementation and am running on Tomcat 7.0.62 on Windows x64. Stand-alone, this servlet works as expected. I can access it using my browser and it produces the expected output. I have a second servlet in a different web app that uses a RequestDispatcher to include the output from the CDI servlet. When included in this manner, the CDI servlet produces output up to the point at which it accesses an @RequestScoped bean. When the request scoped bean is accessed, the CDI servlet fails with the following exception: |org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contextsfor scope type javax.enterprise.context.RequestScoped at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:708) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90) ... | I posted a detailed description of the problem at Stack Overflow, but haven't found a solution yet: https://stackoverflow.com/questions/30622162/included-cdi-enabled-servlet-fails-with-contextnotactiveexception-weld-001303 It looks to me like the Weld request listener that sets up the application context is perhaps not being fired. Note that I can't use a request dispatcher forward, as my application aggregates the output from several servlets. Also, the application works correctly on IBM WebSphere Application Server (using the native WAS CDI support rather than Weld), but I need the application to work on Tomcat. Since the app works on WebSphere, I am inclined to think that I might be dealing with either a Weld or a Tomcat limitation. Could someone please I help me understand what I need to do on Tomcat to successfully use a RequestDispatcher to include the output of a CDI servlet that is external to my web app? thanks, Scott
