add more languages to code blockas

Signed-off-by: Christoph Rueger <[email protected]>

Author: chrisrueger

_appnotes/interceptors.md

@@ -10,36 +10,40 @@ A recurring question on OSGi forums is how to use _interceptors_. The [Spring fr
 
 Let's say we have a function that performs some work. In the following example we need to do some "pre work", "post work", and additionally handle exceptions in similar way:
 
-	void doWork() {
-	    preWork();
-		try {
-		   … do work
-		   postWork();
-		} catch( Throwable t) {
-	       exceptionWork(t);
-		   throw t;
-		}
+```java
+void doWork() {
+	preWork();
+	try {
+		… do work
+		postWork();
+	} catch( Throwable t) {
+		exceptionWork(t);
+		throw t;
 	}
-	
-	void doOtherWork() {
-	    preWork();
-		try {
-		   … do other work
-		   postWork();
-		} catch( Throwable t) {
-	       exceptionWork(t);
-		   throw t;
-		}
+}
+
+void doOtherWork() {
+	preWork();
+	try {
+		… do other work
+		postWork();
+	} catch( Throwable t) {
+		exceptionWork(t);
+		throw t;
 	}
+}
+```
 
 The problem with this approach is that it creates a lot of boiler plate code, and the actual work gets lost. How can we get rid of this noisy and distracting code? 
 
 One possible solution is to use Interceptors. With this approach, you add an annotation and now the caller is ensuring that your annotation is correctly interpreted.
 
-	@Work(SOME_PARAMETER)
-	void doWork() {
-		   … do work
-	}
+```java
+@Work(SOME_PARAMETER)
+void doWork() {
+		… do work
+}
+```
 
 Voila, boiler plate gone! Problem solved. Or is it?
 
@@ -76,9 +80,11 @@ However, we're many years further today then when that model was introduced, and
 
 Since Java 8 we now have lambdas! (About 42 years after Smalltalk.) Lambdas are interceptors turned inside out. In the transaction composition problem the interceptor had to do something before it ran our code, then ran our code, and then handle any exceptions and do some post-processing. With lambdas, we can achieve the same model by the method calling the interceptor and passing the function.
 
-	void doWork() {
-	    interceptor.doWork( () -> ... working );
-	}
+```java
+void doWork() {
+	interceptor.doWork( () -> ... working );
+}
+```
 
 That is, instead of typing an annotation above the method, you just use a method with that name and pass it parameters, one of the parameters being the function you want to check.
 
@@ -90,14 +96,16 @@ An extremely interesting example of this is the work being done on the [Transact
 
 The underlying problem with transactions is that when you get called in a service oriented world it is not always clear how to _compose_ the transactions. I.e. join, reject if on is there, or start. This is a classical problem where you need to do something _before_ and _after_ your actual code. Therefore the transaction control service makes it look like:
 
-       @Reference Store<Person> persons;
-       @Reference TransactionController txc;
+```java
+@Reference Store<Person> persons;
+@Reference TransactionController txc;
 
-       public Person findPerson( long id) {
-            return txc.required( () -> 
-                 persons.find( "select * from Person where id=%s", id )
-            );
-       }
+public Person findPerson( long id) {
+	return txc.required( () -> 
+			persons.find( "select * from Person where id=%s", id )
+	);
+}
+```
      
 Therefore, with the same amount of code (or less) you do not need the magic interceptors.
 

_qs/410-exercise-service.md

@@ -25,9 +25,11 @@ In OSGi enRoute this means the name of the project should end with `.api` and yo
 
 In this new project, we rename the template API to reflect our semantics. So rename the `com.acme.prime.api` package to `com.acme.prime.upper.api` and the `Prime.java` file to `Upper.java`. Then change the `Upper` class so that we can use it to change a word to upper case:
 
-	public interface Upper {
-		String upper(String input);
-	}
+```java
+public interface Upper {
+	String upper(String input);
+}
+```
 
 If you have another API in the future, you can then add it to the same project in another package.
 
@@ -56,20 +58,24 @@ The first thing we need to do is to make sure the Upper Application can see the
 
 Then we change the `UpperApplication` component class. We must add a setter method for the `Upper` service with a `@Reference` annotation, which means we must import `org.osgi.service.component.annotations.Reference`. No we can add the reference to the end of the class (convention is to place references at the end):
 
-	public class UpperApplication implements REST {
-		...
+```java
+public class UpperApplication implements REST {
+	...
 
-		@Reference
-		Upper upper;
-	}
+	@Reference
+	Upper upper;
+}
+```
 
 The `@Reference` annotation creates a dependency on this service; the `UpperApplication` component is not started until the service registry contains an Upper service. 
 
 The next step is to use the `upper` instance variable that we've just set in the `getUpper` method (so we must import `com.acme.prime.upper.api.Upper` again).
 
-	public String getUpper(String string) {
-		return upper.upper(string);
-	}
+```java
+public String getUpper(String string) {
+	return upper.upper(string);
+}
+```
 
 If the OSGi framework is still running, you likely get errors since we now have an unresolved requirement in our code; we're referring to the `com.acme.prime.upper.api` package which is now not provided by anybody.
 

_tutorial_base/300-api.md

@@ -17,16 +17,18 @@ This section discuss an _API_ project. An API project can be used on the classpa
 
 We want to make a component that evaluates expressions. Though we could start with the implementation, let's do it right and first define the contract.  The service contract for now could be an interface:
 
-	package com.acme.prime.eval.api;
+```java
+package com.acme.prime.eval.api;
+/**
+ * A service that evaluates an expression and returns the result
+ */
+public interface Eval {
 	/**
-	 * A service that evaluates an expression and returns the result
+	 * Evaluate an expression and return the result.
 	 */
-	public interface Eval {
-		/**
-		 * Evaluate an expression and return the result.
-		 */
-		double eval(String expression) throws Exception;
-	}
+	double eval(String expression) throws Exception;
+}
+```
 
 Ok, it does not get a lot easier than this!
 
@@ -78,17 +80,21 @@ The box with rounded corners represents a bundle; the inside black box represent
 
 You might not have noticed it but you actually semantically versioned this package as well (don't you love magic?). When you look in the `com.acme.prime.eval.api` package you will find the `package-info.java` file. Double clicking will show the contents. In this file we define the version of the package. If you make modifications to the package, you should always update the version in this file as well.
 
-	@org.osgi.annotation.versioning.Version("1.0.0")
-	package com.acme.prime.eval.api;
- 
+```java
+@org.osgi.annotation.versioning.Version("1.0.0")
+package com.acme.prime.eval.api;
+``` 
+
 ### Provider & Consumer Types
 
 In this API, any party that will implement the `Eval` interface is considered to be the _provider_. A provider must fully implement a contract that has virtually no backward compatibility unlike _consumers_ of this API. Any change in the version that affects the public API must result in  rebuild of the provider's bundle. That is, if our version here goes to 1.1 we want to make sure our providers that implemented 1.0 are no longer compatible.  
 
 Obviously it is a nightmare to ensure that the proper version ranges are used. We can significantly help the provider by adding an annotation to this interface:
 
-	@ProviderType
-	public interface Eval { ... }
+```java
+@ProviderType
+public interface Eval { ... }
+```
 
 The bnd tool will now automatically ensure that any _implementers_ of this interface use semantic versioning to import the package with a minor range, for example `[1.0,1.1)`.