RE: Understanding how to controlling what data is written to log4j appenders

2016-03-08 Thread Cris Berneburg - US 
Chris

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, March 08, 2016 11:36 AM
To: Tomcat Users List
Subject: Re: Understanding how to controlling what data is written to log4j 
appenders

[SNIP]

> Yeah, it's a shame it's the case, but to understand how logging works,
> you also have to understand how the logger configures itself (which isn't
> a big deal), and that also means understanding how Java ClassLoaders work.
>
> I didn't even say anything about ClassLoaders, but that's why this is all
> happening: when log4j is loaded, it only has visibility to the classes
> that have been loaded by its own ClassLoader or those "higher up" in the
> chain of ClassLoaders that go up to the initial ClassLoader that the JVM
> starts to load everything.
>
> You can even break the chain of ClassLoaders a bit if you want.
>
> For example, Tomcat uses its own bootstrap ClassLoader to load some very
> basic things, then loads the container in a separate ClassLoader so that
> it doesn't interfere with anything the web applications are doin g.
>
> Then each web application gets its own ClassLoader which doesn't have
> visibility into the server's ClassLoader. There are some games being
> played with which classes are and are not available to either (or both)
> Tomcat and the applications, much of which is not visible to the user
> unless they (a) understand it and (b) configure it differently from the
> default.

Ah, OK, interesting - thanks for explaining that.

> The upshot is that, if you have your own log4j.jar file bundled with your
> application (which I think you *should*), then when you try to initialize
> it, it will initialize based upon the application's logging configuration
> and basically be completely separate from Tomcat's logging configuration.

That's good to know and makes sense.

> Then there is System.out, which is shared by everyone. So if your web
> application's logger is configure to log to System.out, then Tomcat's logger
> can capture that logging and *also* redirect it to wherever it wants.

Thanks, I did not know that.  Might be handy if refactoring the application to 
replace System.out with logger calls is prohibitive.

> It's kind of like a river, where you can redirect the water almost wherever
> you want (except that this river can also clone water molecules and send
> them in two directions *at once*). Okay, terrible analogy. Sorry.

Ha, ha, ha!  :-)

--
Cris Berneburg, Lead Software Engineer, CACI

RE: Understanding how to controlling what data is written to log4j appenders

2016-03-08 Thread Cris Berneburg - US 
Chris,

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, March 08, 2016 10:44 AM
To: Tomcat Users List
Subject: Re: Understanding how to controlling what data is written to log4j 
appenders

[SNIP]

>> # stdout is set to be a ConsoleAppender. 
>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>
> This is what is killing you, plus everything that looks like this:
>
> log4j.logger.com.proginet.sift.struts=${cfi.struts.logging.level}, stdou t
>
> Everything that says log4j.logger.[something]=[level], stdout
>
> Is going to send those log messages to the "stdout" appender, which is tied
> to System.out. You'll need to do one of two things to dig yourself out:
>
> 1. Use swallowOutput="true" on your , which performs some magic to 
> take
> System.out from applications' calls and redirect it elsewhere else (to the 
> tomcat-
> defined loggers that can be configured in Tomcat's log4j.properties file).
>
> 2. Change the "stdout" appender to be something other than ConsoleAppender, 
> and
> point it at a file on the disk.
>
> I'm not a fan of the first option, but it's sometimes the quickest way to 
> handle
> everything all at once, and usually doesn't require any changes to the 
> application's
> configuration.

[SNIP]

>> # Set root logger level to ERROR and its only appender to stdout. 
>> log4j.rootLogger=ERROR, CFCC
>> 
>> log4j.appender.CFCC = org.apache.log4j.DailyRollingFileAppender
>
> That should probably work.
>
> But if you removed log4j.jar from the application, only the global 
> log4j.properties
> file will be read. It's okay to have log4j.jar in the bin/ directory as well 
> as your
> webapp's WEB-INF/lib directory. The former will run/configure Tomcat's 
> logging, and
> the latter will run/configure the application's logging. In fact, if the 
> application
> initializes log4j itself (usually by creating a new PropertyConfigurator 
> object), then
> weird things can happen with the application re-defining the global 
> configuration for
> Tomcat.
>
> I'd recommend having two .jar files and two .properties files, just to be 
> safe.

Thanks for taking the time to explain these 2 concepts.  It has helped me, and 
hopefully the question's originator, understand the interaction between Tomcat 
and log4j a little better.

--
Cris Berneburg, Lead Software Engineer, CACI

RE: Understanding how to controlling what data is written to log4j appenders

2016-03-08 Thread Cris Berneburg - US 
ot making it 
into the log4j logs?

As I am new to log4j, I am somewhat intimidated by your configuration, and am 
not sure how much more helpful I can be.  :-)

However, if I were in your shoes, I would try a systematic approach in 
experimentation.  I would comment out everything in all the log configurations. 
 Then, one at a time, uncomment one logger and one appender, restart the 
container, and see how the logs behave.  If that one piece of the configuration 
does not work, then tweak it and retry.  Once that portion works, then I would 
move onto the next logger and appender and repeat.

To sum up, if the configuration is complex, simplify it.  Once the simple 
configuration works, then adjust to handle a more advanced setup.

>>>> -Joleen
>>>>
>>>> On Fri, Mar 4, 2016 at 4:33 PM, Cris Berneburg - US 
>>>> > wrote:
>>>>
>>>>> Hi Joleen
>>>>>
>>>>> -Original Message-
>>>>> From: Joleen Barker [mailto:oldenuf2no...@gmail.com]
>>>>> Sent: Thursday, March 03, 2016 11:23 PM
>>>>> To: Tomcat Users List
>>>>> Subject: Re: Understanding how to controlling what data is written 
>>>>> to log4j appenders
>>>>>
>>>>> > Hello,
>>>>> >
>>>>> > I don't know if I should use a new thread or not but this is a
>>>>> continuation of this issue. I found that even after my changes 
>>>>> there was very little being written to my new log and there were 
>>>>> still many of the product messages being written to the 
>>>>> catalina.out. It has now come to my attention that the web 
>>>>> application contains a log4j.jar file in the /lib 
>>>>> directory and a log4j.properties file in the /classes directory.
>>>>> > This log4j.properties file has a lot more items in it and I 
>>>>> > believe
>>>>> is the reason all the messages from the product are still going to 
>>>>> the catalina.out log.
>>>>> >
>>>>> > Here I was so proud of myself for getting the logs to go to an
>>>>> appender and the log rolling over as expected only to find the 
>>>>> catalina.out still growing with messages from the application.
>>>>>
>>>>> Hey, that's a good start!  I just completed refactoring our app to 
>>>>> use log4j2, and it was a challenge.  While I am new to using log4j, 
>>>>> maybe we can stumble thru your problem and solve it together.
>>>>>
>>>>> > I am unsure how to get these messages to be added to my log file 
>>>>> > that
>>>>> is being used from the log4j.properties file that is in the 
>>>>> CATALINA_BASE/lib directory.
>>>>> >
>>>>> > One of the other things I noticed is the vendor has a 
>>>>> > tomcat-juli.jar
>>>>> in the CATALINA_BASE/lib as well as in the CATALINA_BASE/bin 
>>>>> directory where it should be. Would the one that is in the 
>>>>> CATALINA_BASE/lib directory be doing anything. Maybe it is there in 
>>>>> error and not really effecting anything but I don't know.
>>>>> >
>>>>> > I did read in a note on the tomcat web page that gave the
>>>>> instructions to use the log4j logging that the steps it had written 
>>>>> were not needed if you just want to use log4j in your own web 
>>>>> application - in that case, you would just put log4j and the 
>>>>> log4j.properties in the WEB-INF/lib and the WEB-INF/classes of your 
>>>>> web application which it appears the vendor did. So I think I would 
>>>>> need to edit their log4j.properties file.
>>>>> >
>>>>> > Am I on the right track at all here?
>>>>>
>>>>> I would check a few things:
>>>>>
>>>>> 1. Check the container/application startup messages for autoconfig 
>>>>> or default config notifications.  This may be a moot point since 
>>>>> you already said "the logs to go to an appender and the log rolling over 
>>>>> as expected".
>>>>>
>>>>> 2. Check the log4j config files:
>>>>>   a. For appenders that go to Console or System_Out.
>>>>>   b. That the logger(s) refer to the appender(s) you want.
>>>>>   c. Check the logger(s) "level" to ensure the messages levesl are 
>>>>> >

RE: Understanding how to controlling what data is written to log4j appenders

2016-03-04 Thread Cris Berneburg - US 
Hi Joleen

-Original Message-
From: Joleen Barker [mailto:oldenuf2no...@gmail.com]
Sent: Thursday, March 03, 2016 11:23 PM
To: Tomcat Users List
Subject: Re: Understanding how to controlling what data is written to log4j 
appenders

> Hello,
>
> I don't know if I should use a new thread or not but this is a continuation 
> of this issue. I found that even after my changes there was very little being 
> written to my new log and there were still many of the product messages being 
> written to the catalina.out. It has now come to my attention that the web 
> application contains a log4j.jar file in the /lib directory and a 
> log4j.properties file in the /classes directory.
> This log4j.properties file has a lot more items in it and I believe is the 
> reason all the messages from the product are still going to the catalina.out 
> log.
>
> Here I was so proud of myself for getting the logs to go to an appender and 
> the log rolling over as expected only to find the catalina.out still growing 
> with messages from the application.

Hey, that's a good start!  I just completed refactoring our app to use log4j2, 
and it was a challenge.  While I am new to using log4j, maybe we can stumble 
thru your problem and solve it together.

> I am unsure how to get these messages to be added to my log file that is 
> being used from the log4j.properties file that is in the CATALINA_BASE/lib 
> directory.
>
> One of the other things I noticed is the vendor has a tomcat-juli.jar in the 
> CATALINA_BASE/lib as well as in the CATALINA_BASE/bin directory where it 
> should be. Would the one that is in the CATALINA_BASE/lib directory be doing 
> anything. Maybe it is there in error and not really effecting anything but I 
> don't know.
>
> I did read in a note on the tomcat web page that gave the instructions to use 
> the log4j logging that the steps it had written were not needed if you just 
> want to use log4j in your own web application - in that case, you would just 
> put log4j and the log4j.properties in the WEB-INF/lib and the WEB-INF/classes 
> of your web application which it appears the vendor did. So I think I would 
> need to edit their log4j.properties file.
>
> Am I on the right track at all here?

I would check a few things:

1. Check the container/application startup messages for autoconfig or default 
config notifications.  This may be a moot point since you already said "the 
logs to go to an appender and the log rolling over as expected".

2. Check the log4j config files:
  a. For appenders that go to Console or System_Out.
  b. That the logger(s) refer to the appender(s) you want.
  c. Check the logger(s) "level" to ensure the messages levesl are >= that 
minimum threshold.

3. If you are in doubt as to which log4j config file is in use and have the 
ability to experiment, try changing the config files (and restarting the 
container?) to see how that affects the logs.  Often what I will do is try to 
break something with invalid syntax - if that causes an error then I know I am 
editing the correct file, but if no error is generated, then I don't even have 
the correct file and know I should be looking elsewhere.

4. Check the application code to be sure it is not writing to System.out or 
calling exception printStackTrace directly.

5. Is there an "adaptor" for connecting the Tomcat logging interface to log4j 
that needs to be configured?  I did not use the logging interface built into 
Tomcat, so I cannot provide help with that.

> Would it be bad to post their log4j.properties along with mine to see how I 
> can edit it to have the info go to the new log?
>
> -Joleen
>
> On Fri, Dec 4, 2015 at 4:49 PM, Joleen Barker 
> wrote:
>
>> Hello Chris,
>>
>> As of now I am not using JULI any longer. I am using the log4j
>> v1.2.17.jar
>>
>> Eventually I will jump in to the log4j v2 users and try my hand at that.
>>
>> Thank you for the clarification on where to go for information. I
>> completely missed seeing the log4j mailing list. Could you send me the
>> url to signup for it.
>>
>> Have a wonderful weekend.
>>
>> -Joleen
>>
>>
>>
>> On Fri, Dec 4, 2015 at 1:11 PM, Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
>>> Joleen,
>>>
>>> On 12/3/15 11:55 PM, Joleen Barker wrote:
 The information you gave me for the additivity was PERFECT! It did
>>> exactly
 what I was looking for. This also really allowed me to understand
 what processes were writing to which log. I have the settings in
 place in my test environment now and if all goes well the changes
 will be added in
>>> the
 production environment soon.
>>>
>>> Glad you are making progress.
>>>
>>> There are many folks here who have experience with log4j (myself and,
>>> evidently, Konstantin as well), but for more thorough log4j help,
>>> you're probably going to wait to go over to the log4j mailing list.
>>>
>>> If JULI is in the mix (the default logging framework for Tomcat) and

RE: Is there a way for code running on Tomcat 7+ to determine the URL of the Web App it's running under?

2016-02-15 Thread Cris Berneburg - US 
Chris

[SNIP: Chris Schultz and Greg Dougherty] 

> >>> The web app needs a DB password so it can connect to the DB.
> >> 
> >> I disagree that the web app needs a password.
> > 
> > The web app has to be able to read and write to the DB.  That takes a 
> > password.
> 
> I agree with Leo: your application only needs a javax.sql.DataSource.
> That can be pre-seeded with a password to make connections. The web 
> application itself doesn't need to have any authentication information in it,
> unless you want to be able to make new connections with different credentials.
> 
> My web applications have nary a username or password to access their 
> databases, and yet connections to SQL DataSources work perfectly fine.
> Multiple dev and test environments, demo, and production. Same code base. 
> Same revision-control system. No passwords.

Sorry, I'm confused.  Are you saying that your database does not require 
password authentication?  Or are you saying that while your DB does require 
password authentication, the applications do not access those passwords because 
you rely on a data source that provides the password to the DB?  Is the data 
source is an intermediary that does the authentication?  I'm still struggling 
conceptually with the "security requirement" of having encrypted passwords, as 
opposed to clear-text passwords, stored in config files on the tomcat server.  
"It's turtles (passwords) all the way down!"  Or is that a different issue?

[SNIP AGAIN]

--
Cris Berneburg, Lead Software Engineer, CACI


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

RE: WebEx meeting invitation: Apache Tomcat: TLS key and certificate generation

2016-01-27 Thread Cris Berneburg - US 
> The recording for this is now available on the Apache Tomcat YouTube
> channel: https://www.youtube.com/channel/UCpqpJ0-G1lYfUBQ6_36Au_g

Thanks Mark!

> > [SNIP]
> >>
> >> *Apache Tomcat: TLS key and certificate generation* Tuesday, 26 
> >> January 2016
> >> 10:00  |  GMT Time (London, GMT)  |  1 hr
> >>
> >> [SNIP]

--
Cris Berneburg, Lead Software Engineer, CACI


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

RE: Tomcat 8.0.30 Session lost

2016-01-12 Thread Cris Berneburg - US 
Thomas

> -Original Message-
> From: Olaf Kock [mailto:tom...@olafkock.de] 
> Sent: Monday, January 11, 2016 4:12 PM
> To: Tomcat Users List
> Subject: Re: Tomcat 8.0.30 Session lost
> 
> Well, at least you do a bit of protection instead of just disabling the 
> session fixation security filter. However, be aware that potentially many 
> people might come from the same IP address - either because it's a NATing 
> home router or a big company's proxy server. Especially if you want to attack 
> someone who's in the same network as yourself, this IP-based protection is 
> quite useless.
> 
> I think I'm seeing the problems, and as long as you know what you're doing 
> and you accept the unavoidable consequences of this lower grade protection, 
> everything is fine.
> 
> It still sounds funny that the session is not available with the next 
> requests... Might be worth to try different browsers for their timing on the 
> receipt of the cookie

+1

Have you tried different browsers, say Internet Explorer, Chrome, and Firefox 
to see if the behavior is the same for all?

This is kind of a long shot, but I'll mention it anyway.  I had a similar kind 
of problem, where every resource request on a page was trying to create a new 
session.  It turns out IE had a bug processing URL's with special chars in 
them, in my case an underscore "_".  Using a different browser other than IE, 
or accessing the server by IP address instead of DNS name, hid the problem.  
After researching, experimentation, and pulling my hair out, I finally realized 
the underscore was the issue.  Renaming the server solved the problem.  Use 
keyword "weirdness" to search for old posts on this topic.

Perhaps another long shot, and please forgive me if you have already made this 
clear, have you verified the timing and concurrency of your authentication and 
loading of page resources?  IOW, are they the same, or different use-case 
events?

> Also, as you call HttpServletRequest.login manually, double check that you're 
> doing this before the response is committed to the client, specifically 
> before any other (old) session id cookie is already in the response stream. 
> It sounds weird, but might help you debug further (note that I'm not looking 
> at tomcat's code. Apologies if I'm not making sense)
> 
> Olaf
> 
> Am 11.01.2016 um 21:52 schrieb Thomas Scheffler:
> >
> > I will file two bugs soon describing the issues I had. Hopefully they 
> > will be fixed.
> >
> > 1.) if using HttpServetRequest.login(String, String) further request 
> > in the session are loosing the users Principal.
> >
> > 2.) After changing sessionId, old sessionIds should still be valid for 
> > a short period of time of to the same client.
> >
> > Fixing one of these would cause the bug to disappear.
> >
> > To prevent session fixation attacks, I use IP address checking so that 
> > sessions are bound to the same IP address.
> >
> > Thanks to all the responses. Without you help it would have not been 
> > possible to get this fixed after two month of searching!
> >
> > kind regards,
> >
> > Thomas
> >

--
Cris Berneburg, Lead Software Engineer, CACI

RE: WebEx meeting invitation: Apache Tomcat: TLS Virtual Hosting

2015-12-16 Thread Cris Berneburg - US 
Mark (and Chris),

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Sent: Wednesday, December 09, 2015 12:08 PM
> To: Tomcat Users List
> Subject: Re: WebEx meeting invitation: Apache Tomcat: TLS Virtual Hosting
> 
> Mark,
> 
> On 12/9/15 8:46 AM, Mark Thomas wrote:
> > On 09/12/2015 13:39, Cris Berneburg - US wrote:
> >> Aww phooey, I missed it!  I set my reminder incorrectly and ended up 
> >> trying to sign in 20 minutes late.  By the time I did sign in, the place 
> >> was empty.  "Hello, anybody there?"
> > 
> > All is not lost:
> > 
> > https://www.youtube.com/channel/UCpqpJ0-G1lYfUBQ6_36Au_g
> 
> New and improved... with SOUND!

Thanks for doing the presentation, recording it, AND improving the sound.  :-)

> Your tax dollars at work. ;)
> 
> (Thanks Mark)
> 
> -chris


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

RE: WebEx meeting invitation: Apache Tomcat: TLS Virtual Hosting

2015-12-09 Thread Cris Berneburg - US 
Aww phooey, I missed it!  I set my reminder incorrectly and ended up trying to 
sign in 20 minutes late.  By the time I did sign in, the place was empty.  
“Hello, anybody there?”

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313

From: Mark Thomas [mailto:messen...@webex.com]
Sent: Wednesday, December 02, 2015 5:59 AM
To: users@tomcat.apache.org
Subject: WebEx meeting invitation: Apache Tomcat: TLS Virtual Hosting

Hello,

Mark Thomas invites you to join this WebEx meeting.





Apache Tomcat: TLS Virtual Hosting

Tuesday, 8 December 2015

21:00  |  GMT Time (London, GMT)  |  1 hr





Join WebEx meeting 



Meeting number:

642 749 240






Join by phone

Call-in toll-free number: 1-877-8818371  (US)

Call-in number: 1-617-3374371  (US)

Show global 
numbers

Attendee access code: 289 459 03





Add this 
meeting
 to your calendar.





Can't join the meeting? Contact support.





IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. By joining this session, you automatically consent to such 
recordings. If you do not consent to being recorded, discuss your concerns with 
the host or do not join the session.

RE: Need help understanding DB connection versus servlet request life cycle

2015-08-18 Thread Cris Berneburg - US 
Chris,

Thanks for taking time to explain all that to me.  I appreciate it.  My 
responses inline below.

--
Cris Berneburg, Lead Software Engineer, CACI


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Saturday, August 15, 2015 8:32 PM
To: Tomcat Users List
Subject: Re: Need help understanding DB connection versus servlet request life 
cycle

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Cris,
 
 On 8/14/15 1:36 PM, Cris Berneburg - US wrote:
  -Original Message- From: osagie uwaifo 
  [mailto:osagieuwa...@gmail.com] Sent: Friday, August 14, 2015 10:49 AM 
  To: Tomcat Users List Subject: Re: Need help understanding DB 
  connection versus servlet request life cycle
  
  Chris,
  
  Why don't you allow tomcat manage the connection for you?
  
  http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
  
  [SNIP]
 
 You just need to code myBatis to use a JNDI DataSource. Then make sure that 
 the DataSource you configure in Tomcat (in your application's 
 META-INF/context.xml file) agrees with the DataSource's name you tell myBatis 
 to use. Sometimes the exact syntax on either side is tricky to get, since 
 certain components like to add their own prefixes without making it 
 abundantly clear what prefixes are actually being added from the root of the 
 JNDI context.

I just re(?)discovered that myBatis is already configured to use DBCP, which 
may mean I don't need to set up a JNDI datasource after all:

transactionManager type=JDBC/
dataSource type=POOLED

I added these connection pooling properties below.  Hopefully that will help 
support DB connections in the JSP layer, at least until they are later moved to 
the servlet layer like you suggest.

property name=poolMaximumActiveConnections value=30 /
property name=poolMaximumCheckoutTime value=6 /
property name=poolPingQuery value=SELECT 1 /
property name=poolPingEnabled value=true /

 It's not a good idea to keep a database connection open for the duration of 
 the request. For one, not all requests are going to require a database 
 connection, and you'd be pulling one out of the pool only to starve other 
 requests that actually do need them. Second, the request (usually) takes 
 longer than the database transaction, so you are also starving other threads 
 by doing that.
 
 I would recommend checking a connection out of the pool, performing a small 
 transaction, then returning the connection to the pool using 
 Connection.close(). If you need to perform multiple transactions, you can 
 grab another connection if necessary.
 
 If you find that you have multiple separate transactions per request that are 
 stalling waiting for connections, you might consider creating a utility 
 method that handles that set of transactions and does them all with a single 
 connection.

Yeah, you're right, it's not very efficient.  However, we're a low-volume site, 
and we might be able to get away with it until refactoring is finished.  The 
myBatis documentation 
(https://mybatis.github.io/mybatis-3/getting-started.html) says this in the 
SqlSession section:

 consider the SqlSession to follow a similar scope to that of an HTTP request. 
 In other words, upon receiving an HTTP request, you can open a SqlSession, 
 then upon returning the response, you can close it.

Debugging, I see that my ServletRequestListener.requestInitialized is not fired 
for every HTTP request, so it's not quite that bad.

On the other hand, the myBatis docs say this earlier in the same paragraph, 
which may explain my ExecutorException: Executor was closed problems:

 Each thread should have its own instance of SqlSession. Instances of 
 SqlSession are not to be shared and are not thread safe. Therefore the best 
 scope is request or method scope. Never keep references to a SqlSession 
 instance in a static field or even an instance field of a class.

QUESTIONS:  I don't understand what parts have separate threads.  Does JSP 
rendering get its own thread separate from the servlet?  Do Java tags embedded 
in JSP each have their own thread separate from the JSP rendering?

Anyway, I changed the JSP pages to open their own SqlSession (instead of 
sharing from the servlet) and explicitly close it when finished.  In the future 
I may also move the opening of the SqlSession from the request listener to each 
servlet that needs one.

 Finally, you should take some time to remove all database accesses from your 
 JSP code and move it back into the servlet layer. That will give you a 
 clean separation between your controllers (the
 servlets) and your views (the JSPs). JSPs have fewer tools to allow you to 
 handle errors, etc. and so it's best to know that all is well before you try 
 to generate a response -- because once the response has been committed, you 
 can't take it back and say whoops, we actually couldn't load that object 
 from the database. Instead, you'll get either a broken page or a 
 silently-failed page

Need help understanding DB connection versus servlet request life cycle

2015-08-14 Thread Cris Berneburg - US 
BACKGROUND:  I've been doing Java servlet coding for about 2 years and need 
help understanding something.  I work on a legacy JSP and servlets web 
application project using Tomcat.  Previously all the SQL was embedded right 
into the Java and JSP code.  I added the myBatis framework and moved all the 
SQL to mappers.  Also previously, every SQL statement had its own separate DB 
connection instantiated and opened but not closed.  I changed that so each 
servlet request would have only one open DB connection by adding a 
ServletRequestListener that opens the sqlSession in requestInitialized and 
closes it in requestDestroyed.

PROBLEM: When running in my IDE in my dev environment, various random myBatis 
calls in the JSP pages would fail.  After one would fail, all the rest would 
fail too.  There were 3 repeated phrases - NullPointerException, 
PersistenceException, and ExecutorException Executor was closed.

DEBUGGING: It appeared the DB connection was being closed before the page was 
finished rendering.  That meant the MyBatis ServletRequestListener 
requestDestroyed handler was being triggered before the JSP page was finished 
being served.  When I commented out the sqlSession.close statement the JSP page 
worked OK.

WORK-AROUND: I added a keepConnectionOpen flag in my development configuration 
file and coded the ServletRequestListener requestDestroyed handler to not close 
the sqlSession if the flag was true.  The JSP page now loads without error.

NOTE 1: While there being only one open SQL session per servlet request open at 
a time is an improvement, it bothers me that the DB connection is not being 
explicitly closed.

NOTE 2: The problem does not currently happen in our test environment.

NOTE 3: Our web site has low traffic volume.

QUESTION(s) 1: Why is the ServletRequestListener requestDestroyed handler 
triggered before the JSP page is finished?  Is it due to my IDE or Tomcat or 
something else?  My interpretation is that the IDE is handling the processing 
differently than Tomcat somehow, although I don't understand that since the IDE 
is invoking Tomcat.  Should I be concerned that the problem will eventually 
happen in my test and future production environments?

QUESTION 2: Is there a better way to manage DB connections anyway?

DEVELOPMENT ENVIRONMENT:
OS - Windows 7 Pro SP1 64-Bit
IDE - IntelliJ Idea 12.1.6
TOMCAT - 6.0.37
JAVA - JDK 1.6.0.24

TEST ENVIRONMENT:
OS - Windows Server 2012 R2 Standard 64-Bit
TOMCAT - 6.0.37
JAVA - JRE 1.8.0.45

NOTE 4: My customer uses Tomcat 6, so I must use that too.

You read down this far?  Thanks for your time, help, and encouragement.  :-)

--
Cris Berneburg, Lead Software Engineer, CACI


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

RE: Need help understanding DB connection versus servlet request life cycle

2015-08-14 Thread Cris Berneburg - US 
Osagie

-Original Message-
From: osagie uwaifo [mailto:osagieuwa...@gmail.com] 
Sent: Friday, August 14, 2015 10:49 AM
To: Tomcat Users List
Subject: Re: Need help understanding DB connection versus servlet request life 
cycle

 Chris,
 
Why don't you allow tomcat manage the connection for you?
 
 http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
 
 It is a lot easier that way. Do you need examples?

Thanks for your reply and the link.  I'll read up on that.  Yes, I probably 
need examples of hooking up the connection pool to myBatis.  The page does say 
this:

 How to use 
 Usage of the Tomcat connection pool has been made to be as simple as possible,
 for those of you that are familiar with commons-dbcp, the transition will be 
 very
 simple. Moving from other connection pools is also fairly straight forward.

I have no experience with either commons-dbcp or using connection pools, so for 
me it does not seem fairly straight forward.  :-)  But I will keep reading 
and Google how to connect myBatis to the Tomcat connection pool.  Thanks for 
the suggestion!

 On Fri, Aug 14, 2015 at 9:12 AM, Cris Berneburg - US cberneb...@caci.com
 wrote:
 
  BACKGROUND:  I've been doing Java servlet coding for about 2 years and 
  need help understanding something.  I work on a legacy JSP and 
  servlets web application project using Tomcat.  Previously all the SQL 
  was embedded right into the Java and JSP code.  I added the myBatis 
  framework and moved all the SQL to mappers.  Also previously, every 
  SQL statement had its own separate DB connection instantiated and 
  opened but not closed.  I changed that so each servlet request would 
  have only one open DB connection by adding a ServletRequestListener 
  that opens the sqlSession in requestInitialized and closes it in 
  requestDestroyed.
 
  PROBLEM: When running in my IDE in my dev environment, various random 
  myBatis calls in the JSP pages would fail.  After one would fail, all 
  the rest would fail too.  There were 3 repeated phrases - 
  NullPointerException, PersistenceException, and ExecutorException Executor 
  was closed.
 
  DEBUGGING: It appeared the DB connection was being closed before the 
  page was finished rendering.  That meant the MyBatis 
  ServletRequestListener requestDestroyed handler was being triggered 
  before the JSP page was finished being served.  When I commented out 
  the sqlSession.close statement the JSP page worked OK.
 
  WORK-AROUND: I added a keepConnectionOpen flag in my development 
  configuration file and coded the ServletRequestListener 
  requestDestroyed handler to not close the sqlSession if the flag was 
  true.  The JSP page now loads without error.
 
  NOTE 1: While there being only one open SQL session per servlet 
  request open at a time is an improvement, it bothers me that the DB 
  connection is not being explicitly closed.
 
  NOTE 2: The problem does not currently happen in our test environment.
 
  NOTE 3: Our web site has low traffic volume.
 
  QUESTION(s) 1: Why is the ServletRequestListener requestDestroyed 
  handler triggered before the JSP page is finished?  Is it due to my 
  IDE or Tomcat or something else?  My interpretation is that the IDE is 
  handling the processing differently than Tomcat somehow, although I 
  don't understand that since the IDE is invoking Tomcat.  Should I be 
  concerned that the problem will eventually happen in my test and 
  future production environments?
 
  QUESTION 2: Is there a better way to manage DB connections anyway?
 
  DEVELOPMENT ENVIRONMENT:
  OS - Windows 7 Pro SP1 64-Bit
  IDE - IntelliJ Idea 12.1.6
  TOMCAT - 6.0.37
  JAVA - JDK 1.6.0.24
 
  TEST ENVIRONMENT:
  OS - Windows Server 2012 R2 Standard 64-Bit TOMCAT - 6.0.37 JAVA - JRE 
  1.8.0.45
 
  NOTE 4: My customer uses Tomcat 6, so I must use that too.
 
  You read down this far?  Thanks for your time, help, and encouragement.
  :-)
 
  --
  Cris Berneburg, Lead Software Engineer, CACI
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 
 --
 Thanks,
 Osagie Uwaifo

RE: Form authentication with Tomcat 7.0.63 behind Apache HTTPD and mod_jk

2015-07-14 Thread Cris Berneburg - US 
Mark

Look for *** for my response.

-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID] 
Sent: Monday, July 13, 2015 2:13 PM
To: Tomcat Users List
Subject: Re: Form authentication with Tomcat 7.0.63 behind Apache HTTPD and 
mod_jk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Folks,

I have resolved the issue:

On 7/10/2015 11:27 AM, Mark Eggers wrote:
 Now with the shipped examples goodness:
 
 
 On 7/9/2015 10:39 PM, Konstantin Kolinko wrote:
 2015-07-10 2:35 GMT+03:00 Mark Eggers
 its_toas...@yahoo.com.invalid:

 Folks,

 I seem to be having a problem trying to use form-based 
 authentication. What worked in 7.0.62 no longer works in 7.0.63.
 Using 7.0.62 I can successfully authenticate in my toy application 
 and the latest version of Jenkins. Using 7.0.63 I end up on the form 
 error page in my toy application and the latest version of Jenkins.


[SNIP]

 
 I'll try to start working through the code changes to see where the 
 likely culprit is.
 
 . . . just my puzzled 2 cents
 /mde/

It would have helped (and not wasted everyone's time) if I had read the 
changelog carefully.

- From the changelog:

fix 57938: Correctly handle empty form fields when a form is submitted
   as multipart/form-data, the maxPostSize attribute of the
   Connector has been set to a negative value and the Context
   has been configured with a value of true for
   allowCasualMultipartParsing. The meaning of the value zero
   for the maxPostSize has also been changed to mean a limit of
   zero rather than no limit to align it with maxSavePostSize
   and to be more intuitive. (markt)

My AJP connector (since I have to support some oddly-written application
s):

Connector URIEncoding=UTF-8
   connectionTimeout=60
   maxPostSize=0
   port=8009
   protocol=AJP/1.3
   redirectPort=8443 /

Since 0 now really means 0, I was not getting any POST parameters throug h.

It now reads:

Connector URIEncoding=UTF-8
connectionTimeout=60
maxPostSize=-1
port=8009
protocol=AJP/1.3
redirectPort=8443 /

and everything works.

Sorry for the noise.

*** No problem - even your noise is educational for me.  :-)  ***

. . . documentation, it's not just for breakfast anymore /mde/ -BEGIN PGP 
SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJVo/+3AAoJEEFGbsYNeTwtPn4IAK0tdY22hwq/LRr71ozShRgx
XiCiHB/X79P71VIbs8rQ5Ao3RNG6quEzsZQXWXFNvvWq4uSh3cUivRLd53LylST2
aGrdn1UhJCGOmI5zaLiPo+XOlhLkp2DdGVUwfMjwmO0g/4Ogfqq2NBR2BZ4JTwyd
tX0GraXUc04ORErFiJdHx2vxx9lf9ysbvjts4ARE+w2ugV2Us7ZziCmu7uiOEALm
5Fozif5GYbQb2npssyszgA4brI8UWIChlpcr8QQP6IpuKmZK3yeRNzV5yC9UyfCg
NhrOl6UDdStqekQTgxdORezgz5vJTxREnJbEHYKJ3XIB0nM9ObXhObwPA46Jx64=
=kKwI
-END PGP SIGNATURE-

RE: tomcat severe error when shutting down service but startup is clean

2015-02-13 Thread Cris Berneburg - US 

 -Original Message-
 From: David kerber [mailto:dcker...@verizon.net]
 Sent: Thursday, February 12, 2015 9:40 AM
 To: Tomcat Users List
 Subject: Re: tomcat severe error when shutting down service but 
 startup is clean

 On 2/12/2015 9:06 AM, Wirth, Kevin wrote:
 I keep getting these weird tomcat errors on shutdown on a newly built system 
 using tomcat 7.0.57 on  a windows 2012 server with jdk 1.7 that I can't 
 figure out.  This is the catalina log:
 Feb 12, 2015 8:54:31 AM org.apache.catalina.loader.WebappClassLoader
 clearReferencesJdbc
 SEVERE: The web application [/identityiq] registered the JDBC driver 
 [com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it 
 when the web application was stopped. To prevent a memory leak, the JDBC 
 Driver has been forcibly unregistered.
 Feb 12, 2015 8:54:31 AM org.apache.catalina.loader.WebappClassLoader
 clearReferencesThreads
 SEVERE: The web application [/identityiq] appears to have started a thread 
 named [Thread-3] but has failed to stop it. This is very likely to create a 
 memory leak.

DK I ran into this a while back, and it means exactly what it says:  the db 
driver is being registered (loaded), but not being unloaded.  I fixed it by 
putting the db driver unload commands in a contextDestroyed method.

cb David
cb
cb I have the same issue as Kevin.  What unload commands code did you call 
in the contextDestroyed method?  Are those methods universal?  The reason I 
ask is because we use different ODBC drivers for different environments.

DK I call this code from my .contextDestroyed method (I didn't write it, I 
copied it from somewhere on the web):

DK public static void unRegisterDrivers() {
DK try {
DKfor ( EnumerationDriver drivers = DriverManager.getDrivers(); 
DK drivers.hasMoreElements(); ) {
DK   DriverManager.deregisterDriver( drivers.nextElement() );
DK}
DK } catch ( Exception e ) {
DK/* log the exception */
DK }
DK }

Thanks David!  That solved this error message:

message
org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc

SEVERE: The web application [/irma] registered the JDBC driver
[com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it when 
the web application
was stopped. To prevent a memory leak, the JDBC Driver has been forcibly 
unregistered.
/message

However, the one below still occurs, which I don't understand.  Is it saying 
that an instance of an object was created outside of java garbage collection 
control that is not being released?

message
org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks

SEVERE: The web application [/irma] created a ThreadLocal with key of type
[com.microsoft.sqlserver.jdbc.ActivityCorrelator$1] (value 
[com.microsoft.sqlserver.jdbc.ActivityCorrelator$1@dc160cb])
and a value of type [com.microsoft.sqlserver.jdbc.ActivityId] (value 
[de6bd261-6408-4336-86e2-375848be61b5-5])
but failed to remove it when the web application was stopped. This is very 
likely to create a memory leak.
/message

In the contextDestroyed listener method I added 
[System.out.println(String.valueOf(driver));] to try to get more info, but I'm 
not sure it provided anything meaningful:

log
sun.jdbc.odbc.JdbcOdbcDriver@49f4bcf7
SQLServerDriver:1
/log



 The jdbc driver I am using is in the folder identityiq under the webapps 
 directory in tomcat.  It is the sqljdbc4.jar driver.  This driver is not in 
 the tomcat\lib directory.  Please help because I am getting no help from the 
 vender.  Thank you.

 Kevin Wirth
 [...]


--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


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

RE: tomcat severe error when shutting down service but startup is clean

2015-02-12 Thread Cris Berneburg - US 

-Original Message-
From: David kerber [mailto:dcker...@verizon.net] 
Sent: Thursday, February 12, 2015 9:40 AM
To: Tomcat Users List
Subject: Re: tomcat severe error when shutting down service but startup is clean

On 2/12/2015 9:06 AM, Wirth, Kevin wrote:
 I keep getting these weird tomcat errors on shutdown on a newly built system 
 using tomcat 7.0.57 on  a windows 2012 server with jdk 1.7 that I can't 
 figure out.  This is the catalina log:
 Feb 12, 2015 8:54:31 AM org.apache.catalina.loader.WebappClassLoader 
 clearReferencesJdbc
 SEVERE: The web application [/identityiq] registered the JDBC driver 
 [com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it 
 when the web application was stopped. To prevent a memory leak, the JDBC 
 Driver has been forcibly unregistered.
 Feb 12, 2015 8:54:31 AM org.apache.catalina.loader.WebappClassLoader 
 clearReferencesThreads
 SEVERE: The web application [/identityiq] appears to have started a thread 
 named [Thread-3] but has failed to stop it. This is very likely to create a 
 memory leak.

 I ran into this a while back, and it means exactly what it says:  the db 
 driver is being registered (loaded), but not being unloaded.  I fixed it by 
 putting the db driver unload commands in a contextDestroyed method.

David

I have the same issue as Kevin.  What unload commands code did you call in 
the contextDestroyed method?  Are those methods universal?  The reason I ask 
is because we use different ODBC drivers for different environments.


 The jdbc driver I am using is in the folder identityiq under the webapps 
 directory in tomcat.  It is the sqljdbc4.jar driver.  This driver is not in 
 the tomcat\lib directory.  Please help because I am getting no help from the 
 vender.  Thank you.

 Kevin Wirth
 [...]



--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


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

RE: tomcat on windows 2012 weirdness

2014-12-18 Thread Cris Berneburg - US 
Chris

cb I interpret this to mean that my local IE browser thinks the 
cb intranet web site that I access either by name or by IP is actually
cb 2 different sites in 2 different security zones.  I will try to 
cb adjust my browser security settings and see if that makes any differences.

cs That sounds plausible. If IE changes its cookie policy based upon those 
zones, then you may have found the issue. I wonder if your local policy 
whitelists a certain IP range but doesn't use hostnames, which may account for 
the difference.

Turning off IE Compatibility Mode for intranet sites did boost the request 
header User-Agent from Mozilla/4.0 to Mozilla/5.0, but the browser still 
would not accept cookies.  I have since found the source of the problem and the 
solution, which I will send in a follow-up message.

cs Time to ask your webapp software vendor to fix their web application 
cs so it can be used without cookies ;)

Ouch!  I *am* the software developer for this web application.  :-)

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, December 17, 2014 5:41 PM
To: Tomcat Users List
Subject: Re: tomcat on windows 2012 weirdness

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 12/17/14 2:15 PM, Cris Berneburg - US wrote:
 Ameer (and Chris)
 
 I discovered something else.  When accessing the internal web site by 
 name, it does not work right.  But when I access the web site by IP 
 address, it functions correctly!
 
 If you are using IE9, it has a very useful utility in its developer 
 tool to capture network traffic. Few simple steps to capture it:
 Press F12 -- Go to network tab-- start capturing You can 
 save/export the captured data in an xml file and then can see 
 everything going to-and-fro between your browser and server.
 
 Compare the traffic when you are communicating from localhost, which 
 you say is working fine, with the traffic when you are accessing from 
 an outside client. Pay special attention to the headers section of 
 the HTTP calls.
 
 Thanks for your suggestion.  I tried the IE9 Developer Tools trace, 
 and it was revealing.  I noticed something strange.
 Accessing the web server by IP, the User-Agent was Mozilla/5.0, but 
 by server name User-Agent was Mozilla/4.0.  There are other header 
 differences too.  By IP has the session and cookie info, but by name 
 does not - aha!  The Accept header was different also.
 
 I interpret this to mean that my local IE browser thinks the intranet 
 web site that I access either by name or by IP is actually
 2 different sites in 2 different security zones.  I will try to adjust 
 my browser security settings and see if that makes any differences.

That sounds plausible. If IE changes its cookie policy based upon those zones, 
then you may have found the issue. I wonder if your local policy whitelists a 
certain IP range but doesn't use hostnames, which may account for the 
difference.

Time to ask your webapp software vendor to fix their web application so it can 
be used without cookies ;)

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

iQIcBAEBCAAGBQJUkgZyAAoJEBzwKT+lPKRYiw0QAIVq/Y8aO6JkXM0RQ4d2dWLX
4TDwVF0XI07uVa1QcvkgYxqdvd6pA4yOeZVbqDTv72gGG5gPnKVkqPTCp0lmoZ3m
SVxQ0fwSoJOFkzTVo8LMj/LtNYpMbgGr95S4uU7yEU9NvREYggEbD0npxVWt605Q
Z+WBvLoSCdmimEQFagCQDiqbx+daosd+Af+WUbP3DrKjT5aLj31CEp3hWzvjas3s
eYANOMe0bwf3s5oV1zcRHJLF9cO/mnFFn4ZTW8T9MFUJyYqgQg8rX7Kl5mynpiGt
SNOO3RF3IvEzosjMri0FKqrIvLL5TFt7cYvHKTWI0MH3eJERvAnV7HLFebfgaSVv
peBxNcNHTr0QLzmKbvM6ykF01xDfqxsBbOXz7CXb4XkHfj7JdoMSa/SuEWQIIc7X
vM5+Z4ObVF491VIq7AZBNLh/BwPVT8f5ot0QiFS234FeulfSqRH2rbDjHQhwP4Z0
bpVsmTyY9v2dJdmUZubTBOXgmKgyFSWInIEIEX6i7wQmJLeIU9fNflzg9/iqxxeb
WQtYu74SfP3MS79Fy6R/p1v4GxRIpSEIuE2Ovchnb9J3DXLkMKO03xcgu8IoupI9
OjHqjC6CnIV1XGS/cJL96bdAuPYvv3pvPloeT1u+gQ+3KdAf0/XJxBNPSFBOQZJ7
p7LIG+jYWMtX0x7pMWai
=KlDA
-END PGP SIGNATURE-


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

RE: tomcat on windows 2012 weirdness

2014-12-18 Thread Cris Berneburg - US 
Konstantin

Thanks for your response.  I was encouraged by your suggestion, thinking that 
setting would be the magic solution to my problem.  :-)

I wrote a very simple filter to set the response header for X-UA-Compatible: 
IE=edge.  However, it did not solve the problem.  I could see in the IE 
developer tools that the name and value were set.  But the request header 
User-Agent remained Mozilla/4.0, and the still browser would not accept 
cookies.

Turning off IE Compatibility Mode for intranet sites did boost the request 
header User-Agent from Mozilla/4.0 to Mozilla/5.0, but the browser still 
would not accept cookies.

I have since found the source of the problem and the solution, which I will 
send in a follow-up message.

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313

-Original Message-
From: Konstantin Preißer [mailto:kpreis...@apache.org] 
Sent: Wednesday, December 17, 2014 2:45 PM
To: 'Tomcat Users List'
Subject: RE: tomcat on windows 2012 weirdness

Hi,

 -Original Message-
 From: Cris Berneburg - US [mailto:cberneb...@caci.com]
 Sent: Wednesday, December 17, 2014 8:15 PM
 To: 'Tomcat Users List'
 Subject: RE: tomcat on windows 2012 weirdness
 
 Ameer (and Chris)
 
 I discovered something else.  When accessing the internal web site by 
 name, it does not work right.  But when I access the web site by IP 
 address, it functions correctly!
 
  If you are using IE9, it has a very useful utility in its developer 
  tool to
 capture network traffic. Few simple steps to capture it:
  Press F12 -- Go to network tab-- start capturing You can 
  save/export the
 captured data in an xml file and then can see everything going 
 to-and-fro between your browser and server.
 
  Compare the traffic when you are communicating from localhost, which
 you say is working fine, with the traffic when you are accessing from 
 an outside client.
  Pay special attention to the headers section of the HTTP calls.
 
 Thanks for your suggestion.  I tried the IE9 Developer Tools trace, 
 and it was revealing.  I noticed something strange.  Accessing the web 
 server by IP, the User-Agent was Mozilla/5.0, but by server name 
 User-Agent was Mozilla/4.0.  There are other header differences too.  
 By IP has the session and cookie info, but by name does not - aha!  
 The Accept header was different also.
 
 I interpret this to mean that my local IE browser thinks the intranet 
 web site that I access either by name or by IP is actually 2 different 
 sites in 2 different security zones.  I will try to adjust my browser 
 security settings and see if that makes any differences.

Just some additional notes about IE (I don't know if they are applicable to 
your situation):

- IE displays intranet sites in Compatibility mode by default (that is, IE7 
mode). This is why I always add the following HTTP header to websites:
X-UA-Compatible: IE=edge

This will ensure IE always uses the latest document mode/level. Note that with 
this header IE's browser mode can still be compatibility view (sending a 
Mozilla/4.0 MSIE 7.0 User-Agent) although the document mode will be the latest 
(IE9 on IE9, IE11 on IE11 etc.)

The Developer Tools should show the current browser mode and document mode of 
IE.


- In IE on a Windows Server OS, for security reasons the IE enhanced security 
mode is active which will block some content on websites in the internet 
security zone (while for intranet sites it will use a lower security level). 
This mode can be enabled or disabled in the Server Manager.


Regards,
Konstantin Preißer

RE: tomcat on windows 2012 weirdness - SOLUTION

2014-12-18 Thread Cris Berneburg - US 
Chris, Andre, Ameer, and Konstantin

Thank you all very much for your time, insight, and help.  I have a learned a 
lot about during this ordeal, and I am a better web developer for it.

OK, the source of and solution to the problem is...

Internet Explorer 9 will not accept cookies from Intranet sites?

http://superuser.com/questions/294895/internet-explorer-9-will-not-accept-cookies-from-intranet-sites

 My issue ended up that I was using an invalid character in my local fqdn.
 In my case it was underscore.
 www.website_dev.com
 That name didn't allow cookies to work. When I changed the underscore to a 
 hyphen everything was good.

Bingo!  Changed the server name and it worked.  All my angst due to a bug in 
IE.  Who would have ever guessed that?  ;-)

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, December 17, 2014 5:41 PM
To: Tomcat Users List
Subject: Re: tomcat on windows 2012 weirdness

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 12/17/14 2:15 PM, Cris Berneburg - US wrote:
 Ameer (and Chris)
 
 I discovered something else.  When accessing the internal web site by 
 name, it does not work right.  But when I access the web site by IP 
 address, it functions correctly!
 
 If you are using IE9, it has a very useful utility in its developer 
 tool to capture network traffic. Few simple steps to capture it: 
 Press F12 -- Go to network tab-- start capturing You can 
 save/export the captured data in an xml file and then can see 
 everything going to-and-fro between your browser and server.
 
 Compare the traffic when you are communicating from localhost, which 
 you say is working fine, with the traffic when you are accessing from 
 an outside client. Pay special attention to the headers section of 
 the HTTP calls.
 
 Thanks for your suggestion.  I tried the IE9 Developer Tools trace, 
 and it was revealing.  I noticed something strange.
 Accessing the web server by IP, the User-Agent was Mozilla/5.0, but 
 by server name User-Agent was Mozilla/4.0.  There are other header 
 differences too.  By IP has the session and cookie info, but by name 
 does not - aha!  The Accept header was different also.
 
 I interpret this to mean that my local IE browser thinks the intranet 
 web site that I access either by name or by IP is actually
 2 different sites in 2 different security zones.  I will try to adjust 
 my browser security settings and see if that makes any differences.

That sounds plausible. If IE changes its cookie policy based upon those zones, 
then you may have found the issue. I wonder if your local policy whitelists a 
certain IP range but doesn't use hostnames, which may account for the 
difference.

Time to ask your webapp software vendor to fix their web application so it can 
be used without cookies ;)

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

iQIcBAEBCAAGBQJUkgZyAAoJEBzwKT+lPKRYiw0QAIVq/Y8aO6JkXM0RQ4d2dWLX
4TDwVF0XI07uVa1QcvkgYxqdvd6pA4yOeZVbqDTv72gGG5gPnKVkqPTCp0lmoZ3m
SVxQ0fwSoJOFkzTVo8LMj/LtNYpMbgGr95S4uU7yEU9NvREYggEbD0npxVWt605Q
Z+WBvLoSCdmimEQFagCQDiqbx+daosd+Af+WUbP3DrKjT5aLj31CEp3hWzvjas3s
eYANOMe0bwf3s5oV1zcRHJLF9cO/mnFFn4ZTW8T9MFUJyYqgQg8rX7Kl5mynpiGt
SNOO3RF3IvEzosjMri0FKqrIvLL5TFt7cYvHKTWI0MH3eJERvAnV7HLFebfgaSVv
peBxNcNHTr0QLzmKbvM6ykF01xDfqxsBbOXz7CXb4XkHfj7JdoMSa/SuEWQIIc7X
vM5+Z4ObVF491VIq7AZBNLh/BwPVT8f5ot0QiFS234FeulfSqRH2rbDjHQhwP4Z0
bpVsmTyY9v2dJdmUZubTBOXgmKgyFSWInIEIEX6i7wQmJLeIU9fNflzg9/iqxxeb
WQtYu74SfP3MS79Fy6R/p1v4GxRIpSEIuE2Ovchnb9J3DXLkMKO03xcgu8IoupI9
OjHqjC6CnIV1XGS/cJL96bdAuPYvv3pvPloeT1u+gQ+3KdAf0/XJxBNPSFBOQZJ7
p7LIG+jYWMtX0x7pMWai
=KlDA
-END PGP SIGNATURE-


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

RE: tomcat on windows 2012 weirdness

2014-12-17 Thread Cris Berneburg - US 
Chris

Thanks again for your replies.  Meh, sorry for the double-negative about the 
cookies.  :-)

One thing I learned by trial and error is that accessing the internal web site 
by name behaves wrongly, but accessing it by IP behaves rightly!

Also, I must be wrong about the cookies being enabled/disabled anyway.  I did 
the IE9 trace Ameer suggested, and it was revealing.  It appears the cookies 
are conditional depending on how the server is accessed.  Will follow up in 
another message.

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, December 12, 2014 3:15 PM
To: Tomcat Users List
Subject: Re: tomcat on windows 2012 weirdness

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ameer,

On 12/12/14 3:11 PM, Ameer Mawia wrote:
 On Sat, Dec 13, 2014 at 1:06 AM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 Cris,
 
 On 12/12/14 2:18 PM, Cris Berneburg - US wrote:
 Hi Chris
 
 Thanks for your replies.  I am somewhat new to Tomcat, only been 
 using it for 1 year, so some of the technical details are new to 
 me.
 
 Is it possible that you are not using URL-based session ids, and 
 that your browser has cookies disabled via a policy?
 
 I will need to check URL-based session ids.  How do I check?
 
 If your browser has cookies disabled, then all the links on the web 
 pages in this web application should have a ;jsessionid=[id]
 path parameter added to them. See below.
 
 Also, my browser does not have cookies disabled.
 
 This is almost certainly the issue.
 
 
 Chris, I think he meant cookies are already enabled on his browser.

Ah! A double-negative. I read too quickly.

Well, the protocol analyzer will certainly help inform the conversation.

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

iQIcBAEBCAAGBQJUi0zKAAoJEBzwKT+lPKRYZHAQAJYqjchuvYXOuYQN2PmjAbly
dnlmXiOJIeaPVCaVtFy2oBxhxP0KaAZHFUdofF2n9Fx2s5EIL5fxexIp0wkQmmuE
PORs1Wm5Iz0ArOVCXcP3lBgQFYB/TRY0ryo/2MTQE7Eto77frBGL6gduqiHeelJn
vfJ9DF1IujxWadGVzhF6277wkANrL/RBJBr23ly/dBGmZ09mzGMtGWbLdXPxN6rv
IimC1K8/r4RKbz8qYRib1CCx2Rmn5xfxw5aAp0I71xyUdBygSH6DiZmzLKDalCnV
OqX6ujD5TlFO7x56I7/C+BdohZUXopTKQwVFnvbgbTsfBwZ9qNQCFtcI6QauYJWK
B9Q8Jo5uZ+7kSE/5U9EY6G6vZUKGBi2iqc13CWMrpMNOavjO9vIc823WBjkfPVIP
cd8WQgwjQaHLooGeHKxkPZDiUKXsIK4/aGLs38V2Oe3NvTnZLuWqAcXyuwke2/sP
Yav+Yp9F7QKIZnlJWSjIM3Nk4DZjg4P2p3pi/N+k3ko0g/4L9P4tBirE2BwzT/Yu
CpFLF//Io0xTeSk5BbB2ghTBY5dzZOZNA4oNhTAXvgvrLaENYKb2vwRu8ArACVR+
bBnFGgkEC+vl26KgcZVJEfrj+9Q+Q9eMAs7VkAIikfizZYogYdXBKNXdj+Y72LM2
/Cup5W8jGgaXJnzLCm8k
=lmci
-END PGP SIGNATURE-

RE: tomcat on windows 2012 weirdness

2014-12-17 Thread Cris Berneburg - US 
Ameer (and Chris)

I discovered something else.  When accessing the internal web site by name, it 
does not work right.  But when I access the web site by IP address, it 
functions correctly!

 If you are using IE9, it has a very useful utility in its developer tool to 
 capture network traffic. Few simple steps to capture it:
 Press F12 -- Go to network tab-- start capturing You can save/export the 
 captured data in an xml file and then can see everything going to-and-fro 
 between your browser and server.

 Compare the traffic when you are communicating from localhost, which you say 
 is working fine, with the traffic when you are accessing from an outside 
 client.
 Pay special attention to the headers section of the HTTP calls.

Thanks for your suggestion.  I tried the IE9 Developer Tools trace, and it was 
revealing.  I noticed something strange.  Accessing the web server by IP, the 
User-Agent was Mozilla/5.0, but by server name User-Agent was Mozilla/4.0.  
There are other header differences too.  By IP has the session and cookie info, 
but by name does not - aha!  The Accept header was different also.

I interpret this to mean that my local IE browser thinks the intranet web site 
that I access either by name or by IP is actually 2 different sites in 2 
different security zones.  I will try to adjust my browser security settings 
and see if that makes any differences.

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


-Original Message-
From: Ameer Mawia [mailto:ameer.ma...@gmail.com] 
Sent: Friday, December 12, 2014 3:12 PM
To: Tomcat Users List
Subject: Re: tomcat on windows 2012 weirdness

On Sat, Dec 13, 2014 at 1:06 AM, Christopher Schultz  
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Cris,

 On 12/12/14 2:18 PM, Cris Berneburg - US wrote:
  Hi Chris
 
  Thanks for your replies.  I am somewhat new to Tomcat, only been 
  using it for 1 year, so some of the technical details are new to me.
 
  Is it possible that you are not using URL-based session ids, and 
  that your browser has cookies disabled via a policy?
 
  I will need to check URL-based session ids.  How do I check?

 If your browser has cookies disabled, then all the links on the web 
 pages in this web application should have a ;jsessionid=[id] path 
 parameter added to them. See below.

  Also, my browser does not have cookies disabled.

 This is almost certainly the issue.


Chris, I think he meant cookies are already enabled on his browser.


 If your browser does not support cookies (Tomcat knows if you support 
 cookies if you send a JSESSIONID cookie, but it can't tell if you send 
 nothing), then the web application must fall-back to using URL-based 
 session-tracking.

 Unfortunately, this isn't entirely auto-magical: the web application 
 needs to support it properly. Most 3rd-party web applications should 
 already be doing things properly, but if you have an in-house 
 application, it may not be written properly.

 When emitting a URL onto a page for a client, the application needs to 
 run the URL through a call to HttpServletResponse.encodeURL(String) or 
 HttpServletResponse.encodeRedirectURL(String). These methods will add 
 the ;jsessionid=[id] path parameter to the URL when the client does 
 not support cookies. In this way, session-tracking will still work.

 If the application isn't doing this for *every URL in the whole 
 application*, then sessions can be dropped and the user will have to 
 re-authenticate. If this is the case, you only have two options:

 1. Re-enable cookies on your browser
 2. Review the application and fix every instance of a URL on a page 
 (it's a huge job)

  Is the browser or the server (or both) on Windows 2012?
 
  The server is on Win 2012. It works OK when both the browser and 
  server are the same 2012 VM. I don't know if it works when both 
  client and server are both Win 2012 but different machines. I will 
  be able to check that soon. It does not work with different client 
  OS version and box than the server, but that may simply be 
  coincidence.

 It may be a cookie policy: if localhost is trusted, the cookie policy 
 may change.

  Try using a protocol sniffer to see if the browser is sending a 
  session id to the server, and if the server is responding with a 
  session id either before or after login.
 
  Wow, that sounds intimidating - never done that before.  :-)

 It's worth learning how to do. I think there's a plug-in for MSIE 
 called IEHeaders (or something similar). Install that and you can 
 watch the conversation between client and server -- even when TLS is 
 being used.


If you are using IE9, it has a very useful utility in its developer tool to 
capture network traffic. Few simple steps to capture it:
Press F12 -- Go to network tab-- start capturing You can save/export the 
captured data in an xml file and then can see everything going to-and-fro 
between your browser

RE: tomcat on windows 2012 weirdness

2014-12-17 Thread Cris Berneburg - US 
Chris

 When emitting a URL onto a page for a client, the application needs to run 
 the URL through a call to HttpServletResponse.encodeURL(String) or 
 HttpServletResponse.encodeRedirectURL(String). These methods will add the 
 ;jsessionid=[id] path parameter to the URL when the client does not 
 support cookies. In this way, session-tracking will still work.

You are almost certainly correct about the sessions and cookies.  :-)  I 
tried another experiment.  I logged into the app to get to the main page and 
obtain a session.  The images did not load.  FYI, I checked the links and they 
do *not* append ;jsessionid=[id].  Then, I went to the address bar and 
requested one of the images that failed BUT appended ;jsessionid=[id].  (I 
obtained the active session ID from a Tomcat log file.)  The image loaded!

If the application isn't doing this for *every URL in the whole 
application*, then sessions can be dropped and the user will have to 
re-authenticate. If this is the case, you only have two options:
 1. Re-enable cookies on your browser  2. Review the application and 
fix every instance of a URL on a page (it's a huge job)

So the web application is *not* written correctly to handle when the client 
does not support cookies.  That is, it does not call HttpServletResponse 
.encodeURL or .encodeRedirectURL.  And wow, rewriting would be a huge job.  
:-)

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, December 12, 2014 2:36 PM
To: Tomcat Users List
Subject: Re: tomcat on windows 2012 weirdness

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 12/12/14 2:18 PM, Cris Berneburg - US wrote:
 Hi Chris
 
 Thanks for your replies.  I am somewhat new to Tomcat, only been using 
 it for 1 year, so some of the technical details are new to me.
 
 Is it possible that you are not using URL-based session ids, and that 
 your browser has cookies disabled via a policy?
 
 I will need to check URL-based session ids.  How do I check?

If your browser has cookies disabled, then all the links on the web pages in 
this web application should have a ;jsessionid=[id] path parameter added to 
them. See below.

 Also, my browser does not have cookies disabled.

This is almost certainly the issue.

If your browser does not support cookies (Tomcat knows if you support cookies 
if you send a JSESSIONID cookie, but it can't tell if you send nothing), then 
the web application must fall-back to using URL-based session-tracking.

Unfortunately, this isn't entirely auto-magical: the web application needs to 
support it properly. Most 3rd-party web applications should already be doing 
things properly, but if you have an in-house application, it may not be written 
properly.

When emitting a URL onto a page for a client, the application needs to run the 
URL through a call to HttpServletResponse.encodeURL(String) or 
HttpServletResponse.encodeRedirectURL(String). These methods will add the 
;jsessionid=[id] path parameter to the URL when the client does not support 
cookies. In this way, session-tracking will still work.

If the application isn't doing this for *every URL in the whole application*, 
then sessions can be dropped and the user will have to re-authenticate. If this 
is the case, you only have two options:

1. Re-enable cookies on your browser
2. Review the application and fix every instance of a URL on a page (it's a 
huge job)

 Is the browser or the server (or both) on Windows 2012?
 
 The server is on Win 2012. It works OK when both the browser and 
 server are the same 2012 VM. I don't know if it works when both client 
 and server are both Win 2012 but different machines. I will be able to 
 check that soon. It does not work with different client OS version and 
 box than the server, but that may simply be coincidence.

It may be a cookie policy: if localhost is trusted, the cookie policy may 
change.

 Try using a protocol sniffer to see if the browser is sending a 
 session id to the server, and if the server is responding with a 
 session id either before or after login.
 
 Wow, that sounds intimidating - never done that before.  :-)

It's worth learning how to do. I think there's a plug-in for MSIE called 
IEHeaders (or something similar). Install that and you can watch the 
conversation between client and server -- even when TLS is being used.

Hope that helps,
- -chris

 -Original Message- From: Christopher Schultz 
 [mailto:ch...@christopherschultz.net] Sent: Thursday, December 11,
 2014 1:35 PM To: Tomcat Users List Subject: Re: tomcat on windows
 2012 weirdness
 
 Cris,
 
 On 12/11/14 12:41 PM, Christopher Schultz wrote:
 Cris,
 
 On 12/11/14 11:28 AM, Cris Berneburg - US wrote:
 I'm having trouble with my JSP web app using Tomcat 6 and 7 on 
 Windows Server 2012.
 
 The issue is that no matter what file I request in the browser URL, 
 it always returns

RE: tomcat on windows 2012 weirdness

2014-12-12 Thread Cris Berneburg - US 
Hi Chris

Thanks for your replies.  I am somewhat new to Tomcat, only been using it for 1 
year, so some of the technical details are new to me.

 Is it possible that you are not using URL-based session ids, and that your 
 browser has cookies disabled via a policy?

I will need to check URL-based session ids.  How do I check?  Also, my browser 
does not have cookies disabled.

 Is the browser or the server (or both) on Windows 2012?

The server is on Win 2012.  It works OK when both the browser and server are 
the same 2012 VM.  I don't know if it works when both client and server are 
both Win 2012 but different machines.  I will be able to check that soon.  It 
does not work with different client OS version and box than the server, but 
that may simply be coincidence.

 Try using a protocol sniffer to see if the browser is sending a session id to 
 the server, and if the server is responding with a session id either before 
 or after login.

Wow, that sounds intimidating - never done that before.  :-)

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, December 11, 2014 1:35 PM
To: Tomcat Users List
Subject: Re: tomcat on windows 2012 weirdness

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 12/11/14 12:41 PM, Christopher Schultz wrote:
 Cris,
 
 On 12/11/14 11:28 AM, Cris Berneburg - US wrote:
 I'm having trouble with my JSP web app using Tomcat 6 and 7 on 
 Windows Server 2012.
 
 The issue is that no matter what file I request in the browser URL, 
 it always returns the app welcome file, that is, the login page. Even 
 when requesting an image.  The one exception is that after logging 
 in, the main menu page appears, but none of the graphics or CSS files 
 load.  Clicking on the app links, it just brings up the welcome page 
 again.  Checking the Tomcat log files, I see that Tomcat is returning 
 the welcome page instead of the files requested in the main menu 
 page.
 
 Using the Tomcat manager, I see that my application has a ridiculous 
 number of sessions, instead of just one.  I interpret that for every 
 single file requested, a new Tomcat session is being generated and 
 possibly invalidated.
 
 FYI, using the same setup on Windows Server 2003 and 2008 works fine. 
 Opening the same firewall ports on all three OS's has been done. Even 
 disabling the firewall on 2012 does not affect the issue in any way.  
 And to make things even weirder, accessing the application from a 
 browser on the server itself using localhost works fine!
 
 I wonder if there is some mystery setting somewhere that is crippling 
 the app.  Got any suggestions?  Please help.  Thanks!
 
 Check two quick things:
 
 1. Do you have any security-constraints in WEB-INF/web.xml? If so, do 
 they all make sense, and can users actually access those resources 
 once logged-in (or at all)?
 
 2. Do you have any servlets in WEB-INF/web.xml mapped to / other 
 than the DefaultServlet (which should be configured by default so you 
 shouldn't have to configure it yourself)?

After re-reading your post, it's pretty clear that my initial questions will be 
worthless and not help you.

Is it possible that you are not using URL-based session ids, and that your 
browser has cookies disabled via a policy? Is the browser or the server (or 
both) on Windows 2012?

Try using a protocol sniffer to see if the browser is sending a session id to 
the server, and if the server is responding with a session id either before or 
after login.

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

iQIcBAEBCAAGBQJUiePTAAoJEBzwKT+lPKRYORoP/iCMTFyLmWf6SCBbQX4HH7A+
zGFqVw95Iaf2Kd2xwMqy6xA8SLpVhtr/TezyJQQHTCg3pMgx9NS9kFZPV4QACEVF
iM6QGk0xnzEo5v4SBTgj9dp/aIF3eYQV0P6kkLGlEm7Zgno/nIHHRL3hYQAj+Lj9
f7czP1nEx2+OyoVtVedV1LxyvuohtUJto5/c1cslwl3+GhCYNqqAcFchdRjDp/KI
qt9IWvkC3OfS+asTfxJ23BITAHXnTDOemeIYZ9yRolVfbYzI8+JtNMDjMB69hQgS
yy45//MI38p50dW2+qxNk41R113I3rL7fvAV7lKJh6Eaxr/R0oxUgEj1cSv34s5X
x30feYSxmpVBveCgb4pmiGoZ/DmEhb53qHDs5EbPE3LkjkN9nAN1A9mGscwMETBC
SqF1ECgJz8H95hOOf/g45CZSyB+5fQ1VHoTGQQya6WBVYrvfl+tRxCMw2bP2/I2L
2Owl4IYOGZxqjkMHzX5ubRYqE2TLXo3pgTNKYRaR6fJhlR04gAZqdnAXCES67VD0
WSFqSQcMZYuzZvCAJ87YOiCLbvF48uV2BEOUTmxp92f1i1o3qoAqrmOZVtP1d+Gu
rxXHYjd0sw0jV27VWpoWc0KVsLP/ZXxKrjU2h8OE0vr5MHeZkPyj6YKs9BISV8An
30qBjkuotwNX319XEmtz
=zyqf
-END PGP SIGNATURE-

RE: tomcat on windows 2012 weirdness

2014-12-12 Thread Cris Berneburg - US 
Andre

Thanks for taking the time to respond to my plea.  :-)

 the way you describe it sounds like an authentication problem, where a bunch 
 of near simultaneous requests to the server (for embedded images, css, etc.) 
 all hit some not yet authenticated condition, and all together (or rather 
 each separately) return a 401 or similar (or a login page instead of a 
 requested image e.g.).  Maybe there is something new in that respect with 
 Windows Server 2012, which your application's authentication framework does 
 not handle well ?

My problem is that I don't know what changed in Win 2012 that would cause 
Tomcat to behave differently.  Perhaps it's a default security setting that 
changed?  FYI, I can request image files from the 2008 server w/o being logged 
in and they display just fine.

Below is a sample from my localhost_access_log.  Notice that all the files, 
except for the favicon which we don't have, all return a status of 200 and size 
3715 - the welcome file - no matter what was requested.  200 means OK, right?

10.25.20.35 - - [03/Dec/2014:11:50:04 -0500] GET /app/ HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:50:05 -0500] GET /app/include/styles.css 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:50:05 -0500] GET /app/css/GridStyle.css 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:50:05 -0500] GET /app/images/back2.gif 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:50:06 -0500] GET /images/favicon.ico HTTP/1.1 
404 987
10.25.20.35 - - [03/Dec/2014:11:51:27 -0500] POST /app/Login HTTP/1.1 200 5526
10.25.20.35 - - [03/Dec/2014:11:51:27 -0500] GET /app/include/styles.css 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:51:27 -0500] GET /app/images/back2.gif 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:51:27 -0500] GET /app/css/GridStyle.css 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:51:27 -0500] GET /app/images/f15.jpg HTTP/1.1 
200 3715
10.25.20.35 - - [03/Dec/2014:11:51:28 -0500] GET /app/images/tab-off.gif 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:51:28 -0500] GET /images/favicon.ico HTTP/1.1 
404 987
10.25.20.35 - - [03/Dec/2014:11:59:08 -0500] GET /app/main/main.jsp HTTP/1.1 
200 3715
10.25.20.35 - - [03/Dec/2014:11:59:08 -0500] GET /app/include/styles.css 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:59:08 -0500] GET /app/images/back2.gif 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:59:08 -0500] GET /app/css/GridStyle.css 
HTTP/1.1 200 3715
10.25.20.35 - - [03/Dec/2014:11:59:08 -0500] GET /app/images/favicon.ico 
HTTP/1.1 200 3715

 (or the structure of your application).
 (e.g. the login page itself contains references to images and css which 
 themselves are in a protected area and so on).

Eh, the login page itself is really plain - no images in it.  Just the pages 
afterwards once you log in.

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313


-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Thursday, December 11, 2014 1:22 PM
To: Tomcat Users List
Subject: Re: tomcat on windows 2012 weirdness

Cris Berneburg - US wrote:
 Hi Folks
 
 I'm having trouble with my JSP web app using Tomcat 6 and 7 on Windows Server 
 2012.
  
 The issue is that no matter what file I request in the browser URL, it always 
 returns the app welcome file, that is, the login page.  Even when requesting 
 an image.  The one exception is that after logging in, the main menu page 
 appears, but none of the graphics or CSS files load.  Clicking on the app 
 links, it just brings up the welcome page again.  Checking the Tomcat log 
 files, I see that Tomcat is returning the welcome page instead of the files 
 requested in the main menu page.
 
 Using the Tomcat manager, I see that my application has a ridiculous number 
 of sessions, instead of just one.  I interpret that for every single file 
 requested, a new Tomcat session is being generated and possibly invalidated..
 
 FYI, using the same setup on Windows Server 2003 and 2008 works fine.  
 Opening the same firewall ports on all three OS's has been done.  Even 
 disabling the firewall on 2012 does not affect the issue in any way.  And to 
 make things even weirder, accessing the application from a browser on the 
 server itself using localhost works fine!
 
 I wonder if there is some mystery setting somewhere that is crippling the 
 app.  Got any suggestions?  Please help.  Thanks!
 

Without realling getting to the bottom of it, the way you describe it sounds 
like an authentication problem, where a bunch of near simultaneous requests to 
the server (for embedded images, css, etc.) all hit some not yet 
authenticated condition, and all together (or rather each separately) return a 
401 or similar (or a login page instead of a requested image e.g.).

Maybe there is something new in that respect with Windows Server 2012, which 
your application's authentication framework does not handle well ?
(or the structure of your application).
(e.g. the login

tomcat on windows 2012 weirdness

2014-12-11 Thread Cris Berneburg - US 
Hi Folks

I'm having trouble with my JSP web app using Tomcat 6 and 7 on Windows Server 
2012.
 
The issue is that no matter what file I request in the browser URL, it always 
returns the app welcome file, that is, the login page.  Even when requesting an 
image.  The one exception is that after logging in, the main menu page appears, 
but none of the graphics or CSS files load.  Clicking on the app links, it just 
brings up the welcome page again.  Checking the Tomcat log files, I see that 
Tomcat is returning the welcome page instead of the files requested in the main 
menu page.

Using the Tomcat manager, I see that my application has a ridiculous number of 
sessions, instead of just one.  I interpret that for every single file 
requested, a new Tomcat session is being generated and possibly invalidated.

FYI, using the same setup on Windows Server 2003 and 2008 works fine.  Opening 
the same firewall ports on all three OS's has been done.  Even disabling the 
firewall on 2012 does not affect the issue in any way.  And to make things even 
weirder, accessing the application from a browser on the server itself using 
localhost works fine!

I wonder if there is some mystery setting somewhere that is crippling the app.  
Got any suggestions?  Please help.  Thanks!

--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313



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