Archivos para la categoría: java

El tema de las anotaciones son más que conocidas en el mundo java y hoy en día casi todo lo configuramos con anotaciones, aquellos tiempos en los que se hacía todo en interminables ficheros xml que nadie era capaz de seguir se acabaron (gracias a dios).

Pero cuantas veces, sobre todo para los que usamos Spring Framework, hemos visto aquello de @EnableSomething y luego hacer uso de @Something? no os habéis preguntado nunca como funciona?

Todo esto surge, porque hace poco me surgió una necesidad en la que encajaba completamente una custom annotation para reutilizar el código. El caso en cuestión era suscribirse a eventos en kafka y me resultaba tedioso el tener que configurar kafka en cada módulo donde quisiera escuchar un evento y más aún los if que surgían… pongamos un ejemplo:

@KafkaListener(topics = "mitopic)
public void listener(String payload){
Event event = Event.from(payload);
if (event.name == "READ") {
// do something
} else if (event.name == "WRITE" {
// do something
} else if (event.name == "DELETE" {
// do something
}
}

Esta solución al menos a mi, me hace sangrar los ojos.. y es que no me llevo bien con los ifs y menos aún, con los concatenados.

Podríamos pensar en crear tres métodos distintos, uno para cada evento. Pero ni con esas vamos a conseguir quitarnos los ifs. Sin embargo, resultaría super sencillo contar con algo así:

@MyCustomAnnotation({Event.READ, Event.WRITE, Event.DELETE})
public void onEvent(String payload){
// do something
}

Incluso si quisiésemos separarlo, hasta quedaría bien:

@MyCustomAnnotation({Event.READ})
public void onRead(String payload){
// do something
}
@MyCustomAnnotation({Event.WRITE})
public void onWrite(String payload){
// do something
} 
@MyCustomAnnotation({Event.DELETE})
public void onDelete(String payload){
// do something
} 

¿A que queda mejor? ¿pero como hacerlo? Lo veremos en la segunda parte…

Anuncios

Aaay! Los IDEs. Cuánto bien y cuánto mal hacen en nuestras vidas. Qué haríamos sin la indentación automática del código o sin los imports automáticos. Y qué bonico cuando tenemos unos cuantos imports del mismo paquete, y se nos agrupan todos en un import con wilcards, ¿no? Leer el resto de esta entrada »

Muchos tendremos repositorios maven añadidos de la siguiente forma, en nuestros ficheros pom.xml o settings.xml:

<repository>
   <id>apache.snapshots</id>
   <name>JBoss Maven2 repository</name>
   <url>http://repository.jboss.com/maven2/</url>
   <releases>
      <enabled>false</enabled>
      <updatePolicy>always</updatePolicy>
      </releases>
   <snapshots>
      <enabled>true</enabled>
      <updatePolicy>always</updatePolicy>
   </snapshots>
</repository>

El atributo updatePolicy hace referencia a la frecuencia con la que descargaremos las actualizaciones de ese repositorio. Si trabajamos con snapshots que sabemos que tienen mucho movimiento, sí que tiene sentido usar una política always. Sin embargo, si trabajamos con versiones estables que no van a verse modificadas, esto no tiene ningún sentido y lo único que hace es comerse ancho de banda y retrasar las construcciones. Y si internet te va un poco lento ese día, tómate varios cafés.

Así que si éste es nuestro caso, mejor cambiar el valor de updatePolicy a daily (es el valor por defecto) para que sólo haga esta comprobación una vez al día. Podríamos ser más restrictivos aún y establecerlo a never, de forma que sólo realizaría las comprobaciones si la información no existe a nivel local.

Fuente: Maven Reference.

Ahora que codehaus ha cerrado y ya no sirve repositorios de maven, tenemos que modificar nuestra configuración de maven para apuntar a algún otro repositorio y que no casquen.

Por ejemplo, el de mulesoft cubre todas nuestras necesidades. Editaremos nuestro fichero ~/.m2/settings.xml para incluir este repositorio:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">

   <!-- CONFIGURACIÓN EXTRA QUE PUEDA TENER -->

   <profiles>
      <profile>
         <id>myProfile</id>
         <repositories>

            <!-- TODOS MIS REPOSITORIOS -->

            <repository>
               <id>codehaus-mule-repo</id>
               <name>codehaus-mule-repo</name>
               <url>https://repository-master.mulesoft.org/nexus/content/groups/public</url>
               <layout>default</layout>
            </repository>
         </repositories>
      </profile>
   </profiles>

	<activeProfiles>
		<activeProfile>myProfile</activeProfile>
	</activeProfiles>
</settings>

Fuente: codehaus.

Uno de los servicios que ofrece Google en su plataforma app engine, es el acceso de usuarios a través de las sus cuentas de Google. Es la interfaz UserService la encargada de proporcionarnos esta información de usuario, así como de autenticarlo contra Google.
Leer el resto de esta entrada »

A %d blogueros les gusta esto: