We have a number of org.jnp.interfaces.NamingContextFactory subclasses that are in the server module which should really be in the naming module to avoid unnecessary dependencies on the server module, and jboss.jar:
org.jboss.naming.BridgeNamingContextFactory org.jboss.naming.NamingContextFactory org.jboss.iiop.naming.ORBInitialContextFactory The issue came up when looking at these security related variations which should subclass the org.jboss.naming.NamingContextFactory version to pickup its ability to remember non-default InitialContextFactory environment settings: org.jboss.security.jndi.LoginInitialContextFactory org.jboss.security.jndi.JndiLoginInitialContextFactory I'm tempted to move all of the server org.jboss.naming.* classes into the naming module to avoid spliting this package across jars, but there jboss-system dependencies, and jmx dependencies that require further refactoring. It should probably be done anyway in preparation for the mc migration. I'll wait a day for feedback before starting this move. If I do move this over to naming I want to move the cvs history along with it. xxxxxxxxxxxxxxxxxxxxxxxxxxxx Scott Stark VP Architecture & Technology JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
