On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote:
> Date: Mon, 29 Jul 2002 15:04:24 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: [5.0 - config] jmx names, part 1: domains
>
> On Mon, 29 Jul 2002, Craig R. McClanahan wrote:
>
> > In the current implementation, the association of webapps to user
> > databases is *indirect* by virtue of the Realm that is used. You can
> > share a single user database across webapps, if you want to, in a couple
> > of different ways:
>
> This is a bit confusing ( i.e. mixing 'realm' and 'user database' ),
> but I understand the idea and I like it.
>
> Let me see if we are talking about the same thing:
>
> - Tomcat should delegate all user-management stuff to a 'commons-user',
> based on UserDatabase, Role, Group, User.
>
Yes, with multiple implementations available for the actual storage.
> - Each webapp will be associated with one ( or more ) UserDatabases.
> A UserDatabase can be used by one or more webapss ( and other
> applications).
>
I think a particular webapp would be associated with only one UserDatabase
(although you could certainly write a Realm implementation that
effectively merged them). A UserDatabase could definitely be shared
across multiple webapps.
> - Realm interface will remain (for backward compatibility).
>
Including the existing implementations, because lots of apps use them, and
some apps have implemented extended versions of Realm.
> - User databases are considered a separate space
>
We might want to include the appropriate MBeans along with the APIs as
well ...
> I'm ok with that - assuming everyone else is ( Nacho spent a lot
> of time on auth and realms - I would like to hear his opinion )
>
>
> > The current admin webapp assumes that all users/roles/groups will be
> > loaded, so it would need to be refined as well as the strategy for
> > creating these mbeans only at startup time.
>
> I think that has to change for 5.0.
>
> In fact a lot in the intialization should change - including
> making more intialization in background or on demand ( user is one
> simple thing that can be delayed ). The startup time is still to
> big IMHO, and loading 1000+ users in memory is not going to help.
>
>
Yep ... just like DAOs backed by databases load the data on demand, we
need a strategy that does the same for user MBeans.
>
> > Regarding competition over the domain name itself, that seems to be a
> > global issue for all JMX-enabled applications.
>
> If we plan to eventually move to commons and keep it independent of
> tomcat - than Users: domain is better.
> If it is specific to tomcat, we should use the same domain.
>
> > > But the more interesting question is what to do if you want a group
> > > of (web)applications sharing the same domain.
> > >
> >
> > We have a variation of that concept in the actual managed components as
> > well -- DefaultContext.
>
> I don't think DefaultContext allows this flexibility - it would be more
> like a ContextGroup or multiple default contexts...
>
>
> > Not unless we go modify those realms to know about users/roles/groups, or
> > build JDBCUserDatabase and JNDIUserDatabase. Either approach is feasible.
>
> I prefer the second, and make all this a separate component ( eventually
> later move it to commons ).
>
> The realms should remain only for backward compat.
>
>
> > Agreed. Like everything, we implemented what we needed for now :-).
>
> As long as the interfaces don't freeze before we are sure that
> things that we'll need in future can be implemented, it's fine :-)
>
> > > > It could have been done that way as well, but it seemed better to provide
> > > > a DAO type pattern for accessing this stuff.
> > >
> > > Not sure what you mean here - can you expand ?
> > >
> >
> > When faced with the requirement to add "web-administratable users" for
> > JWSDP, there were two fundamental approaches we could have taken:
> >
> > * Expand the responsibility of the Realm interface beyond just
> > the authenticate() and hasRole() methods
> >
> > * Treat a "user database" like you would any other sort of data
> > in a database-enabled (or EJB-backed) application, and create an
> > abstraction for the notions of creating, modifying, and removing
> > users/groups/roles.
> >
> > The latter seemed like a better idea at the time, for the reasons
> > discussed further below.
>
> I was asking about the actual API - especially wrt managing large
> databases of users.
>
> The latter is a far better idea IMHO ( including at this time ).
>
> > Definitely need to cover JDBC/JNDI/JAAS/etc. technologies for user
> > databases.
> >
> > Fortunately, if we go this way, we won't actually have to touch
> > UserDatabaseRealm at all (until we modify the interfaces, of course). And
> > then, it's only one Realm implementation to mess with, that can talk to
> > any of the UserDatabase implementations.
>
> Yes. But we should first define a UserDatabase interface that can deal
> with many users and not-in-memory.
>
Yes.
>
> > One thing that will definitely be needed is a way to select a subset of
> > all the users/roles/groups (basically, the "finder method" concept of
> > entity beans).
>
> Yes, both by 'filter' and by id.
>
> For example if we display the users in a page, 50 at a time we should
> be able to iterate in groups of 50 - and register/unregister those beans
> on demand.
>
> The problem is that the model may not work very well as performance
> ( there are notifications, and some overhead on adding mbeans ).
>
> We certainly need a 'user cache' with the most recently used users
> ( for both jndi and jdbc ), but if each user will have an mbean - it's
> a different question.
>
> Costin
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
