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.