Dienstag, 25. Oktober 2011

OSGi - How to get the Bundle Context in a Java Object Instance

In most cases I use DS components, when I need the bundle context instance, the DS Framework injects me the bundle context in the activation method of my component. In most components I don’t like to have a dependency on OSGi APIs in my DS components, but thats another topic.

But sometimes I need an OSGi service or the BundleContext also in non OSGi / DS controlled class. E.g. when I like to write a JAX-WS web service class. There are many ways to get the Bundle Context into this type of Objects. One is to get the Bundle Context from the ClassLoader (which should implements the BundleReference interface). Here a short demo code snippet how to get the bundle API and also the bundle context of a class.



Comment: "However, this requires the code to have the permission to access the class loader." OSGi Core Specification see section 3.8.9.

Better implementation (thanks at Holger for the hint) is by using the OSGi FrameworkUtil class. See the second code snippet:



Another solution could be a holder class with a static field, which holds the actual bundle context instance. This also works when the code does not have the permission to access the class loader.
Eingestellt von um
Labels:

Montag, 17. Oktober 2011

OSGi RFC-0172 Declarative Services Annotations Runtime?

I had with Peter Kriens and Neil Bartlett on Twitter an interesting discussion about "Why the DS annotations in the DRAFT RFC-0172 Declarative Services Annotations should be process at runtime or compile time".

Here in this post I like to show my opinion why to process annotations at runtime.

Runtime Annotations kills DS lazyness?
Peter says at twitter "One of the best things about DS is its lazyness, we do not want to kill this".

My option is that with runtime annotations we do not kill the DS lazyness.
I think we do not need to scan the bundles classes and load them all, to find the DS components in the system. The simplest solution is to have the components with the full qualified class name in the bundle MANIFEST.MF here a sample code snippet:



The next thing is we need a way to read the annotations without loading the class into the class loader to support bundles e.g. with "Bundle-ActivationPolicy: lazy". All information for the DS model is in the system in the byte code (when we use runtime annotations). Because of that, we can read the information for the DS components from the bytecode. Reading annotations from the bytecode is a simple way to provide all the lazyness we have with the XML model. To show this I create a very simple prototype which use the javassist library to process the annotation at runtime in a OSGi framework see https://github.com/tux2323/annotation.processing.osgi/.

Reading Annotations at Runtime is a Performance Issue?
Peter says: "So byte code scanning does not take any time?"

XML reading at runtime does also take time; do you think reading XML can be done faster than reading byte code? All information are in the byte code is reading the byte code really a performance issue? I believe we could make reading the information for the DS components from the byte code almost as fast as reading it from the XML files.

Detect errors early?
Another statement from Peter pro XML model for DS is "Detect errors early".

Yes when the annotation is process at runtime, we won’t also have a static testing tool like bnd which checks at compile time, if everything is okay with the model and shows the problems in the IDE. Why do we need the XML model for doing this?

Why runtime Annotation?
Neil asked me on Twitter "Why would you do at runtime what you can do better at build time?".

My statement is: I would like to process the annotations at runtime, because I don't like to have information in two places in my system, only when there are technical reasons, for doing this. Because of that I think it would be nice to have runtime annotations.

When we have runtime annotations then the SCR Implementation can also decide to support them at runtime or generate at build time the XML Model e.g. via bnd. The most Java frameworks (EJB3, JAXB, JAX-RS...) use runtime annotations for their components, why do OSGi like to go a different way?"

XML and Annotations
Neil asks me on twitter "Sorry I don't understand. You want the runtime to look at both the annotations *and* the XML?"

Short answer: yes.

Long answer: When we support runtime annotations to describe DS components, which should be process at runtime, we must also support the old XML way to be backward compatible. So I like to have both XML and annotations like in the Spring framework. In Spring you could describe a bean via XML and if you like you can describe the spring bean by annotations.

Thanks
Thanks at Neil and Peter for the great discussion. At this point again I would like to say when you use at the moment DS you should use the cool annotations from BND. This is at the moment the best way to develop DS components, I think.

Links
Eingestellt von um
Labels:

Samstag, 15. Oktober 2011

JUnit > 4.10 Rules

It's been a long time ago that I last wrote about JUnit. A number of improvements and releases have been made. There have been lot improvements around the topic JUnit rules added. Today I had little bit free time to look into this new JUnit features.

Class Rules
Now there are also class rules in JUnit. A class rule extends the idea of test method-level rules and can be used to add logic, which should be invoked for or after all test methods. A simple use-case could be, when you need a HTTP server in the test, you could have a class rule to start and stop the server. Here a simple code snippet that starts and stops a HTTP server.



Test Sequence
  1. Start HTTP Server
  2. Run Test : invokeServletWithRequestOne()
  3. Run Test : invokeServletWithRequestTwo()
  4. Stop HTTP Server


Composition of JUnit Rules with RuleChain Feature
In JUnit 4.10 now you can order rules via a rule chain. This is really nice to reuse rules and combine them. Here a simple RuleChain code snippet.



Test Sequence
  1. Start new Jetty Server (rule = ServerRule)
  2. Create new Servlet Instance and add it to the Server (rule = ServletRule)
  3. Run Test : invokeServletWithRequestOne()
  4. Remove Servlet from Server (rule = ServletRule)
  5. Stop Jetty Server (rule = ServerRule)
  6. Start new Jetty Server (rule = ServerRule)
  7. Create new Servlet Instance and add it to the Server (rule = ServletRule)
  8. Run Test : invokeServletWithRequestTwo()
  9. Remove Servlet from Server (rule = ServletRule)
  10. Stop Jetty Server (rule = ServerRule)


Interface MethodRule is deprecated
The type MethodRule is now deprecated because the name makes no sense anymore because now we have class and method-level rules. A rule now should be of the type TestRule.

Thanks
Thanks at David Saff and Kent Beck for the work on JUnit and the cool rule features we have now in JUnit.

Links
Eingestellt von um
Labels:

Donnerstag, 13. Oktober 2011

OSGi Declarative Service Naming and Implementation Patterns

Here some simple OSGi declarative service (DS) naming and implementation patterns I prefer to use.

1. Naming Pattern - Component Name
A DS component name should end with Component e.g. RobotComponent.

public class RobotComponent implements Robot {}

2. Naming Pattern - Start and Stop Method
For methods, which should be called on, activate or deactivate a DS component the following names should be used:
  • start(…) and stop(…)
  • startup(…) and shutdown(…)
  • initialize(…) and deinitialize (…)
  • activate(…) and deactivate(…)

public class RobotComponent implements Robot {
      public void activate(){...}
      public void deactivate(){...}
}

3. Naming Pattern - Service Lifecycle Methods
For the service lifecycle method the following method name patterns should be uses:
  • bind${serviceName}(…) and unbind${serviceName}(…)
  • set${serviceName}(…) and unset${serviceName}(…)
  • add${serviceName}(…) and remove${serviceName}(…)
e.g. void bindRobot(Robot robot) and unbindRobot(Robot robot)


DS method name for bind more then one service instance 0..n or 1..n should become the name add* and remove*.

public class RobotComponent implements Robot {
      public void setEngine(Engine engine){...}
      public void unsetEngine(Engine engine){...}
      public void addSensor(Sensor sensor){...}
      public void removeSensor(Sensor sensor){...}
}


4. Implementation Pattern - Behavior Symmetry
When there is logic for start (activate) or set something there should always be logic for stopping or unset.

5. Implementation Pattern - Avoid Implicit Immediate Components
When a DS component not provide a Service then the component is immediate activate when all reference service are available. When the code is changed and the component know provide a service, then the component is activated when the first client component like to use the service. When a component should be activate immediate then I think avoid implicitly immediate components add always immediate=true.

6. Implementation Pattern - Use Annotations for DS Components
Use BND or Apache Felix SCR annotations to describe DS components.

Links
Eingestellt von um
Labels:

Mittwoch, 12. Oktober 2011

10 min - Domain Driven Design (lightning talk )

Here my slides from my lightning talk about Domain Driven Design. The slides I have not really needed in the lightning talk. Because my notebook crashed and I only could show slide number one. And because of that I only used the first slide. With the first slide I give a 10 minutes overview of domain driven design, keywords, patterns and core ideas. I think this basics ideas behind domain driven design every software developer should know.

Domain Driven Design - 10min

I think the following patterns, keywords and ideas should be known by everyone how developed OO software:
  • Ubiquitous Language
  • Domain
  • Domain Layer
  • Entities
  • Value Object
  • Repository
  • Aggregate
  • Service
  • Factory (e.g. Dependency Injection, Spring, Google Guice...)
  • Assertion
  • ...
For those who could not be in my lighting talk, should have a look at the domain driven demo application. Everyone should have read the book by Eric Evans about Domain Driven Design. Okay the book is not update at all, but I think the most stuff in the book is still correct.

Links and Ressources

Eingestellt von um
Abonnieren Posts (Atom)