On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > I'd focus more on the 5.0 tree to do any major changes, though.
Of course. > Are you talking about the UserDatabase global resource in 4.1? This is > actually a global thing, and not a Realm. See below for more. I just enabled the Http 'mbean' in mx4j, and I'm looking at the list of mbeans that are registered ( after a small change in modeler to make sure a single mbean server is created ). There are several objects: Users:type=Role,rolename=admin,database=UserDatabase Users:type=User,username=both,database=UserDatabase Users:type=UserDatabase,database=UserDatabase One issue is that user databases and user/role can be specified per webapp ( at least in 3.3, I think 4.x have the same feature ). That means 'username=foo' can have different pass/roles in different webapps. The doc doesn't seem to cover the 'domain' part of the component names. I'll send a separate mail with comments on the 'local name' part. > Actually, a Realm is an illustration of how the current scheme actually > does disambiguate between these three cases. The MBean for a Realm can > have any of the following names, depending on where it's nested: > > catalina:type=REALM,engine=Standard > > catalina:type=REALM,host=www.hostname.com,engine=Standard > > catalina:type=REALM,path=/context-path,host=www.hostname.com,engine=Standard I know this. My question is if it would be better to use a different 'domain' for each webapp: myApp:type=REALM,... I'm not sure this is a good idea or not - the benefit would be to eventually control the access to the app by domain ( but that can be done by name ) or allow better grouping. > These attributes specifically refer to the UserDatabase object that is > defined in the global resources in 4.1 (and JWSDP). One or more objects > of this type may indeed exist (with unique names), and the user/group/role > objects associated with them all have unique mbean names that includes the > identifier of the owning UserDatabase. So you're saying that 'user' is global, i.e. if tomcat is included in a J2EE container ( or another application ) it is expected that both will use the same mbeans ? That may be an excelent solution - as long as it is still possible to have users that are specific to webapps. ( i.e. have host, path in the user name ). > Note that a Realm for a particular engine/host/context may or may not > actually use one of the UserDatabase things -- the only Realm > implementation that does is UserDatabaseRealm. If you are using > MemoryRealm, JDBCRealm, JNDIRealm, etc. there are no mbeans for the users > themselves (and you can't maintain the user database through the admin > tool). Why not ? The Realm can have a method 'list users' or 'find user' - and it can register or create User object dynamically. I see no reason why the same interface that is used for memory can't apply to a JDBC realm ( assuming we add the insert statements ) > > My proposal would be to use: > > - 'tomcat' - for all 'server level' components ( including global Realm > > and User) > > > > I don't see why you'd change "catalina" to "tomcat", but that's pretty > trivial in the big picture. Catalina is fine. I was thinking of a domain per webapp and one domain for the container - i.e. coyote/jk + catalina + jasper. > I do think that you misunderstand the global-ness of users -- they are not > in the same hierarchy. I think I misunderstand it - and I still do :-) Can you clarify a bit ? Can you still have the same user name with different roles/pass in different applications, and how does this reflect in the Users: domain. And what's the relation between the Users: and the realms - if I have a JDBCRealm I suppose no Users: will be visible. Is any reason to treat the memory realm differently ? > Take a look at the document referenced above, and you'll see how the > current naming scheme completely deals with the entire Catalina object > hierarchy. Then, we can talk about changes. I'll try to understand it better and send separate comments. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
