Al intentar crear un perfil de servidor WebSphere utilizando el Rational Application Developer 7.5 en Ubuntu 10.04 se queda parado en “importConfigArchive”.

Según este foro de IBM parece ser que el problema está en que sh está enlazado con dash en vez de estar con bash.

Si hacemos que sh esté enlazado con bash, el proceso se puede realizar sin problema.

cd /bin
sudo rm sh
sudo ln -s bash sh

Aunque sería buena idea dejar todo como al principio una vez finalizado el proceso.

cd /bin
sudo rm sh
sudo ln -s dash sh

vía

Algunos enlaces de interés
Installing Rational Software Architect 7.5.4 on Ubuntu Karmic
Linux /Ubuntu tomcat -> too many open files

Para que el tema de los merges del SVN funcione bien, se supone que la forma de trabajo sería la siguiente:

Creación de una nueva rama de código:

  • Todas las ramas (branchs) se deberían crear a partir de una rama principal (trunk)
  • A la hora de crear un branch se “aconseja” poner como comentario:
    Branch from trunk rev:28495
    donde Branch es el nombre de la rama y 28495 es la revisión de partida del trunk de la que se crea la rama

Mezcla de nuevos cambios del trunk al branch:

  • Actualiza tu copia de trabajo a la última versión del branch
  • Averigua el número de revisión del último merge (si todavía no se hizo ninguno, el número de revisión de creación, que, si sigues las indicaciones deberías tener en alguno de los comentarios)
  • Utiliza la herramienta de merge de subclipse para mezclar el trunk en tu copia de trabajo (Team -> Merge)
    • Las URL‘s que aparecen en “From” y en “To” deberían ser las del trunk
    • La revisión del “From” debería ser el número de revisión del último merge
    • La revisión del “To” debería ser “Head
    • Pulsa en el botón Merge y espera a que termine
    • En la consola se muestra un log del proceso realizado. Si aparece algún conflicto (marcado con una C roja, lo que hay que hacer es localizar dichos ficheros en el navegador de archivos, botón derecho y pulsar en Team -> Edit Conflicts, lo que abrirá un nuevo editor con dos paneles con una versión en cada lado. Se resolverán los conflictos (como se realiza normalmente al subir cambios al SVN) y, una vez corregidos, se vuelve al navegador de archivos, sobre el mismo y se pulsa Team -> Mark as Resolved.
  • Probar todo una vez mezclado :)
  • Subir los cambios de la mezcla a la rama y poner como comentario:
    Merging trunk into branch X rev:28495 – rev:29536
    donde X es el nombre de la rama y 28495 y 29536 se refieren a los números de revisión inicial y final que se mezclaron

Pasar cambios de un branch al trunk

  • Actualiza tu copia de trabajo a la última versión del trunk
  • Averigua el número de revisión del último merge (si todavía no se hizo ninguno, el número de revisión de creación del branch, debería aparecer en los comentarios)
  • Utiliza la herramienta de merge de subclipse para mezclar el branch en tu copia de trabajo (Team -> Merge)
    • Las URL‘s que aparecen en “From” y en “To” deberían ser las del branch
    • La revisión del “From” debería ser el número de revisión del último merge
    • La revisión del “To” debería ser “Head
    • Pulsa en el botón Merge y espera a que termine
    • En la consola se muestra un log del proceso realizado. No debería aparecer ningún conflicto ya que se supone que el branch contiene lo último del trunk mas sus propios cambios.
  • Probar todo una vez mezclado :)
  • Subir los cambios de la mezcla al trunk y poner como comentario:
    Merged X branch changes [archive:29536]:[archive:29776] into the trunk
    donde X es el nombre de la rama y 29536 y 29776 se refieren a los números de revisión inicial y final que se mezclaron


Hasta donde yo se, utilizando el plugin subclipse, no existe modo alguno de cambiar desde eclipse el usuario/contraseña almacenados para svn.

Si utilizas SVNKit, el único modo que he encontrado pasa por borrar el archivo %ECLIPSE_HOME%/configuration/org.eclipse.core.runtime/.keyring de tal modo que al intentar conectar de nuevo al svn se nos pedirá el usuario/contraseña. Pero OJO!! que este proceso elimina cualquier contraseña guardada previamente (no solamente las de svn).

Si, por el contrario, usas JavaHL, la información del usuario/contraseña se almacena en el mismo lugar que el cliente svn de línea de comandos. En Windows se encuentra en %APPDATA%\Subversion\auth. En Linux y OSX en ~/.subversion/auth. Como en el caso anterior, podemos borrar dicho directorio con lo que nos volvería a preguntar usuario/contraseña.

Algunos enlaces de interés

subclipse: Wiki: PluginFAQ


Configurar un proxy HTTP en Eclipse es bastante sencillo.

  1. Abrir Window –> Preferences
  2. Pulsar General/Network Connections
  3. Marcar Manual proxy configuration
  4. Introducir la dirección del proxy HTTP
  5. Introducir el puerto del proxy HTTP
  6. Pulsar OK

Leer el resto de esta entrada »


Tras instalar el RSA 7.4.5, al arrancarlo aparecía el mensaje:

An error has occurred. See the log file
/home/rubensa/desarrollo/rsa/7.4.5/workspace/.metadata/.log

y no arrancaba.

Revisando el fichero de log, aparecía el error:

org.eclipse.swt.SWTError: XPCOM error -2147467262

Parece ser que el error se produce al intentar “pintar” una página HTML de ayuda que muestra el RSA al inicio. Este error es debido a que no encuentra la librerías de Mozilla para renderizar la página. Para solucionarlo, basta con añadir en el arranque (bien en el fichero eclipse.ini o bien como parámetro del lanzador):

-vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner

NOTA: Si lo intentas instalar en Ubuntu 10.04 necesitarás instalar también el paquete libstdc++5 que no se encuentra en los repositorios de Ubuntu Lucid Lynx pero que te puedes bajar directamente de los repositorios de debian.

vía


Cuando trabajas con código de terceras partes o con código generado (por ejemplo por axis2) puede ser interesante hacer que Checkstyle ignore ciertas clases que, en principio, no están bajo nuestro control.

Para conseguir esto podemos crearnos un fichero supperssions.xml y configurarlo en nuestro checks.xml del siguiente modo:

<module name=”SuppressionFilter”>
<property name=”file” value=”${samedir}/suppressions.xml”/>
</module>

NOTA: la variable ${samedir} es resuelta por eclipse-cs como el directorio en el que se encuentra nuestro checks.xml.

Dentro de suppressions.xml crearíamos algo como lo siguiente:

<?xml version=”1.0″?>

<!DOCTYPE suppressions PUBLIC
“-//Puppy Crawl//DTD Suppressions 1.1//EN”
“http://www.puppycrawl.com/dtds/suppressions_1_1.dtd”>

<suppressions>
<suppress checks=”.*” files=”.*/stub/.*\.java” />
</suppressions>

Dentro de la etiqueta suppress tienes los atributos checks y files que admiten regEx. En el ejemplo de arriba estoy filtrando todos los checkers para cualquier clase java que esté dentro del sub-paquete stub.

vía


Requisitos:

  • Tener instalado OpenSSL
  • Tener instalado la SUN JSDK

Creación de una Autoridad Certificadora:

  1. Genera clave privada de la CA
    openssl dsaparam -out dsparam.pem 1024
    openssl gendsa -des3 -out private/ca.key dsaparam.pem
  2. Generar una petición de certificado para la propia CA
    openssl req -new -key private/ca.key -out ca.csr
  3. Generar el certificado de la CA firmado por la propia CA
    openssl x509 -signkey private/ca.key -req -days 3650 -in ca.csr -out public/ca.crt

Creación de un certificado de servidor:

  1. Crear un almacén de claves con la clave privada del servidor (en CN especificar el dominio del servidor, ej. dominio.com y el resto dejarlo en blanco)
    keytool -genkey -alias server -keystore private/server.ks -keyalg DSA -sigalg SHA1withDSA
  2. Generar una petición de certificado
    keytool -certreq -alias server -keystore private/server.ks -file server.csr
  3. Generar un certificado firmado por la CA (si existe previamente el fichero “serial.txt” eliminar -CAcreateserial)
    openssl x509 -req -days 360 -in server.csr -CA public/ca.crt -CAkey private/ca.key -CAcreateserial -CAserial serial.txt -out public/server.crt
  4. Importar el certificado del CA en el almacén de claves del servidor
    keytool -import -alias CA -file public/ca.crt -keystore private/server.ks
  5. Importar el certificado del servidor en el almacén de claves
    keytool -import -alias server -file public/server.crt -keystore private/server.ks

Creación de un certificado de cliente (con estructura de DNI electrónico):

  1. Generar la clave privada del cliente
    openssl dsaparam -out dsaparam.pem 1024
    openssl gendsa -des3 -out private/client.key dsaparam.pem
  2. Crear un fichero “dnie.cnf” con el siguiente contenido

    [ req ]
    distinguished_name = req_distinguished_name

    [ req_distinguished_name ]
    countryName = Pais (2 letras)
    countryName_default = ES
    countryName_min = 2
    countryName_max = 2

    commonName = Apellido1 Apellido2, Nombre (AUTENTICACIÓN|FIRMA)
    commonName_max = 64

    givenName = Nombre

    surname = Apellido1

    serialNumber = NNNNNNNNA (número de DNI con letra)
    serialNumber_min = 9
    serialNumber_max = 9

  3. Generar una petición de certificado
    openssl req -config dnie.cnf -new -key private/client.key -out client.csr
  4. Generar un certificado firmado por la CA (si no existe previamente el fichero “serial.txt” añadir -CAcreateserial)
    openssl x509 -req -days 360 -in client.csr -CA public/ca.crt -CAkey private/ca.key -CAserial serial.txt -out public/client.crt
  5. Generar un fichero pkcs12 para importar el certificado en el navegador
    openssl pkcs12 -export -clcerts -in public/client.crt -inkey private/client.key -out private/client.p12 -name your_certificate_client_name

Creación de un truststore (un almacén de claves en el que ir guardar los certificados en los que el servidor “confía”):

  1. Crear un keystore
    keytool -genkey -alias dummy -keyalg DSA -keystore private/truststore.ks
  2. Borrar el alias summy para dejar un keystore “limpio”
    keytool -delete -alias dummy -keystore private/truststore.ks
  3. Importar el certificado del CA (de tal modo que cualquier certificado de cliente firmado por la CA sea válido)
    keytool -import -alias CA -file public/ca.crt -keystore private/truststore.ks

Nota: Para poder consultar los certificados existentes en un keystore podemos utilizar el siguiente comando
keytool -v -list -keystore private/server.ks


En Ubuntu 9.10, utilizando Eclipse 3.5.1, al pulsar con el ratón en un botón no ocurre nada (solamente se selecciona el botón, pero no realiza la acción asociada).

La solución:

  1. Crea un fichero en blanco con el nombre eclipse.sh
  2. Escribe el siguiente código en el fichero:

    #!/bin/sh
    export GDK_NATIVE_WINDOWS=1
    /home/[your eclipse directory]/eclipse $@
  3. Dale permisos de ejecución al fichero eclipse.sh con el siguiente comando:
    chmod 777 eclipse.sh
  4. Ejecuta Eclipse:
    ./eclipse.sh [press enter]


vía

SSL Logo

  • CA (Certification Authority): Firma la clave pública de una persona para que otros puedan verificar que realmente dicha clave pública pertenece a la persona.
  • Certificate: La clave pública de un individuo firmada por una CA. (realmente se trata de un mensaje firmado por la CA que contiene el DN -Distinguised Name- y la clave pública del individuo)
  • PKI (Public Key Infrastructure): Private keys + Public keys + CA + Certificates
  • Keystore: Almacén de claves que contiene las siguientes entradas (generalmente asociadas a un alias)
    • Propia Private key
    • Propio Certificate (Public key firmada por una CA -para dársela a terceros-)
    • Certificates de terceros (Public keys de terceros firmados por una CA)
    • Certificate de la CA (Public Key del CA -firmado por la propia CA-)

Engranajes

  • Part: Parámetro.
  • Port type: Agrupación de operaciones. Similar a lo que sería una clase Java con métodos estáticos.
  • Binding: Asociación entre un “Port type” con un formato de mensaje (como SOAP) y un transporte (como HTTP).
Seguir

Get every new post delivered to your Inbox.