Al crear un formulario de correo, quería probar el envío así que instalé sendmail

sudo apt-get install sendmail

noté que al enviar el correo tardaba mucho, así que agregué la siguiente línea a mi archivo /etc/hosts

127.0.0.1 localhost.localdomain localhost silversurfer

para enviar un correo de prueba desde la terminal puedes ejecutar el siguiente comando

echo “test mail from my localhost” | /usr/sbin/sendmail -f someone@mail.com admin@mydomain.com

notesé que para poder enviar el correo a un dominio externo, necesitamos agregar la opción ‘-f’ la cual agrega al encabezado la dirección de origen (from)

en php tendrás que agregar también esta opción de la siguiente manera

mail(‘admin@mydomain.com’,’subject’, ‘message’, null, ‘-fsomeone@mail.com’ )

Fuentes:
http://stackoverflow.com/questions/7578952/sending-mail-takes-long-time-in-localhost
http://serverfault.com/questions/173762/php-mail-function-painfully-slow-on-local-development-machine/221894#221894

Anuncios

Para configurar un servidor de git local podemos seguir la guía oficial.
La guía nos muestra los pasos necesarios para acceder a un repositorio de git mediante ssh, que es la forma más común para acceder (leer y escribir) a un repositorio. Esto debido a la seguridad y eficiencia que ofrece el protocolo ssh. Puedes leer sobre los distintos protocolos (local, http[s], git, ssh) disponibles en git aquí.

Bueno, lo primero que necesitamos es tener un servidor de ssh

sudo apt-get install openssh-server

Luego tenemos que crear al usuario ‘git’. Yo especifiqué el directorio del usuario para que no me creara el directorio /home/git

sudo adduser --home /home/cirovladimir/Apps/git

nos va a pedir una contraseña y algunos datos, podemos dejar vacíos los demás campos.

Luego nos logeamos como el usuario git y creamos el directorio ‘.ssh/’

sudo su git
cd
mkdir .ssh

a continuación vamos a generar las llaves para nuestros usuarios

ssh keygen -t rsa -C 'usuario_1@gmail.com' -f usuario_1_rsa
ssh keygen -t rsa -C 'usuario_2@gmail.com' -f usuario_2_rsa

nos va a generar un par de llaves para cada usuario, una pública (extensión .pub) y una privada

Hay que agregar las llaves públicas al archivo .ssh/authorized_keys

cat usuario_1_rsa.pub >> .ssh/authorized_keys
cat usuario_2_rsa.pub >> .ssh/authorized_keys

Ahora vamos a iniciar un repositorio para nuestro proyecto

mkdir -p repos/proyecto.git
cd repos/proyecto.git
git --bare init

cerramos la sesión del usuario git

exit

si ya tenemos un repositorio local que queremos sincronizar con el servidor que acabamos de configurar, hacemos lo siguiente

cd miproyecto
git remote add origin git@localhost:repos/proyecto.git
git push origin master

en este caso el servidor es local, si lo configuras en otra máquina puedes sustituir localhost por el nombre de la máquina o su ip.

Si al ejecutar el ‘push’ te arroja un error parecido al siguiente

Error: Agent admitted failure to sign

lo puedes resolver con el comando

ssh-add /ruta/usuario1

y te va a pedir el passphrase que utilizaste cuando generaste la llave.

Fuentes:
http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server
http://git-scm.com/book/ch4-1.html
https://help.github.com/articles/generating-ssh-keys
https://help.github.com/articles/error-agent-admitted-failure-to-sign

JDeveloper 11g – Changing default JVM

Cuando instalas JDeveloper 11g, este incluye el JDK (necesario para ejecutar la aplicación). El problema es que incluye una versión de 32bits. Si tu sistema operativo es a 64 bits -Ubuntu 12.04 por ejemplo- probablemente te aparezca un error como el siguiente

libX11.so.6: cannot open shared object file: No such file or directory

Para resolverlo hay que instalar un JDK a 64 bits y configurarlo en el archivo jdeveloper/jdev/jdev.conf

SetJavaHome /usr/lib/jvm/java-6-openjdk-amd64/

Ya que en mi caso utilizo OpenJDK.

via OTN Discussion Forums : Changing default JVM in Jdeveloper 11 ….

JAXB – Mapping interfaces

octubre 19, 2012

Unofficial JAXB Guide – Mapping interfaces — Java.net.

http://www.attivio.com/blog/56-java-development/636-configuring-java-interfaces-to-work-with-jaxb-and-web-services.html

En una aplicación con múltiples módulos, es probable que diferentes módulos accedan a distintas bases de datos o esquemas y con distintas credenciales.

Para configurar multiples conexiones en Datanucleus hay que crear un archivo jdoconfig.xml en la carpeta META-INF del classpath (WEB-INF/classes/META-INF en una aplicación web). Si utilizas Maven crea el archivo en la carpeta src/main/resources/META-INF y Maven copiara el archivo y la carpeta al classpath.


<?xml version="1.0" encoding="UTF-8"?>

<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig">

<persistence-manager-factory name="compras">

<property name="javax.jdo.PersistenceManagerFactoryClass"

value="org.datanucleus.api.jdo.JDOPersistenceManagerFactory"/>

<property name="javax.jdo.option.ConnectionDriverName" value="oracle.jdbc.OracleDriver"/>

<property name="javax.jdo.option.ConnectionURL" value="jdbc:oracle:thin:@132.147.0.1:1521:dbcompras"/>

<property name="javax.jdo.option.ConnectionUserName" value="usrcompras"/>

<property name="javax.jdo.option.ConnectionPassword" value="secret"/>

<property name="javax.jdo.option.DetachAllOnCommit" value="true"/>

</persistence-manager-factory>

<persistence-manager-factory name="recursoshumanos">

<property name="javax.jdo.PersistenceManagerFactoryClass"

value="org.datanucleus.api.jdo.JDOPersistenceManagerFactory"/>

<property name="javax.jdo.option.ConnectionDriverName" value="oracle.jdbc.OracleDriver"/>

<property name="javax.jdo.option.ConnectionURL" value="jdbc:oracle:thin:@192.168.0.250:1521:dbrh"/>

<property name="javax.jdo.option.ConnectionUserName" value="usrrh"/>

<property name="javax.jdo.option.ConnectionPassword" value="topsecret"/>

<property name="javax.jdo.option.DetachAllOnCommit" value="true"/>

</persistence-manager-factory>

</jdoconfig>

Para obtener una instancia PersistenceManagerFactory podríamos tener una clase PMF en cada módulo (suponiendo que son proyectos distintos) como la siguiente. Cambiando solamente el nombre de acuerdo al PersistenceManagerFactory que vamos a utilizar. También podrías recibir como parámetro el nombre del PersistenceManagerFactory y almacenarlo en un Map para usos posteriores, esto si los módulos se encuentran en el mismo proyecto.


public class PMF {

private static final PersistenceManagerFactory instance=JDOHelper.getPersistenceManagerFactory("compras");

private PMF() {

}

public static PersistenceManagerFactory get(){

return instance;

}

}

Y lo usarías de la siguiente forma


public static List<Compra> getCompras(){

List<Compra> compras;

PersistenceManager pm = PMF.get().getPersistenceManager();

Transaction tx = pm.currentTransaction();

try{

tx.begin();

Query query = pm.newQuery(Compra.class);

jueces=(List<Compra>) query.execute();

tx.commit();

}finally{

if(tx.isActive()){

tx.rollback();

}

pm.close();

}

return compras;

}

Fuentes:

http://www.datanucleus.org/products/datanucleus/jdo/pmf_named.html
http://stackoverflow.com/questions/1297473/maven-including-a-meta-inf-folder-in-the-classes-folder

Hay algunas dependencias que no podrás encontrar en repositorios públicos por alguna razón, como las librerías OJDBC de Oracle. Seguro que puedes instalarlas en tu máquina, pero -en una organización- no quisieras hacer esto en la computadora de cada desarrollador por cada librería que necesiten. Bueno, entonces lo que necesitas es tener tu propio repositorio donde puedas poner todas las librerías comunes que utilicen en tu empresa (las que desarrollen y las de terceros). Por suerte, existe Nexus.
Para instalarlo simplemente descargalo, descomprimelo y ejecutalo.

mkdir nexus
cd nexus
wget http://nexus.sonatype.org/downloads/nexus-oss-webapp-1.9.2.3-bundle.tar.gz
tar -xvzf nexus-oss-webapp-1.9.2.3-bundle.tar.gz
./nexus-oss-webapp-1.9.2.3/bin/jsw/linux-x86-32/nexus start

Asegurate que la última línea corresponda a tu arquitectura, busca el ejecutable que corresponda en el directorio ./nexus-oss-webapp-1.9.2.3/bin/jsw/

Después de ejecutar el último comando debes ver algo como

2011-09-21 15:37:21 INFO [er_start_runner] - org.mortbay.log - Started SelectChannelConnector@0.0.0.0:8081

Abre un navegador y ve a http://localhost:8081/nexus. Debes poder ver la consola de administración. Listo, ya tienes tu propio repositorio instalado.

Ingresa con el usuario “admin” y contraseña “admin123” para ver las opciones administrativas (cambia la contraseña de paso). Te conviene activar la opción “Download Remote Indexes” en la configuración de los repositorios, al menos para Maven Central. Con esto las búsquedas serán más rápidas.
Para ver el Log da clic en la opción “System Files” y selecciona el documento “nexus.log”.

Para que este repositorio sea utilizado dentro de la organización, en la PC de cada desarrollador edita el archivo ${user.home}/.m2/settings.xml y pon el contenido

<?xml version="1.0"?>
<settings>
	<mirrors>
		<mirror>
			<id>nexus.acme.com</id>
			<name>Acme</name>
			<url>http://nexus.acme.com:8081/nexus/content/groups/public/</url>
			<mirrorOf>*</mirrorOf>
		</mirror>
	</mirrors>
</settings>

Por supuesto nexus.acme.com puede ser sustituído por la IP del servidor, p. ej. 192.168.0.250
Ten en cuenta que al poner <mirrorOf>*</mirrorOf> tu repositorio sera utilizado para cualquier dependencia, incluso las de proyectos que tengan configurado otro repositorio en el archivo pom.xml, por lo que si no tienes configurados esos repositorios en Nexus, las dependencias no serán encontradas. Podrías especificar sólo ciertos repositorios de la siguiente forma: <mirrorOf>central,google,apache-snapshots</mirrorOf>
Finalmente, para utilizar el repositorio en tus proyectos, agrega las siguientes líneas al archivo pom.xml

  <repositories>
    <repository>
      <id>nexus.acme.com</id>
      <url>http://nexus.acme.com:8081/nexus/content/groups/public/</url>
    </repository>
  </repositories>

Fuentes:

http://my.safaribooksonline.com/
http://maven.apache.org/guides/mini/guide-mirror-settings.html

JBoss AS7 – Configurar SSL

septiembre 12, 2011

Despues de instalar JBoss AS7

ejecuta el comando

keytool -genkey -alias tomcat -keyalg RSA

ingresa los datos que se te piden y recuerda muy bien la contraseña, la vamos a necesitar en el siguiente paso.
Abre el archivo jbossas_home/standalone/configuration/standalone.xml y busca la línea donde dice

<connector name=”http” protocol=”HTTP/1.1″ socket-binding=”http” scheme=”http”/>

e inmediatamente debajo pon

<connector name=”https” protocol=”HTTP/1.1″ socket-binding=”https” scheme=”https” enabled=”true”>
<ssl name=”https” password=”s3cr3t”/>
</connector>

Listo, ya puedes acceder a tus aplicaciones instaladas en JBoss AS mediante SSL. Para probarlo ingresa en tu navegador https://localhost:8443. Si ya tienes instalada una aplicación, p. ej. jbossas_home/standalone/deployments/rest-easy-sample.war, ingresa https://localhost:8443/rest-easy-sample
La primera vez te va a mostrar una advertencia debido a que nosotros mismos emitimos el certificado, acepta la excepción de seguridad para poder acceder.

Fuentes:
http://community.jboss.org/message/625211?tstart=0
https://docs.jboss.org/author/display/AS7/HTTPS+Connectors