On Mon, 29 Jul 2002, Craig R. McClanahan wrote:

> > - 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.

That's simpler and better. Ok.


> > - 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.

Ok, but maybe we can pakage them in a tomcat4-compat.jar ( and even 
keep them in a separate dir ).


> > - User databases are considered a separate space
> >
> 
> We might want to include the appropriate MBeans along with the APIs as
> well ...

Of course. I was thinking to extend a bit modeler to use the package name
to automatically load an .xml resource - this will make things simpler
and automate a lot of stuff.

If we agree to combine the introspection-based dynamic mbean in modeler
then when a component is registered we first look for an xml resource
in the package, and if none is found we just introspect. 


> Yep ... just like DAOs backed by databases load the data on demand, we
> need a strategy that does the same for user MBeans.

That will have some implications on the UserDatabase API. 

But one major question is if we really want to have an MBean per user.
The alternative is to pass the userId to the UserDatabase methods.
For example:
 getFullName( String userId ); in UserDatabase
instead of:
 getFullName() in User.

Or just treat User as a bean, without making it an MBean ( that would
require the admin code to cast to User ).

I don't know exactly how expensive it is to register a lot of stuff
in JMX and how to un-register and deal with expiration/LRU/etc - so
it may be ok to use MBeans for user as long as we don't expect all
users to be in memory.

I hope that UserDatabase and all the new interfaces introduced in 4.1 are
not 'frozen' or at least not considered for backward compatibility. 

Costin


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

Reply via email to