adding java language to code blocks

improves syntax highlighting for java code

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

Author: chrisrueger

_appnotes/dtos.md

@@ -185,30 +185,32 @@ example, in Java you can click on a field and ask who references it, something t
 
 For example, the OSGi enRoute REST service was designed with DTOs in mind. This is all you have to write (really, no further setup) to create a REST API on `/rest/bundle/:id`.
 
-    @Component
-    public class MyManager implements REST {
-        BundleContext context;
-    
-        @Activate
-        void activate(BundleContext context) {
-            this.context = context;
-        }
-    
-        public List<BundleDTO> getBundle() {
-            return Stream.of(context.getBundles())
-                   .map( this::toDTO )
-                   .collect(Collectors.toList());
-        }
-    
-        public BundleDTO getBundle(long id) {
-            return toDTO(context.getBundle(id));
-        }
-    
-        BundleDTO toDTO( Bundle b) {
-            return b.adapt( BundleDTO.class );
-        }
+```java
+@Component
+public class MyManager implements REST {
+    BundleContext context;
+
+    @Activate
+    void activate(BundleContext context) {
+        this.context = context;
     }
 
+    public List<BundleDTO> getBundle() {
+        return Stream.of(context.getBundles())
+                .map( this::toDTO )
+                .collect(Collectors.toList());
+    }
+
+    public BundleDTO getBundle(long id) {
+        return toDTO(context.getBundle(id));
+    }
+
+    BundleDTO toDTO( Bundle b) {
+        return b.adapt( BundleDTO.class );
+    }
+}
+```
+
 ## DTOs Service
 
 OSGi enRoute includes the [DTOs service][4]. This service is very useful in working with DTOs. It provides the following features:

_doc/215-sos.md

@@ -41,12 +41,14 @@ Components (diagram: parallelograms) can interact with external resources.
 
 Though services can be created with several alternative systems, in OSGi enRoute Service Components are based on _Declarative Services_. A class that wants to become a Service Component can just add an @Component annotation:
 
-	package com.acme;
-	
-	@Component
-	public class Foo {
-		@Activate void open() { System.out.println("Here I am!"); }
-	}
+```java
+package com.acme;
+
+@Component
+public class Foo {
+	@Activate void open() { System.out.println("Here I am!"); }
+}
+```
 
 Declarative services are extremely powerful and therefore have their own [introductory chapter](217-ds.html).
 

_doc/217-ds.md

@@ -30,26 +30,28 @@ The OSGi specifications are very cohesive and decoupled. Though this provides nu
 
 The best advice is to start very simple and use defaults. This basically means the skeleton of your component is:
 
-	package com.acme;
-	@Component 
-	public class Foo implements Bar {
+```java
+package com.acme;
+@Component 
+public class Foo implements Bar {
 
-		@Reference
-		EventAdmin eventAdmin;
+	@Reference
+	EventAdmin eventAdmin;
 
-		@Reference
-		final List<Foo> foo = new CopyOnWriteArrayList<>();
+	@Reference
+	final List<Foo> foo = new CopyOnWriteArrayList<>();
 
-		@interface Config {
-			int port();
-		}
+	@interface Config {
+		int port();
+	}
 
-		@Activate void activate( Config config ) {
-		}
+	@Activate void activate( Config config ) {
+	}
 
-		@Deactivate void close() {
-		}
+	@Deactivate void close() {
 	}
+}
+```
 
 This gives you a static component that can be be fully configured through the `com.acme.Foo` PID with Configuration Admin whatever _Management Agent_ you pick.
 
@@ -66,10 +68,12 @@ If that does not work, ask on a mailing list. Declarative Services are so widely
 
 The core idea is the PID: an identifier that identifies the configuration for the a component _type_. For example, the following component has a PID of `com.acme.FooImpl`:
 
-	package com.acme;
+```java
+package com.acme;
 
-	@Component
-	public class FooImpl { }
+@Component
+public class FooImpl { }
+```
 
 ## Default Configuration 
 
@@ -79,28 +83,32 @@ Let’s forget Configuration Admin for a moment. If you run this component witho
 
 If you want to create a service property to be registered (and provided to the `activate` method) then you can provide such a property in the @Component annotation:
 
-	@Component(
-		property=“foo=bar”
-	)
-	public class Foo { 
-		@Activate void activate( Map<String,Object> map) {
-			assert “bar”.equals(map.get(“foo”));
-		}
+```java
+@Component(
+	property="foo=bar"
+)
+public class Foo { 
+	@Activate void activate( Map<String,Object> map) {
+		assert "bar".equals(map.get("foo"));
 	}
+}
+```
 
 ## Configuration Properties Suck
 
 Properties suck but are often a necessary evil. They do not refactor easily, are error prone in their spelling, require messy conversions to their desired Java types, require casting, and in general look awful in your code with their YELLING UPPER CASE (assuming you turn the keys into constants). How nice would it be if you could just use type safe constructs? 
 
 Well, you can. In the previous examples we used a `Map<String,Object>` to get the service properties in the `activate` method. However, we can also replace this map with any annotation type:
 
-	@interface Config {
-		String foo() default “bar”;
-	}
+```java
+@interface Config {
+	String foo() default "bar";
+}
 
-	@Activate void activate( Foo.Config config ) {
-		assert “bar”equals( config.foo() );
-	}
+@Activate void activate( Foo.Config config ) {
+	assert "bar"equals( config.foo() );
+}
+```
 
 ## Factory Configuration
 
@@ -118,10 +126,12 @@ This is where Configuration Admin comes in. Let’s ignore how we manage Configu
 
 With this configuration the `com.acme.Foo` component will be instantiated twice. One component will get foo=one and the other will get foo=two
 
-	@Activate void activate( Foo.Config config) {
-		String foo = config.foo();
-		assert “one”.equals(foo) || “two”.equals(foo);
-	}
+```java
+@Activate void activate( Foo.Config config) {
+	String foo = config.foo();
+	assert "one".equals(foo) || "two".equals(foo);
+}
+```
 
 ## Singleton Configuration
 
@@ -134,17 +144,21 @@ Assume that there is a singleton Configuration for the ‘com.acme.Foo’ PID:
 
 If we now run our system, the activate method gets called with `foo=singleton`
 
-	@Activate void activate( Foo.Config config) {
-		assert “singleton”.equals( config.foo() );
-	}
+```java
+@Activate void activate( Foo.Config config) {
+	assert "singleton".equals( config.foo() );
+}
+```
 
 ## Mandatory Configuration
 
 Maybe you’ve noticed, but factories now have a rather strange life cycle. If there is no configuration for the given PID, then the component gets instantiated once with the service properties defined in the @Component annotation. If you then create a factory configuration for that PID, the default component is deleted and the factory configuration is used to instantiate a new component. The consequence of this is that you cannot have zero components, there will always be at least one. Though a default instance is sometimes handy, in general it does not make sense. In that case you can make the configuration mandatory: only if the configuration is set (either singleton or factory) will the component be instantiated.
 
-	@Component(
-		configurationPolicy = ConfigurationPolicy.MANDATORY
-	)
+```java
+@Component(
+	configurationPolicy = ConfigurationPolicy.MANDATORY
+)
+```	
 
 With a mandatory configuration the component is only instantiated when there is a Configuration for the corresponding PID. The following table shows how the configuration interacts with this policy:
 
@@ -158,8 +172,10 @@ With a mandatory configuration the component is only instantiated when there is
 
 PIDs are public API since external parties will be aware of them when they configure your component. For this reason it is sometimes better to create a name that can be kept constant over time even if implementations change.
 
-	@Component( name = “com.acme.foo” )
-	public class FooImpl { }
+```java
+@Component( name = "com.acme.foo" )
+public class FooImpl { }
+```
 
 ## Management Agent
 
@@ -180,15 +196,18 @@ Using the annotation types significantly cleaned up our code. However, with File
 
 So how do we link our annotation type to a metatype? Though the metatypes are defined in XML there are fortunately (build) annotations for it. 
 
-	@ObjectClassDefinition
-	@interface Config {
-		@AttributeDefinition
-		String foo();
-	}
+```java
+@ObjectClassDefinition
+@interface Config {
+	@AttributeDefinition
+	String foo();
+}
 
-	@Designate( ocd = Config.class, factory=true )
-	@Component
-	public class Foo {}
+@Designate( ocd = Config.class, factory=true )
+@Component
+public class Foo {}
+
+```
 
 The` @ObjectClassDefinition` and `@AttributeDefinition` can describe the ‘properties’ and provide additional information to control the user interface. The `@Designate` annotation links a configuration type (or as we call it: an Object Class Definition or ocd) to a component’s PID. This will create the proper XML for the Metatype service to link it all together.
 
@@ -197,21 +216,26 @@ The` @ObjectClassDefinition` and `@AttributeDefinition` can describe the ‘prop
 Services are linked to each other by their object classes. I.e. one component requires an instance of the Foo service type. You create that dependency with the `@Reference` annotation. A `@Component` annotated type can then register this service. However, sometimes you cannot avoid but make the _wiring_ of the services more complicated. Sometimes you really need to ensure that a component Bar is really wired to a specific instance of Foo. 
 
 This can be done with the `target` field in the `@Reference` annotation. 
-
-	@Reference( target=“(foo=bar)” )
-	Foo foo;
+```java
+@Reference( target="(foo=bar)" )
+Foo foo;
+```
 
 A component Foo can then register its service with a number of properties under Configuration Admin control. 
 
-	@Component public class FooImpl implements Foo {
-	}
+```java
+@Component public class FooImpl implements Foo {
+}
+```
 
 Another component can depend on this property.
 
-	@Component public class Bar {
-		@Reference( target=“(foo=bar)” )
-		Foo foo;
-	}
+```java
+@Component public class Bar {
+	@Reference( target="(foo=bar)" )
+	Foo foo;
+}
+```
 
 We can now create a configuration for FooImpl 
 
@@ -236,26 +260,32 @@ One of the rare cases where this is necessary is when you have to wait for a con
 
 To register a service manually you require a `BundleContext` object. You can get that objectvia the activate method, just declare a Bundle Context in its arguments and it is automatically injected:
 
-    @Activate
-    void activate( BundleContext context) {
-        this.context = context;
-    }
+```java
+@Activate
+void activate( BundleContext context) {
+	this.context = context;
+}
+```
 
 You can now register a service with the bundle context:
 
-    void register(MyService service) {
-        Hashtable<String,Object> properties = new Hashtable<>();
-        properties.put("foo", "bar");
-        this.registration = context.registerService( MyService.class, service, properties );
-    }
+```java
+void register(MyService service) {
+	Hashtable<String,Object> properties = new Hashtable<>();
+	properties.put("foo", "bar");
+	this.registration = context.registerService( MyService.class, service, properties );
+}
+```
 
 However, you now have the responsibility to unregister this service in your deactivate. If you do not clean up this service then your _component_ might be deactivated while your service still floats around. Your service is _unmanaged_. (Although when the _bundle_ is stopped it will be cleaned up.)
 
-    @Deactivate
-    void deactivate() {
-       if ( this.registration != null)
-         this.registration.unregister();
-    }
+```java
+@Deactivate
+void deactivate() {
+	if ( this.registration != null)
+		this.registration.unregister();
+}
+```
 
 If you create the service is a call back or background thread then you obviously have to handle the concurrency issues. You must ensure that there is no race condition that you register a service while the deactivate method has finished.