2009/8/5 Matías di Tada <[email protected]>: > 2009/8/5 Mariano Cuenze <[email protected]>: >> Estimados/as: >> >> Como parte de una 'prueba de concepto' que estoy haciendo en java (v >> 6.0), en un entorno xubuntu, necesito conectarme a una base h2. >> El código está totalmente completo, mas tiene como referencia externa >> el jar de h2. 'Compila y anda' si al ejecutarlo uso "java -cp <ruta al >> h2.jar> Poc.class". >> >> *el siguiente pedacito de código, no termina de andar, y es el 'motivo >> de mi consulta', ¿qué me estará faltando?¿qué no estaré considerando?: >> >> //inicio codigo >> java.net.URL[] urls = new java.net.URL[1]; >> urls [0]=new java.net.URL("file:///home/mariano/Desktop/testH2/h2.jar"); >> //ruta al jar >> Class clase = Class.forName("org.h2.Driver",true, new >> java.net.URLClassLoader(urls) ); >> //"magia" para evitar el class path >> Connection conn = >> DriverManager.getConnection("jdbc:h2:~/Desktop/hsTest/db", "sa", ""); >> //al ejecutar tira error de "clase no encontrada", no pasa si uso >> "java -cp ruta Poc.class" >> //fin codigo > > Yo tuve que hacer algo parecido para poder hacer un hotdeploy de > cambios en clases. Me cruce con mil problemas y algo que me dio muchas > pistas es una pagina [1] donde se explica bien todo el tema de > classloaders, jar remotos, etc. > A mi me funciono hacer un custom classloader y sobreescribir > loadClass, dentro de loadClass leo el jar, obtengo el .class y llamo a > defineClass. > Suerte, > Matias. > > [1] http://www.szegedi.org/articles/remotejars.html
Gracias Realmente Matias por la respuesta.... Te cuento (les cuento) que leí el artículo y estuve probando bastante... De momento en limpio tengo: +la clase del driver la está cargando (incluso con el código original que usé) +la clase del driver falla miserablemente =) en registrarse con el DriverManager o el DriverManager en registrarla. Eso me llevo a mirar más qué pasa cuando incluis un jar desde el classpath y se ejecuta lo que le indiques 'en la sección del bounce' del jar, en el caso de un driver de jdbc la llamada a Driver.load (método estático de registración). Ahora, si la clase la cargo con un 'ClassLoader' desde java, aún llamando a mano al método estático load(). DriverManager no la puede 'registrar bien', es como si al 'ponerla en el sandbox de un loader particular' (y no el por defecto del thread en ejecución), es 'una clase de otro salero' y no puede 'integrarse bien' al manajer. No se si necesito hacer un 'class loader' de todas y cada una de las clases del jar (extremista, pero bueh); o si tengo qeu 'agregarle al class loader del thread' la ruta del jar para que 'homogeinise' todo (metodo que 'no vi tenga' un ClassLoader) . Aquí mi nueva intriga: + Puedo agregar una url de origen a un ClassLoader ya existente? + La forma de 'chain' de los ClassLoader es "acá tengo un Class loader nuevo para tal recurso, peo si falla, patea el pedido a tal otro (cual parent) que puede saber y le registro _solo_ al crearlo", sería como un bubble del sistema de eventos del w3c. Pero el método getConnection de DriverManager es estático, ya está cargado "con ámbito de classLoader por defecto" y no quisiera ni pensar en 'la oscura maniobra' de recrearlo en un Classloader propio. En resumen, parece que 'aunqeu se carga la clase, tendría que inicializar la clase en el class loader por defecto' para qeu tenga una 'clara visibilidad de creación' por el DriverManager. Puedo estar absoluta y maravillosamente equivocado en lo que expuse. Por las moscas: el requisito de "no puedo usar nada más que 'java Test.class' ", aunque suene caprichoso es _absolutamente necesario_ =). Seguiremos informando desde la escena de los hechos ;) -- Mariano _______________________________________________ Lista de correo Programacion. [email protected] http://listas.fi.uba.ar/mailman/listinfo/programacion
