"norbert" wrote : | | While components of the Fqn may be Object, if one wants to be a List be the component of an Fqn he would have to cast the List to Object to call the intendet constructor (which is not at all intuitive): | | Fqn fqn = new Fqn((Object)list); | |
I don't think the intention is to have individual components of Fqn that are not primitive types (Integer, Boolean, String etc). Since we're doing an element-by-element comparison, comparing lists would recursively have to go down into the list, which is slow. The other reason for using primitives is that they can/could be used as primary keys in a JDBC cache loader impl. Not that we should explicitly design with relational DB in mind, but it is important to be able to come up with a simple mapping. | This lead me to the following: It might be better to adhere to standards and make TreeCache implement javax.naming.DirContext and Fqn implement javax.naming.Name. | I have thought about this, but I'm not a big friend of the javax.naming package. IMO it is overdesigned. | TreeCache could also be used as a high-speed distributed Namingservice for JBoss itself. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3848584#3848584 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3848584 ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
