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].

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.

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:
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:
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

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:

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.

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:
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:

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.
Más información en http://www.topsecurity.dk/cmview/View?id=1575

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:
AddVMOption -Xmx256M
Después de la línea que dice:
AddVMOption  -XX:MaxPermSize=256M
Visto en: http://javainnovations.blogspot.com/2009/10/jdeveloper11g-startup-error.html