Re: Zero downtime deployments

[Neill Lima]

Hello Jason,

This approach of using httpd in front of 2+ Tomcats via AJP works well in
my company. There is a bit of config necessary at httpd level so httpd is
aware of all the Tomcats and also Tomcat config needs to be set to listen
to AJP port instead of default port but it is not rocket science.

This facilitates the deployment of nodes sequentially with no downtime. Of
course, there is a shared session server to take care the sessions are not
lost when Tomcats flip up and down.

Reply in pvt if you need help setting up this.

Thanks,

Neill

On Thu, Dec 3, 2015 at 12:08 AM, Jason Britton  wrote:

> Thank you Christopher, reading now and we'll see if I can swing the
> conference :)
>
> On Wed, Dec 2, 2015 at 4:00 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Jason,
> >
> > On 12/2/15 4:07 PM, Jason Britton wrote:
> > > I was looking for information for how those on the list achieve zero
> > > downtime deployments of their tomcat hosted web applications.  I
> imagine
> > > this can be achieved in a variety of ways, but would love to hear what
> > > works for you.  In our current environment we front multiple tomcat
> > > instances with apache httpd, each tomcat instance hosting one or more
> > > unique web apps.  In order to support this effort we do have the
> > resources
> > > where we could spin up multiple tomcat instances to serve requests for
> a
> > > single application.  I know there is mod_proxy_balancer available for
> > > httpd, and I understand starting with tomcat 7 there is support for
> > > parallel deployment of versioned wars, and tomcat also supports
> > > clustering.  I'm just unsure of what approach I should start digging
> into
> > > and would very much appreciate any of your experiences.  The servers
> > we'll
> > > be rolling out will be using the latest versions of tomcat 8 and apache
> > > httpd 2.4.  Thanks for any insights!
> >
> > Check this out:
> >
> >
> http://people.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20Tomcat%20with%20mod_jk.pdf
> >
> > Start on slide/page 41.
> >
> > Then come to ApacheCon NA 2016 and discuss it!
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: ClientAbortException: java.io.IOException: Failed to send AJP message

[Neill Lima]

How long does it take? It could be some sort of timeout, maybe.

On Mon, Oct 26, 2015 at 3:28 PM, Yogesh Patel 
wrote:

> In our case user is downloading the document and got message like "document
> is deleted or moved" and tomcat has log like "ClientAbortException:
> java.io.IOException: Failed to send AJP message"
>
> On 26 October 2015 at 19:48, Rallavagu  wrote:
>
> > This usually means that "client" has disconnected before the request
> could
> > be completed. Generally, this might happen when a user navigates away
> from
> > a web page before it is completely rendered. You might want to gather
> more
> > information to understand this better.
> >
> > On 10/26/15 7:15 AM, Yogesh Patel wrote:
> >
> >> In out application we are getting following error:
> >>
> >> org.apache.catalina.core.StandardWrapperValve.invoke:Line 211 -
> >> ClientAbortException: java.io.IOException: Failed to send AJP message
> >>
> >>
> >>
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
>
> --
> *Thanks & Regards,*
>
> * Yogesh Patel*
>

Re: How to upgrade Tomcat

[Neill Lima]

I love this page: http://tomcat.apache.org/migration-7.html#Upgrading_7.0.x

Result:

http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/conf/catalina.policy?diff_format=hr1=1445362r2=1678231

On Mon, Jun 8, 2015 at 3:00 PM, David kerber dcker...@verizon.net wrote:

 On 6/8/2015 8:58 AM, Akbar Thanakalacheruvu wrote:

 Hi

 How to upgrade Tomcat from 7.0.37 to 7.0.62 ? Are there any instructions
 or document for the same?


 If you are using a standard installation from the ASF, then just install
 the newer version over the old one and test your app.



 Thanks for the help in advance.

 -Akbar

 This message and any attachments thereto contain information that may be
 privileged, confidential or otherwise protected from disclosure and is the
 property of SumTotal Systems, LLC  It is intended only for the person to
 whom it is addressed.  If you are not the intended recipient, you are not
 authorized to read, print, retain, copy, disseminate, distribute, or use
 this message, any attachments thereto or any part thereof.  If you receive
 this message in error, please notify me at akb...@sumtotalsystems.com
 mailto:akb...@sumtotalsystems.com and delete all copies of this
 message and attachments.   SumTotal Systems, LLC has implemented anti-virus
 software on its computers and servers, however, it is the recipient's own
 responsibility to ensure that all attachments are scanned for viruses prior
 to usage.



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2015-0204 - FREAK vulnerability on tomcat 7.

[Neill Lima]

We would love to help but without the bare minimum description we are
unable to do so.

Sorry!

On Fri, May 15, 2015 at 2:10 PM, Penubothu, Srinivasa M 
srinivasa.penubo...@bankofamerica.com wrote:

 Hello, I am looking for help with fixing FREAK vulnerability on tomcat 7.
 I am unable to find a solution for tomcat. Any help would be much
 appreciated.

 Regards

 Srinivasa(Vasu) Penubothu

 --
 This message, and any attachments, is for the intended recipient(s) only,
 may contain information that is privileged, confidential and/or proprietary
 and subject to important terms and conditions available at
 http://www.bankofamerica.com/emaildisclaimer.   If you are not the
 intended recipient, please delete this message.

Re: File descriptors peaks with latest stable build of Tomcat 7

[Neill Lima]

Hi Andre,

If I am not wrong, if the application in question is monitored in VisualVM
through JMX (https://visualvm.java.net/) you could trigger a Force GC from
its monitoring console.

In order to do that, these startup params might be necessary in the Java
app side :

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9010
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

Thanks,

Neill

On Wed, Apr 22, 2015 at 3:02 PM, André Warnier a...@ice-sa.com wrote:

 Rainer Jung wrote:

 Am 22.04.2015 um 11:58 schrieb Thomas Boniface:

 What concerns me the most is the CLOSE_WAIT on tomcat side because when
 an
 fd peak appears the web application appears to be stuck. It feels like
 all
 its connections are consumed and none can be established from nginx
 anymore. Shouldn't the CLOSE_WAIT connection be recycled to received new
 connections from nginx ?


 Just to clarify:

 Every connection has two ends. In netstat the local end is left, the
 remote end is right. If a connection is between processes both on the
 same system, it will be shown in netstat twice. Once for each endpoint
 being the local side.

 CLOSE_WAIT for a connection between a (local) and b (remote) means, that
 b has closed the connection but not a. There is no automatism for a closing
 it because b has closed it. If CLOSE_WAIT pile up, then the idea of b and a
 when a connection should no longer be used are disparate. E.g. they might
 have very different idle timeouts (Keep Alive Timeout on HTTP speak), or
 one observed a problem that the other didn't observe.

 When I did the counting for

   Count   IP:Port ConnectionState
8381127.0.0.1:8080 CLOSE_WAIT

 the 127.0.0.1:8080 was left in netstat output, so local. It means
 the other side (whatever is the other side of the connection, likely nginx)
 has closed the connection alardy, but not Tomcat.

 And the total number of those connections:

   Count   IP:Port ConnectionState
8381127.0.0.1:8080 CLOSE_WAIT
1650127.0.0.1:8080 ESTABLISHED

 indeed sums up to the default maxConnections 1 mentioned by Chris.

 What I do not understand is, that the same connections looked at from
 nginx being the local end, show a totally different statistics:

   Count   IP:Port ConnectionState
   20119127.0.0.1:8080 SYN_SENT
4692127.0.0.1:8080 ESTABLISHED
 488127.0.0.1:8080 FIN_WAIT2
 122127.0.0.1:8080 TIME_WAIT
  13127.0.0.1:8080 FIN_WAIT1

 But maybe that's a problem to solve after you fixed the CLOSED_WAIT (or
 the 1000 limit) and redo the whole observation.

 Pretty big numbers you habe ...


 Thomas,
 to elaborate on what Rainer is writing above :

 A TCP connection consists of 2 pipes, one in each direction (client to
 server, server to client).
 From a TCP point of view, the client is the one which initially requests
 the connection.  The server is the one which accepts that connection.
 (This is different from the more general idea of server, as in Tomcat
 server.  When Tomcat accepts a HTTP connection, it acts as server; when
 a Tomcat webapp establishes a connection with an external HTTP server, the
 webapp (and by extension Tomcat) is the client).

 These 2 pipes can be closed independently of one another, but both need to
 be closed for the connection to be considered as closed and able to
 disappear.
 When the client wants to close the connection, it will send a close
 request packet on the client-to-server pipe.
 The server receives this, and knows then that the client will not send
 anything anymore onto that pipe.  For a server application reading that
 pipe, this would result in the equivalent of an end of file on that
 datastream.
 In response to the client close request, the server is supposed to react
 by not sending any more data onto the server-to-client pipe, and in turn to
 send a close request onto that pipe.
 Once these various close messages have been received and acknowledged by
 both sides of the connection, the connection is considered as closed, and
 the resources associated with it can be reclaimed/recycled/garbage
 collected etc.. (closed is like a virtual state; it means that there is
 no connection).

 But if one side fails to fulfill its part of that contract, the connection
 is still there, and it just remains there forever until something forceful
 terminates it.  And all the resources tied to that connection also remain
 tied to it, and are subtracted from the overall resources which the server
 has available to perform other tasks.
 From a server point of view, the ideal situation is when all connections
 are actually active and really being used to do something useful (sending
 or receiving data e.g.).
 The worst situation is when there are many useless connections :
 connections in some state or the other, not actually doing anything useful,
 but tying up resources nevertheless.  

Re: File descriptors peaks with latest stable build of Tomcat 7

[Neill Lima]

Hello Christopher S.,

I know it won't. I just wanted to provide insight into Andre W.'s approach.

Thanks,

Neill

On Wed, Apr 22, 2015 at 4:58 PM, André Warnier a...@ice-sa.com wrote:

 Christopher Schultz wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Neill,

 On 4/22/15 9:12 AM, Neill Lima wrote:

 If I am not wrong, if the application in question is monitored in
 VisualVM through JMX (https://visualvm.java.net/) you could trigger
 a Force GC from its monitoring console.


 You can do this, but it won't close any CLOSE_WAIT connections.
 Tomcat's timeout must be reached. I suspect that the timeout(s) are
 simply way too long.


 Just humor me..
 If it doesn't, it doesn't.  But it's easy to do, does not require a change
 of configuration nor a shutdown/restart of Tomcat, and it may show us
 something in principle unexpected.




 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: File descriptors peaks with latest stable build of Tomcat 7

[Neill Lima]

Increasing the amount of opened file descriptors is an accepted fine-tune (*if
your application it is handling the threads properly*)

ulimit -n
ulimit -n [new_value]
ulimit -n

If even after allowing more fds the performance is not adequate, some sort
of scaling (H/V) is necessary.

On Mon, Apr 20, 2015 at 3:41 PM, Rainer Jung rainer.j...@kippdata.de
wrote:

 Am 20.04.2015 um 14:11 schrieb Thomas Boniface:

 Hi,

 I have tried to find help regarding an issue we experience with our
 platform leading to random file descriptor peaks. This happens more often
 on heavy load but can also happen on low traffic periods.

 Our application is using servlet 3.0 async features and an async
 connector.
 We noticed that a lot of issues regarding asynchronous feature were fixed
 between our production version and the last stable build. We decided to
 give it a try to see if it improves things or at least give clues on what
 can cause the issue; Unfortunately it did neither.

 The file descriptor peaks and application blocking happens frequently with
 this version when it only happens rarely on previous version (tomcat7
 7.0.28-4).

 Tomcat is behind an nginx server. The tomcat connector used is configured
 as follows:

 We use an Nio connector:
 Connector port=8080 protocol=org.apache.coyote.
 http11.Http11NioProtocol
selectorTimeout=1000
maxThreads=200
maxHttpHeaderSize=16384
address=127.0.0.1
redirectPort=8443/

 In catalina I can see some Broken pipe message that were not happening
 with
 previous version.

 I compared thread dumps from server with both the new and old version of
 tomcat and both look similar from my stand point.

 My explanation may not be very clear, but I hope this gives an idea how
 what we are experiencing. Any pointer would be welcomed.


 If the peaks happen long enough and your platforms has the tools available
 you can use lsof to look for what those FDs are - or on Linux looking at
 ls -l /proc/PID/fd/* (PID is the process PID file) - or on Solaris use
 the pfiles command.

 If the result is what is expected, namely that by far the most FDs are
 coming from network connections for port 8080, then you can check via
 netstat in which connection state those are.

 If most are in ESTABLISHED state, then you/we need to further break down
 the strategy.

 Regards,

 Rainer


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: French chars not displayed correctly - Tomcat 7

[Neill Lima]

Try adding this to your html:

head
*meta charset=UTF-8*
/head

On Mon, Apr 20, 2015 at 4:45 PM, radiatejava radiatej...@gmail.com wrote:

 Hello Tomcat users, have code like this in my jsp:

 td${pageKeys.ui_user_name_label};/td

 Where td represents a cell of an html table.

 Value of the variable pageKeys.ui_user_name_label populated in server
 side is in french and it is exactly as shown below:

 Nom d'utilisateur

 However, while displaying this in the browser, this is getting displayed
 as:

 Nom drsquo;utilisateur


 How can I get this corrected ? When I try to see the source code, I
 see something like this:

 out.write((java.lang.String)

 org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(${pageKeys.ui_user_name_label},
 java.lang.String.class,
 (javax.servlet.jsp.PageContext)_jspx_page_context, null, false));

 What I want to know from developers here is whether the above code
 really does some escaping/encoding of the content ? Is a there a way
 to avoid this encoding ?

 Appreciate your reply.

 Thanks.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple login/home pages within a tomcat app

[Neill Lima]

Andre,

Excellent reply given the context.

I would add the following:

Given a webapp paradigm why would you need two different login pages to
different resources? Usually what is done is change what the logged user
sees/is able to see. For example:

Scenario 1:

WHEN a administrator logs in to the app XYZ /login URL
THEN the basic option menu is displayed
AND the Manage users option is displayed.

WHEN a administrator goes to app XYZ /manage-users URL
THEN Manage users page is dislayed

Scenario 2:

WHEN a regular user logs in to the app XYZ /login URL
WHEN the basic option menu is displayed
AND the Manage users option is hidden.

WHEN a regular user goes to app XYZ /manage-users URL
THEN Access not allowed page is displayed

Of course there is a bit of servlet and security under hood, but I just
wanted to show how the ACL would change based on the user-role, not the
URL in question.

On Wed, Apr 8, 2015 at 11:17 AM, André Warnier a...@ice-sa.com wrote:

 Olayemi Olatunji wrote:

 Hello Guys,



 I’m sort of a newbie to this but I need to know if its achievable.



 I want to create multiple login pages within a single web app e.g
 www.tomcat.org/login1, /login2



 How can I achieve this?



  Hi.
 Since you claim to be a newbie at this, I'll try to provide a learning
 answer.

 1) the simple answer to your question would be : no (or at least not when
 using the standard built-in authentication mechanisms).
 But do not be too disappointed, because a more complete answer might be
 perhaps, but it depends on the circumstances and on what you want to
 achieve exactly.

 2) a basic and generic explanation of how WWW authentication works :

 a) the browser sends a request to the server, for some server resource
 (e.g. a specific HTML page)
 b) the server receives this request, and checks in its configuration, if
 this resource is protected and requires some form of
 authentication/permission.
 If not, the server returns the requested page and things stop here.
 So the rest below, is in the case where the requested resource is
 protected.
 c) the server then checks if the browser request already contained some
 form of user authentication. (This can be various things, and i will not
 elaborate at this stage).
 If the request contained such an authentication, the server verifies it,
 and if it is ok, the server returns the requested resource (e.g. the
 desired HTML page), and things again stop here.
 d) if the request did not contain ditto valid authentication, instead of
 returning the requested resource, the server sends back something, to let
 the browser/user know that an authentication is required.  This can also be
 various things, and I will again not elaborate, but let's suppose that in
 your case what is returned is a login page.
 e) the user/browser gets and sees the login page.  The user fills it in,
 with user-id and password, and sends this info back to the server.
 f) the server verifies the submitted user-id/password, and if it is ok,
 returns the desired resource to the browser/user.  At the same time as
 sending that requested page, the server also sends some token to the
 browser (for example a cookie), containing the proof that this browser/user
 is now authenticated.
 g) for subsequent requests to the same server, the browser now always
 sends this token along with the next requests.  This will fulfill the check
 that happens at (c) above, so that for these following requests, the server
 will be happy and will return the requested pages, without asking again for
 authentication.

 There are many variations possible in the details, but in rough terms, all
 forms of WWW authentication follow more or less the above scheme.

 Your question relates to step (d) above.
 The server has to return a login page, but you say that it should return a
 specific one among several possible login pages.
 The question thus becomes : how does the server know /which/ login page to
 return ?
 (The user is not yet known/authenticated, so the server cannot use the
 user-id or any other user-related information in order to choose.)
 So what other criteria can the server use then ?

 Possibilities would be :
 - the login page changes depending on the time of day (that's kind of
 unusual, but it is just to illustrate the point)
 - the login page changes depending on the user's IP address
 - the login page changes depending on something else which the browser
 sends along with the initial request

 So, what is your use case precisely, and what are you trying to achieve ?






 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with JMX in tomcat

[Neill Lima]

Tried chmodding 600 in both .access and .password files?

On Tue, Apr 7, 2015 at 5:19 PM, Paul, Subhro subhro.p...@pseg.com wrote:



 -Original Message-
 From: Niranjan Babu Bommu [mailto:niranjan.bo...@gmail.com]
 Sent: Tuesday, April 07, 2015 11:02 AM
 To: Tomcat Users List
 Subject: Re: Issue with JMX in tomcat

 Email sent from outside of PSEG. Use caution before using
 links/attachments.


 I think the following OPTS is missing.

 -Dcom.sun.management.jmxremote=true

 On Tue, Apr 7, 2015 at 10:45 AM, Paul, Subhro subhro.p...@pseg.com
 wrote:

  Dear Team,
 
  Below is the property I was using to enable JMX in tomcat.conf file
  without authentication :
 
  CATALINA_OPTS=${CATALINA_OPTS} -Dcom.sun.management.jmxremote.port=9010
  -Dcom.sun.management.jmxremote.ssl=false
  -Dcom.sun.management.jmxremote.authenticate=false
  -Djava.rmi.server.hostname=xx.xxx.xxx.xxx
 
  This was working fine through jConsole or VisualVM remotely.
 
  To move the change in production server we decided to enable user
  authentication. So, on the same box we did a trial and changed the
 property
  value as below:
 
  CATALINA_OPTS=${CATALINA_OPTS} -Dcom.sun.management.jmxremote.port=9010
  -Dcom.sun.management.jmxremote.ssl=false
  -Dcom.sun.management.jmxremote.authenticate=true
  -Djava.rmi.server.hostname=10.184.222.84
 
 -Dcom.sun.management.jmxremote.password.file=/export/home/webserve/jmxremote.password
 
 -Dcom.sun.management.jmxremote.access.file=/export/home/webserve/jmxremote.access
 
  Content in jmxremote.access :
  monitorRole readonly
  controlRole readwrite
 
 
  Content in jmxremote.password :
  monitorRole webserve
  controlRole webserve
 
 
  Tomcat is running under webserve user. Now every time we connect to the
  JMX on the server getting message Authentication Failed! Invalid
 username
  or password
 
  We are using Linux 6.5 64 bit OS, Tomcat6 and JAVA 1.6. Please let me
 know
  what I need to change here?
 
  Thanks  Regards,
  Subhro Paul
 
 
 
  -
 
  The information contained in this e-mail, including any attachment(s), is
  intended solely for use by the named addressee(s).  If you are not the
  intended recipient, or a person designated as responsible for delivering
  such messages to the intended recipient, you are not authorized to
  disclose, copy, distribute or retain this message, in whole or in part,
  without written authorization from PSEG.  This e-mail may contain
  proprietary, confidential or privileged information. If you have received
  this message in error, please notify the sender immediately. This notice
 is
  included in all e-mail messages leaving PSEG.  Thank you for your
  cooperation.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 


 --
 *Thanks*
 *Niranjan*
 *+1 781.956.6900*



 Dear Niranjan,

 I applied your suggestion and restarted the server. But I am still getting
 same message.

 Thanks  Regards,
 Subhro Paul


 -

 The information contained in this e-mail, including any attachment(s), is
 intended solely for use by the named addressee(s).  If you are not the
 intended recipient, or a person designated as responsible for delivering
 such messages to the intended recipient, you are not authorized to
 disclose, copy, distribute or retain this message, in whole or in part,
 without written authorization from PSEG.  This e-mail may contain
 proprietary, confidential or privileged information. If you have received
 this message in error, please notify the sender immediately. This notice is
 included in all e-mail messages leaving PSEG.  Thank you for your
 cooperation.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat8 gives me WSOD due to LinkageError

[Neill Lima]

Hello Christopher,

Thanks for the reply. Actually not, I am working with out-of-the-box
Tomcat7 and Tomcat8 in this case. I wonder if any classloader changes
occurred in the last builds that could have affected this.

Thanks,

Neill

On Wed, Mar 25, 2015 at 5:44 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Neill,

 On 3/20/15 12:28 PM, Neill Lima wrote:
  As of today I figured out that the jasper.jar in Tomcat's \lib
  takes care of the task out of the box. I've tweaked my pom a few
  times, but I started fresh today and realized it. So no pom updates
  were necessary. Still I'm getting this exception I mentioned in the
  earlier e-mail:
 
  Caused by: java.lang.LinkageError: loader constraint violation:
  when resolving method
 
 org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(Ljavax/servlet/ServletConfig;)Lorg/apache/tomcat/InstanceManager;
 
 
 the class loader (instance of org/apache/catalina/loader/WebappClassLoader)
  of the current class, jsp/WEB_002dINF/jsp/home_005fpage_jsp, and
  the class loader (instance of java/net/URLClassLoader) for the
  method's defining class,
  org/apache/jasper/runtime/InstanceManagerFactory, have different
  Class objects for the type org/apache/tomcat/InstanceManager used
  in the signature at
 
 jsp.WEB_002dINF.jsp.home_005fpage_jsp._jspInit(home_005fpage_jsp.java:128)
 
 
 at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49) at
 
 org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231)
 
   It does not happen on my current Tomcat7 deploy though.

 Do you have any other Tomcat-provided libraries in your web
 applications' WEB-INF/lib directory?

 That can cause all kinds of problems.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJVEuXfAAoJEBzwKT+lPKRYhhgP/imvJyCrUmMw73gkqr/5fUVr
 rmucRx+GaNscY51Bj3boXco/2ANyQDUnIvbubdz57bDzqb6r+Jz7t6rfuK5H27sJ
 W0Kzu0Et7r8Ec9RQPBZ1iRz7jWdG0/DzRsGMcee7APzoomI3mUa0veJDpto3JKbo
 hacvB1SaLX7xatUI3GEQcBB6i15kF2Pu3khylQjUH9XMOd+QwFBah74h1DnwGzAZ
 j5V6VCRaeXAq314qGBFv+SE/3XeCJuKsranRvuatJcIHAHCbolDuh55mmM5UW/1u
 c+7mCsEQ74HeWc8CckxfO87mTDcGI1ppsJ5fm+oNoQVoctyJ0Zp6J4qcyp7K6ZK4
 cHwESgq6ZKf45AfJVHPses2arTniXHyRFUAWs/0En72rtNvMg9yzcoO0kmy2PYEN
 MQWrrfA6zVcnVemL1qxOugbAxD3/dA8N4PD+Wml6Ck/PfQ2K4RYdt9BlW8cMBEPe
 LdQZd/ezBOvs0FWZWtW1KFgKJgrDsUNMApr7r/JD0tY0urGJ1JSHfJKFUeJEoTsc
 e8C+UIV93dkdb5lRZEe64UhHRCdWHx4C6oYzURHu69KX8Bj3y1jrbtA6xw+/nHWV
 g/Ec2dZUyqEHBpM76ueU/B/0BRK3+RThH4PMMedAyEiR1xYsI150sbMBiF3DxSEJ
 quW2uCaBpsZpOuFDfjDS
 =H2X/
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat8 gives me WSOD due to LinkageError

[Neill Lima]

Hello list,

I'm not sure if this the right place to ask, but here it goes...

I have a existing WebApp that I'm planning to upgrade to Tomcat8 (version
8.0.20 as of today). It is running stable in Tomcat7 already for ages.

Tomcat8 does not embed the JasperListener so I added it manually to my
pom.xml otherwise I was getting NoClassDefFoundError.

dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-jasper/artifactId
version8.0.20/version
/dependency

The application bootstraps properly but when I launch a request to it, I'm
getting the following exception;

Caused by: java.lang.LinkageError: loader constraint violation: when
resolving method
org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(Ljavax/servlet/ServletConfig;)Lorg/apache/tomcat/InstanceManager;
the class loader (instance of org/apache/catalina/loader/WebappClassLoader)
of the current class, jsp/WEB_002dINF/jsp/home_005fpage_jsp, and the class
loader (instance of java/net/URLClassLoader) for the method's defining
class, org/apache/jasper/runtime/InstanceManagerFactory, have different
Class objects for the type org/apache/tomcat/InstanceManager used in the
signature at
jsp.WEB_002dINF.jsp.home_005fpage_jsp._jspInit(home_005fpage_jsp.java:128)
at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49) at
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231)

Has anyone experienced/resolved this before?

Re: Tomcat8 gives me WSOD due to LinkageError

[Neill Lima]

Hello Chris,

As of today I figured out that the jasper.jar in Tomcat's \lib takes care
of the task out of the box. I've tweaked my pom a few times, but I started
fresh today and realized it. So no pom updates were necessary. Still I'm
getting this exception I mentioned in the earlier e-mail:

Caused by: java.lang.LinkageError: loader constraint violation: when
resolving method
org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(Ljavax/servlet/ServletConfig;)Lorg/apache/tomcat/InstanceManager;
the class loader (instance of org/apache/catalina/loader/WebappClassLoader)
of the current class, jsp/WEB_002dINF/jsp/home_005fpage_jsp, and the class
loader (instance of java/net/URLClassLoader) for the method's defining
class, org/apache/jasper/runtime/InstanceManagerFactory, have different
Class objects for the type org/apache/tomcat/InstanceManager used in the
signature at
jsp.WEB_002dINF.jsp.home_005fpage_jsp._jspInit(home_005fpage_jsp.java:128)
at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49) at
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231)

It does not happen on my current Tomcat7 deploy though.



On Fri, Mar 20, 2015 at 5:08 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Neill,

 On 3/20/15 4:58 AM, Neill Lima wrote:
  I have a existing WebApp that I'm planning to upgrade to Tomcat8
  (version 8.0.20 as of today). It is running stable in Tomcat7
  already for ages.

 Great.

  Tomcat8 does not embed the JasperListener so I added it manually to
  my pom.xml otherwise I was getting NoClassDefFoundError.

 Wait, what? What do you mean Tomcat8 does not embed the
 JasperListener? What are you actually trying to do? Just run a JSP?
 It should work out of the box without any Maven foolishness.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJVDEXwAAoJEBzwKT+lPKRYQsUQAJjQDrBPvSP5mEg8IsME5kDz
 Y39SDR5I0XQ0cLM3IIgCCFKpfTU71gvbLdJflQSz6JU833iye2E515IijKnlnINr
 0FiJ1E2ogKLJWfmhu28f0VWFXJ3Dy+qSL2AT1H4yF8ed+JTfXWFkzKzkoxSuXeMn
 TKBTUxXfD7f4ei9EEK3ZEDvWUIJ7w6v4gBJ8BriOZ9/iLYTiZ9S90KL/ilp4Iypw
 2/ncET7WqoLqshM4g+fswEeSjOeEQn5J50gebqubUxhsmfUt+BYXGDIchAc8yUVp
 MTjJw5r9QpOCgeNyuMdK4Vg/DCcgsTzhHT7rcYh1iItwckqpcr04rc/AlYFnEU/u
 78MzHR6U0iIAx49tWb6bwRbsjnygFKPHX49dAlhmdopijuNumrl6yvmUyR5fTA8d
 RNvcXbHhMm06SesW7QvkUPZk8Qq6W/2WBH+kKuMMmBXzJt0p7XG3BvgtTqLwBUDj
 7oGli1p8JsV0pg/pYERW4lpNuDg1LsLuzCg1EvRJ7wuoN6j1k47uL6c7dNw4QdFE
 p6DpKpeCZH85y4CCupqexwmhut/OYIF2F6W2NMBgn78SfY8HD51FrBnb9zeiq1Gr
 PgeitwooTzyafWNAvNbPv2TUO6qXzvrY6+eA2UurizMYN30ir3tDh+IwcYNG7OtW
 bcIjoFmirZ36tYJIgwn1
 =wbJX
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org