Table of Content:

• 1. Core Improvement
  • 1.1 New Manipulation process
    • 1.1.1 Manipulation Explanation
    • 1.1.2 Method Entry detection [Done]
    • 1.1.3 Method Exit Detection [Done]
    • 1.1.4 Method Exception Interception [Done]
    • 1.1.5 Flags to avoid useless delegation [Done]
  • 1.2 Build Process
    • 1.2.1 Manipulator Externalization [Done]
    • 1.2.2 BND Based Maven plug-in [Done]
    • 1.2.3 Eclipse Plug-in [Done]
    • 1.2.4 Command Line
  • 1.3 Model Cleaning
    • 1.3.1 Renaming component in type
    • 1.3.2 Attach logger to instances instead of factories
  • 1.4 Core Improvement
    • 1.4.1 Handler improvement for method interception [Done]
    • 1.4.2 Parsing Utility Functions [Done]
• 2. Service Management
  • 2.1 Manage synchronization
  • 2.2 Temporal Dependency Handler
  • 2.3 Proxy Injection
• 3. Non-functional concerns improvement
  • 3.1 Management
    • 3.1.1 JMX Bean Handler [Done]
    • 3.1.2 JMX Bean to create / list / kill instances [Done]
    • 3.1.3 Architecture Representation [In Progress]
  • 3.2 Deployment
    • 3.2.1 Ease iPOJO application deployment with OBR
  • 3.3 Persistence
    • 3.3.1 Persistence Service Design and Implementation [In Progress]
    • 3.3.2 Persistency Handler for 'primitive' components [In Progress]
    • 3.3.3 Persistency Handler for 'composite'
  • 3.4 Data Object Support
    • 3.4.1 Data Object Mapping
    • 3.4.2 Data Object Handler
  • 3.5 Event Admin Management
    • 3.5.1 Event Reception Handler [Done]
    • 3.5.2 Event Sender Handler [In Progress]
  • 3.6 Service Component Architecture Bridges
    • 3.6.1 SCA Reference Handler
    • 3.6.2 SCA Service Providing
  • 3.7 Misc handlers
    • 3.7.1 Lifecycle controller
    • 3.7.2 ThreadContextClassLoader
• 4. Composition Level
  • 4.1 Service Specification Improvement
    • 4.1.1 Syntax
    • 4.1.2 Service Level Dependency Management [Done]
    • 4.1.3 Version Management
    • 4.1.4 State Management
  • 4.2 Local Service
    • 4.2.1 Local Event Admin [In Progress]
    • 4.2.2 Persistence Service inside composite
    • 4.2.3 Local Log Service
• 5. API Support
  • 5.1 Basic API [In Progress]
  • 5.2 DependencyManager API [In Progress]

1. Core Improvement

These improvements concern the iPOJO core runtime manipulation; build process, core model ...).

1.1 New Manipulation process [Done Felix-311]

A new manipulator will be implement to allow field & method interception. Moreover, interception performance is considered.

1.1.1 Manipulation Explanation

• Writing a document explaining exactly what happen during the manipulation.* -         Field Interception
  • Method Interception
  • Constructor Manipulation
  • Instance Manager Injection
  • Manipulation Metadata

1.1.2 Method Entry detection [Done Felix-311]

• Need to intercept just after the method entry. (Before the 'super' call?)
• Gather input arguments
• Argument of the current method must be accessible by handlers.
• A handler should be able to modify arguments (be careful for primitive type (value vs. reference)).

1.1.3 Method Exit Detection [Done Felix-311]

• Need to intercept just before the method exit. (before 'return' instruction)
• For non void method, push in argument the return
• Handlers need to be able to intercept the returned object of a method.
• Handlers can modified the return
• Handler must be able to modify the returned object or value.

1.1.4 Method Exception Interception [Done Felix-311]

• Need to intercept just before the method throws an exception.
• Push the throwable object in argument
• Handler need to be able to intercept the exception object and to react.
• However, they cannot block the exception throwing.

1.1.5 Flags to avoid useless delegation [Done Felix-311]

• To limit the cost of interceptions, injection activation flag is a possibility. Before each interception a flag is tested to check if the method or the field needs to be intercepted or not.

1.2 Build Process

The iPOJO build process is becoming old and use Maven. A new architecture for the build process must be proposed where the manipulator is independent of the used technology (Maven, Eclipse, Ant, Command ...).

1.2.1 Manipulator Externalization [Done Felix-311]

• The first step of the new build process is to externalize the manipulator as an external library.
• Create a front end allowing the manipulation from an already created jar.
• The input of the new manipulator needs to be a JAR file (instead of classes).
• This Jar file should be a correct bundle created with BND.
• Modify Manifest after the process
• After the manipulator of the input bundle file, the manifest needs to be updated to add the activator, iPOJO- Component and modified imported packages.

1.2.2 BND Based Maven plug-in [Done Felix-311]

• Providing a new Maven plug-in based on the new BND Maven plug-in.
• Extend the existing plug-in, add metadata file

1.2.3 Eclipse Plug-in [Done - http://cwiki.apache.org/confluence/display/FELIX/iPOJO+Eclipse+Plug-in]

• Providing an Eclipse plug-in to ease iPOJO user.

1.2.4 Command Line

• Providing a command line to create iPOJO bundle inside scripts.

1.3 Model Cleaning [Done Felix-311]

Some part of the model should be renamed or refactored. configure method should be able to throw exception to notify parsing error or any other problem.

1.3.1 Renaming component in type

• <component> should become <type> or <component-type>

1.3.2 Attach logger to instances instead of factories

Loggers are today attached to factory to avoid the creation of a lot of objects. However, it could be difficult to analyze the log if several instances have been created. So be attaching a logger to instance instead of factories could be simpler.

1.4 Core Improvement

Based on the new manipulation process, the core can be improved.

1.4.1 Handler improvement for method interception [Done Felix-311]

• Thank to the new manipulation process, handlers can intercept method entries and exits.

1.4.2 Parsing Utility Functions [Done Felix-291]

• Utility functions to query type metadata and manipulation metadata could be very useful to avoid to big 'configure' method.

2. Service Management

One of the main iPOJO goals is to manage services interactions. Several improvements can be done.

2.1 Manage synchronization

By using method interception, it could be possible to avoid synchronized block inside the code.

2.2 Temporal Dependency Handler

• A temporal dependency is a dependency inside a method. The dependency block the service invocation since a service provider appears (or for a given duration if no providers appears).
• If a temporal dependency is not resolved, it does not invalidate the instance.

2.3 Proxy Injection

• To avoid problems when an instance give a service object to another object, the dependency handler can inject a proxy instead of the real object.
• The handler invalidates the proxy when the service disappears.

3. Non-functional concerns improvement

These improvements concern the support of other non- functional properties.

3.1 Management

Propose a way to control iPOJO instances remotely.

3.1.1 JMX Bean Handler [Done - http://cwiki.apache.org/confluence/display/FELIX/JMX+Handler]

• Component Instance can be exposed as an MBean to control attribute (get/set) method (invoke) and listen (notification).

3.1.2 JMX Bean to create / list / kill instances [In Progress]

• MBean allowing to list / create and destroy component instances (thank to public factories).

3.1.3 Architecture Representation [in progress]

• Provide a graphic representation of the instance graph.

3.2 Deployment

Propose a way to deploy iPOJO component easily based on OBR facility.

3.2.1 Ease iPOJO application deployment with OBR

• Provide an OBR description of component type and component instance.
• Extend the Maven plug-in to automate this description.

3.3 Persistence

Provide a persistence layer to allow instances to be persistent.

3.3.1 Persistence Service Design and Implementation [In Progress]

• Design and Implement a flexible persistence service.

3.3.2 Persistency Handler for 'primitive' components [In Progress]

• Create a handler allowing an instance to be persistent (thanks to a persistence service).

3.3.3 Persistency Handler for 'composite'

• Create a composite handler allowing a composite instance to be persistent:
  • by using a parent persistence service
  • by using a local persistent service

3.4 Data Object Support

Provide a sort of JDO mechanism.

3.4.1 Data Object Mapping

• Map data objects on persistent instances

3.4.2 Data Object Handler

• Implement a handler creating/retrieving/deleting/updating Data Object by injecting the data object in a field of the POJO.

3.5 Event Admin Management

Provide handlers to easy Event-Base interaction between instances.

3.5.1 Event Reception Handler [Done]

• This handler allows the reception of Event Admin events.

3.5.2 Event Sender Handler

• This handler allows sending Event Admin events.

3.6 Service Component Architecture Bridges

Propose handlers allowing the integration of SCA wires.

3.6.1 SCA Reference Handler

• Handler allowing consuming SCA Service.

3.6.2 SCA Service Providing

• Handler allowing publishing service as SCA service.

3.7 Misc handlers

3.7.1 Lifecycle controller

• This handler allows the Pojo to participate to the instance lifecycle.

3.7.2 ThreadContextClassLoader

• This handler allows setting the ContextClassloader to the bundle class loader at the entry of methods. The old CotnextClassLoader is reused after the method exit.

4. Composition Level

Improvement about iPOJO composition mechanism.

4.1 Service Specification Improvement

These improvements aim to extend service specification with other metadata.

4.1.1 Syntax

• Find an adequate syntax to describe service metadata.

4.1.2 Service Level Dependency Management [Done Felix-311]

• Manage service level dependencies

4.1.3 Version Management

• Add and manage service specification version.

4.1.4 State Management

• Add and manage service state description.

4.2 Local Service

These improvements aim to integrate new service inside composite.

4.2.1 Local Event Admin

• Provide a local event admin to manage private event-based communication.

4.2.2 Persistence Service inside composite

• Provide persistence capability to composite.

4.2.3 Local Log Service

• Provide a local log service centralizing the log of the current composition.

5. API Support

Provide an API to use iPOJO programmatically.

5.1 Basic API [In Progress]

• Provide an API to programmatically :
  • define component type
  • define composition
  • create / kill / listen instances

5.2 Dependency Manager API [In Progress]

• Implementing the Dependency Manager API to allow creating Dependency Manager Components.
• This implementation map Dependency Manager concepts on iPOJO.