I did some brainstorming about this. I'm not satisfied with the design of Fqn as it is.
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'm not a fried of overloading Constructors or methods while keeping the number of arguments constant. It's not compatible with the design of generics (as they are in JDK5.0). We would be better off having a default constructor and a constructor accepting an array of elements. To construct a Fqn from a List having an addList(List)-method would be better. Since it's not taking any Object 'as is' right now, it's not a huge benefit to be allowed to use Object instead of String. Basically an Fqn is just a hirarchical name. It points to a context with bound attributes. 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. This way a TreeCache might be bound to a NamingContext in a way that all Contents of the TreeCache appear seamlessly within the JNDI. TreeCache could also be used as a high-speed distributed Namingservice for JBoss itself. ... just a few ideas I had last night View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3848577#3848577 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3848577 ------------------------------------------------------- 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
