Con la última versión de Winamp, no es necesario tener iTunes para usar iPod! Además, se pueden cargar y bajar archivos desde cualquier computadora, y usar como biblioteca una mezcla de todos los archivos que pongamos de cualquier lado. Y, además, Winamp no pesa nada, mientras que iTunes es un verdadero elefante que aplasta nuestro procesador y nuestra memoria.

Winamp :)

En este tutorial está lo básico para ejecutar ANT desde eclipse; hay que hacer un archivo build.xml en donde uno quiera (el root del proyecto), poner una acción a realizar por default (se ejecutará esta y todas sus dependendicas… la acción que no esté linkeada no se ejecutará). Este es el código de ejemplo:

build.xml

<project name=”AntExample” default=”jar” basedir=”.”>

<!– El default es la operación por default, y la única
que se ejecuta si no le pasan parámetros –>

<!– Define propiedades (variables) –>

<property name=”src” value=”.”/>

<property name=”build” value=”bin”/>

<property name=”deploy” value=”deploy”/>

<!– Hace un directorio –>
<target name=”init”>
<mkdir dir=”${build}”/>
<mkdir dir=”${deploy}”/>
</target>

<!– Compila el código java a ese directorio
(¿por qué el depends? porque hay que hacer
el otro primero) –>
<target name=”compile” depends=”init”>
<!– Compile the java code –>
<javac srcdir=”${src}” destdir=”${build}”/>
</target>
<!– Peeeeero no lo exporta en un .jar, hasta acá –>
<target name=”jar” depends=”compile”
description=”create a Jar file for the application”>
<jar destfile=”${deploy}/hello.jar”>
<fileset dir=”${build}” includes=”**/*.class”/>
<manifest>
<attribute name=”Main-Class” value=”HelloProgram”/>
</manifest>
</jar>
</target>
</project>

Ant tiene bastantes mas funciones, de hecho, cuando tenemos un proyecto con dependencias, que necesite jars para funcionar u otro proyecto con el cual esté conectado, deberemos incluír esto:

<!– Used to include all the libs in a directory –>

<patternset id=”java.libs” includes=”**/*.jar,**/*.zip” />

<!– The libs compiled in the deploy folder at the time the method is called –>

<path id=”compiledLibs” >
<fileset dir=”${deploy}/${libraries}” >
<patternset refid=”java.libs” />
</fileset>
<fileset dir=”${deploy}/”>
<patternset refid=”java.libs” />
</fileset>
</path>

Y cuando compilamos, lo añadimos de esta forma:

<javac classpathref=”compiledLibs” mce_href=”compiledLibs” destdir=”${build}/banelco”>
<src path=”${banelcoGeneralHome}/src/test/java”/>
<src path=”${banelcoGeneralHome}/src/main/java”/>
</javac>

Problemas comunes: cuando tenemos proyectos con dependencias, una solución simple es hacer una carpeta deploy, meter ahí todas las librerías,
compilar allí el proyecto que no tiene dependencias de proyecto como un .jar, y después compilar
el proyecto que si tiene dependencias, que dependa de todos los .jar de ese directorio (entonces,
como el otro proyecto ya está compilado como un .jar, también tendrá sus clases )

Viendo que hay muy poca info sobre Spring en castellano (y menos sobre temas específicos), me dedicaré a escribir sobre ello.

Si uno no quiere modificar directamente los archivos XML, ya que para operadores esto quizás no sea lo mejor, y prefiere cambiar las propiedades principalse en un archivo .properties, esta es la forma de incluír esos .properties en Spring y llamar a los valores de sus variables:

gateway.properties

ioacceptor.port = 1235

applicationContext.xml

<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN” “http://www.springframework.org/dtd/spring-beans.dtd”>
<beans>

<!– Property Place Holder Configuration –>
<bean class=”org.springframework.beans.factory.config.PropertyPlaceholderConfigurer”>
<property name=”locations”>
<value>classpath:com/banelco/gateway/context/gateway.properties</value>
</property>
</bean>

…

<bean class=”org.apache.mina.integration.spring.Binding”>
<property name=”address” value=”:${ioacceptor.port}“/>
<property name=”handler” ref=”iso8583Handler”/>
<property name=”serviceConfig”>
<bean class=”org.apache.mina.transport.socket.nio.SocketAcceptorConfig”>
<property name=”filterChainBuilder” ref=”filterChainBuilder”/>
<property name=”reuseAddress” value=”true”/>
</bean>
</property>
</bean>
</list>
</property>
</bean>
</beans>

Importante: si se desea utilizar mas de un PropertyPlaceHolder en el contexto, se le debe añadir la propiedad <property name=”ignoreUnresolvablePlaceholders” value=”true” />, para que los holders que no pueda resolver uno no tire excepción y pueda resolverlos el otro.

Idea: se pueden extenders las clases de PlaceHolder e implementar de nuevo sus métodos, por ejemplo, el getLocation(), para hacer rutas configuradas y que sólo tengan que poner el nombre del archivo :)

Bueno, ahora ya tenemos cómo acceder a los MBeans desde código, pero ¿cómo crearlos desde código?

Lo primero que tenemos que tener en cuenta es que las clases que queremos crear como MBeans, obligatoriamente tienen que estar en el servidor. O sea, tenemos que exportarlo como un .jar y ponerlo en la carpeta lib del servidor (así me funcionó a mi, si tenemos una aplicación web será un .war y en deploy, aunque no lo probé)

Ya tenemos eso, ahora creamos un MBean cualquiera:

Interfaz TesterMBean

package org.acriter.testJBoss;public interface TesterMBean {public String getNombre();public void setNombre(String nombre);public void init();

Clase Tester

package org.acriter.testJBoss;public class Tester implements TesterMBean{public void init() {// TODO Auto-generated method stub}
private String nombre;
public String getNombre() {
return nombre;
}

public void setNombre(String nombre) {
this.nombre=nombre;
}
}


JMXProBrowser


package org.acriter.testJBoss;import javax.management.MBeanInfo;import javax.management.MBeanOperationInfo;import javax.management.MBeanParameterInfo;import javax.management.ObjectName;

System.out.println("JNDIView.list(true) output:n"+result);
}
}


Bueno, ahora veremos cómo obtener info de un MBean existente en el servidor mediante código. La conexión del servidor es lo que se me complicó mucho, todavía no me explico demasiado cómo funciona. Éste es el código:

org.acriter.testJBoss.JMXBrowser:


package org.acriter.testJBoss;import javax.management.MBeanInfo;
import javax.management.MBeanOperationInfo;
import javax.management.MBeanParameterInfo;
import javax.management.ObjectName;
import javax.naming.InitialContext;import org.jboss.jmx.adaptor.rmi.RMIAdaptor;

Hace poco me encomendaron la desconocida tarea de registrar desde una aplicación stand alone con Spring un MBean en un servidor JBoss. Me costó mucho al principio enteder, lo primero que logré fue declarar un servicio en JBoss desde un archivo .SAR. No me acuerdo mucho del asunto, es algo así:

http://forum.springframework.org/showthread.php?t=11479

Se define una carpeta META-INF en un Proyecto Java, y adentro se le pone un jboss-service.xml, se lo exporta como .jar, y le cambiás la extensión a .SAR, y JBoss te lo toma como servicio.

Acá está el ejemplo:

META-INF/jboss-service.xml:

<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="com.acme.HelloWorldService" name="acme.com:service=HelloWorld">
<attribute name="Message">Hello World</attribute>
</mbean>
</server>com.acme.HelloWorldServiceMBean


com.acme.HelloWorldService

package com.acme; import org.jboss.system.ServiceMBeanSupport;public class HelloWorldService extends ServiceMBeanSupport implements HelloWorldServiceMBean
{
// Our message attribute
private String message = "Sorry no message today";// Getters and Setters
public String getMessage()
{
return message;
}
public void setMessage(String message)
{
this.message = message;
}// The printMessage operation
public void printMessage()
{
log.info(message);
}// The lifecycle
protected void startService() throws Exception
{
log.info("Starting with message=" + message);
}
protected void stopService() throws Exception
{
log.info("Stopping with message=" + message);
}
}

com.acme.HelloWorldServiceMBean:

package com.acme;import org.jboss.system.ServiceMBean;public interface HelloWorldServiceMBean extends ServiceMBean
{
// Configure getters and setters for the message attribute
String getMessage();
void setMessage(String message);// The print message operation
void printMessage();
}Si esto les funciona, ya están listos para la siguiente y terrorífica etapa... obtener la info de un MBean del servidor!  

Un archivo SAR es un archivo de servicio de JBoss. Si quieren probar cómo se muestra un MBean en la consola de JBoss, es decir, instanciar un nuevo servicio, deben:

Crear un nuevo proyecto web dinámico en Eclipse

Hacer este tutorial.

Crear una carpeta META-INF y ahí poner el archivo jboss-services.xml

Exportar el archivo como .JAR

Cambiarle la extensión a .SAR, y pegarlo en la carpeta deploy, del servidor default (o e que usen) de JBoss x)

En definitiva, la diferencia entre un JAR y un SAR es el nombre, y que este último tiene en META-INF la descripción del servicio.

Hace mucho que no programaba en Flash, y me dieron ganas de hacer un juego de rol. Me di cuenta de lo mucho que había cambiado este lenguaje. AS3 es mucho mas robusto e inflexible que sus entregas anteriores, y tienen muchas diferencias.

Las mas importantes:

Totalmente orientado a objetos

Las clases son privadas por defecto! Por eso puede no encontrarlas generalmente.
Existen los paquetes (son la ruta de carpetas en donde estan guardadas).
No existe _root.

Los movieClip no tienen mas enterFrame, onClick, etc. Ahora son todos eventos.

No hay mas attachMovie: http://www.codigo.as/blog/?p=76

Hola! Bienvenidos a este blog, en donde, paradójicamente, no pondré estúpidos artículos comparando las características de Java y las de C#, sino que pondré artículos de cosas que estoy descubriendo yo y que podrían llegar a serle útil a alguien (y a mi para acordarme)