lqjack / peaberry Goto Github PK

Document the "org.ops4j.peaberry.osgi.flushInterval" setting that
adjusts the periodic flushing of unused OSGi services (this is to
avoid repeatedly getting and ungetting heavily used services).

Also consider improving the behavior so that a setting of 0 means
that services unget as soon as they're unused rather than relying
on spinning the flushing thread.

org.ops4j.peaberry.eclipse registers an Eclipse extension point "module" and 
declares the schema to be "schema/modules.exsd".  This file is not available 
so the Eclipse PDE tooling generates a warning.

The file exists in svn so I think it is simply a packaging issue. 
http://code.google.com/p/peaberry/source/browse/trunk/extensions/eclipse/sche
ma/modules.exsd



I'm using 1.1.1 with Eclipse 3.5 on Vista.

If the instance created by the factory is itself an IExecutableExtension, the 
factory is 
responsible for passing on the config data.  From the 
IExecutableExtensionFactory javadocs, 

"The factories are responsible for handling the case where the concrete 
instance implement {@link 
IExecutableExtension}."

An example use case of this is the CommonNavigator view 
(http://www.techjava.de/topics/2009/04/eclipse-common-navigator-framework/).  
Clients like me can 
subclass CommonNavigator, which implements IExecutableExtension, and declare 
their view class:

<view
      name="My Navigator"
      icon="icons/view16/nav.gif"
      class="org.example.MyNavigator"
      id="org.example.MyNavigator">
</view>

This case is fine because the view framework calls setInitializationData on 
MyNavigator.  When I 
use the GuiceExtensionFactory, i.e.

<view
      name="My Navigator"
      icon="icons/view16/nav.gif"
      class="org.ops4j.peaberry.eclipse.GuiceExtensionFactory:org.example.MyNavigator"
      id="org.example.MyNavigator">
</view>

setInitializationData doesn't get called and CommonNavigator fails.

I've attached a patch with my rough idea for a fix.  I was unable to get the 
project to build so I 
didn't test it out.

I'm using Peaberry 1.1.1 and Eclipse 3.5.

Internally we use a custom Guice scope that ensures only one instance of a
specific binding is created for each bundle context (ie. like a per-bundle
singleton). It's a very simple implementation that registers each instance
with the global OSGi service registry along with the "owning" bundle id.
The published type is taken directly from the binding key.

We should expose this to clients via a new scope annotation: @BundleScope.

We must have some consistent story about factory configurations. Seems it
is best to use the approach of iPojo where each instance of a factory
configuration defines a single instance of an iPojo component. Similarly I
plan to allow maximum one factory configuration per Injector. As
configuration instances are created and destroyed Injectros are created and
destroyed in sync. This might form the base of our component model.

I've downloaded the 1.1.1 zip and used the deployed bundles in my ad-hoc
eclipse target definition.

Defining a module using the org.ops4j.peaberry.eclipse.modules does not
work since the released peaberry.eclipse-1.1.1.jar file lacks the XSD file!
I guess this is an error in the maven build missing such an eclipse feature.

I am using peaberry inside the felix server (actually a CQ instance, the
commercial version of sling + jackrabbit)
I tried to print out the classloader of Import.class. It seems like there
two class loaders loaded it. So when getting the constructor using
Import.class, it says no such method, because the parameter type mismatch.
I am not sure if this is caused by CQ or caused or misuse. 

Currently decoration is applied to the local "Import" aspect of exported
services, but not the external "Export" aspect. This means that only the
code exporting the service will see the decoration, not clients using it.

This is counter-intuitive and limits the possibilities of decorating
exports to add functionality without needing to recompile the application code.

Decorating the published "Export" aspect is a bit more tricky, but makes
life much more easier. We should also apply decoration to services passed
onto watching scopes so they too share a consistent view.

Use case: To create a workaround for missing lifecycle management in 1.0,
own lifecycle management could be implemented using put and unput with the
same service object instance.

In file OSGiServiceExport, "put" checks the equality of the instances:

  public synchronized void put(final T newInstance) {
    if (newInstance != instance) { // NOPMD
      ...

but in unput, the instance is never reset to null.

Usually one will watch the changes of services related to an import so an 
watch/unwatch method on the import will be useful and makes no harm. 
This watch / unwatch should have only one parameter: the service watcher.

I propose to change:

  ScopedServiceBuilder<T> filter(String filter);

to:

  ScopedServiceBuilder<T> filter(org.osgi.framework.Filter filter);


The reason is that using a String opens the door to use bogus expressions
without detecting them. Even the expressions on the Peaberry wiki are not
well formatted. On the OSGi reference implementation they would throw an
exception because they are missing the surrounding ().

If only the Filter class would be used, Peaberry wouldn't have to deal with
LDAP issues. 

Hello,
I think it's a must for Peaberry as an OSGi Service Layer Runtime (or SLR
:) to expose the OSGi service tracking from it's API. This API must:

1) allow the user to receive a callback when a proxy becomes valid/invalid
as it's service comes and goes. 

2) allow the user to describe the services he imports as 
required or optional. Than allow the user to specify lifecycle callbacks so
that when a required service "flashes" the respective activity going inside
the bundle can start/stop as well.

3) Allow the user to test a proxy for validity. Maybe cast to some mixed-in
Proxy interface and call an "isBound" method? This allows the user to test
when optional service are unavailable.

4) Allow the user to register a default implementation for an optional
service. The difference from a regular service registration is that this
one relates to the import of the same service. Peaberry will use a special
comparator when choosing which service to import. This will always pick the
users own default implementation last. This I think is better than the
NullObject pattern followed by iPojo.


Some use cases for this are:

1) Stateful required service: When the user has loaded some state into a
service he uses it is not acceptable for it to be hot-swapped. Instead the
classes that use it must receive a callback so that they can reset their
state as well.

2) Active bundle: A bundle that runs threads, does i/o or both should have
the option to stop it's activity when a required service is not available.
Currently it is very easy to stop the activity upon
ServiceUnavailableException but there is no easy way to restart it once the
dependency comes back.

3) Service unregistration: It is a common pattern to take down your service
registration when a required dependency goes away. Note that you usually
keep the content of the bundle assembled so that when the dependency comes
back you just have to register the service to advertise it is available
once more. This plays nice with the (2) use case where you also suspend
your bundles activities while the critical dependency is not available.

4) Optional service: make the treatment of optional services uniform with
the treatment of all other services. Makes it easier to switch between
optional and non-optional.

5) Make Peaberry more 'complete': The user must be able to do all the work
in declarative java code: 
 - the content of Guice modules.
 - service exports.
 - service imports.
 - life-cycle signals and hooks.

Than the user steps aside and lets Peaberry control when services are
registered and unregistered and when the activities in the bundle are
started and stopped. Currently the user does all the work in the
BundleActivator, and must do all the lifecycle tracking and hooking
directly against the BundleContext. I.e. the activator contains 50%
declarative Guice code and 50% imperative error-prone lifecycle control code.

Having lifecycle support will remove the need for the user to code a
BundleActivator and use directly a BundleContext. Instead he will specify
in the manifest only the classes that contain declarative java code. Than
peaberry can follow the extender pattern. It will track for bundle events
use Bundle.loadClass() to create the declarative user code and use
Bundle.getBundleContext() to manage the service dependencies on behalf of
the user bundle.

Note: In numerous Guice presentations Bob Lee says Guices role in life is
to only inject and not be a container. I.e. of the 4 phases of the lifecyle
of an object Guice deals with only the first one:
1) create
2) start
3) stop
4) destroy

The dynamism of OSGi makes (2),(3),(4) just as hard as (1). I suppose doing
(1) right is hard in all of Java. Doing (2),(3),(4) right is hard in OSGi
because of it's dynamism. I think to be really useful an OSGi SLR must deal
with the complete object lifecycle and be more of a container than Guice
tries to be :)

Should look into injecting Eclipse Extensions using Guice rather than
"new", possibly by using a per-bundle injector or per-bundle modules.

As mentioned on the front page, we want to be able to inject extensions too.

The peaberry API supports the concept of nested service scopes by allowing
you to export your own scope inside an existing scope, along with a filter
attribute that describes the sort of services you're interested in.

The enclosing service scope is then supposed to forward matching services
to your nested scope, as they are exported/modified/removed. This feature
is missing from the current OSGi ServiceRegistry implementation.

Nested scopes provide the same functionality as customized service trackers
in standard OSGi. By exporting a scope and filter to the current service
registry, you can receive callbacks as services appear and disappear, and
act accordingly.

I often find myself figuring out if I'm just dumb when using guice and 
peaberry and trying to take a look at their code during debugging sessions. I 
do remember that in a previous version (1.0?) the source code was bundled 
together with the deployable artifact. Is it possible to restore them?

Suppose I use a StickyDecorator without a reset task. This means that as
soon as the service becomes unavailable the sticky import will start
tossing ServiceUnavailableException from that point on right? 

Now because this guard clause:

if (null != resetTesk && null != instance && null == instance.attributes()) {
  instance = null;
  ...

requires there to be a resetTask in order for the service object to be
released it seems that object will be held until the application drops the
broken service proxy to the garbage collector. I suppose any sane
application would do just that and later use Guice to create a new sticky
proxy. Nevertheless it's probably better to no count on the app for this. I
am attaching a small patch where the service instance is released more eagerly.

Also even if the instance was released very eagerly there is still a
potentially infinite lag between the time the service becomes invalid and
the application tries to use it and releases the service object. I suppose
as Stuart suggests some weak reference magic must be used to close this
last hole.

I have to add I am not sure I understand the fine details Import<T>
contract so the patch might now be as correct as I wish. Hmm....I will
probably open another issue for better javadoc ;P

What steps will reproduce the problem?
1. Define a class A which extends an abstract class B.
2. Export class B as a service which is implemented by A, as following:
bind(export(B.class)).toProvider(service(A.class).export());
3. Run the application

What is the expected output? What do you see instead?
Service B should be exported successfully. But I got
IllegalArgumentException(Msg.SERVICE_EMPTY_CLASS_LIST_EXCEPTION) instead.

What version of the product are you using? On what operating system?
peaberry-1.1.1 w/ peaberry.activation-1.2-20101303

Please provide any additional information below.
OSGiSeviceExport.getInterfaceNames() should add super classes as well as
interfaces to names.

Look here for requirements and suggested designs:

http://code.google.com/p/peaberry/wiki/ConfigRegistry

From: Sylvain Mina

The org.ops4j.peaberry.eclipse.ExtensionListener class implements
IRegistryEventListener which appears in Eclipse 3.4. The previous way to
track the events participating in extension/extension points changes was to
use the IRegistryChangeListener. It provides an IRegistryChangedEvent which
delta information about extension and extension point.

The activation bundle does not unregister the services of the extended
bundle when its beeing stopped. This results in multiple service
registrations when I stop/start the activation bundle.

This is reproducable every time an attempt is made to start the bundle.
I built the project from the latest sources this morning (Oct 13 2008).
An ClassDefNotFoundExepion is cast for:

com.google.inject.internal.cglib.reflect.FastClass

This one as I understand comes originaly from cglib and is repackaged with 
jarjar. Because the class is in fact in the guice bundle but is not 
exported I supposed the problem again has to do with class loading 
delegation. Somehow the load of this class was delegated to the peaberry 
bundle rather than the guice bundle.

I'm attaching a file with the exception, the state of the framework and 
the manifests of the guice and the peaberry bundles. I did this in equinox 
with only 3 bundles: aopalliane, guice, peaberry.

Add further tests to ensure the OSGi ServiceRegistry is production ready.

Also consider using service trackers to reduce the overall look-up cost,
although this could also be achieved by applying some form of "leasing"
decoration to the service.

Module configuration:
--------------------------------------------
binder.bind(MyService.class).to(MyServiceImpl.class).in(Scopes.SINGLETON);

binder.bind(TypeLiterals.export(MyService.class)).
   toProvider(Peaberry.service(Key.get(MyService.class)).export()).
   asEagerSingleton();


MyServiceImpl:
--------------------------------------------
@Inject
public void setDeps(Export<MyService> export) {
}


This configuration will create 2 service registrations pointing to the same
object. This does not happen if I either change ".in(Scopes.SINGLETON)" to
".asEagerSingleton()" or remove the injection of the Export-handle.

Note: this attachment is not intended for inclusion in the project.

Sometimes is necessary to stop watching a service registry. This could be 
accomplished via an "unwatch" method.

In the last piece of code in the user guide AbstractScope<Id> should in
fact be AbstractScope<StockQuote> right? Also all other appearances of Id
the body must be replaced by StockQuote.

Current ideas:

"sticky" service decorator that lazily looks-up a service and, once a valid
instance is found, always returns the same service from that point onwards.

"leased" service decorator that behaves like the "sticky" decorator, except
that it releases the service instance at a set time after it was last used.

any other thoughts?

We currently use ASM to generate bytecode that wraps around the Import<T>
abstraction. The bytecode glue is fairly trivial so it may not be too much
work to write a version that uses Dalvik opcodes instead.

Then we could use Guice (with no AOP) + OSGi + peaberry on Android...

The ImportManager thread started from within the peaberry bundle Activator 
tosses a ServuceUnavailableException when the bundle is restarted. You can 
reproduce this almost always if you restart the activator 2-3 times in 
fast succession.

I think the the sequence that causes this is:

1) zombie.interrupt() is called.
2) the thread manages to snatch a CachingServiceRegistry instance out of 
the Iterable<CachingServiceRegistry)
3) Activator.stop() completes and the BundleContext becomes invalid
4) the thread tries to call CachingServiceRegistry.flush()
5) Tather than complete cleanly it crashes with the attached exception.

I see this a minor/cosmetic problem. However it get's me on edje during 
testing to see a stack trace and have to remember this one is a good 
exception I can ignore.

I fixed this and everything seems to work fine. Because I don't have 
commit access I am attaching the fixed Activator to this issue. I have 
also made some refactorings to make the Activator a bit more Guicy :)

Need to go through and update the tests to cover the new outjection API.

The current release of Newton/Infiniflow re-directs service requests to
remote sources by looking for a certain string in the LDAP service filter.
Users of Newton/Infiniflow therefore need the ability to add this string
(where required) to the LDAP filter passed to the OSGi service registry.

  http://newton.codecauldron.org/site/index.html
  http://www.paremus.com/products/products.html

Now peaberry supports generic filtering (not just LDAP) by registering a
shared listener with the OSGi service registry that only filters on the
type - the returned services are subsequently filtered not in the OSGi
service registry, but in peaberry by using the given AttributeFilter.

While this gives users great flexibility by not tying them to LDAP, it does
make it impossible to add the string needed to identify a remote service
request.

This issue will describe a general-purpose solution that allows more
control over the filter string passed to the OSGi service registry, without
impacting the public API.

Question : 
If I don't use "direct()", does it mean I can use bindInterceptor() from
Guice to add method interceptions to services coming from an OSGi bundle?

Answer:
Unfortunately it looks like Guice only applies method interception to
instances it creates itself, whereas service instances have already been
created elsewhere (not necessarily by Guice).

You can apply decoration to injected services by using "decoratedBy()"
which may suit your needs, although this doesn't have native support for
the AOPAlliance MethodInterceptor API.

Instead it uses the local ImportDecorator API, which is a better fit to
imported services and provides better performance. However it should be
possible to use something like CGLIB to decorate services using the
ImportDecorator.

The need is: to support AOP style interception of imported services using
CGLIB / JDK proxies, etc.

Currently peaberry has a policy to collect only the direct interfaces of 
an exported object rather than traverse the hierarcy and collect all 
interfaces. This mixes bad with AOP for the following reason:

When I bind an Interceptor guice uses BCEL to replace the instance of the 
original class with an instance of a generated class that extends the 
original. So when an interceptor is present what is exported is an 
instance of a subclass, which has no direct interfaces at all - it 
inherits all interfaces from the intercepted class. The effect is that 
peaberry exports the object with an empty list of interfaces and the OSGi 
framework rejects the export.

I.e. adding an interceptor is not transparent: it breaks all current 
intercepted exports and requires me to modify them with explicit lists of 
interfaces under which to export. This I think is a nasty surprise.

I am attaching a simple test case consisting of two bundles. An exporter 
and an importer. The exporter uses an interceptor to log the calls to the 
exported service. The importer calls the service in it's activator. Under 
current peaberry rules this example will not work because I have not 
enumerated the interfaces under which to export. 

I am also attaching a simple patch to the OSGIServiceRegsitry class that 
makes the example work. I simply collect all interfaces from the hierarchy 
rather than only the direct ones.

Subj is not wrong behavior but peaberry must look at another signs.

For example, I have one bean that implements two interfaces. And I want to
export it as two separated services.

I'm doing

MyBean bean = new MyBean();
bind(export(InterfaceA.class)).toProvider(service(bean).export());
bind(export(InterfaceB.class)).toProvider(service(bean).export());

But how I could initialize this bean in @Start @Stop methods? These methods
run only for bean in Singleton scope. I can't put bean into Singleton scope
but it is a singleton.

Also this code does not work for latest 1.2-SNAPSHOT

bind(export(Impl.class)).toProvider(service(Impl.class).export());
bind(Impl.class).in(Scopes.SINGLETON);

[deleted issue]

The peaberry bundle does not export the packages

org.ops4j.peaberry.util.decorators
org.ops4j.peaberry.util.ldap

I am attaching a patch for peaberry.bnd that fixes this.

p.s. I'm sorry for Issue  #15 - i accidentally pressed "enter" while editing.

I hit a rather odd situation:

No matter what the thread that calls a service proxy and causes a SUE the
exception thrown contains a stack trace that describes how the thread that
started my bundle went into the BundleActivator, invoked
Injector.injectMebers(this), created a SUE instance and stored it in a
private static final field in the proxy class. 

In other words the SUE describes the point where the proxy was created -
not the point where it was called. 

This seems evil! Not only I don't know how the execution reached the point
of the service call but I see a completely irrelevant stack trace to
confuse me further.

Looking at org.ops4j.peaberry.internal.ImportGlu I can see that this is all
done completely on purpose. Why? :)

What steps will reproduce the problem?
1. Download examples
2. Set target platform

What is the expected output? What do you see instead?
The examples run. But the Eclipse PDE shows errors in "Locations" in "Target 
definition"

I've attached a target definition which works for me.

Need to cover watching for services, export handles, and attribute filters.

Peaberry activation automatically calls methods marked with @Start / @Stop 
annotations. But this only works for Singletons and not on Exports.
There will be quite useful to handle the start / stop also on Exports where the 
"start" will be called when the Export is published into the registry and 
"stop" 
when the Export is unpublished.

I already have this implemented but I would wait with committing it till we get 
a consensus about.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Currently when no service matches a unary injection point, for example:

   @Inject
   MyService foo;

then accessing foo will throw a NPE - it would be better if the service
proxy provided a Nil object that threw a runtime exception (ie.
ServiceUnavailable) instead.

Nil objects could also be used when services disappear while iterating over
a service registry. For example: hasNext() might be true, but between this
call and the call to next() the service may disappear, in which case we'd
return a Nil object instead of null.

Currently when you watch for service updates you always receive all
matching service events, even when you add the watching scope to a
"single()" service that uses a proxy to delegate to the "best" service.

But as Kai pointed out this is not intuitive, because you'll receive events
about other services coming and going even when the proxy keeps delegating
to the same "best" service. (ie. the other services are not "better")

We can solve this by adding code between the raw watching scope and the
real scope, to mimic the same behaviour as the "single()" service. That is,
you will receive events when the "best" service changes, as expected.

If the manifest attribute "Bundle-Module" value has a space after the module 
name it will result into  
an error that the module class cannot be found. As spaces are hard to see in 
messages this is a 
pretty hard to spot problem.

Solution would be to trim the spaces after reading the manifest attribute.

As a consequence of this discussion

http://groups.google.com/group/guice-osgi/browse_thread/thread/98847d5a8d07441a

I think Peaberry should have better support for binding providers that
delegate to the OSGi service registry. Currently the user can choose from
several overloaded Peaberry.serviceProvider(...) methods.

(1) All of them require a ServiceRegistry instance as parameter. This is a
bit cumbersome specially because Peaberry puts the ServiceRegistry in the
module anyway.

(2) It is not possible to specify a custom filter expression when binding
the provider. From the discussion:

bind(A).annotatedWith(B).to(osgiService(A, "(reliable=true)"); 

The serviceProvider(...) methods always assume that the user specified the
filter in an @Service annotation.

Obviously, some people will prefer the @Service annotation while other will
prefer binding the provider. Both models should be a first class citizen in
Peaberry.

A method like this in the Peaberry class would already help:

public static <T> Provider<T> serviceProvider(
  final Class<T> type, 
  final String filter) {

  return new Provider<T>(){
    @Inject
    private ServiceRegistry registry;

    public T get() {
      return type.cast(
        ServiceProviderFactory.getUnaryProvider(
          null, registry, type, 
          ServiceFilterFactory.getServiceFilter(null, type)).get()
        );
    }
  };
}

This requires to make the ServiceProviderFactory.getUnaryProvider(...)
method public.

Whenever you iterate over a collection of services any proxy instances are
cached in case they're needed in a later iteration. This cache uses a weak
key and a strong value. Unfortunately the value has a strong reference back
to the key via the Import handle, which means the entry won't be collected.

The solution is to use a soft reference for the value, which allows
collection while still providing "cache-while-possible" semantics.

Hello!
I plan to use peaberry to my project. It's maven driven. I notice there is
a peaberry mvn repository -
http://repository.ops4j.org/maven2/org/ops4j/peaberry/. 
However, it still remain the 0.3 version. It seems you no longer update it.
Could you please update the existing mvn repository or put it to maven
default repository?

In BundleTracker, if the activate(bundle) throws an exception, it just log
the exception. Instead, it should call bundle.stop(Bundle.STOP_TRANSIENT)
to stop the bundle so that the framework can set the bundle's state as
RESOLVED rather than ACTIVE.

e.g.

try {
  activate(bundle);
} catch (Exception e) {
  /* Log this somehow */
  e.printStackTrace(); 

  try {
    bundle.stop(Bundle.STOP_TRANSIENT);
  } catch (Exception e1) { }
}

What steps will reproduce the problem?
1. Install peaberry bundle into a container
2. Bundle is resolved but activation fails as aopalliance classes 
are not found.

Expected:
If peaberry requires org.aopalliance.aop interfaces then peaberry bundle 
should state it in bundle metadata e.g. via Import-Package header.  This 
would simplify debugging and configuration of OSGi runtime.

Actually:
aopalliance interfaces are requested via Class.forName and thus this 
dependency can not be discovered by tools. Currently there are no 
references to org.aopalliance.aop package in bundle metadata.

Product version:
guice 1.0 rc1