Download Informe de actividad

Informe de actividad
David A. Velasco Villanueva
sprint # 22
16/07/2010 – 07/09/2010 (extendido tras 22/07/2010)
Objetivos planteados y alcanzados
•
[000033] Hacer los adaptadores de implementación portables / configurables
[DONE]
•
[000051] Estudiar LAMS
[DONE]
•
[000035] Documentación de diseño interno de GLUEletManager
[ WIP ]
•
Modificar la configuración de MoodleAdaptor a un solo parámetro 'URL base'
[DONE]
Por partes
Modificar la configuración de MoodleAdaptor a un solo parámetro 'URL base'
** Modificar la configuración de MoodleAdaptor a un sólo parametro
En un sólo parámetro "URL base" se agrupa nombre de servidor o IP, puerto y, opcionalmente, un
trozo de ruta que irá prefijado a 'GLUEletManager'.
** Componer la URL en las llamadas a GLUEletManager a partir del parámetro URL base
Modificar en lib.php las funciones gluelet_get_configuration(...), gluelet_get_instance(...) y
gluelet_delete_remote_instance(...) para que compongan la URL de llamada a partir del valor
guardado en $CFG->{GLUELET_MOD . '_base_url'} (valor configurado en la consola de
administración).
Modificar el resultado entregado por las funciones gluelet_get_tools_list() y
gluelet_post_new_instance(...) para que en la base de datos no se guarden las URLs completas, sino
sólo la parte final posterior a la cadena 'http://' . $CFG->{GLUELET_MOD . '_base_url'} .
'/GLUEletManager'.
[000033] Hacer los adaptadores de implementación portables / configurables
Similar a lo hecho con GLUEletManager:
•
fichero app.properties con propiedades configurables
•
dos propiedades:
◦ port: número de puerto de atención de peticiones
◦ logging: on/off, para activar/desactivar el sistema de logging
Cambios en código afectan únicamente al fichero [Whatever]AdaptorServerMain, inicialización del
adaptador.
[000051] Estudiar LAMS
** Carga de la lista de herramientas 'GLUEficadas' a partir de resultado de GET TOOLS
Nos quedamos en:
2010-07-15 18:19:16,244 ERROR [org.apache.catalina.core.ContainerBase.
[jboss.web].[localhost].[/lams/tool/gsglue10].[action]] Servlet.service() for
servlet action threw exception
java.lang.StackOverflowError
at java.lang.String.indexOf(String.java:1521)
at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:127)
at
org.jboss.net.protocol.file.Handler.parseURL(Handler.java:35)
at java.net.URL.<init>(URL.java:596)
at java.net.URL.<init>(URL.java:464)
at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:976)
at sun.misc.URLClassPath$FileLoader.findResource(URLClassPath.java:966)
at sun.misc.URLClassPath$1.next(URLClassPath.java:196)
at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:206)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:416)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader$3.next(URLClassLoader.java:413)
at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:438)
at
org.jboss.mx.loading.UnifiedLoaderRepository3.getResources(UnifiedLoaderReposito
ry3.java:332)
at
org.jboss.mx.loading.RepositoryClassLoader.findResources(RepositoryClassLoader.j
ava:543)
at java.lang.ClassLoader.getResources(ClassLoader.java:1041)
at java.lang.ClassLoader.getResources(ClassLoader.java:1037)
at
org.restlet.engine.util.EngineClassLoader.getResources(EngineClassLoader.java:15
1)
at org.restlet.engine.Engine.registerHelpers(Engine.java:724)
at org.restlet.engine.Engine.discoverConnectors(Engine.java:475)
at org.restlet.engine.Engine.<init>(Engine.java:325)
at org.restlet.engine.Engine.register(Engine.java:246)
at org.restlet.engine.Engine.register(Engine.java:235)
at org.restlet.engine.Engine.getInstance(Engine.java:148)
at org.restlet.engine.Engine.getLogger(Engine.java:203)
at org.restlet.Context.getCurrentLogger(Context.java:87)
at org.restlet.engine.Engine.registerHelper(Engine.java:659)
at org.restlet.engine.Engine.registerHelpers(Engine.java:688)
at org.restlet.engine.Engine.registerHelpers(Engine.java:730)
(se repiten las 10 últimas hasta la saciedad)
Pensando que podría ser un problema por la carga dinámica de objetos.
Pero no. El problema es que el servidor de aplicaciones no incluye las bibliotecas RESTlet en el
CLASSPATH de la aplicación web. Para solucionarlo, además de copiar los JAR correspondientes
en el directorio lams.ear del servidor desplegado, hay que hay que añadir sus nombres en el fichero
lams.ear/META-INF/application.xml, en el que se indica que JARs deben cargarse en el contexto
del EAR.
La entrada en el fichero, con todos los JAR necesarios, es:
<!-- GLUElet dependencies , by davivel -->
<module>
<java>glue-common.jar</java>
</module>
<module>
<java>org.restlet.ext.atom.jar</java>
</module>
<module>
<java>org.restlet.ext.xml.jar</java>
</module>
<module>
<java>org.restlet.jar</java>
</module>
<!-- End of GLUElet dependencies , by davivel -->
Todo esto lo he hecho a mano. Habrá que plantearse cómo modificar el fichero build.xml para
hacer el despliegue de la forma más simple e independiente posible.
Esto soluciona el problema de carga, aunque en el momento de completar la interacción se produce
un último error. La comunicación con GLUEletManager se establece correctamente, PERO al
intentar acceder al contenido de los <atom:entry> de respuesta se obtiene una excepción por un
valor NULL.
Afortunadamente no es un problema en la llamada GET, sino en la biblioteca GLUECommon en la
que basamos la extracción de datos de las herramientas formateadas. Tras hacer un poco de
fontanería en la misma, se soluciona completando adecuadamente el método
FormattedFeed.getEntries() y añadiendo un constructor más a FormattedEntry, con parámetro único
de tipo (DOM) Node.
Ojo; que la carga del conector cliente RESTlet haya sido posible no quiere decir ni que haya sido
eficiente (creo un Component RESTlet antes de cada llamada, dudo mucho que sea necesario...), ni
que respete la seguridad del contenedor de servlets (aunque en este punto, el hecho de que el
contenedor no intente impedir la conexión puede ser una buena señal). Habrá que comprobar ambas
cosas en el futuro.
Pero ahora toca hacer un poco de roadmap para LAMSAdaptor.
** Roadmap de tareas siguientes
Llamadas GLUE por implementar:
•
(1) Lanzar GET CONFIGURATION al seleccionar la herramienta (¿hay que añadir botón?)
•
(4b) POST INSTANCE
•
(6) GET INSTANCE
•
(7) DELETE INSTANCE - ¿cuándo?
Modificaciones en la interfaz de usuario:
•
(1) Extender IU con un bloque cuando se seleccione la herramienta GLUE en la lista
•
(2) Incluir el formulario XForms en el bloque anterior
•
(3) Recoger la respuesta XML del formulario XForms en LAMSAdaptor (puede que
construir el documento XML)
•
(6) Modificar las vistas de monitorización / uso para poder visualizar la instancia GLUElet
Integración con interacciones en LAMSAdaptor:
•
(4a) Guardar la configuración XForms en la base de datos; implica modificar el modelo de
datos persistentes
•
(4b) Buscar el punto (en código) más adecuado para lanzar POST INSTANCE
◦ implica analizar cómo funciona la característica 'postergar configuración hasta
monitorización'
•
(5) Comprobar las operaciones hechas automáticamente por LAMS cuando se asigna una
secuencia de aprendizaje que incluye un GLUElet a un curso LAMS
•
(8) Encajar el uso de grupos
Limpieza (después):
•
eliminar 'restos' de lams-forum
•
revisar eficiencia de llamadas
•
refactorizar
•
generar mecanismo de despliegue fácil
Planificación: agrupar todas las anteriores en actividades racionalmente, de acuerdo con lo que se
puede probar y lo que no; ¿estimación de tiempo? (puf – this will be hard)
#### AHORA ####
Detalle de modificaciones:
•
Vista:
◦ web\jsps\authoring\basic.jsp
▪ (lo que haya, que algo es)
◦ conf\language\lams\ApplicationResources_en_AU.properties
ApplicationResources.properties
y
▪ (lo que haya, que algo es)
•
Modelo – AÑADIR ATRIBUTO toolConfigurationForm a Gluelet, que implica:
◦ src\...\persistence\Gluelet.java
▪ añado atributo String toolConfigurationForm, para guardar el formulario
▪ añado getToolConfigurationForm y setToolConfigurationForm para atributo
toolConfigurationForm
▪ getToolConfigurationForm
incluye
column="toolConfigurationForm"
XDoclet
@hibernate.property
▪ añado toolConfigurationForm a la implementación de los métodos equals() y
hashCode()
◦ db\sql\create_lams_tool_gluelet.sql
▪ añado columna "toolConfigurationForm text" al final de tl_gsglue10_gluelet
◦ db\sql\table-schema.sql
▪ añado "toolConfigurationForm text" al final de creación de tl_gsglue10_gluelet
◦ db\sql\insert_lams_tool_gluelet_data.sql
▪ añado valor "TEST TOOLCONFIGURATIONFORM" como valor por defecto de
columna toolConfigurationForm.
◦ src\java\...\service\GlueletService (y IGlueletService)
▪ añado método 'public String getToolConfigurationForm(String glueToolId);'
•
Controlador (ver cambios, que los hay)
◦ NO TOCAR DIRECTAMENTE STRUTS-CONFIG.xml ; es un fichero generado; tocar
en su lugar conf/xdoclet/struts-action.xml
▪ añado acción getToolConfigurationForm
◦ src\java\...\web\actions\AuthoringAction
▪ añado método getToolConfigurationForm(...), que hace:
•
(ver código)
Otras cosas no planeadas
** Comprobar la solución del RESTlet issue 1306
He recibido una notificación del equipo de RESTlet pidiéndome que pruebe el problema con la
excepción en ClientResource.get(), ya que según ellos debería estar solucionado.
He probado con RC4 y el problema original está corregido:
•
Las pruebas con el código Proxy / Server que envié para que probaran el error ponen de
manifiesto que el error persiste en las versiones 2m07, 2RC1 y 2RC2; y está corregido en
2RC4 (no he probado RC3).
•
Las pruebas con GLUEletManager confirman la corrección con 2RC4.
Cabe destacar que, al tirar el adaptador de implementación para provocar la excepción en
GLUEletManager y enviar como respuesta desde éste el código HTTP generado por la propia
excepción, éste resulta ser un código 1001, que no es estándar. Cosas de RESTlet...
Cambios derivados:
•
eliminación del 'apaño' en las llamadas a recursos remotos desde GLUEletManager, en:
◦ ConfigurationResource.getRemoteResource(...)
◦ InstanceResource.getRemoteResource(...)
◦ InstanceResource.deleteRemoteResource(...)
◦ InstanceFactoryResource.postRemoteCreation(...)
◦ GLUEletManagerServerMain.resetClientConnector() (eliminado)
•
deben actualizarse los JAR de RESTlet a instalar con GLUEletManager al paquete de la
versión 2.0 RC4, disponible en http://www.restlet.org/downloads/2.0/restlet-jse-2.0rc4.zip ;
no es necesario actualizar los JARs de los adaptadores de implementación.
## Y además ##
•
Gestiones habituales
Futuro
### OLD ###
GO ON, LAMSAdaptor:
•
1. Conseguir una herramienta 'tonta' que no produzca errores.
(DONE)
•
2. Modificar la interfaz de autoría para incluir una lista de selección hardcoded para las
herramientas.
(DONE)
•
3. Modificar la configuración de la lista de selección para que se cargue a partir la
respuesta de GET TOOLs
(WIP)
Paralelamente, hay que avanzar de verdad con:
•
Completar [000035]: documentación de diseño interno de GLUEletManager; y otras
actividades de documentación
•
[000033] Hacer [Implementation]Adaptor portables