Scumm Bar

[Java] Find free port

noreply@blogger.com (Stefano Ghio) — Fri, 10 Feb 2012 14:18:00 +0000

Getting the number of an unused port on the system via Java 7 is as easy as:

import java.net.ServerSocket;

public static int findFreePort(){
int port = 0;
try(ServerSocket server = new ServerSocket(0);){
port = server.getLocalPort();
}catch(Exception e){
System.err.println("unable to find a free port");
return null;
}
return port;
}

We do not need to call a server.close() since Java 7 does that automatically for us as we used the new try-catch block with resources declaration

[Java] Access MySQL with Hibernate

noreply@blogger.com (Stefano Ghio) — Fri, 03 Feb 2012 19:19:00 +0000

In this post we will give a fair example on how to access a MySQL database via Hibernate in Java.
For this example we will be using MySQL server 5.5, Hibernate 3.3 and the Eclipse IDE.

Download here the example's source code.

Suppose we have access to a database,test, with a table, testtable:

Column name	Column type	Constraints	Description
id	int	AUTO_INCREMENT PRIMARY KEY	The object's ID
column1	varchar(20)	UNIQUE	A unique String for this object
column2	int	NOT NULL	A mandatory numeric field for this object

Created with the following SQL code:

create table testtable(id int AUTO_INCREMENT, column1 varchar(20) unique, column2 int not null, primary key(id));

And a Java class, PersistentObject, defining an object to be made persistent in said table:

package it.eng.test.hibernate.persistentobject;
import java.io.Serializable;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.NamedQueries;
import javax.persistence.NamedQuery;
import javax.persistence.Table;
import javax.persistence.Transient;

@Entity
@Table(name = "testtable")
@NamedQueries(value = {
  @NamedQuery(name = "getItem", query = "select i from PersistentObject i where i.column1 = ?"),
  @NamedQuery(name = "getItems", query = "select i from PersistentObject i"),
  @NamedQuery(name = "deleteItem", query = "delete from PersistentObject i where i.column2 = ?")
  })
public class PersistentObject implements Serializable{
  private static final long serialVersionUID = -2853745324178701257L;
  /*Required for Hibernate*/
  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  @Column(name = "id")
  private Long id;
  /*Our columns*/
  @Column(name = "column1")
  private String column1;
  @Column(name = "column2")
  private int column2;
  /*This field is part of our PersistentObject but will not be stored on the DB*/
  @Transient
  private Object nonPersistent;

  /*Getters & Setters, every persistent field must have one for Hibernate*/
  public Long getID(){
   return id;
  }

  public String getColumn1() {
   return column1;
  }

  public void setColumn1(String column1) {
   this.column1 = column1;
  }

  public int getColumn2() {
   return column2;
  }

  public void setColumn2(int column2) {
   this.column2 = column2;
  }

  public void setId(Long id) {
   this.id = id;
  }

  public Object getNonPersistent() {
   return nonPersistent;
  }

  public void setNonPersistent(Object nonPersistent) {
   this.nonPersistent = nonPersistent;
  }

  /*Required for Hibernate*/
  public PersistentObject(){
  }

  /*Our own constructor*/
  public PersistentObject(String column1, int column2, Object nonPersistent){
   this.column1 = column1;
   this.column2 = column2;
   this.nonPersistent = nonPersistent;
  }
}

By using Java annotations, we are able to easily mark which class fields we want to make persistent and which queries we are going to create for our object:

@Entity
@Table(name = "testtable")
@NamedQueries(value = { @NamedQuery(name = "getItem", query = "select i from PersistentObject i where i.column1 = ?"),
@NamedQuery(name = "getItems", query = "select i from PersistentObject i"),
@NamedQuery(name = "deleteItem", query = "delete from PersistentObject i where i.column2 = ?") })

With this, we are saying that there is a table called testtable in our database on which the queries listed afterwards should operate. We wrote them in HQL, a modified version on SQL by Hibernate.

The first query for example is the equivalent of:

SELECT * FROM testtable WHERE column1 = VALUE;

and by executing it, we are returned the matching PersistentObject object(s).

The PRIMARY KEY is specified as required for Hibernate as an AUTO_INCREMENT integer:

@Id
@GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "id")
private Long id;

Note that our class can also include fields which will not be stored; to define so, we simply mark them as @Transient.

Hibernate also requires us to create an empty constructor and getter and setter methods for each persistent field.

Now we need to create two more classes in order for Hibernate to function properly:

package it.eng.test.hibernate;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
public class HibernateServiceUtil {
private static EntityManagerFactory emf;

    private static EntityManager em;

    /*The name of our PERSISTENCE_UNIT, as specified in the META-INF/persistence.xml file*/
private static final String PERSISTENCE_UNIT = "TEST";

/*Initialize our DB connection*/
public static EntityManager initEntityManager() {
        if (emf == null) {
        /*
        * If we want to set those properties via code rather than write them in the XML file:
        *
         Map addedOrOverridenProperties = new HashMap();
        addedOrOverridenProperties.put("hibernate.connection.password", PWD);
        addedOrOverridenProperties.put("hibernate.connection.url", URL);
        addedOrOverridenProperties.put("hibernate.connection.username", USERNAME);
        emf = Persistence.createEntityManagerFactory(PERSISTENCE_UNIT, addedOrOverridenProperties);
        */
        emf = Persistence.createEntityManagerFactory(PERSISTENCE_UNIT);
            em = emf.createEntityManager();
        }
        return em;
    }

    public void cleanup() {
        em.clear();
    emf.close();
    }

}

With this, we define a way to initialize Hibernate's Entity Manager for our persistence units. We are also required to create an XML file called persistence.xml and put it under the META-INF/ folder of our project:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="TEST" transaction-type="RESOURCE_LOCAL">
  <class>it.eng.test.hibernate.persistentobject.PersistentObject</class>
  <properties>
   <property name="hibernate.archive.autodetection" value="class, hbm" />
   <property name="hibernate.show_sql" value="true" />
   <property name="hibernate.connection.driver_class" value="com.mysql.jdbc.Driver" />
   
   <property name="hibernate.connection.password" value="12345" />
   <property name="hibernate.connection.url" value="jdbc:mysql://127.0.0.1/test" />
   <property name="hibernate.connection.username" value="root" />
   
   <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect" />
   <property name="hibernate.c3p0.min_size" value="5" />
   <property name="hibernate.c3p0.max_size" value="20" />
   <property name="hibernate.c3p0.timeout" value="300" />
   <property name="hibernate.c3p0.max_statements" value="50" />
   <property name="hibernate.c3p0.idle_test_period" value="3000" />
  </properties>
</persistence-unit>
</persistence>

Where we define, among other things, the connection parameters for the database containing the table for our PersistentObject objects:

<property name="hibernate.connection.password" value="PWD" />
<property name="hibernate.connection.url" value="jdbc:mysql://URL/test" />
<property name="hibernate.connection.username" value="USERNAME" />

Alternatively, we could set those parameters at runtime by using the following code inside the HibernateServiceUtil class:

Map addedOrOverridenProperties = new HashMap();
addedOrOverridenProperties.put("hibernate.connection.password", PWD);
addedOrOverridenProperties.put("hibernate.connection.url", URL);
addedOrOverridenProperties.put("hibernate.connection.username", USERNAME);
emf = Persistence.createEntityManagerFactory(PERSISTENCE_UNIT, addedOrOverridenProperties);

We also need a PersistentObjectHibernateUtil class where to code our queries in Java to perform at least the basic CRUD operations:

package it.eng.test.hibernate.persistentobject;
import java.util.List;
import it.eng.test.hibernate.HibernateServiceUtil;

import javax.persistence.EntityManager;
import javax.persistence.Query;

public class PersistentObjectHibernateUtil {
private static EntityManager entityManager;

 public static void initPersistentObjectHibernateUtil() {
  entityManager = HibernateServiceUtil.initEntityManager();
 }

 /*Create and store our object on the DB*/
 public static PersistentObject savePersistentObject(String column1, int column2, Object nonPersistent) {
  entityManager.getTransaction().begin();
  PersistentObject p = new PersistentObject();
  p.setColumn1(column1);
  p.setColumn2(column2);
  p.setNonPersistent(nonPersistent);
  entityManager.persist(p);
  entityManager.getTransaction().commit();
  return p;
 }

 /*Store an already existing object on the DB*/
 public static void savePersistentObject(PersistentObject p) {
  entityManager.getTransaction().begin();
  entityManager.persist(p);
  entityManager.getTransaction().commit();
 }

 /*Implementation of our NamedQueries*/

 public static PersistentObject getItem(String column1){
  try{
   Query query = entityManager.createNamedQuery("getItem");
   /*place this value where the first ? appeared in the query*/
   query.setParameter(1, column1);
   PersistentObject result = (PersistentObject) query.getSingleResult();
   return result;
  }catch(Exception e){
   System.err.println("unable to get PersistentObject "+column1+" from DB");
   return null;
  }
 }

 @SuppressWarnings("unchecked")
 public static List<PersistentObject> getItems(){
  try{
   Query query = entityManager.createNamedQuery("getItems");
   return query.getResultList();
  }catch(Exception e){
   System.err.println("unable to get PersistentObjects from DB");
   return null;
  }
 }

 public static void deleteItem(int column2){
  try{
   Query query = entityManager.createNamedQuery("deleteItem");
   /*place this value where the first ? appeared in the query*/
   query.setParameter(1, column2);
   query.executeUpdate();
  }catch(Exception e){
   System.err.println("unable to delete PersistentObject "+column2+" from DB "+e.getMessage());
   e.printStackTrace();
  }
 }

 /*We can also overload those methods*/
 public static void deleteItem(PersistentObject p){
  try{
   entityManager.getTransaction().begin();
   Query query = entityManager.createNamedQuery("deleteItem");
   query.setParameter(1, p.getColumn2());
   query.executeUpdate();
   entityManager.getTransaction().commit();
  }catch(Exception e){
   System.err.println("unable to delete PersistentObject "+p.getColumn2()+" from DB "+e.getMessage());
   e.printStackTrace();
  }
 }

 /*Updates an object already stored*/
 public static void updatePersistentObject(PersistentObject p){
  try{
   if (p == null){
    System.err.println("cannot update PersistentObject because it is NULL");
    return;
   }
   entityManager.getTransaction().begin();
   entityManager.merge(p);
   entityManager.getTransaction().commit();
  }catch(Exception e){
   System.err.println("unable to update PersistentObject "+p.getColumn1()+" on DB");
  }
 }

}
As you can see, for every namedQuery previously defined and for basic operations, we define a method which tells Hibernate what to perform for us. For example, for the getItem query previously defined we use:

Query query = entityManager.createNamedQuery("getItem");
query.setParameter(1, VALUE);

to tell Hibernate to replace the first "?" in the query HQL with VALUE before executing it.

Finally, we are required to put an additional XML file, called hibernate.cfg.xml under our project's root:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
  "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
  "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
    <session-factory>
        <property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
        <property name="hibernate.connection.password">12345</property>
        <property name="hibernate.connection.url">jdbc:mysql://127.0.0.1/test</property>
        <property name="hibernate.connection.username">root</property>
        <property name="hibernate.default_schema">test</property>
        <property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>
        
  <property name="connection.pool_size">1</property>
  
  <property name="current_session_context_class">thread</property>
  
  <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>
  
  <property name="show_sql">true</property>
    </session-factory>
</hibernate-configuration>

where we define some Hibernate configuration parameters.

You can then export the project as a Runnable JAR from Eclipse or download here the already packaged and ready-to-go demo.

ECF remote OSGi DS Declarative Services example

noreply@blogger.com (Stefano Ghio) — Wed, 01 Feb 2012 16:39:00 +0000

In this post we will give a fair example of the workings of the OSGi DS Declarative Services remoted with ECF.

For this example we will be using the Eclipse IDE for Java with the ECF Remote Services Target Components  plug-in, the Equinox framework and ZooKeeper as a service discovery provider.

Suppose we have a service: HelloService, its interface: IHello and a client: HelloConsumer who declares a dependency on the service by pointing to its interface using the DS method. He would also like to be able to remotely access it.

When a component declares it provides a service, the OSGi framework stores that information in its internal registry.

Download here the example's source code. You should be able to import everything inside Eclipse as-is. Inside you will find:

Interface - IHello.java:

package it.eng.test.remote.ds.hello;
public interface IHello {
public String greet(String to);
}

Implementation - HelloService.java:

package it.eng.test.remote.ds.helloservice;
import it.eng.test.remote.ds.hello.IHello;
public class HelloService implements IHello{
    public String greet(String to){
        return "Greetings "+to;
    }
}

As we can see, the service offers a single, simple method which returns a String.

Client - HelloConsumer.java:

package it.eng.test.remote.ds.helloconsumer;
import it.eng.test.remote.ds.hello.IHello;
public class HelloConsumer {
    public void bindHello(IHello proxy) {
        System.out.println("Got proxy IHello="+proxy);
        System.out.println(proxy.greet(proxy.toString()));
    }
}

The consumer declares the dependency on the service by requiring its interfaces and has a single method, bindHello, which prints something on standard output as soon as the required remote service becomes available to the consumer.

The framework knows that HelloConsumer needs that particular services since he declared it in his XML configuration which must be put under the OSGI-INF/ folder:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.eng.test.remote.ds.helloconsumer">
<implementation class="it.eng.test.remote.ds.helloconsumer.HelloConsumer"/>
<reference bind="bindHello" cardinality="0..n" interface="it.eng.test.remote.ds.hello.IHello" name="IHello" policy="dynamic"/>
</scr:component>

Here the bundle is saying that the class it.eng.test.remote.ds.helloconsumer.HelloConsumer dynamically and optionally depends on one of the possible it.eng.test.remote.ds.hello.IHello interface implementations and that when one of them becomes available inside the framework, its bindHappy method should be called.

The dynamically policy attribute means that the bundle is able to work properly even when the services are dynamically switched; the alternative would be static, which would require the DS to deactivate the component and create a new instance each time the required service changes.

The dependency is optional since the cardinality was set to 0..N, meaning the component can be started even if that particular dependency is not currently available and it requires the DS to invoke the associated method multiple times, one for each service instance currently available in the registry. 1..1 would mean instead that the dependency is mandatory. Another alternative would be 0..1.

Furthermore, the name of the bind* method can be changed as pleased as long as it reflects the one written in the java code.

On its side, the service must declare its own XML configuration, listing the interface implementations offered, the classes implementing them, and a series of parameters used to make the service remotable.

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.eng.test.remote.ds.helloservice">
   <implementation class="it.eng.test.remote.ds.helloservice.HelloService"/>
   <property name="service.exported.interfaces" type="String" value="*"/>
   <property name="service.exported.configs" type="String" value="ecf.generic.server"/>
   <property name="ecf.exported.containerfactoryargs" type="String" value="ecftcp://192.168.23.28:6666/hello"/>
   <service>
      <provide interface="it.eng.test.remote.ds.hello.IHello"/>
   </service>
</scr:component>

This line indicates that all methods described in the service interface are to be made remotable:

   <property name="service.exported.interfaces" type="String" value="*"/>

This value is linked to the OSGi framework implementation we used (Equinox + ECF) and indicates that the service should be exposed as a Web Service:

   <property name="service.exported.configs" type="String" value="ecf.generic.server"/>

located here:

   <property name="ecf.exported.containerfactoryargs" type="String" value="ecftcp://192.168.23.28:6666/hello"/>

If we do not set the previous property, the service will be published by ZooKeeper as remotable anyway but it will use a random port, the machine hostname instead of its IP and a auto-generated folder name. Currently there is no way to have it use the IP in any case.

As you can see by looking at the source code, nowhere is written where to publish or locate a service (assume we did not set the last of the above properties). However, since magic happens only in movies, there must be some place where to define those properties, else nothing will work.

In our setup, using ZooKeeper allows us to configure the service discovery protocol in multiple ways:

standalone: each framework's ZooKeeper instance must know the exact IP of the others in order to communicate with it. If a new client appears, there is no way to make it join the network without having to reconfigure and restart every instance;

centralized: a central ZooKeeper instance acts as a server with which other instances register. When a new client appears it must know the central ZooKeeper's IP in order to koin the network. All services are shared through the one and only central instance, if it goes down, the entire network crashes;

replicated: a group of servers is configured to communicate, perform leader elections and manage the service discovery routine. The group servers IPs must still be known by every peer, but this allows for more flexibility.

we chose the standalone one which means we configure the Java VM at launch time with the needed information.

Before being able to export our applications from Eclipse or run them within it, we shall follow additional steps to effectively create Eclipse Applications from our code.

Lars Vogel wrote a good tutorial about Eclipse RCP Applications. We can follow it, but keep in mind we are not exactly going to deploy an Eclipse application, instead we will be using those mechanics to successfully export our OSGi bundles along with all necessary dependencies and configuration.

We must thus add a class implementing the IApplication interface in both service and client along an XML configuration file which shall go under the project's root folder.

Service - HelloApp.java:

package it.eng.test.remote.ds.helloservice;
import org.eclipse.equinox.app.IApplication;
import org.eclipse.equinox.app.IApplicationContext;
public class HelloApp implements IApplication {
    boolean done = false;
    Object appLock = new Object();
    public Object start(IApplicationContext context) throws Exception {
        // We just wait...everything is done by DS and HelloComponent
        synchronized (appLock) {
            while (!done) {
                try {
                    appLock.wait();
                } catch (InterruptedException e) {
                    // do nothing
                }
            }
        }
        return IApplication.EXIT_OK;
    }
    public void stop() {
        synchronized (appLock) {
            done = true;
            appLock.notifyAll();
        }
    }
}

with this XML configuration:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.7"?>
<plugin>
   <extension
         id="HelloServiceTest"
         point="org.eclipse.core.runtime.applications"> <application
            cardinality="*"
            thread="any"
            visible="true">
         <run class="it.eng.test.remote.ds.helloservice.HelloApp">
         </run>
      </application>
   </extension>
</plugin>

Client - HelloCApp.java:

package it.eng.test.remote.ds.helloconsumer;
import org.eclipse.equinox.app.IApplication;
import org.eclipse.equinox.app.IApplicationContext;
public class HelloCApp implements IApplication {
    boolean done = false;
    Object appLock = new Object();
    public Object start(IApplicationContext context) throws Exception {
        // We just wait...everything is done by DS and HelloComponent
        synchronized (appLock) {
            while (!done) {
                try {
                    appLock.wait();
                } catch (InterruptedException e) {
                    // do nothing
                }
            }
        }
        return IApplication.EXIT_OK;
    }
    public void stop() {
        synchronized (appLock) {
            done = true;
            appLock.notifyAll();
        }
    }
}

with this XML configuration :

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
   <extension
         id="HelloConsumerTest"
         point="org.eclipse.core.runtime.applications">
      <application
            cardinality="*"
            thread="any"
            visible="true">
         <run class="it.eng.test.remote.ds.helloconsumer.HelloCApp">
         </run>
      </application>
   </extension>
</plugin>

We have hence defined for both service and client two methods: start and stop which, guess what, are called when the application is started or stopped.

In the plugin.xml configuration we say that our applications shall be visible for the user; for example, some applications may provide features to other applications but nothing directly to the user, in this case the application should not be revealed to the user to start it individually. They may run in any thread instead of only the main one and that an unlimited number of instances can be active at the same time.

Now, before successfully launch them, we must configure ZooKeeper to properly do its job. We can do this by changing the application launch parameters to include all necessary dependencies (including org.apache.hadoop.zookeeper and org.eclipse.ecf.provider.zookeeper) and the following Java VM arguments inside the Run configuration:

-Dzoodiscovery.dataDir=bla -Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3030;clientPort=3031

for the service, and:

-Dzoodiscovery.autoStart=true; -Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3031;clientPort=3030

for the client.

With that we are saying that the service's ZooKeeper component should use the bla/ directory to store its temporary files and publish the service in a standalone configuration at the specified IP:PORT using clientPort for incoming connections; the client's ZooKeeper component on its side should instead automatically scan the network for other ZooKeeper instances at startup time connecting to the one at the specified address in order to share services between the two involved frameworks (in our case they are on the same host but cannot be inside the same framework - how would configure ZooKeeper then?).

Eclipse allows us to create from the previously generated Run configurations the Product configurations for our applications and store them in particular XML files called product files, usually stored under the product/ folder. These files also include the OSGi framework's required plug-ins in order for every component to work:

Service - helloservicezookeeper.product

<?xml version="1.0" encoding="UTF-8"?>
<?pde version="3.5"?>
<product application="it.eng.test.remote.ds.helloservice.HelloServiceTest" useFeatures="false" includeLaunchers="true">
   <configIni use="default">
   </configIni>
   <launcherArgs>
      <programArgs>-consoleLog -console</programArgs>
      <vmArgs>-Declipse.ignoreApp=true -Dosgi.noShutdown=true -Dzoodiscovery.dataDir=bla
-Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3030;clientPort=3031</vmArgs>
      <vmArgsMac>-XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts</vmArgsMac>
   </launcherArgs>
   <launcher>
      <solaris/>
      <win useIco="false">
         <bmp/>
      </win>
   </launcher>
   <vm>
   </vm>
   <plugins>
      <plugin id="it.eng.test.remote.ds.hello"/>
      <plugin id="it.eng.test.remote.ds.helloservice"/>
      <plugin id="javax.transaction" fragment="true"/>
      <plugin id="org.apache.hadoop.zookeeper"/>
      <plugin id="org.apache.log4j"/>
      <plugin id="org.eclipse.core.contenttype"/>
      <plugin id="org.eclipse.core.jobs"/>
      <plugin id="org.eclipse.core.runtime"/>
      <plugin id="org.eclipse.core.runtime.compatibility.registry" fragment="true"/>
      <plugin id="org.eclipse.ecf"/>
      <plugin id="org.eclipse.ecf.discovery"/>
      <plugin id="org.eclipse.ecf.identity"/>
      <plugin id="org.eclipse.ecf.osgi.services.distribution"/>
      <plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin"/>
      <plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy"/>
      <plugin id="org.eclipse.ecf.provider"/>
      <plugin id="org.eclipse.ecf.provider.remoteservice"/>
      <plugin id="org.eclipse.ecf.provider.zookeeper"/>
      <plugin id="org.eclipse.ecf.remoteservice"/>
      <plugin id="org.eclipse.ecf.sharedobject"/>
      <plugin id="org.eclipse.ecf.ssl" fragment="true"/>
      <plugin id="org.eclipse.equinox.app"/>
      <plugin id="org.eclipse.equinox.common"/>
      <plugin id="org.eclipse.equinox.concurrent"/>
      <plugin id="org.eclipse.equinox.ds"/>
      <plugin id="org.eclipse.equinox.preferences"/>
      <plugin id="org.eclipse.equinox.registry"/>
      <plugin id="org.eclipse.equinox.util"/>
      <plugin id="org.eclipse.equinox.weaving.hook" fragment="true"/>
<plugin id="org.eclipse.osgi"/>
      <plugin id="org.eclipse.osgi.services"/>
      <plugin id="org.eclipse.osgi.services.remoteserviceadmin"/>
      <plugin id="org.eclipse.persistence.jpa.equinox.weaving" fragment="true"/>
   </plugins>
</product>

Client - helloconsumerzookeeper.product

<?xml version="1.0" encoding="UTF-8"?>
<?pde version="3.5"?>
<product application="it.eng.test.remote.ds.helloconsumer.HelloConsumerTest" useFeatures="false" includeLaunchers="true">
   <configIni use="default">
   </configIni>
   <launcherArgs>
      <programArgs>-consoleLog -console -clean</programArgs>
      <vmArgs>-Declipse.ignoreApp=true -Dosgi.noShutdown=true -Dzoodiscovery.autoStart=true; -Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3031;clientPort=3030</vmArgs>
      <vmArgsMac>-XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts</vmArgsMac>
   </launcherArgs>
   <launcher>
      <solaris/>
      <win useIco="false">
         <bmp/>
      </win>
   </launcher>
   <vm>
   </vm>
   <plugins>
      <plugin id="it.eng.test.remote.ds.hello"/>
      <plugin id="it.eng.test.remote.ds.helloconsumer"/>
      <plugin id="javax.transaction" fragment="true"/>
      <plugin id="org.apache.hadoop.zookeeper"/>
      <plugin id="org.apache.log4j"/>
      <plugin id="org.eclipse.core.contenttype"/>
      <plugin id="org.eclipse.core.jobs"/>
      <plugin id="org.eclipse.core.runtime"/>
      <plugin id="org.eclipse.core.runtime.compatibility.registry" fragment="true"/>
<plugin id="org.eclipse.ecf"/>
      <plugin id="org.eclipse.ecf.discovery"/>
      <plugin id="org.eclipse.ecf.identity"/>
      <plugin id="org.eclipse.ecf.osgi.services.distribution"/>
      <plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin"/>
      <plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy"/>
      <plugin id="org.eclipse.ecf.provider"/>
      <plugin id="org.eclipse.ecf.provider.remoteservice"/>
      <plugin id="org.eclipse.ecf.provider.zookeeper"/>
      <plugin id="org.eclipse.ecf.remoteservice"/>
      <plugin id="org.eclipse.ecf.sharedobject"/>
      <plugin id="org.eclipse.ecf.ssl" fragment="true"/>
      <plugin id="org.eclipse.equinox.app"/>
      <plugin id="org.eclipse.equinox.common"/>
      <plugin id="org.eclipse.equinox.concurrent"/>
      <plugin id="org.eclipse.equinox.ds"/>
      <plugin id="org.eclipse.equinox.preferences"/>
      <plugin id="org.eclipse.equinox.registry"/>
      <plugin id="org.eclipse.equinox.util"/>
      <plugin id="org.eclipse.equinox.weaving.hook" fragment="true"/>
<plugin id="org.eclipse.osgi"/>
      <plugin id="org.eclipse.osgi.services"/>
<plugin id="org.eclipse.osgi.services.remoteserviceadmin"/>
      <plugin id="org.eclipse.persistence.jpa.equinox.weaving" fragment="true"/>
   </plugins>
</product>

After exporting the applications as Eclipse products we are left with two folders with an executable file in them. Do not even bother to try to run it as id will not work, instead open a terminal and browse to the exported_application_folder/plugins folder; here you will find all the required OSGi plug-ins for your application. You can run the service by typing:

java -Dzoodiscovery.dataDir=bla -Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3030;clientPort=3031 -jar org.eclipse.osgi.jar -configuration ../configuration -console

and the client with:

java -Dzoodiscovery.autoStart=true; -Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3031;clientPort=3030 -jar org.eclipse.osgi.jar -configuration ../configuration -console

Now if you start your bundles inside their respective frameworks, you should see, along ZooKeeper's infos, "Got proxy IHello=OSGi_PROXY_NAME" and "Greetings PROXY_NAME". You can download the already exported and ready-to-go service and client applications here.

r-OSGi remote OSGi example

noreply@blogger.com (Stefano Ghio) — Tue, 31 Jan 2012 15:24:00 +0000

In this post we will give a fair example of the workings of the OSGi services remoted through r-OSGi.

In order for the example to work, we must have an OSGi framework with the r-OSGi extension. Also, make sure the 9278 port on your system is free as r-OSGi uses it for its purposes.

Suppose we have a remotable service: HelloService, its interface: IHello and a client who declares a dependency on the service by pointing to its interfaces. It would also like to be able to access it remotely.

When a component declares it provides a service, the OSGi framework stores that information in its internal registry.

Download here the example's source code. You should be able to import everything inside Eclipse as-is. Inside you will find:

Interface - IHello.java:

package it.eng.test.remote.hello;
public interface IHello {
public String sayHello(String from);
}


Implementation - HelloService.java:

package it.eng.test.remote.helloservice;
import it.eng.test.remote.hello.IHello;
public class HelloService implements IHello{
    public String sayHello(String from){
        return "Hello from "+from;
    }

}

As we can see, the service offers a single, simple method which returns a String.

The service also uses a BundleActivator to register the service as remotable on the framework:

package it.eng.test.remote.helloservice;
import it.eng.test.remote.hello.IHello;
import java.util.Hashtable;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import ch.ethz.iks.r_osgi.RemoteOSGiService;
public class Activator implements BundleActivator {
    private BundleContext context;
    public BundleContext getContext() {
        return context;
    }
    @SuppressWarnings({ "rawtypes", "unchecked" })
    public void start(final BundleContext context) throws Exception {
          final Hashtable properties = new Hashtable();
          properties.put(RemoteOSGiService.R_OSGi_REGISTRATION, Boolean.TRUE);
          context.registerService(IHello.class.getName(), new HelloService(), properties);
          System.out.println("Service registered.");
      }
    public void stop(BundleContext bundleContext) throws Exception {
        context = null;
    }
}

The client is, for simplicity only, composed just by the BundleActivator. When started it connects to the remote framework through its r-OSGi component to browse the available services and connect to the one it is interested in.

package it.eng.test.remote.helloconsumer;
import it.eng.test.remote.hello.IHello;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceReference;
import ch.ethz.iks.r_osgi.RemoteOSGiService;
import ch.ethz.iks.r_osgi.RemoteServiceReference;
import ch.ethz.iks.r_osgi.URI;
public class Activator implements BundleActivator {
    private BundleContext context;
    public BundleContext getContext() {
        return context;
    }
    public void start(final BundleContext context) throws Exception {
          final ServiceReference serviceRef = context.getServiceReference(RemoteOSGiService.class.getName());
          if (serviceRef == null) {
              System.out.println("R-OSGi service not found!");
} else {
              final RemoteOSGiService remote = (RemoteOSGiService) context.getService(serviceRef);
              try {
                  remote.connect(new URI("r-osgi://192.168.23.96:9278"));
                  final RemoteServiceReference[] references = remote.getRemoteServiceReferences(
                      new URI("r-osgi://192.168.23.96:9278"), IHello.class.getName(), null);
                  if (references == null) {
                      System.out.println("Service not found!");
                  } else {
                      final IHello hello = (IHello) remote.getRemoteService(references[0]); System.out.println(hello.sayHello(System.getProperty("os.name")));
                  }
              } finally {
                  context.ungetService(serviceRef);
              }
          }
      }

    public void stop(BundleContext bundleContext) throws Exception {
context = null;
    }
}

The consumer firstly checks for the r-OSGi component presence, then uses it to connect to another r-OSGi enabled framework located at the address hardcoded in the Activator itself.

After the connection is established, he browses the remote framework's services to find the IHello implementation; if it is there, he attaches to it and prints "Hello from OS\_NAME" on standard output before unbinding from the service.

DOSGi DS Distributed OSGi Declarative Services example

noreply@blogger.com (Stefano Ghio) — Tue, 31 Jan 2012 14:38:00 +0000

In this post we will give a fair example of the workings of the OSGi DS Declarative Services remoted with DOSGi.

We can use either one of the following frameworks:

and the Eclipse IDE (for Java). The code can be launched either inside Eclipse or from a standalone OSGi framework.

NOTE:

Using DS with DOSGi requires the developer to use the "old school" BundleActivator else, even if programming following the DS specification, it will not be possible to attach to the desired service due to a bug currently not fixed yet, which prevents the target framework to register the proxy service on demand.

Interfaces, implementations and clients should all reside in their own package, meaning you should create a new Plug-in project, without template inside Eclipse (with the RCP Plug-in developer resources plugin installed) for each of them.

Suppose we have a service: HelloService, its interface: IHello and a client: HelloCunsomer who declares a dependency on the service by pointing to its interfaces using the DS method.

When a component declares it provides a service, the OSGi framework stores that information in its internal registry.

Download here the example's source code. You should be able to import everything inside Eclipse as-is. Inside you will find:


Interface – IHello.java

package it.eng.test.dosgi.hello;

public interface IHello {

public String sayHello(String from);

}


Implementation – HelloService.java

package it.eng.test.dosgi.helloservice;

import it.eng.test.dosgi.hello.IHello;

public class HelloService implements IHello{

    public String sayHello(String from){

        System.out.println("REMOTE CALL");

        return "Hello from "+from;

    }
}

If you inspect it, you will see that the it offer a single, simple method which returns a String.


Client – HelloConsumer.java

package it.eng.test.dosgi.helloconsumer;
import org.osgi.service.component.ComponentContext;
import it.eng.test.dosgi.hello.IHello;

public class HelloConsumer {
    private IHello hello;

    public void bindHello(IHello h) {
        hello = h;
        System.out.println("binded");
    }

    public void unbindHello(IHello h) {
        hello = null;
        System.out.println("unbinded");
    }

    public void start(ComponentContext bc) {
        System.out.println("started"); System.out.println(hello.sayHello(System.getProperty("os.name")));
    }

}

The consumer declares the dependency on the service by requiring its interface and has some methods of his own:

start: this method is called as soon as the component is started;
bind*: this method is called when the required *Service becomes available;
unbind*: this method is called when the required *Service becomes unavailable.

It also requires a BundleActivator:

package it.eng.test.dosgi.helloconsumer;

import it.eng.test.dosgi.hello.IHello;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.util.tracker.ServiceTracker;

public class Activator implements BundleActivator {
    private ServiceTracker tracker;

    public void start(BundleContext context) throws Exception {
        tracker = new ServiceTracker(context, IHello.class.getName(), null);
        tracker.open();
    }

    public void stop(BundleContext context) throws Exception {
        tracker.close();
    }
}

With the activator, the bundle declares a ServiceTracker as a workaround for that bug.

The framework knows that Consumer needs that particular service since he declared it in his XML configuration which must be put under the OSGI-INF/ folder:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" activate="start" name="it.eng.test.dosgi.helloconsumer">
<implementation class="it.eng.test.dosgi.helloconsumer.HelloConsumer"/>
<reference bind="bindHello" cardinality="1..1" interface="it.eng.test.dosgi.hello.IHello" name="IHello" policy="static" unbind="unbindHello"/>
</scr:component>

Here the bundle is saying that the class it.eng.test.dosgi.helloconsumer.HelloConsumer statically and necessarily depends on one of the possible it.eng.test.dosgi.hello.IHello interface implementations and that when one of them becomes available or unavailable inside the framework, its bindHello or unbindHello method should be called.

The static policy attribute means that the DS is required to deactivate the component and create a new instance each time the required service changes; the alternative would be dynamic which means that the bundle is able to work properly even when the services are dynamically switched.

The dependency is mandatory since the cardinality was set to 1..1, meaning the component cannot be started until that particular dependency is currently available, contrarily to 0..1 which means instead that it is optional. Another alternative would be 0..N, which would require the DS to invoke the associated method multiple times, one for each service instance currently available in the registry.

Furthermore, the name of the bind* and unbind* methods can be changed as pleased as long as it reflects the ones written in the java code.

Additionally, the client must specify an additional configuration indicating to the framework where to look for remote services; this XML must be put under the OSGI-INF/remote-service folder and must be compiled for every host to connect to:

<endpoint-descriptions xmlns="http://www.osgi.org/xmlns/rsa/v1.0.0">
<endpoint-description>
    <property name="objectClass">
      <array>
        <value>it.eng.test.dosgi.hello.IHello</value>
      </array>
    </property>
    <property name="endpoint.id">http://localhost:9091/hello</property>
    <property name="service.imported.configs">org.apache.cxf.ws</property>
</endpoint-description>
</endpoint-descriptions>

On its side, the service must declare its own XML configurations, listing the interface implementations offered, the classes implementing them, and a series of parameters used to make the service remotable.

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.eng.test.dosgi.helloservice">
   <implementation class="it.eng.test.dosgi.helloservice.HelloService"/>
   <property name="service.exported.interfaces" value="*" />
<property name="service.exported.configs" value="org.apache.cxf.ws" />
<property name="org.apache.cxf.ws.address" value="http://localhost:9091/hello" />
<service>
     <provide interface="it.eng.test.dosgi.hello.IHello"/>
</service>
</scr:component>

This line indicates that all methods described in the service interface are to be made remotable:

<property name="service.exported.interfaces" value="*" />

This value is linked to the OSGi framework implementation we used (Apache CXF) and indicates that the service should be exposed as a Web Service:

  <property name="service.exported.configs" value="org.apache.cxf.ws" />

located here:

  <property name="org.apache.cxf.ws.address" value="http://localhost:9091/hello" />

When we export our projects as Deployable plug-ins and fragment and install all the resulting bundles inside the same OSGi framework and start them, we see that Consumer prints on the standard output the string "started" right after it is starts and then, alternatively depending on their service implementation bundle's state, the strings: "binded" and "unbinded" plus "Hello from OS\_NAME".

OSGi Blueprint Services example

noreply@blogger.com (Stefano Ghio) — Mon, 30 Jan 2012 19:28:00 +0000

In this post we will give a fair example of the workings of the OSGi Blueprint Services.

We can use either one of the following frameworks:

Eclipse Gemini

Apache Camel

Apache Aries

and the Eclipse IDE (for Java). The code can be launched either inside Eclipse or from a standalone OSGi framework.

Interfaces, implementations and clients should all reside in their own package, meaning you should create a new Plug-in project, without Activator or template inside Eclipse (with the RCP Plug-in developer resources plugin installed) for each of them.

Suppose we have a service: HelloService, its interface: IHello and a client: HelloCunsomer who declares a Java Bean dependency on the service by pointing to its interfaces using the Blueprint method.

When a component declares it provides a service, the OSGi framework stores that information in its internal registry.

Download here the example's source code. You should be able to import everything inside Eclipse as-is. Inside you will find:


Interface – IHello.java

package it.eng.test.blueprint.hello;

public interface IHello {
public void sayHello();
}


Implementation – HelloService.java

package it.eng.test.blueprint.helloservice;

import it.eng.test.blueprint.hello.IHello;

public class HelloService implements IHello{
    public void sayHello(){
        System.out.println( "Hello World!" );
    }
}

If you inspect it, you will see that the it offer a single, simple method which prints something on standard output.


Client – HelloConsumer.java

package it.eng.test.blueprint.consumer;

import it.eng.test.blueprint.hello.IHello;

public class HelloConsumer {
    private IHello service;

    // Bean properties
    public IHello getService() {
        return service;
    }

    public void setService(IHello service) {
        this.service = service;
    }

    public void init() {
        System.out.println("OSGi client started.");
        if (service != null) {
            System.out.println("Calling sayHello()");
            service.sayHello(); // Invoke the OSGi service!
        }
    }
}

The consumer declares the bean dependency on the service by requiring its interface and has some methods of his own:

init: this method is called as soon as the requested bean is injected inside the application;
get*: this method is called this method is called to get the * property;
set*: this method is called this method is called to set the * property;


The framework knows that Consumer needs that particular service since he declared it in his XML configuration which must be put under the OSGI-INF/blueprint folder. As soon as the service becomes available it is injected as a bean inside the consumer:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

<reference id="helloWorld"
        interface="it.eng.test.blueprint.hello.IHello"/>

<bean id="client"
        class="it.eng.test.blueprint.consumer.HelloConsumer"
        init-method="init">
    <property name="service" ref="helloWorld"/>
</bean>

</blueprint>

Here the bundle is saying that the interface it.eng.test.blueprint.hello.IHello should be referenced as helloWorld and declares a bean for that reference to be injected on the property service of the it.eng.test.blueprint.consumer.HelloConsumer class with the init initialization method.

On its side, the service must declare its own XML configurations, listing the interface implementations offered through which beans.

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

</blueprint>

When we export our projects as Deployable plug-ins and fragment and install all the resulting bundles inside the same OSGi framework and start them, we see that Consumer prints on the standard output the string "OSGi client started." right after it is starts and then, when the required bean becomes available and injected, "Calling sayHello()" then "Hello World!".

OSGi DS Declarative Services example

noreply@blogger.com (Stefano Ghio) — Fri, 27 Jan 2012 17:08:00 +0000

In this post we will give a fair example of the workings of the OSGi DS services.

I suggest you read a good OSGi tutorial by Lars Vogel before moving further if you are not much confident with the OSGi specification.

We are working with the Equinox OSGi framework, which is part of the Eclipse IDE (for Java). The code can be launched either inside Eclipse or from a standalone OSGi framework; for the latter option, grab the following jar packages from under the plugins/ folder of our Eclipse installation:


org.eclipse.osgi
org.eclipse.equinox.ds
org.eclipse.equinox.util
org.eclipse.osgi.services

and copy them in a folder of your choice.

Now open a command prompt, browse to that folder and type:

java -jar org.eclipse.osgi.jar -console

to make the OSGi prompt appear. From here you can issue a lot of commands to the OSGi framework, some of which are:

help
ss - shows the current status of the installed bundles
install file:path - installs the bundle available at the specified path. It will be given an unique numeric ID
uninstall ID
start ID
stop ID
refresh - forces a framework refresh and update of the bundles state

The bundles can be in only one of the following states at a time:

INSTALLED: the bundle has been successfully installed on the platform;

RESOLVED: all of the bundle's dependencies are currently available, the bundle is ready to be started or it has just been stopped;

STARTING: the bundle is starting, it is waiting for the method which takes care of the necessary start operations to return;

```
ACTIVE: the bundle is up and running;
```
STOPPING: the bundle is stopping, it is waiting for the method which takes care of the necessary stop operations to return.

There exists an additional state, UNINSTALLED, but it will never be shown by the framework.

In order for the DS component to work properly, you must install and start all the bundles copied before (org.eclipse.osgi excluded) inside the framework.

Now we can begin our example.

Interfaces, implementations and clients should all reside in their own package, meaning you should create a new Plug-in project, without Activator or template inside Eclipse (with the RCP Plug-in developer resources plugin installed) for each of them.

Suppose we have two services: HappyService and SadService, their interfaces: IHappy and ISad and a client: Customer who declares a dependency on the services by pointing to their interfaces using the DS method.

When a component declares it provides a service, the OSGi framework stores that information in its internal registry.

Download here the example's source code. You should be able to import everything inside Eclipse as-is. Inside you will find:


Interface - IHappy.java

package it.eng.test.ds.happy;

public interface IHappy {
 public void imHappy();
}
Interface - ISad.java

package it.eng.test.ds.sad;

public interface ISad {
 public void imSad();
}
Implementation - HappyService.java

package it.eng.test.ds.happyservice;

import it.eng.test.ds.happy.IHappy;

public class HappyService implements IHappy{
 public void imHappy(){
  System.out.println("I'm happy :)");
 }
}
Implementation - SadService.java

package it.eng.test.ds.sadservice;

import it.eng.test.ds.sad.ISad;

public class SadService implements ISad{
 public void imSad(){
  System.out.println("I'm sad :(");
 }
}


If you inspect them, you will see that the two services offer a single, simple method which prints something on standard output.


Client - Consumer.java

package it.eng.test.ds.consumer;

import it.eng.test.ds.happy.IHappy;
import it.eng.test.ds.sad.ISad;

public class Consumer {
 private IHappy happy;
 private ISad sad;
 
 public synchronized void bindHappy(IHappy happy){
  this.happy = happy;
  happy.imHappy();
 }
 
 public synchronized void unbindHappy(IHappy happy){
  this.happy = null;
  sad.imSad();
 }
 
 public synchronized void bindSad(ISad sad){
  this.sad = sad;
  sad.imSad();
 }
 
 public synchronized void unbindSad(ISad sad){
  this.sad = null;
  happy.imHappy();
 }
 
 public void activate(){
  System.out.println("I'm here");
 }
 
}

The consumer declares the dependency on the two services by requiring their interfaces and has some methods of his own:


activate: this method is called as soon as the client bundle is started;
bind*: this method is called immediately after the required *Service becomes available on the framework;
unbind*: this method is called immediately after the required *Service becomes unavailable on the framework.

The framework knows that Consumer needs those particular services since he declared it in his XML configuration which must be put under the OSGI-INF/ folder:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.eng.test.ds.consumer">
   <implementation class="it.eng.test.ds.consumer.Consumer"/>
   <reference bind="bindHappy" cardinality="0..1" interface="it.eng.test.ds.happy.IHappy" name="IHappy" policy="dynamic" unbind="unbindHappy"/>
   <reference bind="bindSad" cardinality="0..1" interface="it.eng.test.ds.sad.ISad" name="ISad" policy="dynamic" unbind="unbindSad"/>
</scr:component>

In there the bundle is saying that the class it.eng.test.ds.consumer.Consumer dynamically and optionally depends on one of the possible it.eng.test.ds.happy.IHappy interface implementations and that when one of them becomes available or unavailable inside the framework, its bindHappy or unbindHappy method should be called.

The dynamically policy attribute means that the bundle is able to work properly even when the services are dynamically switched; the alternative would be static, which would require the DS to deactivate the component and create a new instance each time the required service changes.

The dependency is optional since the cardinality was set to 0..1, meaning the component can be started even if that particular dependency is not currently available, contrarily to 1..1 which means instead that it is mandatory. Another alternative would be 0..N, which would require the DS to invoke the associated method multiple times, one for each service instance currently available in the registry.

Furthermore, the name of the bind* and unbind* methods can be changed as pleased as long as it reflects the ones written in the java code.

On their side, the two services must declare their own XML configurations, listing the interface implementations offered and the classes implementing them:

HappyService XML:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.eng.test.ds.happyservice">
   <implementation class="it.eng.test.ds.happyservice.HappyService"/>
   <service>
      <provide interface="it.eng.test.ds.happy.IHappy"/>
   </service>
</scr:component>

SadService XML:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.eng.test.ds.sadservice">
   <implementation class="it.eng.test.ds.sadservice.SadService"/>
   <service>
      <provide interface="it.eng.test.ds.sad.ISad"/>
   </service>
</scr:component>

When we export our projects as Deployable plug-ins and fragment and install all the resulting bundles inside the same OSGi framework and start them, we see that Consumer prints on the standard output the string "I'm here" right after it is starts and then, alternatively depending on their service implementation bundle's state, the strings: "I'm happy :)" and "I'm sad :(".

Why beer is good for the brain

noreply@blogger.com (Stefano Ghio) — Sun, 15 Jan 2012 10:04:00 +0000

Well ya see, Norm, it's like this. A herd of buffalo can only move as fast as the slowest buffalo. And when the herd is hunted, it is the slowest and weakest ones at the back that are killed first.
This natural selection is good for the herd as a whole, because the general speed and health of the whole group keeps improving by the regular killing of the weakest members.

In much the same way, the human brain can only operate as fast as the slowest brain cells. Excessive intake of alcohol, as we know, kills brain cells. But naturally, it attacks the slowest and weakest brain cells first. In this way, regular consumption of beer eliminates the weaker brain cells, making the brain a faster and more efficient machine.
That's why you always feel smarter after a few beers.

Cheers, 1982

ITALIANO:

Beh vedi, Norm, funziona cosi'. Una mandria di bufali puo' muoversi al piu' velocemente come il bufalo piu' lento. E quando la mandria viene cacciata, sono i piu' lenti e deboli rimasti indietro ad essere uccisi per primi.

Questa selezione naturale giova alla mandria stessa, perche' la salute e la velocita' generale di tutto il gruppo continua a migliorare grazie all'eliminazione costante dei membri piu' deboli.

Quasi allo stesso modo, il cervello umano puo' operare al piu' velocemente come le piu' lente cellule cerebrali. Un'assunzione eccessiva di alcool, come sappiamo, uccide le cellule cerebrali. Ma naturalmente, attacca le piu' lente e deboli per prime. In questo modo, un'assunzione regolare di birra elimina le cellule cerebrali piu' deboli, rendendo il cervello una macchina piu' rapida ed efficiente.

Ecco perche' ti senti sempre piu' furbo dopo un paio di birre.

[Sheet music] Take me home, country roads piano

noreply@blogger.com (Stefano Ghio) — Tue, 08 Nov 2011 17:46:00 +0000

This version is the one from the movie Whispers of the heart and it's based on the John Denver's original one.

Questa versione e' del film Whispers of the heart ed e' basata sull'originale di John Denver.

Scarica lo spartito/Download sheet music.

[Sheet music] Starcraft Terran theme piano

noreply@blogger.com (Stefano Ghio) — Tue, 08 Nov 2011 17:42:00 +0000

Scarica lo spartito/Download sheet music.

[Sheet music] Murder, she wrote piano theme - La signora in giallo

noreply@blogger.com (Stefano Ghio) — Tue, 08 Nov 2011 17:41:00 +0000

Scarica lo spartito/Download sheet music.

How to contact Facebook or delete your account

noreply@blogger.com (Stefano Ghio) — Tue, 27 Sep 2011 18:34:00 +0000

Contacting Facebook can really be a pain, but definitely deleting your account is even harder. Since they rely on your data to survive, they will hang on to it as long as possible.

Luckily, Mary Smith gathered all possible ways to contact Facebook and receive support. Feature requests, suggestions, bug reports and account deletion can all be found there.

You can even request Facebook to send you a CD copy of all the data they have about you accordingly with your country's privacy laws.

By the way, good luck at getting Facebook to reply to you, especially with the data request. If they don't answer, insist since they MUST satisfy your request within a limited time.

UPDATE: An anonymous user pointed out that more information about that is available at webmarketing-conseil.

Legend of Dragoon fix disc 2 freeze after Lenus & Regole battle

noreply@blogger.com (Stefano Ghio) — Tue, 13 Sep 2011 14:34:00 +0000

ENGLISH: please refer to supercheats, quick summary: beat the battle without ever going Dragoon

ITALIANO:

The Legend of Dragoon é uno di quei giochi che non risentono dell’etá. Purtroppo, se si prova a giocarlo su una qualsiasi console che non sia la ormai rara PlayStation 1 (PS2, PS3, PSP o usando l’emulatore PSX), per qualche motivo dopo la battaglia contro Lenus e Regole verso la fine del disco 2, lo schermo diventa nero ed il gioco va in freeze senza possibilitá di recupero.

Fortunatamente (grazie Google search e supercheats!), esiste una soluzione: terminare la battaglia senza mai trasformare alcun personaggio in Dragone. La cosa non é poi cosí impossibile come sembra, basta seguire alcuni accorgimenti:

avere il party ad un livello di almeno 20
inserire Meru nel party poiché, essendo dello stesso elemento (acqua) dei due boss, riceve meno danni dai loro attacchi e gli oggetti magici d’attacco usati da lei sono piú efficaci
inserire Shana nel party poiché gli oggetti magici d’attacco usati da lei sono piú efficaci
fare grande scorta di oggetti d’attacco come Incenerimento (bersaglio singolo) e Magma sgorgante (bersagli multipli), molto efficaci specie se utilizzati da Dart, Meru o Shana
puó aiutare equipaggiare Dart con la Lama Rovente perché aggiunge attacco fuoco a cui sono deboli i due boss
evitare di inserire Kongol o Albert nel party per via della loro scarsa difesa magica e lentezza
in alternativa a Shana, inserire Rose o Haschel nel party con il compito di utilizzare oggetti di recupero ed attaccare fisicamente Lenus verso la fine della battaglia quando non si hanno piú oggetti d’attacco
puó aiutare equipaggiare con l’Anello del Bandito il membro piú lento del party, equipaggiare con l’Anello Lenitivo il membro del party che sará addetto alla cura e con l’Anello Fisico il membro del party con meno PF

Portugal.. como un Jarro

noreply@blogger.com (Stefano Ghio) — Wed, 10 Aug 2011 06:20:00 +0000

Ci sono un Irlandese, un Portoghese e due Italiani in Portogallo con un jarro in mano.. Scopri come va a finire guardando le foto

Ps: If anyone knows who's the girl in the background, please say it in a comment!

GNOME 3 add applications taskbar/panel

noreply@blogger.com (Stefano Ghio) — Sun, 31 Jul 2011 21:41:00 +0000

GNOME 3 does not have, like GNOME 2, two taskbars: one for the applications and one for the system tray. It is possible to add the application taskbar (which includes a system tray panel too) manually with the project tint2. All instructions for installing under different distros are available directly on the developers website.

ITALIANO:

GNOME 3 non ha, a differenza di GNOME 2, due taskbar: una per le applicazioni e una per la system tray. É possibile aggiungere la barra delle applicazioni (che include anche un pannello di tray) manualmente tramite il progetto tint2. Tutte le istruzioni per l’installazione sotto differenti distribuzioni sono disponibili direttamente sul sito degli sviluppatori.

GNOME 3 enable right click on desktop and show icons

noreply@blogger.com (Stefano Ghio) — Sun, 31 Jul 2011 21:32:00 +0000

GNOME 3 by default doen’t show any icon on the desktop and does not allow right-clicking it. You could change this behaviour manually:

run yum install dconf-editor as root or install it via add/remove software and launch it when it’s ready
navigate the menus through org –> GNOME –> Desktop –> Background
search for the show-desktop-icons entry and chek its checkbox

ITALIANO:

GNOME 3 di base non mostra alcuna icona sul desktop e non permette il click destro. Si puo’ modificare questo comportamento manualmente:

lanciate yum install dconf-editor da root o installatelo via add/remove software ed avviatelo al termine
navigate i menu attraverso org –> GNOME –> Desktop –> Background
cercate la voce show-desktop-icons e selezionate la checkbox associata

GNOME 3 add minimize and restore buttons to windows

noreply@blogger.com (Stefano Ghio) — Sun, 31 Jul 2011 21:24:00 +0000

GNOME 3 by default shows only the “close” button on windows. You could add the other two (minimize and restore/maximize) manually:

run yum install gconf-editor as root or install it via add/remove software and launch it when it’s ready
navigate the menus through Desktop –> GNOME –> Shell –> Windows
search for the button_layout entry and edit its value to :minimize,maximize,close (colon included!)
restart nautilus or log out and in again to see the changes take effect

ITALIANO:

GNOME 3 di base mostra solo il bottone “chiudi” sulle finestre. Si possono aggiungere gli altri due (minimizza e ripristina) manualmente:

lanciate yum install gconf-editor da root o installatelo via add/remove software ed avviatelo al termine
navigate i menu attraverso Desktop –> GNOME –> Shell –> Windows
cercate la voce button_layout e modificate il suo valore a :minimize,maximize,close (due punti inclusi!)
riavviate nautilus o fate log out e log in di nuovo per vedere il cambiamento in azione

Realtek wireless on Fedora

noreply@blogger.com (Stefano Ghio) — Sun, 31 Jul 2011 21:05:00 +0000

This article applies to the 819x Realtek wireless cards series like models 8191SEvB, 8191SEvA2, 8192SE, …

Main reference site is Stanislaw Gruszka’s compact wireless website.

You can either try the -stable version or the –next. Both have different kernel requirements, the –next version, though more unstable, is compiled against the latest kernel version so you should run yum update kernel as root before installing the appropriate package for your system.

After installation you will have to reboot the system before being able to use and control your wireless card through NetworkManager.

ITALIANO:

Questo articolo si applica ai modelli di schede wireless Realtek serie 819x quali 8191SEvB, 8191SEvA2, 8192SE, …

Il sito di riferimento é compact wireless di Stanislaw Gruszka.

Potete provare sia la versione -stable che la –next. Entrambe hanno differenti requisiti di kernel, la versione –next, sebbene piú instabile, é compilata per l’ultima versione del kernel supportata dal sistema per cui é sufficiente lanciare yum update kernel da root prima di installare il pacchetto corretto per il proprio sistema.

Al termine dell’installazione sará necessario riavviare il sistema prima di poter usare e controllare la propria scheda wireless attraverso il NetworkManager.

[MatLab] EM – Expectation Maximization reconstruction technique implementation

noreply@blogger.com (Stefano Ghio) — Wed, 20 Jul 2011 16:33:00 +0000

EM – Expectation Maximization is an iterative algorithm used in tomographic images (as in CT) reconstruction, very useful when the FBP – Filtered Back Projection technique is not applicable.

Basic formula is:

f_k+1 = (f_k / alpha) (At (g / (A f_k)))

where:

f_k is solution (the resulting reconstructed image) at k-th iteration, at first iteration it is our guess
g is image sinogram (what we get from the scanning)
A f_k is Radon transform of f_k
At is inverse Radon
alpha is inverse Radon of a sinogram with all values 1 which represents our scanning machine

Get the source code here.

[MatLab] SIRT - Simultaneous Iterative Reconstruction Technique implementation

noreply@blogger.com (Stefano Ghio) — Wed, 20 Jul 2011 16:26:00 +0000

SIRT – Simultaneous (algebraic) Reconstruction Technique is an iterative algorithm used in tomographic images (as in CT) reconstruction, very useful when the FBP – Filtered Back Projection technique is not applicable.

Basic formula is:

f_(k+1) = f_k + At (g - A f_K)

where:

f_k is solution (the resulting reconstructed image) at k-th iteration, at first iteration it is our guess
g is image sinogram (what we get from the scanning)
A f_k is Radon transform of f_k
At is inverse Radon

Get the source code here.

[MatLab] Filter a tomographic image in Fourier’s space

noreply@blogger.com (Stefano Ghio) — Wed, 20 Jul 2011 16:16:00 +0000

MatLab has built-in functions to simulate acquisition and elaboration of tomographic (as in CT) images. When it comes to filtering the image prior to back-projecting it, it is possible to do it yourself without relying on the (good as in Shepp-Logan) filters MatLab has.

We will filter our image in Fourier’s space. For each column of the sinogram, we:

apply the Fourier transform
filter it
apply the Fourier antitransform

When we reconstruct our image WITHOUT having MatLab apply any filter, we’ll see the image, filtered with our filter, as a result. Get the source code here.

[PHP] PageRank implementation

noreply@blogger.com (Stefano Ghio) — Wed, 06 Jul 2011 14:21:00 +0000

There are two possible PageRank implementations: the power method and the iterative method. We will describe both.

To check the results obtained we provide a scri'pt to generate a .gexf file to be opened with Gephi.

Test datasets are available at the Toronto university website.

Technologies used:

PHP
Gephi
XML

1.Power method

This method takes longer than the other one, however the result is equally right. Using a sparse matrix instead of the full one may help speed up the process.

Method description:

Pick the NxN input matrix and make it stochastic, call it A
Create the P" matrix as alpha*A+(1-alpha)*M with alpha a factor which describes the probability of a random jump and M an NxN matrix filled with values 1/N
Create starting vector v_0 with length N filled with values 1/N
Compute v_m = v_m-1*P" where the first time v_m-1 is exactly v_0
Compute the difference v_m - v_m-1 which should converge to 0
When the difference doesn't vary over a certain threshold or i iterations have been made, stop. v_m should contain the PageRank for every page

To run the program you must have the nodes and adj_matrix files from the chosen dataset. The implementation source code is found here here.

NOTE: Due to Apache and PHP limitations, you may have to modify the php.ini file to grant more memory to the scripts (if you don't want to store the matrix on filesystem like we did) by setting the memory_limit parameter to at least 768MB and raising the maximum script execution time to 5 minutes(300 seconds) with max_execution_time.

2. Iterative method - found on phpir

To use this method you must have the nodes and adj_list files from the chosen dataset.

Method description:

Each page is given a starting PR of 1/N where N is the number of nodes in the graph. Each page then gives to every page it links a PR of current_page_PR/number_of_outbound_links.
It's introduced a dampening factor alpha (0,15) which represents the probability of making a random jump while visiting the graph or when reaching a cul de sac.

PR_new = alpha/n + (1-alpha)*PR_old

Every PR is then normalized between 0 and 1.

The process keeps going until it has reached i iterations or the difference between old and new PR doesn't vary over a certain threshold.

Our implementation is available here.

3. Gephi parser:

To use the parser you you must have the nodes and adj_list files from the chosen dataset. The parser outputs a .gexf file to be opened with Gephi. Here is a sample .gexf file obtained by parsing the first dataset available on the site (the one about abortion).

pro-AD website: MRI analysis for prodromal Alzheimer’s assessment

noreply@blogger.com (Stefano Ghio) — Wed, 25 May 2011 13:39:00 +0000

Recently I participated in the pro-AD’s website development.

pro-AD is a website created at DIFI, the University of Genoa’s Department of Physics, to help medics automagically analyse MRI images for the prodromal Alzheimer's disease assessment.

Registered medics can easily submit DICOM or NII files through the website to their private local folder via the java applet JUploader or the PHP uploader which is shown automatically when no java plugin is detected on the user's browser. They can then modify the information associated with those images: age, gender and an optional unique ID - no personal data about the patients is stored anywhere anytime during the process.

Easy access for the medic's personal profile is provided through a dedicated page; if a valid e-mail address is provided, it is possible to enable e-mail notifications about processing results.

When one or more files are selected for processing, the server enqueues them in a multithreaded pipeline and starts the analysis. At the end, a single number which describes the patient's likelihood of being affected in the near future by the disease is returned for each file sent to processing. If the file processed was of really bad quality or was not a valid file, the process fails and an error is shown instead of the result.

All results are stored for easy future access and can be viewed and exported in XLS format from a dedicated page. If a file is sent to processing more times, only the latest result is stored.

[PHP] Create XLS document

noreply@blogger.com (Stefano Ghio) — Wed, 25 May 2011 13:18:00 +0000

If you need to create XLS documents via PHP, you may need these functions:

//XLS Begin of file
function xlsBOF() {
echo pack("ssssss", 0x809, 0x8, 0x0, 0x10, 0x0, 0x0);
return;
}
//XLS End of file
function xlsEOF() {
echo pack("ss", 0x0A, 0x00);
return;
}
//Writes a number in a cell
function xlsWriteNumber($Row, $Col, $Value) {
if($Value == null){
xlsWriteLabel($Row, $Col, $Value);
}
else{
echo pack("sssss", 0x203, 14, $Row, $Col, 0x0);
echo pack("d", $Value);
}
return;
}
//Writes a string in a cell
function xlsWriteLabel($Row, $Col, $Value ) {
$L = strlen($Value);
echo pack("ssssss", 0x204, 8 + $L, $Row, $Col, 0x0, $L);
echo $Value;
return;
}

//Creates headers to download the file
function xlsWriteHeader(){
// Send Header
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Content-Type: application/force-download");
header("Content-Type: application/octet-stream");
header("Content-Type: application/download");;
header("Content-Disposition: attachment;filename=EXPORTNAME.xls ");
header("Content-Transfer-Encoding: binary ");
}

[PHP] Send mail with attachment using PEAR

noreply@blogger.com (Stefano Ghio) — Wed, 25 May 2011 13:08:00 +0000

If you use PEAR and want to send mails with attachments via PHP, you may find this helpful.

First, ensure you have installed PEAR’s Mail and Mail_mime packages. Then, you just need a function like this:

function send_mail($mail, $subject, $bodytxt, $bodyhtml, $attachment){
    require_once('Mail.php');
    require_once('Mail/mime.php');
    //mail parameters, this is the basic one
    $params = array("host"=>"YOUR_HOST");
    //creates smtp mail object
    $mail_sender = Mail::factory("smtp", $params);
    //creates mail headers
    $headers = array("From"=>"YOUR_ADDRESS", "To"=>$mail, "Subject"=>$subject);
    //creates attachment and body fields
    $crlf = "\n";
    $mime = new Mail_mime($crlf);
    $mime->setTXTBody($bodytxt);
    $mime->setHTMLBody($bodyhtml);
    $mime->addAttachment($attachment, "ATTACHMENT_TYPE");
    //never change these lines order
    $body = $mime->get();
    $headers = $mime->headers($headers);
    $error=$mail_sender->send($mail, $headers, $body);
    return $error;
}

where:

YOUR_HOST is your mail host, something like smtp.gmail.com
$mail is the recipient’s mail address
$bodytxt is the mail’s body in TXT format, do not use HTML markup here!
ATTACHMENT_TYPE is the attachment’s MIME type as per IANA’s specifications, something like image/jpeg
if you change the order of the last lines, the attach operation will not work