The problem didn't occur with 1.6.2 release of iPojo... Solved but I am still puzzled
This ticket it is not relevant anymore so I close it.

Thanks Clement for your support !

Hello

I have sent you a few files on your gmail adress. I hope this will help you.

I also tried with:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
intProp = 3;
boolProp = true;
if(strProp.equals("foo"))

else

strAProp = new String[]

;
intAProp = new int[]

;
}
});

try

catch (InterruptedException e)

But, it also works.

Hello

I am currently on vacation. I will post the code in two weeks.

Fyi, I used ipojo 1.4, annotations only (@ServiceProperty & @Requires with filter) except for instance creation, and the OSGi runtime is Equinox.

The problem is using the filter property of @Requires in two separate bundles. The instance using the filter is not created.

Bundle A :

@ServiceProperty(value = "false")
private boolean ready;

...

SwingUtilities.invokeLater(new Runnable() {
public void run() {
ready = true;
}});

Bundle B :

@Require(filter = "(ready=true))

BundleConstructor()

By the way, there is no Runnable variable created, the anonymous function is invoked immediately.

Hi,

It seems to work...
I did that:

       // Service properties
        private int intProp;
	private String strProp;
	private String[] strAProp;
	private int[] intAProp;
	private boolean boolProp;

	public boolean foo() {
		Runnable runnable = new Runnable() {
			public void run() {
				intProp = 3;
				boolProp = true;
				if(strProp.equals("foo")) { strProp = "bar"; }
				else { strProp = "foo"; }
				strAProp = new String[] {"foo", "bar", "baz"};
				intAProp = new int[] {3, 2, 1};
			}
		};
		new Thread(runnable).start();

		try {
			Thread.sleep(500);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}

		return true;
	}

The service properties are correctly updated inside the method. Could you give me more details ? If you have a small bundle reproducing the issue, I would be happy to check that.

D'ailleurs merci pour iPojo !

Je n'aurais probablement jamais utilisé OSGi dans mon projet pro si j'avais du vendre l'usage brut d'OSGi. Et désormais on a plus qu'une seule application capable de charger toutes les briques fonctionnelles de notre domaine. Un gain de temps et de maintenance énorme.

Bonne continuation.

The original code is longer, but that's the spirit ...