Contenedores OC4J

Ke onda chavos, soy nuevo en el foro, y ya tengo una wena duda jajajaja... se supone ke tengo un servidor OC4J, en el cual tengo en config mi data_source. En mi codigo de java tengo una clase ke accesa a ese datasource a traves de:

InitialContext initialcontext = new InitialContext();
DataSource ds = (DataSource)initialcontext.lookup("java:comp/env/jdbc/siarp");
localConnection = ds.getConnection();

Como sabemos la clase se keda en WEB-INF, sin embargo la clase tambien se duplica en una carpeta que se coloco en raiz de la aplicacion. la estructura es mas o menos asi:

SIARP
- classes
conexion <- aki uso la linea que les comente arriba

- web-inf
classes
conexion <-aki esta tambien dicho codigo.

Si mas o menos entiendo bien, el codigo que se encuentra bajo web-inf me recupera el jndi.
Mi duda es si el que se encuentra en classes de raiz del sitio puede accesar al jndi?

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

war?

Tu aplicación está empaquetada como un war? Porque en ese caso, ese folder de classes a nivel raíz creo que no se lee (aunque dependerá del contenedor supongo).

Por qué no haces simplemente una prueba poniendo un println o log en una clase que vaya en classes en el raíz a ver si sale en el log...

War-cito

Sipi, esta dentro de un WAR... y tienes razon voy a checar si esa clase se esta ejecutando ( me escudo de ke la aplicacion no es mia, jajajaja no se kien la programó, sencillamente le toy dando mantenimiento por cuestiones de uso de conexiones a bd ). Al parecer esa carpeta la usan unos applets que vienen dentro, y los mandan a llamar unos jsp, pero como dices tu, podria ser que nunca usa esa clase. Vere que detalle le encuentro... la verdad ya me noqueo esta cosa fea de sistema que hicieron jajajajaja...

Imagen de ezamudio

ah claro

Ese folder "classes" a nivel raíz es visible a nivel web... lo que hay dentro de WEB-INF no, pero ese a nivel raíz sí, y puede ser que exista para applets, porque así descargan de ahí las clases que necesitan. Pero entonces esa clase que pones ahí se ejecuta en el applet, y desde el applet no creo que sea accesible el datasource (no debería serlo, por seguridad).

Asi es... ya cheque bien

Asi es... ya cheque bien como dices correctamente. Estos applets quieren hacer una conexion a la base de datos, y al momento de ejecutar la clase, manda el error de

javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial

Por los motivos de seguridad que ya entendemos. Por lo que veo no podra usar una conexion "dinamica" como la que estoy intentando.

En un principio opté por usar un archivo PROPERTIES para que de ahi tomaran las conexiones y funciono bien, pero me hicieron la peticion de ver si se podia omitir el uso de archivos de configuracion y ke automaticamente tomara el jndi para no tener que mover siempre esos archivos para mandar a desarrollo y luego a productivo.

No existe alguna otra forma de que tomara el datasource del contenedor???? Es mi duda final, si no lo hay tendre que darme por vencido ... ( fu..ing codigo )

Imagen de ezamudio

espero que no

Tal vez podrías hacer el directorio JNDI accesible al mundo para que se conecten los applets... y cualquier persona que encuentre el JNDI público. Mal diseño, haces tu aplicación, tu base de datos y tus otros servicios JNDI muy vulnerables.

Necesitas poner en el contenedor un servicio que se conecte a la base de datos y realice las operaciones que necesitas, y publicar un API para poder utilizar ese servicio. Por ejemplo usando RMI pero requiriendo comunicación segura con SSL y usar algun mecanismo de autenticación para que solamente usuarios legítimos del applet puedan usar ese servicio. Y el applet se vuelve cliente de ese servicio; ya no ejecuta SQL ni usa JDBC directamente con el DataSource sino que únicamente tiene acceso a la funcionalidad expuesta por el servicio.