RE: tomcat-user.xml re-writing - bug?

[Extance, Paul]

Bug 22715 posted

> BTW, what makes you think UserDatabase is new? ;)

As opposed to the old MemoryRealm from Tomcat 4.0.x, which is now commented
out by default in server.xml :-)

  
  

PaulE


-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 25, 2003 10:44 AM
To: Tomcat Users List
Subject: RE: tomcat-user.xml re-writing - bug?


Howdy,
It looks like a bug -- file it in Bugzilla.

You can't stop the file being re-written, and if you have any comments
in the file they'll be removed.

I'm not sure if XML entities are allowed or not.  It's really intended
to be a simple, get started quickly mechanism.  Not a complete
enterprise user database solution ;)

BTW, what makes you think UserDatabase is new? ;)

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Extance, Paul [mailto:[EMAIL PROTECTED]
>Sent: Monday, August 25, 2003 1:20 PM
>To: 'Tomcat Users List'
>Subject: tomcat-user.xml re-writing - bug?
>
>Hi,
>
>I'm using the new UserDatabase (org.apache.catalina.UserDatabase /
>org.apache.catalina.users.MemoryUserDatabaseFactory) as configured by
>default with Tomcat 4.1.27.
>
>Our System admin made a basic XML error, and in tomcat-users.xml put
and
>entry in like...
>
>
>
>Obviously the '&' makes this invalid XML, and tomcat doesn't start...
>
>We changed the & to & the XML was then valid, the user account
worked,
>life was good
>
>A few days later, after he restarted the server, it was broke again...
>
>Seems that when Tomcat re-wrote out the tomcat-users.xml file, instead
of
>escaping the & and writing it back out as & it just put it out a &,
so
>we were back to square one!
>
>Question:
>1) Is this a bug?
>2) Can I stop the 're-writing' part of this as a work around?
>3) Are XML entities not allowed in tomcat-users.xml?
>
>Thanx
>
>PaulE
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

tomcat-user.xml re-writing - bug?

[Extance, Paul]

Hi,

I'm using the new UserDatabase (org.apache.catalina.UserDatabase /
org.apache.catalina.users.MemoryUserDatabaseFactory) as configured by
default with Tomcat 4.1.27.

Our System admin made a basic XML error, and in tomcat-users.xml put and
entry in like...



Obviously the '&' makes this invalid XML, and tomcat doesn't start...

We changed the & to & the XML was then valid, the user account worked,
life was good

A few days later, after he restarted the server, it was broke again...

Seems that when Tomcat re-wrote out the tomcat-users.xml file, instead of
escaping the & and writing it back out as & it just put it out a &, so
we were back to square one!

Question:
1) Is this a bug? 
2) Can I stop the 're-writing' part of this as a work around?
3) Are XML entities not allowed in tomcat-users.xml?

Thanx

PaulE


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Threading Question

[Extance, Paul]

We have had similar issues with wanting some objects to be accessible by any
classes executing in a thread that is processing the response. Our solution
was to use ThreadLocal to create a thread variable, if you are using either
a FrontController (like Struts) or a Filter that each request must pass
through, you can create the thread variable on entry, and unset it in the
'finally' block of your controller...

For an example of this here is...

a) a modified version of Struts controller that sets the variable via our
SecurityManager
http://jaffa.sourceforge.net/javadoc/1_2_0/src-html/org/jaffa/presentation/p
ortlet/PortletServlet.html#line.205

b) The class that actually manages the variable and uses it.
http://jaffa.sourceforge.net/javadoc/1_2_0/src-html/org/jaffa/security/Secur
ityManager.html#line.358

The core of this is simply...
364// Attach the security context to the thread
365bindToThread(ctx);
366try {
367// Now invoke the method
368return method.invoke(obj, args);
369} finally {
370// As the last thing to do before returning either an
object or an exception
371// Remove the current context from the thread
372unbindFromThread();
373}

If you want to use a filter, just replace the above 'return' with a
chain.doFilter( request, response ) inside your doFilter() method.

I think the concern with a static Map, it that it could give one thread
access to another threads data. I guess this is why things like
java.servlet.http.HttpSessionContext were deprecated in v2.2 because of
cross request access.

Paul Extance

-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 31, 2003 9:54 PM
To: [EMAIL PROTECTED]
Subject: Re: Threading Question


"Roggeveen, Brian P" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello,
>
> I was wondering if it is safe to assume that when using the multithreaded
> model, a single unique thread will handle each incoming request? In other
> words, does the servlet container implement a thread per connection model
or
> is there a way to specify this configuration?

The thread-per-connection model is mandated in the Servlet spec, so Tomcat
(and any other compliant Servlet-Container) will behave this way.

>
> The reason I ask is that at any given point within my servlets' supporting
> code/beans, I would like to have access to the HttpSession instance that
> corresponds to the client for whom the current line of code is being
> executed. Another way of looking at the situation would be at any given
> point within my servlets' supporting code/beans, I would like to have
access
> to the HttpRequest that caused this particular line of code to be
executed.
> In order to accomplish this, I envisioned using a Map that contained
thread
> keys and HttpSession values. As requests came in, the Map would be updated
> appropriately such that supporting code need only look up an HttpSession
> using the current thread. Maybe I'm making this more complex than it needs
> to be.

You are most definitely making this more complex than it needs to be ;-).

>
> Thanks!
> Brian Roggeveen
> EDS - Work Force Management
> Voice: (314) 264-8991
> Fax:(314) 264-8901
> Email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: load testing tomcat

[Extance, Paul]

We use the load tester from the Jaffa project
(http://jaffa.sourceforge.net/documentation/tools/testing/) which is based
on HttpUnitTest (http://httpunit.sourceforge.net) we're able to reuse our
unit tests for load testing, which saves some development time. It provides
some nice default features for authentication and provides random log-ins
from given user sets.

I've not tried it will SSL, but as httpunittest supports SSL (see
http://httpunit.sourceforge.net/doc/sslfaq.html) I'm sure it will work.

Paul Extance

-Original Message-
From: Mark W. Webb [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 29, 2003 7:30 AM
To: Tomcat Users List
Subject: load testing tomcat

does anyone have experience load testing tomcat?  I am especially 
interested in mutually authenticate SSL load testing where tomcat runs 
in conjunction with apache 2.0.47.

What tools are people using to test tomcat/apache?

thank you.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Logging off container authenticated user

[Extance, Paul]

We use a filter to cache other data about a user in the session once they
have authenticated. (see
http://jaffa.sourceforge.net/documentation/presentation/sessions.html or the
code @
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jaffa/JaffaCore/source/java/o
rg/jaffa/presentation/portlet/session/UserSessionFilter.java?rev=HEAD&conten
t-type=text/vnd.viewcvs-markup)

As you can see if we fail to get the extra data for the user we invalidate
the session, (ie log out) and redirect to an error page.

If you want a more complex version of the JDBC realm to add extra clauses
for security look at
http://jaffa.sourceforge.net/documentation/security/web/#realm 


Paul Extance


-Original Message-
From: Christian J. Dechery - ACCENTURE [mailto:[EMAIL PROTECTED]

Sent: Tuesday, July 15, 2003 6:54 AM
To: Tomcat Users List (E-mail)
Subject: Logging off container authenticated user

I finally got a FORM-based authentication from the container (in this case,
Tomcat) working.
 
But I have a little doubt, how can I logoff this user?
 
Cuz in my system, the login doesn't deppend only on authenticating him for
username and password, I must validate some other stuff, so it would be
interesting if I could authenticate him, and if I could not validate the
other stuff, log him off and present a message.
 
Thanks.

___
:: Christian J. Dechery 
:: Accenture do Brasil 
:: CHT - Solutions Operations 
:: [EMAIL PROTECTED] 

 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Alternate password encyption code? [UPDATED]

[Extance, Paul]

With reference to the tomcat JDBC Encryption realm, a new version is
available which includes the necessary MBeans stuff for tomcat 4.1.24

The jar is available @
http://prdownloads.sourceforge.net/jaffa/jaffa-tomcat_1_2_0.jar?download

And at last some proper documentation @
http://jaffa.sourceforge.net/documentation/security/web/

Paul Extance

-Original Message-
From: Extance, Paul 
Sent: Tuesday, June 03, 2003 11:40 AM
To: 'Tomcat Users List'
Cc: Extance, Paul
Subject: RE: Alternate password encyption code?

We've already done this as part of the Jaffa (jaffa.sourceforge.net) open
source project. For more details see...

The Source Code @
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jaffa/JaffaCore/source/java/o
rg/jaffa/tomcat/realm/JDBCEncryptionRealm.java?rev=HEAD&content-type=text/vn
d.viewcvs-markup

The Jaffa Site @ http://jaffa.sf.net

The JAR, if you want the easy way... is attached!

This has been tested with most tomcat releases from 3.3a upto 4.1.24 and
works. It supports two types of encryption signatures

String xxx(String password) and
String xxx(String password, String Userid) in case you want to use their
user id as part of the key for the encryption

You provide the class name and the method name in server.xml, and it looks
for either method 1 or 2 and uses that to encrypt the password, before
comparing it with the one in the database. It does not try to decrypt the
database password, so a one way encryption algorithm can be supported.

This Realm also allow you some other features like extending the where
clause for the retrieve on user records, and the select for how to read the
roles (incase you don't want to create additional views!)

An example of how it can be used in server.xml is...



Just make sure you but the attached JAR, and your JAR in the /server/lib
directory, and put the database driver JAR(s) in the same place or in
/common/lib

Hope this helps...

Paul Extance

-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 31, 2003 9:25 AM
To: Tomcat Users List
Subject: Re: Alternate password encyption code?

Jeff Sexton wrote:
> On Thu, 29 May 2003, Raible, Matt wrote:
> 
>>Why don't you just have the JDBCRealm do it - add digest="SHA".
> 
> 
> I need something other than SHA, I need to use my own custom code for an
> encyrption method of my own that is not provided by JDBCRealm
> 
> 
>>To programmatically do it using form-based authentication, I've used a
>>LoginServlet that's mapped to "auth" in my login.jsp's form.  In this
>>servlet, I encrypt the password and redirect to "j_security_check" - is
that
>>what you're looking for?
> 
> 
> Maybe.  I'll do some reading about form-based authentication.  I'm not
> sure.
> 
> I'm after this because I already have set up a JDBCRealm based system,
> with BASIC authentication, and SHA, under Tomcat for both servlets and
> cocoon stuff.  Now I want to tie this together with another application
> that encypts passwords differently from any method available in JDBCRealm.
> 
> I have the code for the encyption.  If I could simply drop this code into
> the user validation JDBCRealm does for me in Tomcat, it'd be great because
> the security would all work and I wouldn't have to create any
> user/password management pages of my own.

Based on the documentation here

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html#Digested%20
Passwords

and a quick look at the sources here

http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-4.0/catalina/src
/
share/org/apache/catalina/realm/JDBCRealm.java?rev=HEAD&content-type=text/pl
ain

it does not look to me like you are going to be able to do this without 
hacking the JDBC Realm implementation.  The tomcat JDBC Realm 
implementation supports digested (*not* encrytped) passwords using 
java.security.MessageDigest to do the hashing.  This means that the 
hashing must be performed using one of the standard algorithms specified 
here
http://java.sun.com/j2se/1.4.1/docs/guide/security/CryptoSpec.html#AppA

You are probably best off going with one of the approaches that Matt has 
outlined if you want to serve login pages from the tomcat nodes.


Phil



> 
> If I can do this, I can tie Tomcat authentication to the password system
> my company has on other systems.
> 
> Any tips are helpful!  I'm a little lost with this.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Servlet Containers & J2EE Frameworks

[Extance, Paul]

In a nutshell, if its not in the J2EE Spec, you can't assume is part of the
available architecture of a J2EE compliant app server, even if 50% of the
containers provide it. So if your looking for 'job scheduling', for example,
and some have it, and other don't, you basically need to build one your self
to use in the containers that don't have it, and for the ones that do, build
custom wrappers for each implementations. 

I think your question of whether you should use JNDI to decide which
implementation to invoke on a given container is just the tip of the
iceburg. How you decided on the implementation to use in a given case can be
as simple as a 'Factory Pattern', which may read web.xml, any other .xml or
.properties config file you dream up. In web.xml you could use servlet
parameters, , or even 

But by taking this task on, you are almost doing single handed what the J2EE
Spec team and the community are all the app server providers are trying to
do which is ...
   1) Define the common interface for the feature (like scheduling)
   2) write a reference implementation (keeping to J2EE specs) for
containers that don't have this feature
   3) For each container that has this feature already, write a custom
bridge between there API's and your generic Interface(s).

The dilemma then comes when/if that feature is included in the next j2ee
spec, and all vendors now support it. I'll guess your interfaces will not be
an exact match and you're left with the choice of
1) throw away everything above and refactor your app to the new J2EE spec,
 or
2) Keep your 'proprietary' non-J2EE spec compliant version
 or
3) Implement a wrapper between your original API your app is coded against,
and the new J2EE app, assuming there is a match.

It just a hard problem to solve!

I think your goals for a framework are similar to ours, which is why we
started the JAFFA open source (http://jaffa.sf.net). A J2EE based solution
(EJB's optional), utilizing the best of what's already been built, and
adding on bits where we can't find existing solutions that fit.

We took the above 'interface/factory' approach with our persistence layer,
we implemented a standard interface, with the view to have different
'engines' based on different evolving technologies (JDBC, O/R Engines, JDO,
Entity Beans), so that the application code and business logic could stay
the same even if we change the underlying technology. All this abstraction
comes at a price, with many compromises along the way. We had a CastorJDO
implementation, we move to a more basic JDBC O/R implementation, and are now
considering an implementation base on Jakarta OJB project for JDO
compliance...

The only thing you need to be certain of with frameworks is that they meet
the relevant parts of the J2EE specs that you care about, beyond that pick
existing frameworks that you believe meet you technical needs and that are
supported by a community that have the same beliefs and vision for the
architecture and you do. Choice is a great thing and with Java there a
plenty of open/commercial ones to pick from. Choose wisely as you will be
investing lots of time and effort learning it. In my opinion 'real'
applications will always need more features that what comes in an 'out the
box' container or architecture, as its the real world solutions that drive
the next iterations of what should be in the J2EE specs and what new
patterns and features are needs in the frameworks. It's a cycle.

Paul Extance

-Original Message-
From: Robert Biernat [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 22, 2003 8:42 PM
To: 'Tomcat Users List'
Subject: RE: Servlet Containers & J2EE Frameworks

I suggest you take a look at the J2EE patterns and blueprints on the SUN
website.

Theyre are numerous patterns and techniques that go along way in helping you
architect a distributed J2EE system that is both flexible and portable.

-Original Message-
From: Steve Garcia [mailto:[EMAIL PROTECTED]
Sent: Friday, 23 May 2003 1:41 PM
To: Tomcat Users List
Cc: [EMAIL PROTECTED]
Subject: RE: Servlet Containers & J2EE Frameworks


It is interesting that you are doing what I wish to achieve.  I have an
application that we need to rewrite and make more portable, we want to
design it such that it supports multiple app servers and databases, just
like your organization/company.  Sorry this is a long e-mail, but I would
like to hear your thoughts, and anybody elses, on this topic.

Re: the database layer.  We are consigned to exclusively use an O/R Mapping
tool.  Frankly, if we want to support numerous RDBMS, then I don't see any
other way around it.  I suppose we could write custom SQL for each provider
and use JDBC but that sucks big time.  I've looked into Jakarta OJB, and I
think it will do the job.  What are your thoughts on this?  There is still
some work for configuring the datasources/configuration files, but
theoretically it should only be an issue of configuration files, not source.
(at least in theory).

Re

RE: Alternate password encyption code?

[Extance, Paul]

We've already done this as part of the Jaffa (jaffa.sourceforge.net) open
source project. For more details see...

The Source Code @
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jaffa/JaffaCore/source/java/o
rg/jaffa/tomcat/realm/JDBCEncryptionRealm.java?rev=HEAD&content-type=text/vn
d.viewcvs-markup

The Jaffa Site @ http://jaffa.sf.net

The JAR, if you want the easy way... is attached!

This has been tested with most tomcat releases from 3.3a upto 4.1.24 and
works. It supports two types of encryption signatures

String xxx(String password) and
String xxx(String password, String Userid) in case you want to use their
user id as part of the key for the encryption

You provide the class name and the method name in server.xml, and it looks
for either method 1 or 2 and uses that to encrypt the password, before
comparing it with the one in the database. It does not try to decrypt the
database password, so a one way encryption algorithm can be supported.

This Realm also allow you some other features like extending the where
clause for the retrieve on user records, and the select for how to read the
roles (incase you don't want to create additional views!)

An example of how it can be used in server.xml is...



Just make sure you but the attached JAR, and your JAR in the /server/lib
directory, and put the database driver JAR(s) in the same place or in
/common/lib

Hope this helps...

Paul Extance

-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 31, 2003 9:25 AM
To: Tomcat Users List
Subject: Re: Alternate password encyption code?

Jeff Sexton wrote:
> On Thu, 29 May 2003, Raible, Matt wrote:
> 
>>Why don't you just have the JDBCRealm do it - add digest="SHA".
> 
> 
> I need something other than SHA, I need to use my own custom code for an
> encyrption method of my own that is not provided by JDBCRealm
> 
> 
>>To programmatically do it using form-based authentication, I've used a
>>LoginServlet that's mapped to "auth" in my login.jsp's form.  In this
>>servlet, I encrypt the password and redirect to "j_security_check" - is
that
>>what you're looking for?
> 
> 
> Maybe.  I'll do some reading about form-based authentication.  I'm not
> sure.
> 
> I'm after this because I already have set up a JDBCRealm based system,
> with BASIC authentication, and SHA, under Tomcat for both servlets and
> cocoon stuff.  Now I want to tie this together with another application
> that encypts passwords differently from any method available in JDBCRealm.
> 
> I have the code for the encyption.  If I could simply drop this code into
> the user validation JDBCRealm does for me in Tomcat, it'd be great because
> the security would all work and I wouldn't have to create any
> user/password management pages of my own.

Based on the documentation here

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html#Digested%20
Passwords

and a quick look at the sources here

http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-4.0/catalina/src
/
share/org/apache/catalina/realm/JDBCRealm.java?rev=HEAD&content-type=text/pl
ain

it does not look to me like you are going to be able to do this without 
hacking the JDBC Realm implementation.  The tomcat JDBC Realm 
implementation supports digested (*not* encrytped) passwords using 
java.security.MessageDigest to do the hashing.  This means that the 
hashing must be performed using one of the standard algorithms specified 
here
http://java.sun.com/j2se/1.4.1/docs/guide/security/CryptoSpec.html#AppA

You are probably best off going with one of the approaches that Matt has 
outlined if you want to serve login pages from the tomcat nodes.


Phil



> 
> If I can do this, I can tie Tomcat authentication to the password system
> my company has on other systems.
> 
> Any tips are helpful!  I'm a little lost with this.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JDBC / ThreadLocal pattern.

[Extance, Paul]

I use the same pattern to bind a security context to a thread, which is
set/unset in a common controller for all Servlet request. So the theory of
binding the stuff to a thread works well, even in an EJB context, as they
are single threaded too.

So the theory is good, but if you going to have a connection pool anyhow,
this is just a lazy way to pass the connection around. Still seems like
overkill if many calls don't need to use the database for anything...
I guess you could be lazy and only get the connection from the pool and bind
it to the threadlocal just before you use it for the first time. 

You'd still need to go straight to the connection pool, if you needed to use
a second connection in the same thread. We use a pattern similar to the
Fowler UOW pattern (Unit Of Work) and pass that around where needed

Seems to me that this is the simple question of 'global variables' or
'passing parameters' style of coding. The 'global variables' approach seems
some what less object orientated in my opinion (Coming from a 4GL background
where I was haunted by global variables :-) )

PaulE.

-Original Message-
From: Brett Neumeier [mailto:brett.neumeier@;ualloyalty.com]
Sent: Thursday, October 31, 2002 9:19 AM
To: 'Tomcat Users List'
Subject: RE: JDBC / ThreadLocal pattern.


> > If the connection is available for more than one request 
> > depends on the way the container handles threads. If each 
> > request is a new Thread you will win nothing. 
> > Instead you will loose performace as each request
> > would create a new connection to the database.
> 
> Yes that is true, there for we've thought of a way to have 
> the ThreadLocal get its connection from a pool. 

The notion of binding a Connection to a particular Thread using a
ThreadLocal is a pretty good idea.  The big advantage to my mind is that you
can use the Connection from any level of the call tree without passing it
around as a parameter.  What you need to keep in mind is that you must reset
the ThreadLocal before the Thread leaves your control.  In other words:

- At the beginning of your processing, check out a Connection from a
connection pool and bind it to the ThreadLocal.
- Throughout processing, the ThreadLocal can be used to obtain access to the
Connection.
- At the end of your processing, close the connection (which returns it to
the connection pool) and reset the ThreadLocal.

If you need to maintain database state across multiple HTTP requests, a
slight modification is needed:  before you check a Connection out from the
connection pool, look in the HttpSession to see whether there is a
Connection there already.  If there is, bind that Connection to the
ThreadLocal.  Otherwise, obtain a new Connection and put it both in the
HttpSession and in the ThreadLocal.

In the context of servlets, one good way to structure this would be to
create a ServletWithConnection class (extending HttpServlet), and have its
service() method
look something like this:

protected static ThreadLocal tl = new ThreadLocal();
protected void service (..) {
Connection conn = connPool.getConnection();
tl.set(conn);
super.service();
tl.set(null);
conn.close();
}

Then you can extend this servlet whenever you need a database connection,
override doGet, doPost, whatever, as normal, and access the Connection via
tl.get() whenever you need it.

Incidentally, Martin Fowler talks about this in his new book on enterprise
architecture patterns -- look at the "registry" pattern.

http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=0321127420

Cheers,

bn

--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Using JAXB in a Servlet (class loader prob?)

[Extance, Paul]

We are using Tomcat 4.0.6 and JDK 1.4.0 with just use the vanilla install of
tomcat, and we don't put the xerces.jar in the WEB-INF/lib either, and all
this works fine. We use JDOM in the web app, its probably because the
Crimson XML parser is include in 1.4.0, and it uses that?

The vanilla install of TC 4.0.6 also puts xerces in common\lib, so it's
maybe using that. 

PS we are using the FULL version of Tomcat not the 'Lite' version for JDK
1.4.0.

Hope that helps

PaulE

-Original Message-
From: Steve Slatcher [mailto:steve_slatcher@;scientia.com]
Sent: Thursday, October 31, 2002 2:13 AM
To: Tomcat Users List
Subject: Re: Using JAXB in a Servlet (class loader prob?)


Thanks for that.  If it is a Tomcat bug that has been addressed, I'll put
the issue on the back burner for a while.  Can you remember if you noticed
the xerces issue I mentioned?

Extance, Paul wrote:
> Upgrade to tomcat 4.0.4 - 4.0.6, then you can put the jaxb-rt.jar
> into the WEB-INF/lib directory. I think 4.0.3 has some class loader
> issues with packages that start with java and javax in the WEB-
> INF/lib folders
>
> This solved the problem for us.
>
> PaulE
>
> -Original Message-
> From: Nick Lombard (VSP) [mailto:nick.lombard@;vcontractor.co.za]
> Sent: Wednesday, October 30, 2002 5:05 AM
> To: Tomcat Users List
> Subject: RE: Using JAXB in a Servlet (class loader prob?)
>
>
> Hi Steve
>
> My half a cent comment.
>
>  interested in 
> We are successfully using shared jar files accross applications by
> placing them in the $TOMCAT_HOME/shared/lib directory.
>
> This will help to not use the common/lib directory.
>
> Hope it helps.
> Nick.
>
> -Original Message-
> From: Steve Slatcher [mailto:steve_slatcher@;scientia.com]
> Sent: Wednesday, October 30, 2002 2:54 PM
> To: Tomcat Users List
> Subject: Using JAXB in a Servlet (class loader prob?)
>
>
> Hi all
>
> I have some code that uses JAXB that works fine in a standalone app
> with the jars I expect it to need.  When I put the same code in a
> webapp I got a couple of problems initialising the Sevlet (see log
> file below).
>
> I managed to get rid of one problem (javax.xml.bind.JAXBContext) by
> putting a copy of jaxb-api.jar in /common/lib (before it was only in
> app/WEB-INF/lib).
>
> The second problem was solved by copying a xerces.jar into my
> app/WEB-INF/lib directory (as far as I can tell my standalone app did
> not need org.w3c.dom.ls.DocumentLS at all).
>
> Can anone shed more light on this?  Specifically I would be
> interested in any ways to avoid using the /common/lib directory.
>
> I'm using Tomcat 4.0.3, JAXB 1.0 beta (currently the latest version),
> and the magic Xerces that came to the rescue was 1.4.4.  Despite the
> name of my webapp I am NOT intent on spamming!
>
> Cheers
>
> Steve Slatcher
>
> 2002-10-30 11:33:14 WebappLoader[/spam]: Deploying class repositories
> to work directory C:\jakarta-tomcat-4.0.3\work\localhost\spam
> 2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/activation.jar to
> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\activation.jar
> 2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR /WEB-
> INF/lib/dom.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-
> INF\lib\dom.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/jax-qname.jar to
> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jax-qname.jar
> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/jaxb-api.jar to
> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-api.jar
> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/jaxb-libs.jar to
> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-libs.jar
> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/jaxb-ri.jar to
> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-ri.jar
> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/jaxb-xjc.jar to
> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-xjc.jar
> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/jaxp-api.jar to
> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxp-api.jar
> 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/log4j-1.2.6.jar to
> C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\log4j-
> 1.2.6.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-
> INF/lib/mail.jar to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-
> INF\lib\mail.jar 2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
> /WEB-INF/lib/sax.jar to C:\jakarta-tomcat-
> 4.0.3\bin\..\webapps\spam\WEB-INF\lib\sax.jar 2002-10-30 11:33:15

RE: Using JAXB in a Servlet (class loader prob?)

[Extance, Paul]

Upgrade to tomcat 4.0.4 - 4.0.6, then you can put the jaxb-rt.jar into the
WEB-INF/lib directory. I think 4.0.3 has some class loader issues with
packages that start with java and javax in the WEB-INF/lib folders

This solved the problem for us.

PaulE

-Original Message-
From: Nick Lombard (VSP) [mailto:nick.lombard@;vcontractor.co.za]
Sent: Wednesday, October 30, 2002 5:05 AM
To: Tomcat Users List
Subject: RE: Using JAXB in a Servlet (class loader prob?)


Hi Steve

My half a cent comment.

mailto:steve_slatcher@;scientia.com]
Sent: Wednesday, October 30, 2002 2:54 PM
To: Tomcat Users List
Subject: Using JAXB in a Servlet (class loader prob?)


Hi all

I have some code that uses JAXB that works fine in a standalone app with
the jars I expect it to need.  When I put the same code in a webapp I got a
couple of problems initialising the Sevlet (see log file below).

I managed to get rid of one problem (javax.xml.bind.JAXBContext) by putting
a copy of jaxb-api.jar in /common/lib (before it was only in
app/WEB-INF/lib).

The second problem was solved by copying a xerces.jar into my
app/WEB-INF/lib directory (as far as I can tell my standalone app did not
need org.w3c.dom.ls.DocumentLS at all).

Can anone shed more light on this?  Specifically I would be interested in
any ways to avoid using the /common/lib directory.

I'm using Tomcat 4.0.3, JAXB 1.0 beta (currently the latest version), and
the magic Xerces that came to the rescue was 1.4.4.  Despite the name of my
webapp I am NOT intent on spamming!

Cheers

Steve Slatcher

2002-10-30 11:33:14 WebappLoader[/spam]: Deploying class repositories to
work directory C:\jakarta-tomcat-4.0.3\work\localhost\spam
2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/activation.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\activation.jar
2002-10-30 11:33:14 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/dom.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\dom.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/jax-qname.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jax-qname.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/jaxb-api.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-api.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/jaxb-libs.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-libs.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/jaxb-ri.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-ri.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/jaxb-xjc.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxb-xjc.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/jaxp-api.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\jaxp-api.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/log4j-1.2.6.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\log4j-1.2.6.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/mail.jar
to C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\mail.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR /WEB-INF/lib/sax.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\sax.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Deploy JAR
/WEB-INF/lib/xercesImpl.jar to
C:\jakarta-tomcat-4.0.3\bin\..\webapps\spam\WEB-INF\lib\xercesImpl.jar
2002-10-30 11:33:15 WebappLoader[/spam]: Reloading checks are enabled for
this Context
2002-10-30 11:33:15 StandardManager[/spam]: Seeding random number generator
class java.security.SecureRandom
2002-10-30 11:33:15 StandardManager[/spam]: Seeding of random number
generator has been completed
2002-10-30 11:33:15 ContextConfig[/spam]: Added certificates -> request
attribute Valve
2002-10-30 11:33:15 StandardWrapper[/spam:Mailer]: Marking servlet Mailer
as unavailable
2002-10-30 11:33:15 StandardContext[/spam]: Servlet /spam threw load()
exception
javax.servlet.ServletException: Error instantiating servlet class
com.scientia.spam.MailerServlet
 at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:8
93)
 at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:808)
 at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java
:3266)
 at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3395)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
 at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
 at org.apache.catalina.startup.Cata

RE: JDBC / ThreadLocal pattern.

[Extance, Paul]

2 Cents...

Not all threads need to do things with the database? kind of a waste to use
the thread with the connection sitting idle, if it is a limited resource.
I'm guessing the worker thread pool in tomcat typically needs to be higher
that that of the connection pool its classes would use, in which case your
hogging/wasting a valuable resource. This alone would probably justify not
using it for me.

We sometimes using multiple connections in a single thread if our business
process need two isolated transactions, one to do the work (which could
rollback) and the other to do the logging to the database, which should not
be rolled back with the main transaction. Could this be supported with a
single connection per thread?

If you have stateful form beans (say with STRUTS) that want to maintain
connection state, can you guarantee that the same thread will service the
same request associated to this stateful bean. I know in a web/stateless
environment you probably don't want to leave connections open across
successive calls...so maybe this is not a real issue..

PaulE

-Original Message-
From: Reynir Hübner [mailto:reynir@;hugsmidjan.is]
Sent: Wednesday, October 30, 2002 11:06 AM
To: Tomcat Users List
Subject: JDBC / ThreadLocal pattern.


Hi all, 

This email is a little bit off topic, as it's more about JDBC-related stuff
than tomcat.

I'm really looking for comments on the approach for JDBC connection pooling
described in the article at : 
http://www-106.ibm.com/developerworks/java/library/j-threads3.html

In (very) short:  the idea here is to have one jdbc-connection for each
thread, instead of a pool with connections.

I've got few ideas on the subject, for example this may be cool because : 

 1. I will never have to worrie about not returning connections anymore, as
they will always be garbage collected as soon as the thread is dead.
 2. The connection will be available for more than one request so I can lazy
load resultsets.
 3. This might make transaction-service implementation easyer
 4. many other great things

I realise there must be some kind of problems by doing it this way, but I
only came up with these :

 1. can this approach cause too many connections to the database (75 threads
in Tomcat is the default means 75 connections) ?
 2. can it be to heavy for the garbagecollector to collect all the dead
connections lying around when a thread dies ?
 3. anything more negative stuff ?

I am looking for comments on the pattern.. Please respons if you have any.
Thanx alot!

[EMAIL PROTECTED]





--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Help: Custom Error Page Wild Card?

[Extance, Paul]

Is there a more efficent way to get the web.xml to point to an common error
page for all errors?

I currently have in web.xml


  
400
/errorpage/error.jsp
  
  
401
/errorpage/error.jsp
  
  
403
/aura4d/security/logon/jsp/noAccess.jsp
  
  
404
/errorpage/error.jsp
  
  
405
/errorpage/error.jsp
  
  
409
/errorpage/error.jsp
  
  
412
/errorpage/error.jsp
  
  
413
/errorpage/error.jsp
  
  
415
/errorpage/error.jsp
  
  
500
/errorpage/error.jsp
  
  
501
/errorpage/error.jsp
  
  
502
/errorpage/error.jsp
  
  
503
/errorpage/error.jsp
  
  
java.lang.Throwable
/errorpage/error.jsp
  

I tried a wildcard for a default but that didn't work
  
  
403
/aura4d/security/logon/jsp/noAccess.jsp
  
  
java.lang.Throwable
/errorpage/error.jsp
  
  
*
/errorpage/error.jsp
   

The problem i have is that our users  keep seeing the default 'Tomcat' error
page, and keep reporting 'Tomcat' errors, of course Tomcat is fine, its
normally the application or the end user that is the problem, so i don't
want any scenarios to bring up the tomcat error page.

PS: I'm currently using Tomcat 4.0.6

Thanx

PaulE

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Java Connectors in Tomcat?

[Extance, Paul]

Is there plans to allow the Tomcat container to support the JCA part of the
J2EE Spec. I have a JSP(Struts)/JDO based app, that runs on Tomcat, no EJB's
in site. If i want to use a 3rd party connector (like SAP) do i now need a
EJB type container like JBoss, or is Tomcat planning to support JCA some
time in the future?

If this is a stupid question i apologies, just trying to get my head round
the JCA stuff and what it means to my deployment!

Thanx

PaulE

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tomcat, JAXB and SecurityManager

[Extance, Paul]

We have had a problem with JAXB under Tomcat 4.0.3, as it couldn't find the
jaxb-rt.jar in the WEB-INF/lib folder. 

We also put it in the %catalina_home%/common/lib, and it still couldn't find
it.
We then put the jar in the %java_home%/jre/lib/ext and then it worked.

We then upgraded to Tomcat 4.0.4 and the problem went away.

So if your getting a 'ClassNotFound' exception this may help.

PaulE

-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 09, 2002 7:09 AM
To: Tomcat Users List
Subject: RE: Tomcat, JAXB and SecurityManager


Bonjour! ;)

>If i launch it from a servlet, i failed.

Can you please provide more details?  The stack trace would be helpful.  Any
suspicious or error messages in the tomcat logs?

>One more point, if the same code is run under Tomcat 4.0.1, it work !!!

Then I would look at the release notes for 4.0.3 to see what changes were
made to the security manager between 4.0.1 and 4.0.3 ;)

> Cédric (very despited for two days).

What does very despited mean? 

Yoav Shapira
Millennium ChemInformatics

--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: share session between webapps

[Extance, Paul]

We have the same requirements, and to agree with Craig, we use the
request.getUserPrincipal()!=null to assert they are
authenticated, and we also use the request.getUserPrincipal().getName() to
get the User Id (or key) so we can use this
in our application.

In addition we've built a variant of the JDBC realm that allows an
additional encryption class to be specified, it will
use this class to encrypt the password before validating it with the
database. (We decided not to add this to RealmBase, but
I'm sure could if you wanted).

Example


It also has some other nice features

It is being released as part of the http://jaffa.sf.net project, but it you
want an advanced copy of the source, class, jar ,docs etc let me know

BTW: If I have webapp1 deployed on tomcat 4.0x on Linux, and another webapp2
on Tomcat on a W2K box, is there any way to implement single sign on across
the two?

Paul Extance
[EMAIL PROTECTED]


-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 31, 2002 9:39 AM
To: Tomcat Users List
Subject: Re: share session between webapps




On Wed, 31 Jul 2002, Michael Remijan wrote:

> Date: Wed, 31 Jul 2002 08:34:34 -0500
> From: Michael Remijan <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: share session between webapps
>
> ...
>
> Is there technique to share a session, or objects within the session
> between web applications?

No.  And it wouldn't work even if there was such a mechanism, because each
webapp has its own class loader -- the classes in webapp A's /WEB-INF
directory are not visible to webapp B (and vice versa).

> What I want to do is login or register at a
> site and if the user moves to a different webapp, I want to be able to
> determine, by looking for an object in the user's session, that they are
> already logged in.
>
>  Using realms and single sign on doesn't appear to do what I want
> because it A) doesn't allow me to get me the primary key for the user,

What's wrong with calling request.getRemoteUser() or
request.getUserPrincipal().

> B) doesn't allow me to write any special processing code, specifically
> to md5 encrypt the password before performing the query.

IMHO, if you are using container managed security you have absolutely no
business messing with passwords.  Either let the container manage all of
that or do it yourself.

 C) most
> importantly, it doesn't seem to allow me to carry information accross
> webapps.
>

This is true for *all* information, not just for security credentials.  If
you want to share information across webapps, the standard approaches are:

* Store it externally in a database, EJB, etc. that is accessed
  from each webapp

* (Container-specific, so no portability guarantees) store it in
  a static variable of a class that is loaded from a parent class
  loader of the webapp class loaders.  For Tomcat 4, that means
  putting the class in someplace like common/lib.

> 
>

Craig


--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: How to abort the webapp load/deployment

[Extance, Paul]

I already use Struts, so i'll probably just put an extra check in the
controller.

I guess i'll wait to see what Servlet Spec 2.4 has to offer for disabling
the app loading..

Thanks for all the replies 

PaulE

-Original Message-
From: Mike Jackson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 24, 2002 1:39 PM
To: Tomcat Users List
Subject: RE: How to abort the webapp load/deployment


You could uild a MVC app where there are no page accesses
that don't pass through the controller (i.e. index.form and
form is mapped to a servlet which does a requestDispatcher
to index.html or index.jsp).  Have the controller only pass
people through if the validation has occured successfully.

If this is greek I can give you a better example.

--mikej
-=-
mike jackson
[EMAIL PROTECTED]

-Original Message-
From: Extance, Paul [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 24, 2002 12:13 PM
To: '[EMAIL PROTECTED]'
Subject: How to abort the webapp load/deployment


Hello,

Is it possible to write a 'validation' servlet, that does some basic checks,
which if fail, cause the whole web application to be unavailable?

This servlet would be flagged as  such that it was the
first one to execute.

I'm trying to achive something similar to JBoss 2.x where if the verifier
fails for an EAR, it does not deploy it at all. I want the similar concept
but for my Web Application, such that critical initialization errors make
the the whole application unavailable.

I can't find anythingin in the Java Servlet Spec to indicate that this is
possible, or anything in the tomcat documenation.

Thoughts?

Thanks

PaulE

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

How to abort the webapp load/deployment

[Extance, Paul]

Hello,

Is it possible to write a 'validation' servlet, that does some basic checks,
which if fail, cause the whole web application to be unavailable?

This servlet would be flagged as  such that it was the
first one to execute.

I'm trying to achive something similar to JBoss 2.x where if the verifier
fails for an EAR, it does not deploy it at all. I want the similar concept
but for my Web Application, such that critical initialization errors make
the the whole application unavailable.

I can't find anythingin in the Java Servlet Spec to indicate that this is
possible, or anything in the tomcat documenation.

Thoughts?

Thanks 

PaulE

--
To unsubscribe, e-mail:   
For additional commands, e-mail: