On Wed, 13 Feb 2002, Glenn Nielsen wrote:
> Date: Wed, 13 Feb 2002 11:53:52 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4 JDBCRealm Connection Pooling
>
> Remy Maucherat wrote:
> >
> > > On Wed, 13 Feb 2002, Glenn Nielsen wrote:
> > >
> > > Hi Glenn,
> > >
> > > Personally, I like the latter idea better (a new JDBCRealm implementation
> > > that uses a JNDI named data source) to avoid disruption of existing
> > > applications.
> >
> > Yes, I agree.
> > Internal Catalina components can now use JNDI in the HEAD branch. So the
> > DataSource could be defined in GlobalNamingResources, and the realm should
> > be able to use it. This DataSource could be shared by more components.
> >
>
> A global JDBC DataSource for Realms may work for some,
> but when virtual hosting websites and applications
> for different customers I need a different Realm for each customer.
> That way each customer has their own name space for userid's and roles.
>
You can still use JNDI resources for this -- just set up as many different
connection pools as you need (under different names), and attach the
JDBCDataSourceRealm for each application to the appropriate connection
pool name.
In the HEAD branch, I used the same basic technique for configuring the
UserDatabaseRealm in the default server.xml file. It is configured with
the global resource name of the UserDatabase implementation to use
(default configuration value is "java:UserDatabase"). For per-host or
per-webapp user databases, I would simply set up some more of these, under
different resource names, and connect the UserDatabaseRealm for each
webapp appropriately.
(Speaking of which, we might also consider writing a JDBCUserDatabase
implementation as well -- that way, the admin webapp can be used to update
the users in a database instead of in "conf/tomcat-users.xml" like
MemoryUserDatabase does.)
> In addition I use a different DataSource for normal customer dB
> application data and realm data. The separation of these data sources
> makes sure that a customer application can't be spoofed somehow to
> compromise the entries in the db for a realm.
>
This is all easy to set up. It's also easy to set up a scenario where a
single connection pool, configured in the global resources, is actually
shared by the JDBCDataSourceRealm and made available to an application
(through a <ResourceLink>) if that is what your application requires.
> Regards,
>
> Glenn
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
