<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.jakarta.tomcat.user">
    <title>gmane.comp.jakarta.tomcat.user</title>
    <link>http://blog.gmane.org/gmane.comp.jakarta.tomcat.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221925"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221924"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221923"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221922"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221921"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221920"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221919"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221918"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221917"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221916"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221915"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221914"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221913"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221912"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221911"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221910"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221909"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221908"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221907"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221906"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221925">
    <title>Re: Shared data source (Bug 49543)</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221925</link>
    <description>&lt;pre&gt;Exactly, I had no way of knowing because the documentation of ResourceLink
does not inform these "details". :)

Konstantin was perfect in his description in bugzilla.



On Thu, May 24, 2012 at 12:06 PM, Christopher Schultz &amp;lt;
chris&amp;lt; at &amp;gt;christopherschultz.net&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Robert Anderson</dc:creator>
    <dc:date>2012-05-24T15:23:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221924">
    <title>Re: memory leak in tomcat</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221924</link>
    <description>&lt;pre&gt;Is this the same server with the Wicket app you posted about earlier ?
If so, you have a Wicket app that is storing the
SessionFactoryObjectFactory on a page as a class member. Wicket stores
each page a user has been to in the user's session. If the page has
class members, then it serializes them and stores them too. I have seen
this kind of thing happen many times before causing big memory usage.

Remove the Wicket app and run the Eclipse Memory Analyzer.

Thanks,

Warren Bell

On 5/24/12 5:42 AM, Konstantin Kolinko wrote:
&lt;/pre&gt;</description>
    <dc:creator>Warren Bell</dc:creator>
    <dc:date>2012-05-24T15:22:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221923">
    <title>Re: user switching or application interacting with container based authentication</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221923</link>
    <description>&lt;pre&gt;
Upon further thinking, of course you would not necessarily need an Apache httpd front-end 
for this, and could do this all within Tomcat.
The container-level authentication comes first, before your webapp is even called.
So that is your Tomcat-level authentication, by company.
Then you could still have some servlet filter (which runs after the container-level 
authentication) to pick up this special POST parameter and do your "application-level" 
authentication.
&lt;/pre&gt;</description>
    <dc:creator>André Warnier</dc:creator>
    <dc:date>2012-05-24T15:20:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221922">
    <title>Re: user switching or application interacting with container based authentication</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221922</link>
    <description>&lt;pre&gt;
So, if I understand correctly :
- the first level of authentication is, say, by company, and is meant basically to avoid 
some unauthorised people accessing the website of each customer
- the second level of authentication is within this company's dedicated website, and is 
meant to distinguish between different "actors" within that website.
- and within the website, there is an incentive for the actors to use their own id, and 
not someone else's when they do something

As far as the "within the one website" thing is concerned, the other suggestions that you 
have received seem the way to go.  How you really integrate that into each action that 
these people do, I don't know really.
But I would imagine that you could have some kind of applet within your web pages, which 
reads a barcode from a barcode reader, and adds what it has read as a POST parameter, 
before it submits the form to the server.
And then on the server, you pick up this special parameter, and switch the userPrincipal 
on-the-fly, as they say.

As far as the first-level authentication is concerned, here is maybe a bit of lateral 
thinking :
If you put an Apache httpd front-end in front of Tomcat, then you could install some form 
of standard authentication at the Apache httpd level, which protects that website "in 
general" with the "company login".  Then only if that authentication succeeds, you would 
proxy the calls to Tomcat (using mod_jk for instance).  But Tomcat would know nothing 
about this front-end authentication, and would not need to know.
Similarly, Apache httpd would never know - nor need to know - when the user at the Tomcat 
level changes.

I think such a scheme would keep things nicely separated, and simplify the whole design.
&lt;/pre&gt;</description>
    <dc:creator>André Warnier</dc:creator>
    <dc:date>2012-05-24T15:15:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221921">
    <title>Re: memory leak in tomcat</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221921</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Konstantin,

On 5/24/12 8:42 AM, Konstantin Kolinko wrote:

It may, if the ClassLoader holds references to Class objects (it does)
that contain static members with lots of data (not so sure about this
part).


+1

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk++T9YACgkQ9CaO5/Lv0PAwAQCfZSz67ALyFrRfZaVYs6Tjoee7
Q4UAnA/Q2vIjecxXPEW+BzsN7GeSJQk3
=zQcP
-----END PGP SIGNATURE-----
&lt;/pre&gt;</description>
    <dc:creator>Christopher Schultz</dc:creator>
    <dc:date>2012-05-24T15:12:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221920">
    <title>Re: Shared data source (Bug 49543)</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221920</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert,

On 5/24/12 10:57 AM, Robert Anderson wrote:

Gotcha: you didn't know that this was an example only relevant to
tomcat-jdbc (not that you should have -- I didn't know, either). I
thought you were already using tomcat-jdbc and I believe the docs
there are accurate.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk++ToIACgkQ9CaO5/Lv0PDFHQCgrXsXmL3C/Cc3a74Lt8ul8Ton
RyQAn0WwW4ZfQVJz3s8pHHh/ulBm7vwX
=XrXd
-----END PGP SIGNATURE-----
&lt;/pre&gt;</description>
    <dc:creator>Christopher Schultz</dc:creator>
    <dc:date>2012-05-24T15:06:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221919">
    <title>RE: maxParameterCount with Tomcat 5.5.23</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221919</link>
    <description>&lt;pre&gt;For my Red Hat delivered Tomcat, changes to the connector attribute were ignored. However, I did find a fix that works.

In tomcat5.conf, after all other settings are added to JAVA_OPTS, add the value you desire for max parameter count like this:

# RH KB 100383
# Override default max parameter count of 512
JAVA_OPTS="$JAVA_OPTS -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=10000"

The Red Hat KB article references JBoss run script, but the above works fine for standalone Tomcat.

-----Original Message-----
From: Caldarale, Charles R [mailto:Chuck.Caldarale&amp;lt; at &amp;gt;unisys.com] 
Sent: Friday, May 11, 2012 3:51 PM
To: Tomcat Users List
Subject: RE: maxParameterCount with Tomcat 5.5.23



It would be interesting to know who's publishing such garbage.


Not on a Tomcat mangled by Red Hat - you're on your own with that.  If you use a real Tomcat, it will certainly work.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe&amp;lt; at &amp;gt;tomcat.apache.org
For additional commands, e-mail: users-help&amp;lt; at &amp;gt;tomcat.apache.org
&lt;/pre&gt;</description>
    <dc:creator>Haenni, Tia</dc:creator>
    <dc:date>2012-05-24T14:59:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221918">
    <title>Re: Shared data source (Bug 49543)</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221918</link>
    <description>&lt;pre&gt;Chris,

Basically, the ResourceLink documentation doesn't say that to enable shared
pool with different credentials:

1) You have to add tomcat-jdbc.jar in Tomcat 6.0 classpath;

2) You have to put the attributes in global resource definition:
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" and
alternateUsernameAllowed="true".


Cheers,

Robert

On Thu, May 24, 2012 at 11:46 AM, Christopher Schultz &amp;lt;
chris&amp;lt; at &amp;gt;christopherschultz.net&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Robert Anderson</dc:creator>
    <dc:date>2012-05-24T14:57:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221917">
    <title>Re: Shared data source (Bug 49543)</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221917</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert,

On 5/24/12 7:50 AM, Robert Anderson wrote:

So, how does your "script" deviate from the Tomcat documentation? It
seems that you followed the docs and now it works. Right?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk++ScsACgkQ9CaO5/Lv0PAy4ACWNsbvFopO5tY0s0SXCDfnmXEb
7wCfTJA3lvlqkl7hXrAcVB70EREQ7EU=
=ssa2
-----END PGP SIGNATURE-----
&lt;/pre&gt;</description>
    <dc:creator>Christopher Schultz</dc:creator>
    <dc:date>2012-05-24T14:46:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221916">
    <title>Re: user switching or application interacting with container based authentication</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221916</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris,

On 5/23/12 7:06 PM, chris derham wrote:

NB: ACEGI is now called "Spring Security".

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk++R/gACgkQ9CaO5/Lv0PAgXwCgtJy6H3IQ/zTXXAGE8NTfmYMN
nSEAnjDvGCXJBkvAyP4dTtCNgGq0Bnp/
=xMMQ
-----END PGP SIGNATURE-----
&lt;/pre&gt;</description>
    <dc:creator>Christopher Schultz</dc:creator>
    <dc:date>2012-05-24T14:38:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221915">
    <title>Re: user switching or application interacting with container based authentication</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221915</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dirk,

On 5/23/12 7:01 PM, dirk ooms wrote:

We use securityfilter for AAA and the user is stored in the session:
you can just replace the user object and boom: you are a new user. We
support "user impersonation" in this way and allows administrators to
masquerade as another user and then go back to their original login.

Switching to securityfilter may not be a great plan for you, though
it's not terribly hard to do. But, its a possibility.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk++R7gACgkQ9CaO5/Lv0PBVSQCePHZUW/l2Ybdcqegu206zfY+g
6rIAniyLbfpW0m96AeietxvHYXysOW7r
=ROLF
-----END PGP SIGNATURE-----
&lt;/pre&gt;</description>
    <dc:creator>Christopher Schultz</dc:creator>
    <dc:date>2012-05-24T14:37:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221914">
    <title>Re: encrypt the database password</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221914</link>
    <description>&lt;pre&gt;yes, there is, search http://tomcat.markmail.org for the same
org.apache.tomcat.util.digester.PROPERTY_SOURCE
is a system property where you can add the code that digests properties in server.xml
This code can 'decode' your encoded properties



----- Original Message -----
&lt;/pre&gt;</description>
    <dc:creator>Filip Hanik Mailing Lists</dc:creator>
    <dc:date>2012-05-24T14:19:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221913">
    <title>Re: Shared data source (Bug 49543)</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221913</link>
    <description>&lt;pre&gt;2012/5/24 Robert Anderson &amp;lt;ranomail&amp;lt; at &amp;gt;gmail.com&amp;gt;:

I added it to Bugzilla.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53289


Thank you. It is good to have a working example.

Best regards,
Konstantin Kolinko
&lt;/pre&gt;</description>
    <dc:creator>Konstantin Kolinko</dc:creator>
    <dc:date>2012-05-24T14:03:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221912">
    <title>Re: memory leak in tomcat</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221912</link>
    <description>&lt;pre&gt;2012/5/24 Christian Kaufhold &amp;lt;kaufhold4j&amp;lt; at &amp;gt;googlemail.com&amp;gt;:

So the memory is used for something useful? That is not a "memory
leak". It is just a web application requiring a lot of memory.

WebappClassLoader is the classloader that is used to load the classes
of your webapp.  Of course, it remembers every class that it loaded
(to satisfy repeated class.forName() calls) and every class that it
loads has a reference it it (via getClass().getClassLoader()).

There may be many classes, but I do not think that the classloader
itself is responsible for 300 Mb of memory.


That would be a hibernate question. I have no clue what that class is about.

Best regards,
Konstantin Kolinko
&lt;/pre&gt;</description>
    <dc:creator>Konstantin Kolinko</dc:creator>
    <dc:date>2012-05-24T12:42:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221911">
    <title>Re: memory leak in tomcat</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221911</link>
    <description>&lt;pre&gt;

One giant leap in the dark and totally-uneducated guess : due to some logical or 
configuration error, this application creates a new session at each request, and they 
never time out ?
&lt;/pre&gt;</description>
    <dc:creator>André Warnier</dc:creator>
    <dc:date>2012-05-24T12:38:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221910">
    <title>memory leak in tomcat</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221910</link>
    <description>&lt;pre&gt;Hi,

I have a leaking Tomcat App
I checked the heap with the Eclipse Memory Analyser
and it says

The classloader/component *"org.apache.catalina.loader.WebappClassLoader &amp;lt; at &amp;gt;
0x94532f50"*
occupies *376.421.152 (79,51%)* bytes. The memory is accumulated in one
instance of
*"java.util.HashMap$Entry[]"* loaded by *"&amp;lt;system class loader&amp;gt;"*.

and the data that is in the entries of the gigantic Map is
org.hibernate.impl.SessionFactoryObjectFactory

Does anyone know why this?

Christian




**
  Class Name Shallow Heap Retained Heap

   - java.util.HashMap$Entry[64] &amp;lt; at &amp;gt; 0xaa9314c0 &amp;lt;mat://object/0xaa9314c0&amp;gt;

272 339.906.832 [image: \]

   - *table* java.util.HashMap &amp;lt; at &amp;gt; 0xaa931498 &amp;lt;mat://object/0xaa931498&amp;gt;

40 339.906.872 [image: .][image: \]

   - *map* org.hibernate.util.FastHashMap &amp;lt; at &amp;gt; 0x94e4bc98&amp;lt;mat://object/0x94e4bc98&amp;gt;

16 339.906.888 [image: .][image: .][image: \]

   - *INSTANCES* class org.hibernate.impl.SessionFactoryObjectFactory &amp;lt; at &amp;gt;
   0x759319f8 &amp;lt;mat://object/0x759319f8&amp;gt;

24 339.907.088 [image: .][image: .][image: .][image: \]

   - *[1788]* java.lang.Object[5120] &amp;lt; at &amp;gt; 0x95148470 &amp;lt;mat://object/0x95148470&amp;gt;

20.496 375.206.992 [image: .][image: .][image: .][image: .][image: \]

   - *elementData* java.util.Vector &amp;lt; at &amp;gt; 0x94538998 &amp;lt;mat://object/0x94538998&amp;gt;

24 375.207.016 [image: .][image: .][image: .][image: .][image: .][image: \]

   - *classes* org.apache.catalina.loader.WebappClassLoader &amp;lt; at &amp;gt;
0x94532f50&amp;lt;mat://object/0x94532f50&amp;gt;

176 376.421.152 [image: .][image: .][image: .][image: .][image:
.][image: .][image:
+]

   - *contextClassLoader* java.lang.Thread &amp;lt; at &amp;gt; 0x94e1ac60
Thread-10&amp;lt;mat://object/0x94e1ac60&amp;gt;
   *Thread*

112 7.112 [image: .][image: .][image: .][image: .][image: .][image: .][image:
+]

   - *contextClassLoader* de.bfd.tools.ConnectionPool$ConnPoolMultiCaster &amp;lt; at &amp;gt;
   0x94e1ad00 Thread-9 &amp;lt;mat://object/0x94e1ad00&amp;gt; »

136 592 [image: .][image: .][image: .][image: .][image: .][image: .][image:
+]

   - *contextClassLoader* java.lang.Thread &amp;lt; at &amp;gt; 0x9bb7b548
Keep-Alive-Timer&amp;lt;mat://object/0x9bb7b548&amp;gt;»

112 168 [image: .][image: .][image: .][image: .][image: .][image: .][image:
+]

   - *classloader* java.security.ProtectionDomain &amp;lt; at &amp;gt;
0x9453a160&amp;lt;mat://object/0x9453a160&amp;gt;»
&lt;/pre&gt;</description>
    <dc:creator>Christian Kaufhold</dc:creator>
    <dc:date>2012-05-24T12:21:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221909">
    <title>Re: Shared data source (Bug 49543)</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221909</link>
    <description>&lt;pre&gt;Hi,

Now it's working! Follows the script:

1) Tomcat 6.0.35: copy tomcat-jdbc.jar to CATALINA_HOME/lib. Tomcat 7.0.x
is ready.

2)  Create a global resource in CATALINA_HOME/conf/server.xml. Attributes
in bold *MUST *be present:

    &amp;lt;Resource name="jdbc/pgserver" auth="Container"
type="javax.sql.DataSource" removeAbandoned="true"
removeAbandonedTimeout="300"
                                   maxActive="200" maxIdle="10"
maxWait="10000"
                                   validationQuery="select 1"
                                   validationInterval="10000"
                                   testOnBorrow="true"
*
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"*
                                   driverClassName="org.postgresql.Driver"

url="jdbc:postgresql://localhost:5432/tjse"
                                   username="globaluser"
                                   password="globalpassword"
*                                   alternateUsernameAllowed="true"*

jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer"
                                   /&amp;gt;


3)  Create a context.xml for apps;

The attribute "name" need not possess the same value of the attribute
"global".

--&amp;gt; CATALINA_HOME/conf/Catalina/localhost/app1.xml (shared connection with
different credential)

&amp;lt;Context&amp;gt;
    &amp;lt;ResourceLink name="jdbc/pgserver"
    global="jdbc/pgserver"
    type="javax.sql.DataSource"
*    factory="org.apache.naming.factory.DataSourceLinkFactory"*
*    username="userapp1"
    password="passwordapp1"*
    /&amp;gt;
&amp;lt;/Context&amp;gt;

--&amp;gt; CATALINA_HOME/conf/Catalina/localhost/app2.xml (shared connection with
default credential)

&amp;lt;Context&amp;gt;
    &amp;lt;ResourceLink name="jdbc/pgserver"
    global="jdbc/pgserver"
    type="javax.sql.DataSource"
    /&amp;gt;
&amp;lt;/Context&amp;gt;


4) JSP to test this feature (in both CATALINA_HOME/webapps/app1 and
CATALINA_HOME/webapps/app2):

&amp;lt;?xml version="1.0" encoding="ISO-8859-1"?&amp;gt;
&amp;lt;!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&amp;gt;
&amp;lt;%&amp;lt; at &amp;gt; page session="false" import="javax.naming.*, java.sql.*, javax.sql.*" %&amp;gt;
&amp;lt;html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"&amp;gt;
    &amp;lt;head&amp;gt;
    &amp;lt;title&amp;gt;Test shared data source&amp;lt;/title&amp;gt;
&amp;lt;/head&amp;gt;
&amp;lt;body&amp;gt;
&amp;lt;%
    Context ctx = null;
    DataSource ds = null;
    Connection c = null;
    Statement stm = null;
    ResultSet rs = null;

    try {

    ctx = new InitialContext();
    ds = (DataSource)ctx.lookup("java:comp/env/jdbc/pgserver");
    c = ds.getConnection();
    stm = c.createStatement();

    rs = stm.executeQuery("select current_user");

    rs.next();

%&amp;gt;
    Current user: &amp;lt;%= rs.getString(1) %&amp;gt;&amp;lt;br/&amp;gt;
&amp;lt;%
    } catch (Exception e) {
%&amp;gt;
    Error: &amp;lt;%= e.getMessage() %&amp;gt;
&amp;lt;%
    } finally {
     if (rs!=null) try  { rs.close(); } catch (Exception ignore){}
     if (stm!=null) try  { stm.close(); } catch (Exception ignore){}
     if (c!=null) try { c.close();} catch (Exception ignore){}    }
%&amp;gt;
&amp;lt;/body&amp;gt;
&amp;lt;/html&amp;gt;


5) App1 output:

Current user: userapp1

6) App2 output:

Current user: globaluser


Thanks and I hope this script can help others with the same problem.


Cheers,

Robert

On Wed, May 23, 2012 at 8:38 PM, Robert Anderson &amp;lt;ranomail&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Robert Anderson</dc:creator>
    <dc:date>2012-05-24T11:50:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221908">
    <title>Re: user switching or application interacting with container based authentication</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221908</link>
    <description>&lt;pre&gt;Andre,

thanks for your thoughts on this. i agree that this issue brings me to
'a loop of increasing contradictions'.  it's probably good to go one
step back and explain the real-life requirement:

we have an application that is used by many small companies, each
company has its own data and can have multiple users (typically 1 to 5).
within a company there is a requirement to switch users in a fast way
(e.g. using a badge or a fingerprint). think of a restaurant having 1
computer and several waiters. we want to trace what is done by which
waiter and there is also an incentive for the waiter to switch users
because his fee will be based on his logged activities.

my reasoning was: i'll keep the standard proven AAA mechanism for the
initial log in, but allow fast user switching within a company where
there is more trust between users (which is security-wise probably a
weak statement). still there is a need for some type of authentication
because the users can have different roles. but this indeed leads to
conflicts between the standard and the proprietary
authentication/authorization mechanism.

my current reasoning is: i need to keep a standard proven AAA mechanism
also for fast user switching. correct? but how do i tackle this given
that we now have form/container-based authentication. do i need a
parallel standard container-based mechanism? what mechanism exists that
allows to authenticate by scanning a barcode (i.e. a single (possibly
long) string)? any pointer/suggestion will be much appreciated.

dirk


&lt;/pre&gt;</description>
    <dc:creator>dirk ooms</dc:creator>
    <dc:date>2012-05-24T10:31:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221907">
    <title>Re: Tomcat 7. MX4J</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221907</link>
    <description>&lt;pre&gt;HI Vadzim,

as you like a hot HTTP-JMX access use

http://www.jolokia.org/

chili...

Peter

 
Am 23.05.2012 um 00:06 schrieb Vadzim Mikhalenak:

&lt;/pre&gt;</description>
    <dc:creator>Peter Roßbach</dc:creator>
    <dc:date>2012-05-24T10:19:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221906">
    <title>Re: user switching or application interacting with container based authentication</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221906</link>
    <description>&lt;pre&gt;
Without going into the technique itself, from your description above it looks to me as if 
this is a scenario so different from what a standard AAA mechanism is designed to achieve, 
that you are going to find yourself getting into a loop of increasing contradictions, if 
you try to fit this into the standard authentication mechanisms.
(In other words : you are going to be using code that has been carefully designed and 
perfected to do things well in one scenario, and try to do something else with it.  I 
would expect all kinds of side-effects, and an endless series of patches upon patches to 
avoid them).

Maybe the first question to ask : why do you need the user to be authenticated /to the 
servlet container/ in the first place ? when, and for what, do you use the return values 
of getUserPrincipal() and/or isUserInRole() ? (I mean really, deep down)

If you rethink the above, imagining that the user-id is just a request parameter like any 
other &amp;lt;form&amp;gt; parameter (*), and that Tomcat itself has no knowledge of an authenticated 
user, what breaks down ?



(*) which according to your own explanation above, you are going to have to do at some 
point anyway.
&lt;/pre&gt;</description>
    <dc:creator>André Warnier</dc:creator>
    <dc:date>2012-05-24T07:37:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221905">
    <title>RE: encrypt the database password</title>
    <link>http://permalink.gmane.org/gmane.comp.jakarta.tomcat.user/221905</link>
    <description>&lt;pre&gt;

Only if you don't bother to protect access to your Tomcat server.  And if you don't do that, you've got much, much bigger problems than someone discovering the DB password.


It's amazing how often this inept question comes up.  If you encrypt the password in server.xml, how do you expect Tomcat to open data base connections?  Read the FAQ:

http://wiki.apache.org/tomcat/FAQ/Password

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
&lt;/pre&gt;</description>
    <dc:creator>Caldarale, Charles R</dc:creator>
    <dc:date>2012-05-24T06:12:03</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.jakarta.tomcat.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.jakarta.tomcat.user</link>
  </textinput>
</rdf:RDF>

