 |
Añadir una dirección | Buscador | Cursos | Artículos | Foros | Formación |
 |
 |
Sistema de Nombrado en Java (JNDI) y II |
|
En esta página:
Soportar Subinterfaces
Un usuario del API puede pasar un string URL a los métodos de la clase InitialDirContext de la misma forma que a los métodos de la clase InitialContext. Para soportar esta capacidad, la correspondiente implementación de contexto URL debe soportar los métodos del interface DirContext además de los del interface Context, usando las técnicas descritas en la sección Implementación de un Contexto.
Si nuestra implementación de contexto URL también soporta federación, debería definir un método interno de utilidad para obtener el contexto de continuación para realizar operaciones de directorio. Aquí tenemos un ejemplo:
protected DirContext getContinuationDirContext(Name n)
throws NamingException {
Object obj = lookup(n.get(0));
CannotProceedException cpe = new CannotProceedException();
cpe.setResolvedObj(obj);
cpe.setEnvironment(myEnv);
return DirectoryManager.getContinuationDirContext(cpe);
}
Este método usa DirectoryManager.getContinuationDirContext() para obtener el contexto de continuación. Las sobrecargas que aceptan Name usan esta utilidad para sus implementaciones. Aquí tenemos un ejemplo de cómo getAttributes() usa getContinuationDirContext():
public Attributes getAttributes(Name name, String[] attrIDs)
throws NamingException {
if (name.size() == 1) {
return getAttributes(name.get(0), attrIDs);
} else {
DirContext ctx = getContinuationDirContext(name);
try {
return ctx.getAttributes(name.getSuffix(1), attrIDs);
} finally {
ctx.close();
}
}
}
La implementación de las sobrecargas que aceptan nombres string usa un patrón similar al usado por los métodos del interface Context. En lugar de esperar un Context como el objeto resuelto desde la utilidad interna getRootURLContext(), los métodos de DirContext deberían esperar un DirContext. Aquí tenemos un ejemplo de implementación de getAttributes():
public Attributes getAttributes(String name, String[] attrIds)
throws NamingException {
ResolveResult res = getRootURLContext(name, myEnv);
DirContext ctx = (DirContext)res.getResolvedObj();
try {
return ctx.getAttributes(res.getRemainingName(), attrIds);
} finally {
ctx.close();
}
}
Soportar Subinterfaces No-Estándars
Añadir soporte URL para métodos del interface DirContext tiene sentido porque este interface contiene métodos que procesan nombres. Añadir soporte URL no tiene sentido para subinterfaces cuyos métodos no hace nada con nombres. Por ejemplo, no necesitamos proporcionar soporte de URL para métodos del interface LdapContext porque ninguno de sus métodos trata con nombres.
Otra razón por la que el soporte URL podría no ser apropiado por algunos subinterfaces es que el modelo podría no ser apropiado. Por ejemplo, los interfaces EventContext y EventDirContext contienen métodos que procesan nombres. Sin embargo, estos interfaces definen un modelo en el registro de oyentes está cerrado para el ejemplar Context. Esto hace que no trabaje bien con URLs, que efectivametne son nombres absolutos que no son elegibles para un ejemplar particular de Context. (Estos dos interfaces y el modelo de eventos que soportan se describieron en la lección Notificación de Eventos.)
Podrían existir otros interfaces, posiblemene propietarios en los que tiene sentido proporcionar soporte de URL. Para dichos casos, deberíamos seguir las guías dadas en la lección anterior y en está página cuando construyamos nuestra implementación de contexto URL. Las sobrecargas que aceptan Name deberían usar getContinuationContext() (si la implementación de contexto soporta federación), mientras que las sobrecargas que aceptan nombres string deberían usar una utilidad similar para getRootURLContext().
Aquí tenemos un ejemplo. BarContext extiende el interface Context añadiendo dos nuevos métodos: barMethod(), que acepta un argumento name, y bazMethod(), que no lo hace. (Una implementación de contexto de ejemplo BarContextImpl , que está basada en el ejemplo HierCtx anterior). Su implementación de contexto URL, barURLContext , implementa el subinterface y desciende del ejemplo anterior fooURLContext . Aquí etá la definición del método relacionado con los nombres de la definición de barURLContext:
public Object barMethod(Name name) throws NamingException {
if (name.size() == 1) {
return barMethod(name.get(0));
} else {
Context ctx = getContinuationContext(name);
if (!(ctx instanceof tut.BarContext)) {
throw new NotContextException(
"Cannot continue operation on nonBarContext");
}
try {
return ((tut.BarContext)ctx).barMethod(name.getSuffix(1));
} finally {
ctx.close();
}
}
}
public Object barMethod(String name) throws NamingException {
ResolveResult res = getRootURLContext(name, myEnv);
tut.BarContext ctx = (tut.BarContext)res.getResolvedObj();
try {
return ctx.barMethod(res.getRemainingName());
} finally {
ctx.close();
}
}
Los métodos que no están relacionados con el nombre, como bazMethod(), normalmente no querán ser llamados desde el contexto URL por la forma en que se accede al contexto URL (ver la explicación más adelante en esta lección). Sin embargo, todavía necesitamos sus implementaciones para satisfacer los requerimientos del lenguaje Java. Necesitamos proporcionar una factoría de contextos URL para esta implementación de contexto URL, como se describió anteriormente en esta lección.
También deberíamos seguir las instrucciones para extender el contexto inicial descritas más tarde en esta lección para soportar URLs para sus subinterfaces. Este último paso no es necesario para el subinterface DirContext, porque ya existe una clase de contexto inicial InitialDirContext, que dirige llamadas a DirContext que envían los nombres strings URL a la implementación de contexto URL apropiada.
|
|
|
| Principio Página |
|
© 1999-2002, Programación en castellano, s.l. Contacto - Datos legales ReD Internet: Hospedaje Web | envio sms gratis | Salvapantallas | Fondos de Escritorio, famosas | melodias moviles gratis| Gratis |