Archive for Implementación

Integrando el manejo de Phidgets en el servidor

De momento va bien la cosa, aunque con un “pero”: No es posible obtener la identificación individual de cada sensor analógico. El pc (o la placa en este caso) sólo sabe que tiene conectado un phidget (el kit de conexión), pero no sabe nada acerca de cuáles son los sensores que este tiene conectado en cada puerto.

Así que habrá que buscar un puerto fijo para cada tipo de sensor. No hay problema por ahora. Ya veré si esto se puede mejorar de alguna manera.

Anuncios

Dejar un comentario

¡Funciona!

Bueno, me ha dado tiempo a hacer una prueba del método que se me ocurrió para solucionar lo de OSGi y Web Services en la misma aplicación y funciona. Ahora sólo necesito un hueco para hacerlo bien hecho.

En realidad el proyecto me está volviendo loco porque poco a poco se está convirtiendo en una especie de cosa monstruosa que está devorando mi vida (menos mal que vivo solo). Ahora que llevo un tiempo con la parte hardware y triposa del proyecto se me olvidan los detalles de la parte Java. Y ahora que tengo que regresar a la parte Java no puedo porque tengo que atender a la parte documentación. Aargh.

En fin, la solución en sí es tonta de sencilla que es (en esencia, por lo menos). No puedo tener una aplicación con OSGi y Web Services al mismo tiempo que funcione sólo con el framework Felix y no con un bicharraco como GlassFish. Pues separo la parte OSGi por un lado y la parte Web Services por otro.

La cosa es mantener Oolong tal y como está ahora. Hacer un pequeño cliente de Web Services que se ejecute junto con Oolong y coja los datos publicados por la placa. Este cliente a su vez es un servidor al que se conecta Oolong por sockets (dentro de la misma máquina, se supone), y que envía objetos serializados que son recogidos por Oolong y que contienen los datos publicados por la estación. Tachán.

Por supuesto, habrá que ver la mejor forma de implementar esto, pero por lo menos ya es algo. Y funciona.

Dejar un comentario

Web Services y OSGi (¡por los pelos!)

A falta de unos pocos días para el Hackatón, donde se supone que tendría que presentar mi maravillosa aplicación que utiliza OSGi y JAX-WS para hacer cosas chulísimas voy y me quedo atascado.

Resulta que tengo por un lado una aplicación que se ejecuta con un framework de OSGi y que funciona bien. Por otro lado tengo un servidor y un cliente de web services que también funcionan bien. ¿Qué ocurre cuando junto ambas cosas? que no tira.

Después de una tarde entera y una noche buscando el error y una solución llego a la conclusión de que las cosas pintan mal. Parece que la biblioteca JAX-WS que viene de serie con la JVM de Sun no funciona bajo OSGi. No parece estar hecha para lanzar servicios dinámicamente que podrían estar o no estar en un momento dado.

Una solución es coger otra implementación de JAX-WS (hay como cuarenta) y ponerla en el directorio de “endorsed libs” del entorno Java para que se utilicen estas en lugar de las que trae la máquina de serie. A mí no me funcionó ni con las de Metro ni con ninguna.

Otra solución es tirar el código de web services que tengo y reimplementarlo bajo un framework para web services compatible con OSGi como Glassfish, Axis2 o cualquiera de estos. Lo cual haría que una aplicación que en principio es una chorrada se convirtirera en un monstruo, de complicada, de grande y de … (esto no sé cómo decirlo en español) … overengineered.

Así que he echado a andar la cabeza y se me ha ocurrido una alternativa que tiene pinta de funcionar. Esta tarde la pruebo y si va bien ¡alegría! ya puedo seguir adelante.

Seguiremos informando

Comments (1)

Look & feel de swing

Una de las primeras cosas que metí en el código de Oolong fue la selección del look&feel de Swing, porque es muy fácil de hacer y así se puede ir viendo cómo queda la aplicación. Como siempre, las cosas no son tan bonitas como parecen al principio, y si bien es sencillo configurar qué look&feel utilizará la aplicación con unas líneas como las siguientes:

try{

    UIManager.setLookAndFeel(

            UIManager.getSystemLookAndFeelClassName());

}

catch(Exception ex){

    UIManager.setLookAndFeel(

            UIManager.getCrossPlatformLookAndFeelClassName());

}

decidir qué look&feel utilizar finalmente y pulir los detalles es más complicado (como siempre que se intentan pulir los detalles en Swing). En mi caso, ahora mismo utilizo el look&feel nativo siempre que esté disponible. Si no hay ninguno disponible o no está definido, se utiliza Metal, que es feísimo.

Otra solución es utilizar algún look&feel desarrollado por terceros como Substance, que es el que más me convence. Esto garantizaría que la aplicación se vería igual en todas las plataformas, pero añade un peso considerable a la aplicación que ya de base ocupa más de 1MB (por incluir el framework Apache Felix).

Ahora mismo tengo pendiente arreglar un problemilla con Oolong que ocurre desde que añadí el widget del termómetro deprisa y corriendo. Hay un pequeño jaleo con este tema de los looks&feels. La aplicación debería aparecer siempre con apariencia GTK (en Linux), pero ahora según que casos aparece con look Metal. Ya le echaré un ojo.

Dejar un comentario

Primeros pasos con OSGi (II): Oolong

Buenas.

Después de llevar un par de días parado, hoy he retomado el proyecto con ganas y he seguido experimentando con OSGi. Como todavía veo un poco lejano el diseño de la aplicación servidor, estoy haciendo los experimentos en Oolong, la aplicación cliente. Así que poco a poco voy dando a luz algunas funcionalidades.

De momento no es más que un ejemplo de OSGi, pero lo único que hace está bastante chulo. Utilizo Apache Felix File Install, que constantemente está vigilando un directorio por si se añaden o se eliminan bundles de la aplicación. El método es un simple sondeo del directorio periódicamente. No sé si esa será la mejor opción de vigilar los bundles, pero si los de Apache han lanzado la aplicación yo me fío. De momento todo funciona bien.

Con OSGi no ha habido problemas, todo ha funcionado según lo previsto. Lo único que tengo que arreglar es el código. Refactorizar y comentar, porque el código para dibujar GUIs en Swing siempre parece un poco feo. De momento estoy contento con cómo estoy organizando y escribiendo la aplicación, aunque iré puliendo detalles conforme vaya sacando versiones.

A lo que iba. De momento Oolong sólo hace una cosa: mostrar una lista con los plugins que hay instalados. Tiene un botón de “Actualizar” que refresca la lista cada vez que se pulsa. Para instalar un plugin sólo hay que copiarlo al directorio “dropins” y la aplicación lo instalará en el instante. Para desinstalarlo, pues se borra del mismo directorio y ya está. Todo esto sin parar la aplicación.

Mañana subiré el código al repositorio y lanzaré la primera versión. No se puede llamar a esto programa todavía, pero me viene bien ir subiendo el primer código. Además sería genial que alguien lo probara en MacOS X para ver cómo se ve. Sospecho que mal, porque lo he programado deprisa y corriendo y para que se me vea bien a mí en Linux. Pero para eso necesito que la gente lo pruebe, para hacer esos arreglillos.

Un saludo

Comments (2)

Instalando GNU/Linux Debian en la BeagleBoard

Gracias al excelente howto de Robert Nelson, a la gente de OpenEmbedded y al Qemu, la instalación de Debian en la placa ha sido casi trivial, sin apenas sorpresas. Una vez entendido el funcionamiento de los modos de USB que permite la placa y cómo utilizar el puerto Ethernet que proporciona el hub USB que estoy utilizando, todo lo demás fue un paseo.

Ahora mismo ya puedo conectar la placa al pc mediante un cable serie null-modem y además acceder a la placa por ssh desde el pc, montar el sistema de archivos raíz por NFS, etc.

Tengo que ver qué versión parcheada del kernel es más conveniente para esta revisión de la placa (la C3). Normalmente, el procedimiento para instalar un kernel Linux en esta placa consiste en obtener la versión que queramos del kernel para OMAP3 (la familia del procesador que lleva la placa) y después aplicar los parches necesarios de entre los que liberan los de OpenEmbedded, para adaptar el kernel a nuestra placa de la forma más precisa posible.

Para ahorrar tiempo y problemas, he optado de momento por probar la instalación con varias versiones ya compiladas del kernel parcheado, construido y proporcionado por Robert Nelson, con lo que me he ahorrado todo el proceso de compilación cruzada del kernel. Todas las que he probado funcionan sin problemas, pero tendría que ver de todas formas cuál viene mejor. Más adelante tendré que construir un kernel a medida de todas formas, para tener un núcleo más pequeño y más apropiado para la placa, así que iré comentando. Pero de momento no es tan prioritaria esa tarea, porque con lo que hay hecho ya funciona todo correctamente. La construcción a medida del kernel es más por motivos didácticos que otra cosa.

Como decía, hubo un momento de crisis hasta que logré hacer funcionar los dispositivos que hay conectados por USB (el puerto Ethernet que trae el hub). El motivo es que la placa tiene dos puertos USB: uno OTG (On The Go) que se puede configurar como host y como esclavo, y otro EHCI que funciona como host. Supuestamente si conectamos al puerto OTG un conector tipo mini-A, que puentea un par de pines, el puerto se configura como host, pero yo conecté ahí el hub usb y no terminaba de funcionar bien el puerto Ethernet. La otra opción era alimentar la placa por el jack de alimentación en lugar de por el OTG y conectar el hub al puerto EHCI. Así funcionó del tirón, así que así se queda.

Conocidas estas cosillas, lo demás es igual que trabajar con Linux en una máquina de escritorio. Seguramente aparecerá algún contratiempo cuando pruebe los phidgets en la placa, pero para eso todavía queda un tiempo.

Dejar un comentario