En SciTE, al buscar números utilizando expresiones regulares no es válido usar el caracter especial \d. En esos casos se debe usar [0-9].
jueves, 2 de diciembre de 2010
SciTE: Encontrar números con Regexp
En SciTE, al buscar números utilizando expresiones regulares no es válido usar el caracter especial \d. En esos casos se debe usar [0-9].
Etiquetas:
Expresiones regulares,
RegExp,
SciTE
Cadena vacía en llamado a SP de SQL Server
Al hacer un llamado a un procedimiento almacenado de SQL Server desde Java, en el que uno de los parámetros era una cadena vacía, éste la recibía como si se le estuviera enviando un espacio en blanco, lo cuál no era válido para el SP.
Se me ocurrió hacer una prueba enviando null en el parámetro en cuestión y resultó que el SP lo tomó correctamente.
Etiquetas:
java,
MSSQL,
Procedimiento almacenado,
SP,
SQL Server
lunes, 23 de agosto de 2010
Oracle: Cómo encontrar las tablas hijas de una tabla
Con el siguiente script se pueden encontrar las tablas hijas para determinada tabla:
Visto en Foros de Oracle
select table_name as hijas from user_constraints where r_constraint_name in (select constraint_name from user_constraints where table_name=upper('&table_name') and constraint_type='P') order by table_name;
Visto en Foros de Oracle
lunes, 28 de junio de 2010
HTTPS hostname wrong
Al acceder a una URL como en el post anterior pero utilizando la dirección IP se me pesentó el siguiente error:
java.io.IOException: HTTPS hostname wrong: should be <10.1.84.139>
Encontré en algún lado que para poder pasar esa verificación de hostname se puede crear un HostNameVerifier y setearlo como el que se va a usar por defecto en la aplicación:
El resultado es:
HostName: 10.1.84.139 sessionHost: 10.1.84.139
java.io.IOException: HTTPS hostname wrong: should be <10.1.84.139>
Encontré en algún lado que para poder pasar esa verificación de hostname se puede crear un HostNameVerifier y setearlo como el que se va a usar por defecto en la aplicación:
HostnameVerifier hv = new HostnameVerifier() { public boolean verify(String urlHostName, SSLSession session){ return true; } }; HttpsURLConnection.setDefaultHostnameVerifier(hv);Lo que no entendí es por qué falla la verificación, si al poner la siguiente línea dentro del método verify:
System.out.println("HostName: " + urlHostName + " sessionHost: " + session.getPeerHost());
El resultado es:
HostName: 10.1.84.139 sessionHost: 10.1.84.139
Etiquetas:
HostNameVerifier,
https,
HttpsURLConnection,
java,
ssl
martes, 2 de marzo de 2010
Java: URL's seguras con certificados no confiables
Para acceder a una URL segura desde Java, se hace el mismo procedimiento que con una URL no segura:
Entonces lo que hay que hacer es instalar un TrustManager que no valide los certificados, en el Contexto SSL.
Una vez hecho esto ya podemos hacer lo del código de arriba sin que nos falle por certificados de seguridad.
URL url = new URL("https://www.urlsegura.com"); URLConnection conn = url.openConnection(); BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream())); String linea; while ((linea = in.readLine()) != null) System.out.println(linea); in.close();Pero si esa URL segura tiene un certificado no confiable, el acceso a esa URL va a fallar, generando un error similar al siguiente:
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Entonces lo que hay que hacer es instalar un TrustManager que no valide los certificados, en el Contexto SSL.
TrustManager[] trustAllCerts = new TrustManager[]{ new X509TrustManager() { public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; } public void checkClientTrusted( java.security.cert.X509Certificate[] certs, String authType) { } public void checkServerTrusted( java.security.cert.X509Certificate[] certs, String authType) { } } }; try { SSLContext sc = SSLContext.getInstance("SSL"); sc.init(null, trustAllCerts, new java.security.SecureRandom()); HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory()); } catch (Exception e) { }
Una vez hecho esto ya podemos hacer lo del código de arriba sin que nos falle por certificados de seguridad.
Etiquetas:
java,
ssl,
TrustManager,
URL,
ValidatorException
jueves, 18 de febrero de 2010
iReport 3.7 unable to resolve class JRBeanCollectionDataSource
Hace ya años que no diseñaba un reporte en iReport.
El que tuve que hacer hoy requería de un subreporte y perdí mucho tiempo buscando el origen del error mencionado arriba.
Pues resulta que cuando yo hacía los subreportes, podía pasar el Data Source Expression de la siguiente manera:
Ahora eso genera un error al compilar la plantilla. Y la solución es muy sencilla, toca poner toda la ruta de la clase, es decir:
El que tuve que hacer hoy requería de un subreporte y perdí mucho tiempo buscando el origen del error mencionado arriba.
Pues resulta que cuando yo hacía los subreportes, podía pasar el Data Source Expression de la siguiente manera:
new JRBeanCollectionDataSource($P{unParametro})
Ahora eso genera un error al compilar la plantilla. Y la solución es muy sencilla, toca poner toda la ruta de la clase, es decir:
new net.sf.jasperreports.engine.data.JRBeanCollectionDataSource($P{unParametro})
jueves, 4 de febrero de 2010
Autenticación contra Websphere MQ 6.0
Al trabajar contra Websphere MQ 6.0 desde Java, encontré que hacen una autenticación del usuario que intenta leer las colas. El problema es que siempre se envían las credenciales del usuario que está logueado localmente, por lo que siempre nos va a decir que no somos un usuario válido.
El error que sale es:
Para solucionar esto hay algunas alternativas
El error que sale es:
javax.jms.JMSSecurityException: MQJMS2013: se ha indicado una autentificación de seguridad no válida para MQQueueManager
Para solucionar esto hay algunas alternativas
- Agregar el usuario que inicia la aplicación (ej: oas103) en el grupo MQM de la máquina que hospeda el MQ.
- Utilizar la propiedad del sistema user.name y pasarle el valor SYSTEM. Esta propiedad es leída por las clases en com.ibm.mqjms.jar. Este "truco" funciona porque el si servidor de MQ está corriendo como un servicio standard de Windows, se debe estar ejecutando con el usuario SYSTEM.
- Insertar en el código Java, en alguna parte, la misma variable de entorno del punto anterior.
System.setProperty("user.name","SYSTEM")
- En el servidor MQ en el JMSAdmin.config agregar la línea:
"SECURITY_AUTHENTICATION=none"
que deshabilite toda la autenticación.
martes, 2 de febrero de 2010
Error al iniciar JDeveloper 11g
Después de instalar JDeveloper 11g intenté iniciarlo, pero me salió un error diciendo "Unable to create an instance of the Java Virtual Machine Located at path...".
La solución es editar el archivo jdev.conf de la carpeta en la que se instaló el JDeveloper, ejemplo: C:\oracle\Middleware\jdeveloper\jdev\bin.
En este archivo se debe agregar la siguiente linea:
La solución es editar el archivo jdev.conf de la carpeta en la que se instaló el JDeveloper, ejemplo: C:\oracle\Middleware\jdeveloper\jdev\bin.
En este archivo se debe agregar la siguiente linea:
AddVMOption -Xmx256MDespués de la línea que dice:
AddVMOption -XX:MaxPermSize=256MVisto en: http://javainnovations.blogspot.com/2009/10/jdeveloper11g-startup-error.html
Suscribirse a:
Entradas (Atom)