Re: CommandProcessor session does not show output

[Pierre De Rop]

Hi Alexander,

I don't know how it worked with previous gogo version, but when using a
command processor, if I'm correct then I think you should test if the
execute command has returned a result object and display it.

I adapted your example which seems to work for me:

*import* java.io.FileDescriptor;

*import* java.io.FileInputStream;

*import* java.io.FileOutputStream;


*import* org.apache.felix.dm.annotation.api.Component;

*import* org.apache.felix.dm.annotation.api.Property;

*import* org.apache.felix.dm.annotation.api.ServiceDependency;

*import* org.apache.felix.service.command.CommandProcessor;

*import* org.apache.felix.service.command.CommandSession;

*import* org.apache.felix.service.command.Converter;

*import* org.apache.felix.service.command.Descriptor;


@Component(provides = Object.*class*)

@Property(name = CommandProcessor.*COMMAND_SCOPE*, value = "test")

@Property(name = CommandProcessor.*COMMAND_FUNCTION*, value = { "execute" })

*public* *class* Example {


@ServiceDependency

CommandProcessor _cmdProc;


*public* *void* execute(String cmd) {

CommandSession session = _cmdProc.createSession(*new*
FileInputStream(FileDescriptor.*in*),

*new* FileOutputStream(FileDescriptor.*out*), *new*
FileOutputStream(FileDescriptor.*err*));

*try* {

Object result = session.execute(cmd);

*if* (result != *null*) {

System.*out*.println("displaying result returned by command:");

System.*out*.println(session.format(result, Converter.*INSPECT*));

}

} *catch* (Exception e) {

e.printStackTrace(System.*out*);

}

}


}


so, if you type under gogo shell "test:exec lb", then the session.execute()
method will return an object; in this case, you can (optionally) use the
session.format method in order to convert it and then display the result.

If now you type for example "test:exec dm", then since the dm gogo command
does not return a result (and display the result internally, using
System.out), then the session.execute method will return null, then in this
case nothing special to do ...

hope this helps


regards
/Pierre

On Tue, Oct 19, 2021 at 10:44 AM Alexander Broekhuis 
wrote:

> Hi all,
>
> I am trying to use the GoGo shell's CommandProcessor to execute commands
> via a rest-like interface. Using older versions of the shell, this used to
> work. But after updating to the latest version (runtime 1.1.4) this doesn't
> work anymore.
>
> Strangely enough, the DependencyManager commands do work, but the GoGo
> Commands don't. Looking in the source, the difference I can see is that the
> DM commands use System.out.println, while the GoGo Commands return the
> output in each command method.
>
> Is there something that I am missing?
>
> Creating a trivial example already shows this:
>
> 
> @Component(provides = TestShell.class)
> @Property(name = CommandProcessor.COMMAND_SCOPE, value = "test")
> @Property(name = CommandProcessor.COMMAND_FUNCTION, value = {"execute"})
> public class TestShell {
>
> @ServiceDependency
> private volatile CommandProcessor commandProcessor;
>
> public void execute(String command) throws Exception {
> CommandSession session = commandProcessor.createSession(new
> FileInputStream(FileDescriptor.in), new
> FileOutputStream(FileDescriptor.out), new
> FileOutputStream(FileDescriptor.err));
> session.execute(command);
> session.close();
> }
> }
> 
>
> Thanks in advance!
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>

Re: DependencyManager composition and additional dependencies with annotations

[Pierre De Rop]

Hello Alexander,

When you use DependencyManager service composition, only the top level
component dependencies (and lifecycle callbacks) are propagated to the
composites, which must not be annotated. They only need to define the same
method callback names than the ones specified in the top level MyComponent
(optionally).

So, in your example, if your MyComposition instance needs to get injected
with the MyService , you will need to define the annotation on the top
level  MyComponent (and possibly define an empty method in case the
MyComponent does not care about the MyService). Then just define the same
bind method on the MyComposition class.

Notice that all lifecycle callbacks are also propagated
(like @Start, @Stop), and the Composition @Start methods can also return a
map in order to propagate more service properties.
Please check
https://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/dm-annotations.html#component-composition

I may have to update the documentation, which is not enough specific, I'm
sorry about that.

So, let's take your original example:

@Component
public class MyComponent {

private final MyComposition myComposition = new MyComposition();





*@ServiceDependencyvoid bind(MyService service) {// Empty
method, we don't care, but all composites may then optionally define the
bind(MyService ) method if, they need the MyService}*
@Start
void start() {
System.out.println("MyComponent.start: ");
}

@Composition
Object[] getComposition() {
return new Object[] { this, myComposition };
}
}

and now, the MyComposition:

public class MyComposition {


*void bind(MyService service) {
System.out.println("MyComposition.bindService: " + service);}*
}

if you have another Composite, and if this one does not case about the
MyService, then it can just not define the bind(MyService) method.

Notice that the MyComposition can also define the start lifecycle callback
(which is only annotated on the top level MyComponent):

public class MyComposition {
void bind(MyService service) {
System.out.println("MyComposition.bindService: " + service);
}

void start() {
System.out.println("MyComposition.start: ");
}
}

hope it helps

kind regards
/pierre

On Fri, Jun 25, 2021 at 7:19 AM Alexander Broekhuis 
wrote:

> Hi all,
>
> I am using the DependencyManager (not SCR), and am wondering if with
> composition it is possible to add additional dependencies in the other
> classes of a component?
>
> In my tests this does not work, but perhaps I am missing something?
>
> Eg:
>
> @Component
> class MyComponent {
>
>   MyComposition myComp = new MyComposition(this);
>
>   @Composition
>   getComposition() {
> return new Object() { this, myComp };
>   }
>
>  // ...
> }
>
> class MyComposition {
>
>   // new dependency, not present in MyComponent, this does not seem to work
>   @ServiceDependency(service = MyService.class)
>   void addMyService(MyService service) {
> // ...
>   }
> }
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>

Re: @Component and @AspectService not playing nice

[Pierre De Rop]

Hi Steve,

You are correct. I just checked, and indeed, what you are describing can be
done using the DM api, but it's not supported when using annotations.
As a work around, you can do the following: in your SomeDomainSpecificClass
aspect implementation, you can manually register the aspect service using
a  bundle context, like this:

(I assume the "SomeDomainSpecificClassAspect" is the implementation of your
SomeDomainSpecificClass aspect:

import org.apache.felix.dm.annotation.api.AspectService;
import org.apache.felix.dm.annotation.api.Inject;
import org.apache.felix.dm.annotation.api.Start;
import org.osgi.framework.BundleContext;

@AspectService(ranking = 10, service=SomeDomainSpecificClass.class)
public class SomeDomainSpecificClassAspect implements
SomeDomainSpecificClass, EntitySynchronizer {

@Inject
BundleContext bc;

@Start
void start() {
bc.registerService(EntitySynchronizer.class, this, null);
}

}

Doing so will register the aspect implementation also as an
EntitySynchronizer service.
Would this work around be fine for you ? let me know.

thanks
/pierre


On Thu, Jun 17, 2021 at 2:23 PM Steve Runion 
wrote:

> 
> AspectComponent =
> getDependencyManager().createAspectComponent().setAspect(SomeDomainSpecificClass.class,
> null, 10)
> component.setInterface(EntitySynchronizer.class, properties);
> component
>   .add(getDependencyManager()
> .createServiceDependency()
> .setService(EventMediator.class)
> .setRequired(true))
>   .add(getDependencyManager()
> .createServiceDependency()
> .setService(LogService.class)
> .setRequired(false));
> return component;
>
> For example this is what one of our Activators look like. Our component
> aspects  and also implements EntitySynchronizer. There
> are other services (only a handful AFAIK) that whiteboard in
> EntitySynchronizers and monitor the health of them by that interface.
>
>
> 
> From: Steve Runion 
> Sent: Thursday, June 17, 2021 5:18 AM
> To: users@felix.apache.org 
> Subject: Re: @Component and @AspectService not playing nice
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> Thanks for the responses.
>
> From what I am reading out usage where we have services that are both
> interceptors (aspects) and services (in their own right) that are white
> boarded in is atypical. I could probably work around this by adding service
> properties (or use one of the ones we are already adding to the aspect) to
> get around the need for these to both be aspects and components.
>
> Get Outlook for iOS<
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukefdata=04%7C01%7CSteve.Runion%40myfuelmaster.com%7C6d55595d4a504b74faab08d93170d9f4%7Cdd4cdb5b3a504947bce6dd41ce3544d6%7C1%7C0%7C637595183055109113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=tLgoMcg04W6f6jcTM5GxoOw3uoWPB5ub%2Fm1etBr0AW0%3Dreserved=0
> >
> 
> From: Pierre De Rop 
> Sent: Thursday, June 17, 2021 2:16:43 AM
> To: users@felix.apache.org 
> Subject: Re: @Component and @AspectService not playing nice
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> Hello Steve,
>
> These annotations are part of the Felix DependencyManager (DM) annotaitons.
>
> So, the two annotations can't be mixed.  @AspectService are specialized
> DependencyManager components (like @AdapterService,
> or @BundleAdapterService), and can be used to dynamically define an
> interceptor (or a chain of interceptors) between a service consumer and a
> service provider.
>
> You will define the service consumer and the service provider using
> DM @Components annotations, but you will define the interceptors using
> the @AspectService annotation.
>
> Example: let's say you have a Database service provider interface.
> Something like:
>
> public interface Database {
> String getObject(String key);
> }
>
> The implementation will be defined using @Component annotation:
>
> @Component
> public class DatabaseImpl implements Database {
> public String getObject(String key) { /* implementation */ }
> }
>
> Then if you want to define an aspect that provides a caching for your
> Database service, you will define it like this with only the
> @AspectService:
> (AspectService are like Components, and can use @ServiceDependency
> annotations, if they 

Re: @Component and @AspectService not playing nice

[Pierre De Rop]

Hello Steve,

These annotations are part of the Felix DependencyManager (DM) annotaitons.

So, the two annotations can't be mixed.  @AspectService are specialized
DependencyManager components (like @AdapterService,
or @BundleAdapterService), and can be used to dynamically define an
interceptor (or a chain of interceptors) between a service consumer and a
service provider.

You will define the service consumer and the service provider using
DM @Components annotations, but you will define the interceptors using
the @AspectService annotation.

Example: let's say you have a Database service provider interface.
Something like:

public interface Database {
String getObject(String key);
}

The implementation will be defined using @Component annotation:

@Component
public class DatabaseImpl implements Database {
public String getObject(String key) { /* implementation */ }
}

Then if you want to define an aspect that provides a caching for your
Database service, you will define it like this with only the @AspectService:
(AspectService are like Components, and can use @ServiceDependency
annotations, if they need to depend on something).

@AspectService
public class DatabaseCache implements Database {

 // The service we are intercepting (injected by reflection)
 volatile Database database;

public String getObject(String key) {
// returns keys from our cache, else return database.getObject(key);
}
}

You can chain multiple aspects that will be ordered using the ranking
annotation attribute, like @AspectService(ranking=10). Once the Database
original service is registered, then the DatabaseCache interceptor will be
instantiated, and registered.

The above example corresponds to the following that is using the original
DM API:

public class Activator extends DependencyActivatorBase {
 
 public void init(BundleContext context, DependencyManager dm) throws
Exception {
 Component aspectComponent = createAspectComponent()
 .setAspect(Database.class, null, 10)
 .setImplementation(DatabaseCache.class):
 dm.add(aspectComponent);
 }
}

or  if you are using the DM lambda API:

public class Activator extends DependencyManagerActivator {
public void init(BundleContext ctx, DependencyManager dm) throws
Exception {
aspect(Database.class, aspect ->
aspect.impl(DatabaseCache.class).rank(10));
}
}

Hope this helps.

kind regards
/pierre

On Thu, Jun 17, 2021 at 2:25 AM David Jencks 
wrote:

> I’m used to the DS OSGI spec @Component annotation but I guess you are
> using the DM annotations and not DS?
>
> David Jencks
>
> > On Jun 16, 2021, at 1:57 PM, Steve Runion 
> wrote:
> >
> > My company has used activators for quite some time, instead of
> annotations, due to a perceived inability for the annotations to fit our
> needs.
> >
> > I have cornered the use case that is reported to be the challenge. We
> have services that are both aspects on services by their interfaces and
> also implement another (common) interface which are whiteboarded in
> elsewhere. The plumbing to get that to work would look like…
> >
> > @AspectService(ranking = 10, service = AimEncryptionKeyService.class)
> > @Component(provides = EntitySynchronizer.class)
> >
> > … however it seems as if these two annotations are not intended to be
> used as the same time. Whichever one is first is applied and the second is
> ignored. Is anyone aware of a workaround, or an idiomatic way, to get this
> scenario to work?
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

[ANN] Felix Dependency Manager r16 Released

[Pierre De Rop]

Dear Felix users;

The Felix team is pleased to announce the release of Dependency Manager r16
version.

Release Notes:

** Bug
 * [FELIX-6180] - Component initialization error message get's printed to
sysout instead of logged to LogService

Kind Regards

-The Felix team

Re: Felix DM - Migrating from version 3 to 4

[Pierre De Rop]

Hello Martin,

you can stop your component by removing it from the dependency manager
object.

Here is an example:

public class Activator extends DependencyActivatorBase {
@Override
public void init(BundleContext ctx, DependencyManager dm) throws
Exception {
Component c = createComponent().setImplementation(Example.class);
dm.add(c);
dm.remove(c); // will stop the component
}
}

regards
Pierre

On Wed, Jul 15, 2020 at 9:13 PM Martin Lichtin 
wrote:

> When migrating from DM version 3 to 4, I've code that's using the stop()
> method on the Component interface.
>
>  component.stop();
>
> What would I migrate this to?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Missing plugin.xml in org.apache.felix.dependencymanager.annotations 4.x.x

[Pierre De Rop]

Hello Abhijeet ;

(responding with limited internet access, I will be available next monday)

Since dm annotations 4.0.0 version, there is no more maven plugins, instead
we use a bnd plugin.
Now if you are using maven, you can uses the "_plugin" attribute in order
to activate the dm bnd plugin when using maven.

Please check [1] where you can find a working sample project (see the
dm.hello/hello.annotations/ sub project in the sample)

Notice that the latest dm annotation version is not 4.2.0, but 5.0.1

So, your example in your previous mail should be changed like for example
this (replace 5.0.1 by 4.2.0 if you really need to use the old 4.2.0
version):

http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
  4.0.0
  bundle
  YOUR.GROUP.ID
  YOUR.ARTIFACT.ID
  YOUR.ARTIFACT.VERSION

  

  org.apache.felix
  org.apache.felix.dependencymanager.annotation
  5.0.1

  

  

  
org.apache.maven.plugins
maven-compiler-plugin

  1.8
  1.8

  

  
org.apache.felix
maven-bundle-plugin
4.1.0
true

  
YOUR BSN
YOUR.PRIVATE_PACKAGE
YOUR.EXPORTED_PACKAGE

<_plugin>org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin;add-require-capability=true
  


  
org.apache.felix

org.apache.felix.dependencymanager.annotation
5.0.1
  

  

  


the doc for dm annotations can be found from [2]

hope this helps;
Pierre

[1]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/tutorials/sample-code.html
[2]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/dm-annotations.html

On Sat, Mar 9, 2019 at 3:18 PM Abhijeet Banerjee 
wrote:

> Greetings,
> Trying to upgrade my DM.annotations 3PP from 3.2.0 to latest, but getting
> below error,
>
> [ERROR] Failed to parse plugin descriptor for
> org.apache.felix:org.apache.felix.dependencymanager.annotation:4.2.0
>
>
> (/Users/grg2fr/dev/.m2/org/apache/felix/org.apache.felix.dependencymanager.annotation/4.2.0/org.apache.felix.dependencymanager.annotation-4.2.0.jar):
> No plugin descriptor found at META-INF/maven/plugin.xml -> [Help 1]
>
> I checked the available versions of the
> org.apache.felix:org.apache.felix.dependencymanager.annotation bundle and
> noticed, that indeed, the plugin.xml was present up until version 3.2.0 and
> disappeared beginning with version 4.0.1
>
> In google, I find the same issue mentioned by a user
>
> https://stackoverflow.com/questions/42340154/missing-plugin-xml-in-org-apache-felix-dependencymanager-annotations-4-x-x
>
> As per resolution, They asked to go as per mentioned link but didn't get
> the doc very much
>
> http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/tutorials/working-with-annotations.html
>
> *I have below plugin in pom.xml, Please help me what exactly I need to
> fix/modify *
> *
>  *
> *
>  *
> *
>   *
> *org.apache.felix
>  *
> *maven-bundle-plugin  *
> *2.4.0*
> *
>  *
> *
>   *
> *org.apache.felix*
> *
> org.apache.felix.dependencymanager.annotation*
> *4.2.0
>   *
> *
>   *
> *
>  *
> *
>  *
> *scan
>  *
> *
>   *
> *
>  *
> *info
>  *
> *
>   *
> *
>   *
> *
>  *
> *
>  *
> *
>   *
> **
>
>
> --
>
> *Thanks\*
> *Abhijeet Banerjee+919910512611*
>

[ANN] Felix Dependency Manager R15 Released

[Pierre De Rop]

Dear Felix users;

The Felix team is pleased to announce the release of Dependency Manager R15
version.

Release Notes:

* [FELIX-5996] - Remove generic parameter in DM Component interface

Enjoy!

-The Felix team

[ANN] Felix Dependency Manager R14 Released

[Pierre De Rop]

Dear Felix users;

The Felix team is pleased to announce the release of Dependency Manager R14
version.

Release Notes:

** Bug
* [FELIX-5990] - DM ServiceTracker memory leak
** Wish
* [FELIX-5991] - DM annotation scanner debug messages are logged in warn
** Task
* [FELIX-5992] - Do not use a global changelog for all dm modules

Enjoy!

-The Felix team

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

[ANN] Felix Dependency Manager R13 Released

[Pierre De Rop]

Dear Felix users;

The Felix team is pleased to announce the release of Dependency Manager R13
version. You will find a quick summary of the changes here:

http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew-r13.html

This release is available from http://felix.apache.org/downloads.cgi

Release Notes:

** Bug
* [FELIX-5683] - getServiceProperties returns null instead of empty
dictionary
* [FELIX-5716] - Dead Lock in DM
* [FELIX-5768] - DM Lambda stop callback not being called
* [FELIX-5955] - Move changelog.txt to toplevel project dir
* [FELIX-5956] - NPE when invoking a lifecycle runnable method from
init method

** New Feature
* [FELIX-5336] - Add support for prototype scope services in DM4

** Improvement
* [FELIX-5967] - DM does not support java9+
* [FELIX-5937] - Refactor DM bndtools/gradle project
* [FELIX-5939] - DM annotations enhancements
* [FELIX-5941] - DM APi enhancements
* [FELIX-5957] - Check if a default implementation is used only on
optional dependencies

** Task
* [FELIX-5960] - Do not supply MD5 checksum

 List of bundles being part of the release:
* org.apache.felix.dependencymanager; version=4.5.0
* org.apache.felix.dependencymanager.shell; version=4.0.7
* org.apache.felix.dependencymanager.runtime; version=4.0.6
* org.apache.felix.dependencymanager.annotation; version=5.0.0
* org.apache.felix.dependencymanager.lambda; version=1.2.0


Enjoy!

-The Felix team

Re: IPOJO Component is not exposing service properly

[Pierre De Rop]

Hello;

maybe you could try by specifying a location "?" when creating the factory
configuration, something like:

Configuration config =
this.configurationAdmin.createFactoryConfiguration("com.my.osgi.MyComponent",
"?")

regards
Pierre


On Wed, Jul 18, 2018 at 3:50 PM, imranrazakhan 
wrote:

> I tried to use configurationAdmin in my Pax-Exam test class with below code
>
> Configuration config =
> this.configurationAdmin.createFactoryConfiguration("
> com.my.osgi.MyComponent");
> Hashtable props = new Hashtable();
> props.put("myprop", "1");
>
> config.update(props);
>
> Error if following
>
> 2018-07-18T15:42:20,201 | ERROR | CM Event Dispatcher (Fire
> ConfigurationEvent:
> pid=com.my.osgi.MyComponent.59c30147-0aea-412f-ad2b-52decc4482ee) |
> ipojo
> | 22 - org.apache.felix.ipojo - 1.12.1.patch20180226 | [ERROR] iPOJO
> Configuration Admin listener : Cannot use configuration
> pid=com.my.osgi.MyComponent.59c30147-0aea-412f-ad2b-52decc4482ee for
> bundle
> mvn:com.my.osgi/my-component/2.0.5-SNAPSHOT because it belongs to bundle
> local
>
>
>
>
>
> --
> Sent from: http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-
> f4833200.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Dependency Manager - Service does not stop

[Pierre De Rop]

Hello Florian,

I have tried to reproduce the problem, but it seems to work well; I have
committed a sample code which reflects the usecase you are describing here
[1].
Can you please clone it and give it a try (the sample code is built using
bndtools 3.4.0).

To build the sample:

git clone https://github.com/pderop/test.dm.factorypid.git
cd test.dm.factorypid
chmod a+x ./gradlew
./gradlew jar
./gradlew export.launch

the last command generates a ubber jar in
test.dm.factorypid/test/generated/distributions/executable/launch.jar

just run it:

cd test.dm.factorypid/test/generated/distributions/executable
java -jar launch.jar

you will see these logs:

Configurator: creating conf
JavacordConnector.configure: property=value
JavacordConnector.start
NOPCommandRegistry.run

now, from gogo, stop the bundle:

g! lb
START LEVEL 1
  ID|State  |Level|Name
   0|Active |0|System Bundle (5.6.10)|5.6.10
   1|Active |1|test (1.0.0.201807052324)|1.0.0.201807052324
   2|Active |1|Apache Felix Configuration Admin Service
(1.8.8)|1.8.8
   3|Active |1|Apache Felix Dependency Manager (4.4.1)|4.4.1
   4|Active |1|Apache Felix Gogo Command (1.0.2)|1.0.2
   5|Active |1|Apache Felix Gogo Runtime (1.0.10)|1.0.10
   6|Active |1|Apache Felix Gogo Shell (1.0.0)|1.0.0
   7|Active |1|Apache Felix Metatype Service (1.1.2)|1.1.2

stop 1

and you will see this logs:

JavacordConnector.stop

so, I wonder why you are overriding the init/start/stop/destroy callbacks
using :

   setCallbacks(null, "connect", "disconnect", null);

This method is only used when you need to override the lifecycle
init/start/stop/destroy callbacks.
Maybe your component has "start"/"stop" callbacks, not
"connect"/"disconnect" callbacks ?

let me know if the sample works for you, maybe there is another thing I
have missed ?

regards
Pierre

[1] https://github.com/pderop/test.dm.factorypid

On Thu, Jul 5, 2018 at 6:43 PM, Florian Pattke  wrote:

> Hello,
>
> I am using a FactoryConfigurationAdapterServer and I have problems to
> unregister the services, when I stop the bundle.
>
> Here is my activator code:
>
> public void init(BundleContext bundleContext, DependencyManager
> dependencyManager) throws Exception {
> dependencyManager.add(
> createFactoryConfigurationAdapterService(
> JavacordConnector.SERVICE_PID,
> "configure",
> true,
> JavacordConnectorConfiguration.class
> )
> .setImplementation(JavacordConnector.class)
> .setCallbacks(null, "connect", "disconnect", null)
> .add(
> createServiceDependency()
> .setService(CommandRegistry.class)
> .setRequired(false)
> .setDefaultImplementation(NOPCommandRegistry.class)
> )
> );
> }
>
> Situation:
> - bundle is active
> - factory adapter is registered
> - via config file and ConfigAdmin is a JavacordConnector registered as well
>
> Now when I stop the bundle nothing happens. All services are still
> available, up and running.
> How can achieve that all these services will be stopped, once I stop the
> bundle?
>
> Regards
> Florian
>
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: DM Lambda "stop" not being called

[Pierre De Rop]

Hello Bree;

Sorry for the late response, I was on vacation.

So, your example is definitely correct, but unfortunately, you came across
a bug which I just fixed using the FELIX-5768
 jira issue.
Sorry about this silly problem, I did not see this basic issue because
there were no integration tests for it, but I just added one.

I will make a new release at the end of this week. In the meantime, if you
want, you can download the patch from here:
https://issues.apache.org/jira/secure/attachment/12905001/org.apache.felix.dependencymanager.lambda-1.1.2.jar
(you can also download it from the FELIX-5768
 jira issue).

Please replace the old org.apache.felix.dependencymanager.lambda-1.1.1.jar
bundle with the new 1.1.2 version from the above link, it should now be ok.

thanks & kind regards
Pierre


On Fri, Jan 5, 2018 at 7:38 PM, Bree Van Oss 
wrote:

> Hello,
>
> We’ve encountered an issue with DM Lambda (1.1.1) where a bundle’s stop
> method is not being called when the bundle is stopped. I have a simple
> project and executable jar that contains an example of this issue in two
> bundles, one using the standard DM syntax, where stop is being called as
> expected and a second that uses the new DM Lambda syntax and the Activator
> code is included below. This second bundle (org.syntech.examples.dmlambda)
> does not result in stop being called.
>
> I have to think I’m just missing something obvious, but try as I might, I
> could not get the DM Lambda enabled bundle’s stop method to be called. Any
> help or guidance would be appreciated. We really like the new DM Lambda
> syntax and would like to use it going forward.
>
> Example: simple activator using DM Lambda syntax, which does not call the
> “stop” method as expected. I’ve tried using the default and specifying the
> callbacks explicitly, nothing seems to work.
>
> @Override
> protected void init(BundleContext ctx, DependencyManager dm) throws
> Exception {
> component(comp -> comp.impl(ExampleServiceUsingDmLambda.class)
> .start("start")
> .stop("stop")
> .provides(ExampleServiceUsingDmLambda.class));
> }
>
>
> Following are the bundle versions contained in example JAR.
>
> 
> Welcome to Apache Felix Gogo
>
> g! lb
> START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.6.10)|5.6.10
> 1|Active |1|osgi.core (6.0.0.201403061837)|6.0.0.201403061837
> 2|Active |1|Apache Felix Log Service (1.0.1)|1.0.1
> 3|Active |1|Apache Felix Metatype Service (1.1.6)|1.1.6
> 4|Active |1|Apache Felix Configuration Admin Service
> (1.8.16)|1.8.16
> 5|Active |1|Apache Felix Dependency Manager (4.4.1)|4.4.1
> 6|Active |1|org.apache.felix.dependencymanager.lambda
> (1.1.1)|1.1.1
> 7|Active |1|Apache Felix Gogo Command (1.0.2)|1.0.2
> 8|Active |1|Apache Felix Gogo Runtime (1.0.10)|1.0.10
> 9|Active |1|Apache Felix Gogo Shell (1.0.0)|1.0.0
>10|Active |1|Apache Felix Remote Shell (1.2.0)|1.2.0
>11|Active |1|Apache Felix Dependency Manager Shell (4.0.6)|4.0.6
>12|Active |1|org.syntech.examples.dmlambda (1.0.0)|1.0.0
>13|Active |1|org.syntech.examples.dmstandard (1.0.0)|1.0.0
>
>  Any help or guidance would be appreciated.
>
> I have also posted this to Stackoverflow. https://stackoverflow.com/
> questions/48100733/apache-felix-stop-method-is-not-
> called-when-using-dmlambda
>
> Thanks,
> Bree
>
>

Re: DM r11 Behavior change in Component.getServiceProperties() intentional?

[Pierre De Rop]

Hi Bram,

The NPE from your sample code is caused by a regression made in r9 release.
I have created a FELIX-5683 issue, and committed the corresponding fix,
which avoids the NPE.

But there is another issue, because if I'm correct, since the initial
version of dm (2.0.1), the getServiceProperties() method returns a copy of
the service properties dictionary maintained in the component impl.  So if
you would like to set service properties like the example you provided, it
won't won't work because the "component.getServiceProperties().put("a",
"b")" will set the property in the copy returned by the
getServiceProperties() method.

can you please have a look at
https://issues.apache.org/jira/browse/FELIX-5683, and comment it ?
can you also checkout the trunk and see if the NPE is now fixed ?

thanks and sorry for the regression;

cheers
Pierre

On Thu, Aug 24, 2017 at 9:21 PM, Bram Pouwelse  wrote:

> Hi all,
>
> The behavior of Component.getServiceProperties() changed in the r11
> release. Since this release the getServiceProperties method returns null if
> instead of an emtpy dictionary, this seems to be in-line with the javadoc
> (@return the properties or null if there are none) but it used
> to return the emtpty dictionary in the past.
>
> We have some errors due to this in several of our projects as in the past
> initializing a component with emtpy properties was a nice way to make sure
> that you never got a null from component.getServiceProperties().
>
> If you do something like (simplified)
> Component component = m_dependencyManager
> .createComponent().setInterface(ApplicationService.class.getName(), new
> Properties())
> component.getServiceProperties().put("a", "b");
>
> This now results in an NPE.
>
> Had a quick look at the history and I think the change is due to the fix
> for this FELIX-5636 [1], on github [2].
>
> Long story, I'm mainly wondering if the change in behavior is intentional
> or not.
>
> Regards,
> Bram
>
> [1] https://issues.apache.org/jira/browse/FELIX-5636
> [2]
> https://github.com/apache/felix/commit/cfb4f0daccd8d940b6acc069b7376f
> 2dd9e92395#diff-d4572933aed00f00ea9594c93598d2f2L682
>

[ANN] Felix Dependency Manager R11 Released

[Pierre De Rop]

Dear Felix users;

The Felix team is pleased to announce the release of Dependency Manager R11
version.

This release is available from http://felix.apache.org/downloads.cgi

Release Notes:

** Bug
* [FELIX-5630] - NullObject is created for a required dependency if the
component is removed and added again to the dependency manager
* [FELIX-5636] - Component of aspect service does not have any service
properties anymore
* [FELIX-5657] - DM released sources can't be rebuilt

** Improvement
* [FELIX-5619] - MultiProperyFilterIndex memory consumption
* [FELIX-5623] - Improve performance of ComponentImpl.getName method
* [FELIX-5650] - Support latest version of Gogo
* [FELIX-5653] - Simplify DM-Lambda samples
* [FELIX-5658] - Include poms in dm artifacts

Enjoy!

-The Felix team

[ANN] Apache Felix Dependency Manager r9 Released

[Pierre De Rop]

The Felix team is pleased to announce the release of Apache Felix
Dependency Manager r9.

This release is available from:

http://felix.apache.org/downloads.cgi

Release notes:

** Bug
* [FELIX-5236] - Single @Property annotation on a type doesn't work
* [FELIX-5242] - Configuration updates may be missed when the component
is restarting
* [FELIX-5244] - Can't inject service using a method ref on a parent
class method.
* [FELIX-5245] - Typo in error logged when a component callback is not
found.
* [FELIX-5268] - Service not unregistered while bundle is starting
* [FELIX-5273] - Wrong log when a callback is not found from component
instance(s)
* [FELIX-5274] - remove callback fails after manually removing dynamic
dependencies
* [FELIX-5399] - Unable to define default map or list config types
* [FELIX-5400] - Can't override default configuration type list value
using an empty list
* [FELIX-5401] - Can't override default configuration type map value
using an empty map
* [FELIX-5402] - Factory configuration adapter ignores factory method
* [FELIX-5411] - When you stop a component, the service references are
not ungotten.
* [FELIX-5426] - Remove callbacks aren't called for optional
dependencies in a "circular" dependency scenario
* [FELIX-5428] - Dependency events set not cleared when component is
removed
* [FELIX-5429] - Aspect swap callback sometimes not called on optional
dependencies
* [FELIX-5469] - Methodcache system size property is not used
* [FELIX-5471] - Ensure that unbound services are always handled
synchronously
* [FELIX-5517] - @Inject annotation ignored when applied on
ServiceRegistration
* [FELIX-5519] - services are not ungotten when swapped by an aspect
* [FELIX-5523] - required dependencies added to a started adapter (or
aspect) are not injected

** Improvement
* [FELIX-5228] - Upgrade DM With latest release of BndTools
* [FELIX-5237] - Configurable invocation handler should use default
method values
* [FELIX-5346] - Start annotation not propagated to sub classes
* [FELIX-5355] - Allow to use properties having dots with configuration
proxies
* [FELIX-5403] - Improve the Javadoc for
org.apache.felix.dm.ComponentStateListener
* [FELIX-5405] - Do not have org.apache.felix.dm.Logger invoke
toString() of message parameters when enabled log level is not high enough
* [FELIX-5406] - DM lambda fluent service properties don't support dots
* [FELIX-5407] - DM annotation plugin generates temp log files even if
logging is disabled
* [FELIX-5408] - Parallel DM should not stop components asynchronously
* [FELIX-5467] - MultiPropertyFilterIndex is unusable when a service
reference contains a lot of values for one key
* [FELIX-5499] - Remove usage of json.org from dependency manager
* [FELIX-5515] - Upgrade DM to OSGi R6 API
* [FELIX-5516] - Allow to not dereference services internally
* [FELIX-5518] - Remove all eclipse warnings in DM code
* [FELIX-5520] - ComponentStateListener not supported in DM lambda
* [FELIX-5521] - add more callback method signature in DM lambda
service dependency callbacks
* [FELIX-5522] - Refactor aspect service implementation
* [FELIX-5524] - add more signatures for aspect swap callbacks
* [FELIX-5526] - Allow to use generic custom DM dependencies when using
dm lambda.
* [FELIX-5531] - Document dependency callback signatures
* [FELIX-5532] - Swap callback is missing in @ServiceDependency
annotation

** Task
* [FELIX-5533] - Fix a semantic versioning issue when releasing
dependency manager

Enjoy!

-The Felix team

Re: Dependency Manager commands not working after upgrading Servicemix from 5.4.0 to 6.1.2

[Pierre De Rop]

Hi Rod,

FYI, I tried with apache-karaf-4.0.8, then I successfully deployed your
standard-3.0.7-features.xml and could install dm like this:

karaf@root()> feature:repo-add file:../features/standard-3.0.7-features.xml
Adding feature url file:../features/standard-3.0.7-features.xml
karaf@root()> feature:install example-feature
karaf@root()> dm wtf
No missing dependencies found.

Now, I tried to install servicemix 6.1.2 but I could not start start it
(I'm getting the error: "Error: Could not find or load main class
org.apache.karaf.main.Main).


So, I tried to install servicemix 6.1.3, which I could successfully start.
But unfortunately in this version, I don't have the "feature:repo-add"
shell command in order to add your standard-3.0.7-features.xml, so i could
not make the test.

May be you should ask directly to the servicemix mailing list ... (anyway,
it works well with apache-karaf-4.0.8)

hope this helps
/Pierre



On Tue, Jan 10, 2017 at 3:07 PM, Rod Allen <rodallen1...@gmail.com> wrote:

> Hi Pierre,
>
> I tried the latest versions you mentioned in both Servicemix 5.4.0 and
> Servicemix 6.1.2. It still worked ok in Servicemix 5.4.0 although I had to
> use JDK 1.8. However it still failed in Servicemix 6.1.2. I was not sure if
> this was more of a Servicemix than Felix question. In order to replicate
> this I hacked an existing features config file for both vanilla
> installations. For Servicemix 5.4.0 it was
>
>
>
>
> *%KARAF_HOME%\system\org\apache\karaf\assemblies\features\standard\2.4.1\standard-2.4.1-features.xml*
> for Servicemix 6.1.2 it was
>
> *%KARAF_HOME%\system\org\apache\karaf\features\standard\3.0.7\standard-3.0.7-features.xml*
>
> this is the closest thing to a replication without actually using our
> custom code (I wanted to keep it simple and use a config as close to the
> originals as possible). I am not sure you will be able to replicate with an
> older Servicemix as I suspect the issue is something specific that was
> changed in 6.1.2 - but I am grateful for you trying on any version. If you
> try it will 5.4.0 and 6.1.2 though you will see the differences in
> behaviour. It could be something basic I am missing or a totally different
> method thats needed. I gather that the Felix framework was downgraded from 
> 4.4.1
> to 4.2.1  whereas karaf itself was upgraded from 2.4.1 to 3.0.7 so I
> wonder if that has something to do with it? I just tried downgrading the
> Felix versions to this and got a different result in Servicemix 6.1.2 :-
>
> 
> mvn:org.apache.felix/
> org.apache.felix.metatype/1.0.10
> mvn:org.apache.felix/org.apache.felix.
> dependencymanager/3.2.0
> mvn:org.apache.felix/org.apache.felix.
> dependencymanager.shell/3.2.0
> 
>
> karaf@root>list | grep Felix
>  76 | Active |  80 | 1.0.12 | Apache Felix
> Metatype
> Service
>  77 | Active |  80 | 3.0.0  | Apache Felix
> Dependenc
> y Manager
>  78 | Active |  80 | 3.0.0  | Apache Felix
> Dependenc
> y Manager Shell
>  79 | Active |  80 | 1.4.1  | Apache Felix
> Shell Ser
> vice
> karaf@root>dm
> karaf@root>dm wtf
> Error:
> Argument wtf is not a valid number.
>
> thanks again
>
> regards
>
> Rod
>
>
> On 10 January 2017 at 12:00, Pierre De Rop <pierre.de...@gmail.com> wrote:
>
>> Hello Rob,
>>
>> I'm have little knowledge about Karaf, but I would like to reproduce your
>> issue.
>> Do you have somewhere a feature containing the dm declaration that I could
>> try to install ? (I have installed karaf 4.0.8).
>>
>> now I have some questions:
>>
>> - do you have some resolution errors in logs during startup ? (can you
>> provide full logs during startup)
>> - also, are you able to run some other gogo commands (are you only having
>> the issue with the dm shell command) ?
>> Now, can you also try the latest dm version
>> (org.apache.felix.dependencymanager:4.3.0
>> and org.apache.felix.dependencymanager.shell:4.0.4) ?
>>
>> let me know;
>>
>> cheers;
>> /Pierre
>>
>> On Tue, Jan 10, 2017 at 11:29 AM, Rod Allen <rodallen1...@gmail.com>
>> wrote:
>>
>> > Hi All,
>> >
>> > I posted a question on stackoverflow here :-
>> >
>> > http://stackoverflow.com/questions/41551076/dependency-
>> > manager-commands-not-working-after-upgrading-servicemix-from-5-4-0-to
>> >
>> > Wondering if anyone who reads this mailing list can help though? I put
>> the
>> > detail in the post above but 

Re: Dependency Manager commands not working after upgrading Servicemix from 5.4.0 to 6.1.2

[Pierre De Rop]

Hello Rob,

I'm have little knowledge about Karaf, but I would like to reproduce your
issue.
Do you have somewhere a feature containing the dm declaration that I could
try to install ? (I have installed karaf 4.0.8).

now I have some questions:

- do you have some resolution errors in logs during startup ? (can you
provide full logs during startup)
- also, are you able to run some other gogo commands (are you only having
the issue with the dm shell command) ?
Now, can you also try the latest dm version
(org.apache.felix.dependencymanager:4.3.0
and org.apache.felix.dependencymanager.shell:4.0.4) ?

let me know;

cheers;
/Pierre

On Tue, Jan 10, 2017 at 11:29 AM, Rod Allen  wrote:

> Hi All,
>
> I posted a question on stackoverflow here :-
>
> http://stackoverflow.com/questions/41551076/dependency-
> manager-commands-not-working-after-upgrading-servicemix-from-5-4-0-to
>
> Wondering if anyone who reads this mailing list can help though? I put the
> detail in the post above but it relates to the dm wtf command 'no longer
> working' when configured in a similar way in Servicemix 6.1.2
>
> the key config section I used for my replication was to add this to a
> features xml file :-
>
> 
>
> mvn:org.apache.felix/org.apache.felix.metatype/1.0.10
>
> mvn:org.apache.felix/org.apache.felix.dependencymanager/3.2.0 bundle>
>
> mvn:org.apache.felix/org.apache.felix.
> dependencymanager.shell/3.2.0
> 
>
> where x.x.x was the version of other features in the same config (I added
> to an existing one to save time). The error I get when typing dm wtf is :-
>
> karaf@root>dm wtf
> Error executing command: Cannot coerce dm(String) to any of
> [(CommandSession, boolean, String, boolean, boolean, boolean, String,
> String, String, String)]
>
> The error in the log has this
> 2017-01-09 16:51:29,627 | ERROR | l for user karaf |
> ShellUtil| 27 - org.apache.karaf.shell.console -
> 3.0.7 | Exception caught while executing command
> java.lang.IllegalArgumentException: Cannot coerce dm() to any of
> [(CommandSession, boolean, String, boolean, boolean, boolean, String,
> String, String, String)]
> at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.
> java:178)
> at
> org.apache.felix.gogo.runtime.CommandProxy.execute(
> CommandProxy.java:82)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.
> java:480)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Closure.executeStatement(
> Closure.java:406)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[27:
> org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:
> 182)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:
> 119)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(
> CommandSessionImpl.java:94)
> at
> org.apache.karaf.shell.console.impl.jline.ConsoleImpl.run(ConsoleImpl.
> java:210)
> at
> org.apache.karaf.shell.console.impl.jline.LocalConsoleManager$2$1$1.run(
> LocalConsoleManager.java:109)
> at java.security.AccessController.doPrivileged(Native
> Method)[:1.7.0_79]
> at
> org.apache.karaf.jaas.modules.JaasHelper.doAs(JaasHelper.
> java:57)[28:org.apache.karaf.jaas.modules:3.0.7]
> at
> org.apache.karaf.shell.console.impl.jline.LocalConsoleManager$2$1.run(
> LocalConsoleManager.java:102)[27:org.apache.karaf.shell.console:3.0.7]
> 2017-01-09 16:51:33,179 | ERROR | l for user karaf |
> ShellUtil| 27 - org.apache.karaf.shell.console -
> 3.0.7 | Exception caught while executing command
> java.lang.IllegalArgumentException: Cannot coerce dm(String) to any of
> [(CommandSession, boolean, String, boolean, boolean, boolean, String,
> String, String, String)]
> at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.
> java:178)
> at
> org.apache.felix.gogo.runtime.CommandProxy.execute(
> CommandProxy.java:82)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.
> java:480)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Closure.executeStatement(
> Closure.java:406)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[27:
> org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:
> 182)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:
> 119)[27:org.apache.karaf.shell.console:3.0.7]
> at
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(
> CommandSessionImpl.java:94)
> at
> org.apache.karaf.shell.console.impl.jline.ConsoleImpl.run(ConsoleImpl.
> java:210)
> at
> 

Re: DependencyManager Parallelism and injection callbacks

[Pierre De Rop]

i made an error in my previous mail: so when A depends on M, and M depends
on X, then when you unregister X, the ordering should be the following:

A.remove(M) should first be called while M and X are still active (not
stopped); then M.remove(X) should be called while X is not yet stopped, and
finally X should be stopped.

cheers;
/Pierre


On Fri, Dec 30, 2016 at 4:03 PM, Pierre De Rop <pierre.de...@gmail.com>
wrote:

> Hello Jeroen;
>
> I think you came across a bug, and I committed a testcase for it as well
> as a patch in trunk (I'm sorry about that).
> see FELIX-5471
>
> So, let me clarify what is assumed to happen when you are using DM with a
> threadpool:
>
> So, when using a threadpool, all DM components are getting activated and
> assembled concurrently, but each distinct component is invoked in its
> callbacks serially, like if it was a kind of an actor. May be you know
> hawtdispatch ? DM is using a similar way as hawtdispatch where a dispatch
> queue is internally used to handle external events for a given component.
> All components have its own queue,  and multiple components queues are
> executed in a shared thread pool.
>
> Now, even when components are enabled concurrently, a correct ordering is
> guaranteed, as it happens in normal mode without a threadpool.
> For example, if A depends on C, C.start() is called first, then C is
> registered and injected into A, but asynchronously. So  A.add(C) /
> A.start() callbacks are then called.
> However, if B also depends on C, then A.add(C) and B.add(C) can be called
> in parallel, as well as A.start() // B.start().
>
> But when you unregister a component, that is when using
> "dm.remove(component)"), then I think you reproduced an issue: so, using
> your example: when A depends on M and M depends on X, then the ordering
> should be the following: M.remove(X) should first be called while X is not
> yet stopped, then A.remove(M) should be called while M is not stopped, and
> finally X should be stopped (it should be the same ordering as when no
> threadpool is used).
>
> Can you please update with the latest dm from trunk and confirm that you
> observe now a correct ordering when components are removed ?
> if you do not observe the correct ordering then please update the
> FELIX-5471 issue and I will then re-investigate in case the patch is not
> satisfying.
>
> thanks a lot;
>
> cheers;
> /Pierre
>
>
> On Fri, Dec 30, 2016 at 11:29 AM, Jeroen Daanen <j.daa...@beinformed.com>
> wrote:
>
>> Hello all,
>> I am doing some experiments enabling parallelism in our application which
>> has a lot of services.
>> Now I sometimes encounter a situation where a service that is being
>> removed via the ‘removed' injection callback is no longer a complete
>> service (the service being removed is missing a required dependency):
>> Service A gets remove callback for M; Service M requires service X;
>> Service X is no longer present in M. All services have been started in
>> parallel using the ComponentExecutorFactory with a thread pool.
>> Is my assumption correct that when enabling parallelism this is likely to
>> happen as the order is not fixed what happens earlier: the removal of X
>> from M or the the removal of M from A?
>> Thanks,
>> Jeroen
>
>
>

Re: DependencyManager Parallelism and injection callbacks

[Pierre De Rop]

Hello Jeroen;

I think you came across a bug, and I committed a testcase for it as well as
a patch in trunk (I'm sorry about that).
see FELIX-5471

So, let me clarify what is assumed to happen when you are using DM with a
threadpool:

So, when using a threadpool, all DM components are getting activated and
assembled concurrently, but each distinct component is invoked in its
callbacks serially, like if it was a kind of an actor. May be you know
hawtdispatch ? DM is using a similar way as hawtdispatch where a dispatch
queue is internally used to handle external events for a given component.
All components have its own queue,  and multiple components queues are
executed in a shared thread pool.

Now, even when components are enabled concurrently, a correct ordering is
guaranteed, as it happens in normal mode without a threadpool.
For example, if A depends on C, C.start() is called first, then C is
registered and injected into A, but asynchronously. So  A.add(C) /
A.start() callbacks are then called.
However, if B also depends on C, then A.add(C) and B.add(C) can be called
in parallel, as well as A.start() // B.start().

But when you unregister a component, that is when using
"dm.remove(component)"), then I think you reproduced an issue: so, using
your example: when A depends on M and M depends on X, then the ordering
should be the following: M.remove(X) should first be called while X is not
yet stopped, then A.remove(M) should be called while M is not stopped, and
finally X should be stopped (it should be the same ordering as when no
threadpool is used).

Can you please update with the latest dm from trunk and confirm that you
observe now a correct ordering when components are removed ?
if you do not observe the correct ordering then please update the
FELIX-5471 issue and I will then re-investigate in case the patch is not
satisfying.

thanks a lot;

cheers;
/Pierre


On Fri, Dec 30, 2016 at 11:29 AM, Jeroen Daanen 
wrote:

> Hello all,
> I am doing some experiments enabling parallelism in our application which
> has a lot of services.
> Now I sometimes encounter a situation where a service that is being
> removed via the ‘removed' injection callback is no longer a complete
> service (the service being removed is missing a required dependency):
> Service A gets remove callback for M; Service M requires service X;
> Service X is no longer present in M. All services have been started in
> parallel using the ComponentExecutorFactory with a thread pool.
> Is my assumption correct that when enabling parallelism this is likely to
> happen as the order is not fixed what happens earlier: the removal of X
> from M or the the removal of M from A?
> Thanks,
> Jeroen

Re: Using service interceptors to inject proxies

[Pierre De Rop]

bundles to catch seems very appealing. Take something like mybatis mappers.
> Those are annotated interfaces.  Being able to simply ask osgi for a
> service implementation of such an interface,  with the mybatis bundle
> recognising and catching the interface and returning the mapper would be
> extremely useful.
>
> But what i am trying to do is using the service registry as a pluggable
> proxy factory i guess. It seems to lack that capability:)
>
> On 6 Oct 2016 9:31 p.m., "Raymond Auge" <raymond.a...@liferay.com> wrote:
>
> I think the point of the service registry is not to fool other code into
> working when it really shouldn't. How would you ensure that the
> implementation of such a proxies would be able to fool the clients?
>
> If you could write a proxy generator that could write any proxy such that
> clients simply work I'd like to invest in your tech because I'll be out of
> a job ;)
>
> In fact, I couldn't see any other way to implement proxies as you suggest
> other than to simply block on any call until a real implementation arrives.
> The closest thing I've seen to what you are describing are the blueprint
> proxies which provide service damping, and let me tell you, you don't want
> to go there. At least I would suggest not going there.
>
> I personally think it's far better to expand your code's awareness of the
> dynamics of OSGi services. And there is no, in my humble opinion, more
> concise and simple way to achieve this than by using Declarative Services.
>
> But implementing such an engine (the one which builds your proxied
> services), if at all, certainly lives in the domain of more powerful
> imperative solutions like Felix DM and/or iPojo.
>
> Sincerely,
> - Ray
>
>
> On Thu, Oct 6, 2016 at 3:02 PM, Martin Nielsen <mny...@gmail.com> wrote:
>
> > Hello Pierre and Reymond
> >
> > First of all, thank you very much for taking the time to provide detailed
> > and patient answers.
> >
> > My usecase was to somehow "Cheat" that service registry, so that a bundle
> > getting a service reference (For example via
> > BundleContext.getServiceReferences) would not actually be supplied by a
> > service from the service registry, but rather a proxy i made, which
> fronts
> > the interface in question.
> > So:
> > Bundle A calls
> > BundleContext.getServiceReference(MyAnnotatedInterface.class)  > nothing is registered on this interface at the time of the call>
> > Some interceptor logic (The component i am trying to make) registers that
> > the interface is called and, instead of looking in the serviceregistry,
> > creates a proxy which it returns to BundleA
> > Bundle A happily uses the proxy it got back, completely oblivious to the
> > fact that it never got to the service registry.
> > Bundle A calls
> > BundleContext.ungetService(myAnnotatedInterfaceServiceReference), at
> which
> > point the proxy is told to close and dispose.
> >
> > So the point would be that the client bundle is completely oblivious to
> the
> > "hack", and that the solution works without first having to register any
> > service on the MyAnnotatedInterface interface.
> >
> > From the answers i have seen here, it looks like that usage is not
> > possible, as any calls to getServiceReference requires something already
> be
> > registered on that interface. Correct?
> >
> > In that case, it would seem that i would have to actually register
> > MyAnnotatedInterface as a service, and then hot-swap it from there. DM
> > aspects seems like a good place to start, but i can't quite figure out if
> > you can use it without doing something more in the client than just
> > registering the service?
> >
> > Again, thanks for your help, i you will suffer my ignorance for a wee bit
> > longer :)
> >
> > -Martin
> >
> > On Thu, Oct 6, 2016 at 5:29 PM, Pierre De Rop <pierre.de...@gmail.com>
> > wrote:
> >
> > > Hello Martin,
> > >
> > > If you are interested, I can describe here DM aspects, which is a
> feature
> > > that might be interesting in your case.
> > > DM aspects are kind of (non functional) interceptors at the OSGi
> service
> > > level. DM aspects are real components, they can have a lifecycle,
> > > can be started/stopped at anytime, and they can declare service
> > > dependencies, if they need some.
> > >
> > > Basically, you can programatically (or using annotations) define some
> > > aspect services that will be applied to any relevant original services
> > > matching s

Re: Using service interceptors to inject proxies

[Pierre De Rop]

Hello Martin,

If you are interested, I can describe here DM aspects, which is a feature
that might be interesting in your case.
DM aspects are kind of (non functional) interceptors at the OSGi service
level. DM aspects are real components, they can have a lifecycle,
can be started/stopped at anytime, and they can declare service
dependencies, if they need some.

Basically, you can programatically (or using annotations) define some
aspect services that will be applied to any relevant original services
matching some given service properties. Multiple aspects can be applied to
the same original service and in such case, the aspects are chained using
some ranking order.

Regarding the start ordering, if a client is already bound to a given
original service, then any post-registered aspects will replace the
original service already bound to the client (either the volatile field in
the client pointing to the original service will be updated or a "swap"
callback will be invoked in order to replace the original service with the
new aspects). If you have a start ordering requirement (that is: you need
any client to be injected at the first time with the aspects and not with
the original service), then as Raymond said you will have to arrange to
register the aspects before the original services.

Let's take an example using the dm-lambda library (but the original DM api
or the DM annotations also work):

Assuming you have an original log service with a property "vendor=apache",
and you want to apply a chain of two aspects on that log service (which has
a vendor service property). Let's assume the first aspect is an
"UpperCaseLogService" which rewrites each log message to uppercase, and the
second one: "ErrorLogEventLogService" is an aspect which triggers an OSGi
event (using EventAdmin) in case the log is emitted using an ERROR level.

Then you would declare those two aspects like this:

public class Activator extends DependencyManagerActivator {
public void init(BundleContext ctx, DependencyManager dm) throws
Exception {
// Create the first aspect which is applied to any LogService
having a "service=vendor" service property.
// Notice the "rank(1)" which means this aspect will be the first
in the chain

aspect(LogService.class, aspect -> aspect
.impl(UpperCaseLogService.class)
.filter("(vendor=apache)")
.rank(1));

// Create the second aspect which is applied to any LogService
having a "service=vendor" service property
// Notice that this aspect has a dependency required on an
EventAdmin service
// Also notice the "rank(2)" which means this aspect will be the
second one in the chain

aspect(LogService.class, aspect -> aspect
.impl(ErrorLogEventLogService.class)
.filter("(vendor=apache)")
.rank(2)
.withSvc(EventAdmin.class, true));
   }
}

Now the UpperCaseLogService aspect class, which convert all logs to upper
case:

public class UppercaseLogAspect implements LogService{
private volatile LogService logService; // injected, possibly the
original LogService, or the next aspect in the chain

void start() {
// optional lifecycle start callback: our aspect is starting
}

void stop() {
// optional lifecycle stop callback: our aspect is stopping
}

public void log(int level, String message) {
logService.log(level, message.toUpperCase());
...
}
}

And the ErrorLogEventLogService aspect, which is injected with the original
LogService , as well as with
the EventAdmin service: it will trigger an event in case the log level is
LOG_ERROR:

public class UppercaseLogAspect implements LogService{
private volatile LogService logService; // injected, possibly the
original LogService, or the next aspect in the chain
private volatile EventAdmin eventAdmin; // injected, used to trigger an
event when the logged message level is in error

void start() {
// optional lifecycle start callback: our aspect is starting
}

public void log(int level, String message) {
if (level == LogService.LOG_ERROR) {
// fire an event using the EventAdmin service injected in this
class
}
logService.log(level, message.toUpperCase());
}
}

So, now, if a client is already injected with a log service, then it will
be swapped at the time the aspect chain is registered.
The aspect chain will be injected automatically in the volatile field which
points to the original service, or you can define a swap callback.

let's take an example, using a volatile field:

first the client:

class Client {
   volatile LogService logService; // the original LogService, or the
aspect chain

   void doLog() {
 logService.log(...);
   }
}

and the corresponding client activator:

public class ClientActivator extends DependencyManagerActivator {

public void init(BundleContext ctx, DependencyManager dm) 

Re: Help debug ServiceDependency in DM4-R8

[Pierre De Rop]

Thanks Mdu, I will look into it.

cheers;
/pierre

On Mon, Sep 26, 2016 at 10:14 PM, mduduzik  wrote:

> Pierre,
> I created  FELIX-5365 
> issue.
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.
> nabble.com/Help-debug-ServiceDependency-in-DM4-R8-tp5018369p5018604.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Help debug ServiceDependency in DM4-R8

[Pierre De Rop]

Hi Mdu,

Can you please open a change request issue in Jira for the "Dependency
Manager Shell" component ? We'll then investigate if  an improvement could
be done.

Also, can you please describe in jira the issue you had in order to avoid
going to the wrong direction ?

my understanding about the issue you had is:

- you have a bundle b1 with a component X depending on a service Y, which
package is imported from cmpn bundle.
- X is unregistered waiting for Y (version x.y.z)
- but Y is registered from bundle b2, which imports the Y package not from
cmpn but instead from a copy of Y service (version x.y.z) into the
b2 bundle (private).

and you would like "dm wtf" saying something like:

X unregistered from bundle b1, waiting for service Y version x.y.z with
package imported from cmpn;  but found an available Y service with same
version, provided by bundle b2 which imports the Y package from bundle b2.

Please confirm in the jira issue that this is the scenario you faced, and
we'll investigate if something can be done in order to improve the "dm wtf"
command (i don't know for now).

cheers
/Pierre

On Sat, Sep 10, 2016 at 12:18 AM, mduduzik  wrote:

> Pierre,
> Like Ray, you are spot on. See my response post shortly before your
> recommendation.
>
> I think "dm wtf" can be improved to make my silly mistake obvious - or
> provide better hints.
>
> Thanks.
> -Mdu
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.
> nabble.com/Help-debug-ServiceDependency-in-DM4-R8-tp5018369p5018374.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Help debug ServiceDependency in DM4-R8

[Pierre De Rop]

By the way, the doc for the dm shell can be found here:

http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/tutorials/leveraging-the-shell.html

cheers
/Pierre

On Sat, Sep 10, 2016 at 12:10 AM, Pierre De Rop <pierre.de...@gmail.com>
wrote:

> Hi Mdu,
>
> indeed, it might be possible that the service consumer bundle is importing
> the package of the service it consumes from a bundle b1, while the service
> provider bundle is importing the package of the service from another bundle
> b2. in this case, the consumer won't see the service.
>
> can you please provide the following:
>
> 1) the package name of the service the consumer is depending on;
>
> 2) from web console, go to OSGi -> Bundles, then click on the service
> provider bundle, and indicate what is displayed for the "Imported Packages"
> section.
>
> 3) do the same for the service consumer bundle.
>
> then we'll see if both service provider bundle and service consumer bundle
> are importing the service package  from the same place.
>
> now, maybe it could also help to use the dm shell: if not installed, then
> install the dm shell bundle; and type "dm  bundle>", and provide what is displayed.
>
> then type "dm ", and also provide what
> is displayed.
>
> the "dm na" displays all unavailable components, and the "dm wtf" display
> root causes which might block the activation of many components (for
> example, if A depends on B , and B depends on C, and C is unavailable, then
> "dm wtf" will only display "C").
>
> you could also, if possible, provide the Activator code for both service
> consumer and service provider.
> (send it to me by mail, in case you don't want to do that in this mailing
> list ... if possible).
>
> cheers;
> /Pierre
>

Re: Help debug ServiceDependency in DM4-R8

[Pierre De Rop]

Hi Mdu,

indeed, it might be possible that the service consumer bundle is importing
the package of the service it consumes from a bundle b1, while the service
provider bundle is importing the package of the service from another bundle
b2. in this case, the consumer won't see the service.

can you please provide the following:

1) the package name of the service the consumer is depending on;

2) from web console, go to OSGi -> Bundles, then click on the service
provider bundle, and indicate what is displayed for the "Imported Packages"
section.

3) do the same for the service consumer bundle.

then we'll see if both service provider bundle and service consumer bundle
are importing the service package  from the same place.

now, maybe it could also help to use the dm shell: if not installed, then
install the dm shell bundle; and type "dm ", and provide what is displayed.

then type "dm ", and also provide what
is displayed.

the "dm na" displays all unavailable components, and the "dm wtf" display
root causes which might block the activation of many components (for
example, if A depends on B , and B depends on C, and C is unavailable, then
"dm wtf" will only display "C").

you could also, if possible, provide the Activator code for both service
consumer and service provider.
(send it to me by mail, in case you don't want to do that in this mailing
list ... if possible).

cheers;
/Pierre

Re: DM4 service factory/multiple service instance support

[Pierre De Rop]

Hi Mdu,

You're welcome; I have created the jira issue in [1] in order to start
investigating if DM4 API could be easily improved in order to support OSGi
scope services. I will start working on this soon.

[1] https://issues.apache.org/jira/browse/FELIX-5336

cheers;
/Pierre

On Thu, Aug 25, 2016 at 8:08 PM, mduduzik  wrote:

> Really cool. I missed following the link to the new project DM sub-project
> you just created. I'll follow that closely.
> -Mdu
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.
> nabble.com/DM4-service-factory-multiple-service-instance-support-
> tp5018226p5018254.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: DM4 service factory/multiple service instance support

[Pierre De Rop]

Hi Mdu

if all consumers are in separated bundles, then you can simply arrange your
service provider to implement the org.osgi.framework.ServiceFactory
interface. Hence, all consumers will be injected with a private copy of the
service provider service.

if, now you have multiple consumer components from the same bundle, and you
want each one depending on a private copy of a given service provider, then
DM4 does not directly support this.

In this case, one work around is possible and as Raymond said, you can use
prototype scopes.
However it won't be fully transparent, because the Provider has to
implement the PrototypeServiceFactory interface, and the Consumer then must
use BundleContext.getServiceObjects in order to get its own copy of the
provider dependency.

So, assuming you have a Consumer component which depends on a Provider
service; then you would basically do something like this at the consumer
activator side:

dm.add(createComponent()
  .setImplementation(Consumer.class)
  .add(createServiceDependency().setService(Provider.class).setCallbacks("bind",
null)));

public class Consumer {
  volatile BundleContext ctx;
volatile Provider provider; // an instance copy

void bind(ServiceReference ref) {
ServiceObjects providers = ctx.getServiceObjects(ref);
provider = providers.getService();
}
}

There is now some ways to encapsulates the usage of ServiceObjects in a
separate helper class.
You will find an example in [1], where a "PrototypeCB" helper class is used
to proxy the injection of the Provider into the Consumer:
when the Provider is injected into the PrototypeCB proxy, then the proxy
uses the getServiceObjects API to get an instance copy, which is
then injected in the real Consumer implementation class, using a java8
method reference.

The Consumer then becomes:

public class Consumer { void bind(Provider provider) { } }

and the Consumer Activator is then using the PrototypeCB as a proxy
callback, like this:

import static prototype.consumer.PrototypeCB.prototype;

public void init(BundleContext bc, DependencyManager dm) throws Exception {
dm.add(createComponent()
 .setImplementation(Consumer.class)
 
.add(createServiceDependency().setService(Provider.class).setCallbacks(prototype(bc,
Consumer::bind), "bind", null)));

You can take a look at the PrototypeCB from [1], in the consumer bundle.
So, in the code above, the prototype() helper function returns a
PrototypeCB helper proxy object, where the Provider dependency will be
injected first (in PrototypeCB.bind method).
Then the proxy will get an instance copy of the Provider and will inject
the copy in the Consumer::bind method reference.

Now, if you really need DM4 to internally support prototype scopes, like
DS, then please open a JIRA issue, and I will start working on it.


[1] https://github.com/pderop/dm.psf

hope this helps;

cheers;
/Pierre



On Thu, Aug 25, 2016 at 7:18 AM, David Jencks <
david_jen...@yahoo.com.invalid> wrote:

> I’d be really amazed if this worked.  I imagine that DM is quite similar
> to DS, and you definitely can’t do that in DS, you have to use the scope
> rather than trying to write your own serviceFactory or
> PrototypeServiceFactory.  If your service is e.g. ServiceFactory that’s
> what you’ll get when you look up the service, not the service it’s a
> factory for.  DS already registers a ServiceFactory for each component.
>
> Hopefully someone who actually knows something about DM will speak up soon
> :-)
>
> david jencks
>
> > On Aug 24, 2016, at 5:54 PM, Raymond Auge 
> wrote:
> >
> > I'm fairly certain that DM supports publishing services of any type and
> > doesn't care about scoping, including implementations of
> > PrototypeServiceFactory.
> >
> > Mdu, your service simply needs to implement PrototypeServiceFactory and
> you
> > should be able to use the DM's imperative API as usual.
> >
> > But any other DM experts may correct me if this is wrong.
> >
> > - Ray
> >
> > On Wed, Aug 24, 2016 at 3:13 PM, mduduzik 
> wrote:
> >
> >> Ray/David,
> >> Thanks for your prompt responses. I would like to accomplish this using
> >> API/Activator approach in DM4 (Felix Dependency Manager 4). Here's the
> >> context within which I would like to do this:
> >>
> >> public class Activator extends DependencyActivatorBase {
> >>@Override
> >>public void init(BundleContext ctx, DependencyManager dm) throws
> >> Exception
> >> {
> >>}
> >> }
> >>
> >> So in other words, a non-Annotation based approach. I hope my request is
> >> clearer.
> >>
> >> Regards.
> >> -Mdu
> >>
> >>
> >>
> >> --
> >> View this message in context: http://apache-felix.18485.x6.
> >> nabble.com/DM4-service-factory-multiple-service-instance-support-
> >> tp5018226p5018230.html
> >> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
> >>
> >> -
> >> To unsubscribe, e-mail: 

Re: DM: Callback "onRemove" callback not found on componnent instances []

[Pierre De Rop]

Hi Bram,

Yes, it seems that you can remove the onRemove callback.
I will work on the issue you have created soon.

cheers;
/Pierre

On Thu, Jun 2, 2016 at 7:53 AM, Bram Pouwelse <b...@pouwelse.com> wrote:

> Hi Pierre,
>
> Thanks! removing the destroy callback resolves the issue. And nice to learn
> that you don't have to remove these dependencies manually anymore :)
>
> One more thought ... I think the onRemoved callback is also not really
> useful in this case as it's only cleaning up the WinkServlet instance but
> once onRemoved is called this instance will never be re-used so cleaning
> would not be needed here?
>
> I've created FELIX-5274 for this.
>
> Regards,
> Bram
>
> On Wed, Jun 1, 2016 at 9:57 PM Pierre De Rop <pierre.de...@gmail.com>
> wrote:
>
> > I now see the warnings while running the org.amdatu.web.rest.itest
> project
> > !
> >
> > ok, Bram, I took a look at the WinkServlet, and I see that from
> > the WinkServlet.dmInit() method, a dependency is dynamically added:
> >
> > protected void dmInit() {
> > ServiceDependency dep =
> > m_component.getDependencyManager().createServiceDependency()
> > .setService(JaxRsRequestInterceptor.class)
> > .setRequired(false)
> > .setCallbacks(m_requestInterceptorHandler,
> > "addedInterceptor", "removedInterceptor");
> >
> > m_component.add(dep);
> > m_requestInterceptorDependency = dep;
> > }
> >
> > This is perfectly OK.
> >
> > now, from the dmDestroy() method, I see that the dynamic dependency is
> then
> > removed:
> >
> > protected final void dmDestroy() {
> > if (m_requestInterceptorDependency != null) {
> > m_component.remove(m_requestInterceptorDependency);
> > m_requestInterceptorDependency = null;
> > }
> > }
> >
> > But since the improvement made in FELIX-5054 (see [1]), it is not needed
> > anymore to cleanup "instance bound" dependencies from the destroy method,
> > because DM does this automatically for you.
> >
> > Now, I tried to comment the dmDestroy method, and it seems to work
> > seamlessly (no more warnings displayed):
> >
> > protected final void dmDestroy() {
> > //if (m_requestInterceptorDependency != null) {
> > //m_component.remove(m_requestInterceptorDependency);
> > //m_requestInterceptorDependency = null;
> > //}
> > }
> >
> > Can you confirm that it also works in your environment ?
> >
> > However, even if it's ok now, of course, if you still remove the dynamic
> > dependency from the destroy method (it is your initial case), then it
> > should still work seamlessly without any warnings displayed, so it seems
> > that you came across a bug which happens when you remove the dynamic
> > dependency from the destroy callback.
> >
> > Can you please open a JIRA issue, I will investigate it asap. In the
> > meantime, I think you can just remove the dmDestroy callback, which is
> not
> > necessary anymore since the FELIX-5054 fix.
> >
> > many thanks;
> >
> > [1] https://issues.apache.org/jira/browse/FELIX-5054
> >
> > cheers
> > /Pierre
> >
> > On Wed, Jun 1, 2016 at 7:34 PM, Bram Pouwelse <b...@pouwelse.com> wrote:
> >
> > > Hi Pierre,
> > >
> > > Just built dm from trunk but I get the same log message :(
> > >
> > > You can checkout the branch (feature/AMDATUWEB-59) and run the itests
> > > from org.amdatu.web.rest.itest
> > > project. I've added some sysouts in the callback methods log (appended
> at
> > > the end of the message) ... so it's only the onRemove callback that
> > fails.
> > >
> > > Regards,
> > > Bram
> > >
> > > onAdd
> > > init
> > > onChange
> > > onAdd
> > > init
> > > onAdd
> > > init
> > > destroy
> > > [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not
> > > found on component instances []
> > > onChange
> > > onAdd
> > > init
> > > onAdd
> > > init
> > > onAdd
> > > init
> > > destroy
> > > [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not
> > > found on component instances []
> > > destroy
> > > [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callba

Re: DM: Callback "onRemove" callback not found on componnent instances []

[Pierre De Rop]

I now see the warnings while running the org.amdatu.web.rest.itest project !

ok, Bram, I took a look at the WinkServlet, and I see that from
the WinkServlet.dmInit() method, a dependency is dynamically added:

protected void dmInit() {
ServiceDependency dep =
m_component.getDependencyManager().createServiceDependency()
.setService(JaxRsRequestInterceptor.class)
.setRequired(false)
.setCallbacks(m_requestInterceptorHandler,
"addedInterceptor", "removedInterceptor");

m_component.add(dep);
m_requestInterceptorDependency = dep;
}

This is perfectly OK.

now, from the dmDestroy() method, I see that the dynamic dependency is then
removed:

protected final void dmDestroy() {
if (m_requestInterceptorDependency != null) {
m_component.remove(m_requestInterceptorDependency);
m_requestInterceptorDependency = null;
}
}

But since the improvement made in FELIX-5054 (see [1]), it is not needed
anymore to cleanup "instance bound" dependencies from the destroy method,
because DM does this automatically for you.

Now, I tried to comment the dmDestroy method, and it seems to work
seamlessly (no more warnings displayed):

protected final void dmDestroy() {
//if (m_requestInterceptorDependency != null) {
//m_component.remove(m_requestInterceptorDependency);
//m_requestInterceptorDependency = null;
//}
}

Can you confirm that it also works in your environment ?

However, even if it's ok now, of course, if you still remove the dynamic
dependency from the destroy method (it is your initial case), then it
should still work seamlessly without any warnings displayed, so it seems
that you came across a bug which happens when you remove the dynamic
dependency from the destroy callback.

Can you please open a JIRA issue, I will investigate it asap. In the
meantime, I think you can just remove the dmDestroy callback, which is not
necessary anymore since the FELIX-5054 fix.

many thanks;

[1] https://issues.apache.org/jira/browse/FELIX-5054

cheers
/Pierre

On Wed, Jun 1, 2016 at 7:34 PM, Bram Pouwelse <b...@pouwelse.com> wrote:

> Hi Pierre,
>
> Just built dm from trunk but I get the same log message :(
>
> You can checkout the branch (feature/AMDATUWEB-59) and run the itests
> from org.amdatu.web.rest.itest
> project. I've added some sysouts in the callback methods log (appended at
> the end of the message) ... so it's only the onRemove callback that fails.
>
> Regards,
> Bram
>
> onAdd
> init
> onChange
> onAdd
> init
> onAdd
> init
> destroy
> [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not
> found on component instances []
> onChange
> onAdd
> init
> onAdd
> init
> onAdd
> init
> destroy
> [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not
> found on component instances []
> destroy
> [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not
> found on component instances []
>
>
>
> On Wed, Jun 1, 2016 at 5:43 PM Pierre De Rop <pierre.de...@gmail.com>
> wrote:
>
> > Hello Bram,
> >
> > The "callback not found on component instances ..." log is normally
> > displayed when a callback is not found from some given callback
> > instance(s).
> >
> > However, I just saw that when a callback instance was used (it is the
> case
> > when an adapter is used), then the log was wrong: it did not log the
> actual
> > callback instance.
> >
> > I fixed this in the  revision 1746480.
> > Can you please svn update the dm from the trunk, and try to reproduce,
> and
> > see if the log is more meaningful now ?
> >
> > Then , if you can't figure out what is going one, then can you tell me
> how
> > I can reproduce the problem using amdatu-web ?
> >
> > let me know.
> >
> > cheers;
> > /Pierre
> >
> > On Wed, Jun 1, 2016 at 4:33 PM, Bram Pouwelse <b...@pouwelse.com> wrote:
> >
> > > Hi,
> > >
> > > I have some troubles with a dependency manager adapter service, for
> some
> > > reason it fails to call the remove callback (looking at the message
> there
> > > are no instances available to invoke the method on). Tried to reproduce
> > the
> > > issue in less complex project but I don't have the problem there...
> > >
> > > The component is added in the DependencyActivatorBase#init method full
> > > source is in bitbucket [1]
> > >
> > > manager.add(createAdapterService(ApplicationService.class, null,
> "onAdd",
> > > "onChange&qu

Re: DM: Callback "onRemove" callback not found on componnent instances []

[Pierre De Rop]

Hello Bram,

The "callback not found on component instances ..." log is normally
displayed when a callback is not found from some given callback
instance(s).

However, I just saw that when a callback instance was used (it is the case
when an adapter is used), then the log was wrong: it did not log the actual
callback instance.

I fixed this in the  revision 1746480.
Can you please svn update the dm from the trunk, and try to reproduce, and
see if the log is more meaningful now ?

Then , if you can't figure out what is going one, then can you tell me how
I can reproduce the problem using amdatu-web ?

let me know.

cheers;
/Pierre

On Wed, Jun 1, 2016 at 4:33 PM, Bram Pouwelse  wrote:

> Hi,
>
> I have some troubles with a dependency manager adapter service, for some
> reason it fails to call the remove callback (looking at the message there
> are no instances available to invoke the method on). Tried to reproduce the
> issue in less complex project but I don't have the problem there...
>
> The component is added in the DependencyActivatorBase#init method full
> source is in bitbucket [1]
>
> manager.add(createAdapterService(ApplicationService.class, null, "onAdd",
> "onChange", "onRemove")
>   .setInterface(Servlet.class.getName(), null)
>   .setImplementation(WinkServlet.class)
>   .setCallbacks("dmInit", "dmStart", "dmStop", "dmDestroy")
>   );
>
> Any hints on where to start looking would be welcome ;)
>
> Regards,
> Bram
>
> 1:
>
> https://bitbucket.org/amdatu/amdatu-web/src/74aabd7944c1e2365d2f8313228d69f3278a1d7a/org.amdatu.web.rest/src/org/amdatu/web/rest/wink/Activator.java?at=feature%2FAMDATUWEB-59=file-view-default
>

[ANN] SCR Tooling Bnd Plugin 1.5.0

[Pierre De Rop]

The Felix team is pleased to announce the release of SCR Tooling Bnd
Plugin 1.5.0

This release is available from http://felix.apache.org/site/downloads.cgi


Release Notes:

Changes from 1.4.0 to 1.5.0
---

** Improvement
* [FELIX-5108] - scr bnd plugin: Add option to suppress writing
log to filesystem
** Bug
* [FELIX-5074] - Using org.apache.felix.scr.bnd together with
maven-bundle-plugin leads to using the wrong bnd version


Enjoy!

-The Felix team

Re: DependencyManager: Removing component before bundle is started doesn't work

[Pierre De Rop]

Good to know it works :-)

I just created FELIX-5268 <https://issues.apache.org/jira/browse/FELIX-5268>
which describes the issue, and added a test case.

Thanks for having reported this problem.

cheers
/Pierre


On Thu, May 26, 2016 at 3:55 PM, Bram Pouwelse <b...@pouwelse.com> wrote:

> Pierre,
>
> I've tested with trunk that seems to work for me :) You are quick, fixing
> the issue took you less time than it took me figuring out what was
> happening ..
>
> Thanks!
>
> Bram
>
> On Thu, May 26, 2016 at 3:45 PM Pierre De Rop <pierre.de...@gmail.com>
> wrote:
>
> > Bram,
> >
> > Can you svn update the trunk, and give it a try ?
> >
> > I fixed the following: when a component is being removed, its service was
> > not unregistered if the bundle state was STARTING !
> >
> > Can you confirm it works now with the trunk ? I wait for your
> confirmation,
> > then I will make a jira issue and the corresponding test case, but
> probably
> > tomorrow.
> >
> > thanks !
> >
> > /pierre
> >
> > On Thu, May 26, 2016 at 9:09 AM, Bram Pouwelse <b...@pouwelse.com>
> wrote:
> >
> > > Thanks!
> > >
> > > Maybe good to mention that I have a workaround for the issue, by
> adding a
> > > bundle dependency [1] to the component that creates and removes these
> > > services everything works ok.
> > >
> > > Regards,
> > > Bram
> > >
> > > 1: createBundleDependency().setBundle(context
> > > .getBundle()).setStateMask(Bundle.ACTIVE).setRequired(true)
> > >
> > > On Thu, May 26, 2016 at 9:05 AM Pierre De Rop <pierre.de...@gmail.com>
> > > wrote:
> > >
> > > > ok Bram; I will try to reproduce this issue with a test case. (I'm
> off
> > > this
> > > > morning, will do it this afternoon).
> > > >
> > > > cheers;
> > > > /Pierre
> > > >
> > > > On Thu, May 26, 2016 at 8:58 AM, Bram Pouwelse <b...@pouwelse.com>
> > > wrote:
> > > >
> > > > > I use an Activator and create a component with service
> dependencies,
> > > when
> > > > > services are added / removed the component will add / remove
> > additional
> > > > > components. This all works but if a component is removed before the
> > > > > BundleActivator#start method has completed the service will stick
> > > around
> > > > in
> > > > > the service registry.
> > > > >
> > > > > Regards,
> > > > > Bram
> > > > >
> > > > > On Thu, May 26, 2016 at 8:51 AM Pierre De Rop <
> > pierre.de...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > but the Activator is invoked only when the bundle is started. I'm
> > not
> > > > > sure
> > > > > > I understand ?
> > > > > > Are you invoking the Activator.init method from another bundle,
> > like
> > > an
> > > > > > extender bundle which would track all install/resolve bundles and
> > > would
> > > > > > instantiate an Activator from a not started bundle and invoke it
> ?
> > > > > >
> > > > > > thanks;
> > > > > > /Pierre
> > > > > >
> > > > > > On Thu, May 26, 2016 at 8:46 AM, Bram Pouwelse <
> b...@pouwelse.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi Pierre,
> > > > > > >
> > > > > > > Thanks for the quick reply. I should've been a bit more clear
> in
> > my
> > > > > > > message, the problem is when you remove a component before the
> > > bundle
> > > > > is
> > > > > > > started (that's why I used the Activator to demonstrate the
> > issue).
> > > > > Once
> > > > > > > the test you've created runs the bundle is already started and
> > all
> > > > > works
> > > > > > as
> > > > > > > expected.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Bram
> > > > > > >
> > > > > > > On Thu, May 26, 2016 at 8:15 AM Pierre De Rop <
> > > > pierre.de...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > >

Re: DependencyManager: Removing component before bundle is started doesn't work

[Pierre De Rop]

Bram,

Can you svn update the trunk, and give it a try ?

I fixed the following: when a component is being removed, its service was
not unregistered if the bundle state was STARTING !

Can you confirm it works now with the trunk ? I wait for your confirmation,
then I will make a jira issue and the corresponding test case, but probably
tomorrow.

thanks !

/pierre

On Thu, May 26, 2016 at 9:09 AM, Bram Pouwelse <b...@pouwelse.com> wrote:

> Thanks!
>
> Maybe good to mention that I have a workaround for the issue, by adding a
> bundle dependency [1] to the component that creates and removes these
> services everything works ok.
>
> Regards,
> Bram
>
> 1: createBundleDependency().setBundle(context
> .getBundle()).setStateMask(Bundle.ACTIVE).setRequired(true)
>
> On Thu, May 26, 2016 at 9:05 AM Pierre De Rop <pierre.de...@gmail.com>
> wrote:
>
> > ok Bram; I will try to reproduce this issue with a test case. (I'm off
> this
> > morning, will do it this afternoon).
> >
> > cheers;
> > /Pierre
> >
> > On Thu, May 26, 2016 at 8:58 AM, Bram Pouwelse <b...@pouwelse.com>
> wrote:
> >
> > > I use an Activator and create a component with service dependencies,
> when
> > > services are added / removed the component will add / remove additional
> > > components. This all works but if a component is removed before the
> > > BundleActivator#start method has completed the service will stick
> around
> > in
> > > the service registry.
> > >
> > > Regards,
> > > Bram
> > >
> > > On Thu, May 26, 2016 at 8:51 AM Pierre De Rop <pierre.de...@gmail.com>
> > > wrote:
> > >
> > > > but the Activator is invoked only when the bundle is started. I'm not
> > > sure
> > > > I understand ?
> > > > Are you invoking the Activator.init method from another bundle, like
> an
> > > > extender bundle which would track all install/resolve bundles and
> would
> > > > instantiate an Activator from a not started bundle and invoke it ?
> > > >
> > > > thanks;
> > > > /Pierre
> > > >
> > > > On Thu, May 26, 2016 at 8:46 AM, Bram Pouwelse <b...@pouwelse.com>
> > > wrote:
> > > >
> > > > > Hi Pierre,
> > > > >
> > > > > Thanks for the quick reply. I should've been a bit more clear in my
> > > > > message, the problem is when you remove a component before the
> bundle
> > > is
> > > > > started (that's why I used the Activator to demonstrate the issue).
> > > Once
> > > > > the test you've created runs the bundle is already started and all
> > > works
> > > > as
> > > > > expected.
> > > > >
> > > > > Regards,
> > > > > Bram
> > > > >
> > > > > On Thu, May 26, 2016 at 8:15 AM Pierre De Rop <
> > pierre.de...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Bram,
> > > > > >
> > > > > > The service should be removed from the service registry when you
> > > remove
> > > > > the
> > > > > > Component from DependencyManager.
> > > > > >
> > > > > > Now, I tried to reproduce the issue you are describing in [1],
> but
> > I
> > > > > could
> > > > > > not (the test is OK).
> > > > > > Can you please take a look at it in order to see if it the same
> > kind
> > > of
> > > > > > scenario you have ? Am i missing something ?
> > > > > >
> > > > > > thank you;
> > > > > >
> > > > > > cheers;
> > > > > > /Pierre
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.itest/src/org/apache/felix/dm/itest/api/AddRemoteTest.java
> > > > > >
> > > > > > On Wed, May 25, 2016 at 8:38 PM, Bram Pouwelse <
> b...@pouwelse.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I have an issue with a bundle that removes a DM component
> before
> > > the
> > > > > > bundl

Re: DependencyManager: Removing component before bundle is started doesn't work

[Pierre De Rop]

ok Bram; I will try to reproduce this issue with a test case. (I'm off this
morning, will do it this afternoon).

cheers;
/Pierre

On Thu, May 26, 2016 at 8:58 AM, Bram Pouwelse <b...@pouwelse.com> wrote:

> I use an Activator and create a component with service dependencies, when
> services are added / removed the component will add / remove additional
> components. This all works but if a component is removed before the
> BundleActivator#start method has completed the service will stick around in
> the service registry.
>
> Regards,
> Bram
>
> On Thu, May 26, 2016 at 8:51 AM Pierre De Rop <pierre.de...@gmail.com>
> wrote:
>
> > but the Activator is invoked only when the bundle is started. I'm not
> sure
> > I understand ?
> > Are you invoking the Activator.init method from another bundle, like an
> > extender bundle which would track all install/resolve bundles and would
> > instantiate an Activator from a not started bundle and invoke it ?
> >
> > thanks;
> > /Pierre
> >
> > On Thu, May 26, 2016 at 8:46 AM, Bram Pouwelse <b...@pouwelse.com>
> wrote:
> >
> > > Hi Pierre,
> > >
> > > Thanks for the quick reply. I should've been a bit more clear in my
> > > message, the problem is when you remove a component before the bundle
> is
> > > started (that's why I used the Activator to demonstrate the issue).
> Once
> > > the test you've created runs the bundle is already started and all
> works
> > as
> > > expected.
> > >
> > > Regards,
> > > Bram
> > >
> > > On Thu, May 26, 2016 at 8:15 AM Pierre De Rop <pierre.de...@gmail.com>
> > > wrote:
> > >
> > > > Hi Bram,
> > > >
> > > > The service should be removed from the service registry when you
> remove
> > > the
> > > > Component from DependencyManager.
> > > >
> > > > Now, I tried to reproduce the issue you are describing in [1], but I
> > > could
> > > > not (the test is OK).
> > > > Can you please take a look at it in order to see if it the same kind
> of
> > > > scenario you have ? Am i missing something ?
> > > >
> > > > thank you;
> > > >
> > > > cheers;
> > > > /Pierre
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.itest/src/org/apache/felix/dm/itest/api/AddRemoteTest.java
> > > >
> > > > On Wed, May 25, 2016 at 8:38 PM, Bram Pouwelse <b...@pouwelse.com>
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I have an issue with a bundle that removes a DM component before
> the
> > > > bundle
> > > > > is started. If that happens the service remains available in the
> > > service
> > > > > registry.
> > > > >
> > > > > I could reproduce this using a simple activator (which doesn't make
> > any
> > > > > sense but works to demonstrate the issue).
> > > > >
> > > > > public class Activator extends DependencyActivatorBase {
> > > > >
> > > > >   @Override
> > > > >   public void init(BundleContext arg0, DependencyManager dm) throws
> > > > > Exception {
> > > > > Component addRemove =
> > > > > createComponent().setInterface(Object.class.getName(),
> > > > > null).setImplementation(Object.class);
> > > > > dm.add(addRemove);
> > > > > dm.remove(addRemove);
> > > > >   }
> > > > > }
> > > > >
> > > > > After starting this bundle the dm gogo command doesn't list any
> > > > components
> > > > > but the service is available in the service registry.
> > > > >
> > > > > g! dm
> > > > >
> > > > > g! inspect cap service 1
> > > > > dm.test [1] provides:
> > > > > -
> > > > > service; java.lang.Object with properties:
> > > > >service.bundleid = 1
> > > > >service.id = 4
> > > > >service.scope = singleton
> > > > >
> > > > > g!
> > > > >
> > > > >
> > > > > Is this expected behavior or a bug?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Bram
> > > > >
> > > >
> > >
> >
>

Re: DependencyManager: Removing component before bundle is started doesn't work

[Pierre De Rop]

but the Activator is invoked only when the bundle is started. I'm not sure
I understand ?
Are you invoking the Activator.init method from another bundle, like an
extender bundle which would track all install/resolve bundles and would
instantiate an Activator from a not started bundle and invoke it ?

thanks;
/Pierre

On Thu, May 26, 2016 at 8:46 AM, Bram Pouwelse <b...@pouwelse.com> wrote:

> Hi Pierre,
>
> Thanks for the quick reply. I should've been a bit more clear in my
> message, the problem is when you remove a component before the bundle is
> started (that's why I used the Activator to demonstrate the issue). Once
> the test you've created runs the bundle is already started and all works as
> expected.
>
> Regards,
> Bram
>
> On Thu, May 26, 2016 at 8:15 AM Pierre De Rop <pierre.de...@gmail.com>
> wrote:
>
> > Hi Bram,
> >
> > The service should be removed from the service registry when you remove
> the
> > Component from DependencyManager.
> >
> > Now, I tried to reproduce the issue you are describing in [1], but I
> could
> > not (the test is OK).
> > Can you please take a look at it in order to see if it the same kind of
> > scenario you have ? Am i missing something ?
> >
> > thank you;
> >
> > cheers;
> > /Pierre
> >
> > [1]
> >
> >
> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.itest/src/org/apache/felix/dm/itest/api/AddRemoteTest.java
> >
> > On Wed, May 25, 2016 at 8:38 PM, Bram Pouwelse <b...@pouwelse.com>
> wrote:
> >
> > > Hi,
> > >
> > > I have an issue with a bundle that removes a DM component before the
> > bundle
> > > is started. If that happens the service remains available in the
> service
> > > registry.
> > >
> > > I could reproduce this using a simple activator (which doesn't make any
> > > sense but works to demonstrate the issue).
> > >
> > > public class Activator extends DependencyActivatorBase {
> > >
> > >   @Override
> > >   public void init(BundleContext arg0, DependencyManager dm) throws
> > > Exception {
> > > Component addRemove =
> > > createComponent().setInterface(Object.class.getName(),
> > > null).setImplementation(Object.class);
> > > dm.add(addRemove);
> > > dm.remove(addRemove);
> > >   }
> > > }
> > >
> > > After starting this bundle the dm gogo command doesn't list any
> > components
> > > but the service is available in the service registry.
> > >
> > > g! dm
> > >
> > > g! inspect cap service 1
> > > dm.test [1] provides:
> > > -
> > > service; java.lang.Object with properties:
> > >service.bundleid = 1
> > >service.id = 4
> > >service.scope = singleton
> > >
> > > g!
> > >
> > >
> > > Is this expected behavior or a bug?
> > >
> > > Regards,
> > >
> > > Bram
> > >
> >
>

Re: DependencyManager: Removing component before bundle is started doesn't work

[Pierre De Rop]

Hi Bram,

The service should be removed from the service registry when you remove the
Component from DependencyManager.

Now, I tried to reproduce the issue you are describing in [1], but I could
not (the test is OK).
Can you please take a look at it in order to see if it the same kind of
scenario you have ? Am i missing something ?

thank you;

cheers;
/Pierre

[1]
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.itest/src/org/apache/felix/dm/itest/api/AddRemoteTest.java

On Wed, May 25, 2016 at 8:38 PM, Bram Pouwelse  wrote:

> Hi,
>
> I have an issue with a bundle that removes a DM component before the bundle
> is started. If that happens the service remains available in the service
> registry.
>
> I could reproduce this using a simple activator (which doesn't make any
> sense but works to demonstrate the issue).
>
> public class Activator extends DependencyActivatorBase {
>
>   @Override
>   public void init(BundleContext arg0, DependencyManager dm) throws
> Exception {
> Component addRemove =
> createComponent().setInterface(Object.class.getName(),
> null).setImplementation(Object.class);
> dm.add(addRemove);
> dm.remove(addRemove);
>   }
> }
>
> After starting this bundle the dm gogo command doesn't list any components
> but the service is available in the service registry.
>
> g! dm
>
> g! inspect cap service 1
> dm.test [1] provides:
> -
> service; java.lang.Object with properties:
>service.bundleid = 1
>service.id = 4
>service.scope = singleton
>
> g!
>
>
> Is this expected behavior or a bug?
>
> Regards,
>
> Bram
>

Re: Re: SCR: Sometimes component gets instantiated twice

[Pierre De Rop]

just out of curiosity;

can you try adding an @Modified annotation somewhere in your component, and
tell if you also observe a component restart ?

/pierre

On Wed, Mar 9, 2016 at 2:01 PM, Jens Offenbach  wrote:

> Yes, it is called between the two activates.
>
> This is the stack trace:
> at
> com.example.nodes.tree.impl.component.Component.deactivate(Component.java:131)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
> at
> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
> at
> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:342)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:157)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:783)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:757)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:615)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:566)
> at
> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:419)
> at
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:391)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2046)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2014)
> at
> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)
> at java.lang.Thread.run(Thread.java:745)
>
>
>
>
> Gesendet: Mittwoch, 09. März 2016 um 13:52 Uhr
> Von: "Carsten Ziegeler" 
> An: users@felix.apache.org
> Betreff: Re: SCR: Sometimes component gets instantiated twice
> Do you also have a debug log for the deactivate method? Is it called in
> between the two activates?
>
> Carsten
>
> Jens Offenbach wrote
> > Hi,
> > I am facing a serious problem in Apache SCR 2.0.2: I have a component
> that requires a valid configuration. Unfortunatley, it sometimes happens
> that the component gets instantiated twice. I am using Eclipse Equinox
> 3.10.2.v20150203-1939, Felix ConfigAdmin 1.8.8 and Apache Fileinstall 3.5.2.
> >
> > This is my component description created by the Apache SCR Plugin:
> > 
> > http://www.osgi.org/xmlns/scr/v1.2.0;
> immediate="true" name="com.example.nodes.tree.impl.component.Component"
> configuration-policy="require" activate="activate" deactivate="deactivate">
> > 
> > 
> > 
> > 
> > 
> >  value="com.example.nodes.tree.impl.component.Component"/>
> >  interface="com.example.nodes.tree.eventing.TreeEventListener"
> cardinality="0..n" policy="dynamic" bind="bind" unbind="unbind"
> updated="updated"/>
> >  interface="com.example.nodes.tree.spi.handler.DataHandler"
> cardinality="0..n" policy="dynamic" bind="bind" unbind="unbind"
> updated="updated"/>
> >  interface="com.example.nodes.tree.spi.handler.ExecuteHandler"
> cardinality="0..n" policy="dynamic" bind="bind" unbind="unbind"
> updated="updated"/>
> > 
> >
> > com.example.nodes.tree.impl.component.Component.cfg (no factory
> configuration):
> >
> > locking.aquireTimeout.value = 30
> > locking.aquireTimeout.unit = SECONDS
> >
> > It is hard to debug. At the moment, I can only offer you the following
> two stack traces. As you can see SCR seems to be triggered twice. The first
> event comes from the framework and signals a bundle change. The second
> event informs SCR about the corresponding configuration creation. It must
> be a race condition in some place.
> >
> > at
> com.example.nodes.tree.impl.component.Component.activate(Component.java:54)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at 

Re: [ANN] Apache Felix Dependency Manager r8 Released

[Pierre De Rop]

Thanks Renato;

It's difficult to make a comparison with Blueprint and IPojo, which I don't
know well; I only practice DM and DS regularly. Let me try to give a quick
overview, with some elements which could help you to make your own opinion
and compare with the other DI frameworks:

- DM takes its initial roots from the early 2000 years. It was started by
Marcel Offermans and over the years, Marcel and some people from the Apache
community (including your humble servant) added some new features in it.
Like other DI frameworks, DM allows to manage OSGi service components. More
specifically, DM is made for those who like to define components
declaratively by java code, using the DM api (or now using the new lambda
api).
However, there is also support for an annotation based API. For general use
cases, annotations do the work, for other complex use cases, API is
necessary, but It is also actually a matter of personal taste.
You can refer to this blog from Marcel:

http://www.planetmarrs.net/dependency-manager-4/

- DM allows to declare dynamic dependencies at runtime: you can first
declare initial service dependencies from your Activator; and then once all
required dependencies are injected, your component "init" callback is then
invoked. And at this point you can add more dependencies dynamically, and
decide which dependencies you want to add based on the already injected
dependencies. So, once all required dependencies are available (including
dynamic dependencies declared from "init" callback), you component is then
called in its "start" callback and registered.

- Filter indices: DM has a special feature that allows to index filters in
order to speed up service lookups. This feature may be useful for large
application (say 1/2 services).

- Thread model:

DependencyManager uses a specific thread model which is described here:


http://felix.staging.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/thread-model.html

Mainly, all component events (dependency events, bundle events) are handled
serially, using a lock-free serial queue, and DM never calls component
lifecycle or dependency callbacks concurrently.
For example, you will never be called concurrently in the "start" callback
and in a dependency callback.
However, take care to use thread safe datastructure, when storing
dependencies in class fields, in case such dependencies may be accessed by
any threads.

Optionally, you can configure DM to handle and start components
concurrently, this can considerably speed up the activation of the
framework (especially if you also use filter indices and when you have
(say 1/2 micro services). And the nice thing is that even if
components are handle concurrently, each component remains "single
threaded": callbacks are still called serially but multiple component can
be activated concurrently.

- Configuration types: when a component depends on a configuration, you can
specify a configuration interface. DM will inject a proxy that converts
method calls from your configuration-type to lookups in the actual map or
dictionary. The results of these lookups are then converted to the expected
return type of the invoked configuration method. As proxies are injected,
no implementations of the desired configuration-type are necessary.

See
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-configuration.html

- DM supports a feature that allows you to define a chain of aspect
services (or service interceptor) if you prefer. Aspects are factories that
create another service on top of the service that they're an aspect for;
they are orderly chained (using an aspect rank) and can "sit between" a
service provider and a service consumer. The service consumer will see the
top of the chain, while the actual service provider will be place in the
bottom of the chain.

- DM allows to create adapter services when a given type of adapted service
is found in the OSGI registry.
Some time ago, Marcel gave an interesting overview about aspects and
adapters here:
http://www.mail-archive.com/dev%40felix.apache.org/msg31197.html
I invite you to take a look at it.

Here is the same example from Marcel, adapted to the new lambda api. So, in
the example, we have a TaskExecutor component which executes all Tasks
published in the OSGi registry:

interface Task {
 void run();
}

public class TaskExecutor {
// required, injected in class field.
volatile ExecutorService executor;

void start() {
// our component is activated
}

public void add(Task task) {
// store our task for later execution
}

public void remove(Task task) {
   // remove our task from the internal list
}
}


Here is how to define the TaskExecutor component, which depends on a
required ExecutorService and on some optional Task services.
The required  ExecutorService is injected by reflection on compatible class
fields, while the 

[ANN] Apache Felix Dependency Manager r8 Released

[Pierre De Rop]

The Felix team is pleased to announce the release of the Felix Dependency
Manager version r8.

This release is available from:

http://felix.apache.org/downloads.cgi


This new release requires the usage of a recent JAVA8 runtime (at least
version 1.8.0_74 if you are using dm-lambda library), and provides some new
features:

- configuration types, which are described in [1] and [2]

- dependency manager lambda, a new library based on java8 lambda
expressions and method references, see [3]

The general documentation for dependency manager can be found from [4]

Release notes:

** Bug
* [FELIX-5146] - Service adapters turn on autoconf even if callbacks
are used
* [FELIX-5147] - Bundle Adapter auto configures class fields even if
callbacks are used
* [FELIX-5153] - DM4 calls stop before ungetService() on ServiceFactory
components
* [FELIX-5155] - Adapter/Aspect extra service dependencies injected
twice if using callback instance
* [FELIX-5178] - Make some component parameters as volatile
* [FELIX-5181] - Only log info/debug if dm annotation log parameter is
enabled
* [FELIX-5187] - No errog log when configuration dependency callback is
not found
* [FELIX-5188] - No error log when a factory pid adapter update
callback is not found
* [FELIX-5192] - ConfigurationDependency race condition when component
is stopped
* [FELIX-5193] - Factory Pid Adapter race condition when component is
stopped
* [FELIX-5200] - Factory configuration adapter not restarted

** Improvement
* [FELIX-5126] - Build DM using Java 8
* [FELIX-5164] - Add support for callback instance in Aspects
* [FELIX-5177] - Support injecting configuration proxies
* [FELIX-5180] - Support for Java8 Repeatable Properties in DM
annotations.
* [FELIX-5182] - Cleanup DM samples
* [FELIX-5201] - Improve how components are displayed with gogo shell

** New Feature
* [FELIX-4689] - Create a more fluent syntax for the dependency manager
builder

Enjoy!

-The Felix team


[1]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-configuration.html
[2]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/component-factory-configuration-adapter.html
[3]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/dm-lambda.html
[4]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html

Re: Downloads page on website contains old content

[Pierre De Rop]

Yes David, I think so.

anyway, I fixed the problem yesterday: I reverted to correct previous
revision 1723970, and updated the following:

AutoConf: 0.1.8
DeploymentAdmin: 0.9.10
Utils: 1.8.2
FileInstall: 3.5.2
EventAdmin: 1.4.6

now, I think it's OK.

cheers;
/Pierre



On Thu, Jan 28, 2016 at 11:24 AM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

> This seems to be caused by commit 1725455 by gnodet:
>
>
> https://svn.apache.org/viewvc/felix/site/trunk/content/downloads.list?r1=1723970=1725455_format=h
>
> Maybe a stale downloads.list file was committed?
>
>
> On 27 January 2016 at 12:02, Bram Pouwelse <b...@pouwelse.com> wrote:
>
> > Thanks Pierre, I don't know the expected versions for all projects but it
> > looks a lot better now
> >
> > On Wed, Jan 27, 2016 at 11:09 AM Pierre De Rop <pierre.de...@gmail.com>
> > wrote:
> >
> > > I think I just fixed it.
> > >
> > >
> > > cheers;
> > > /Pierre
> > >
> > > On Wed, Jan 27, 2016 at 10:09 AM, Pierre De Rop <
> pierre.de...@gmail.com>
> > > wrote:
> > >
> > > > Hi Bram;
> > > >
> > > > Thanks for pointing out this ! Arjun Panday also just contacted me
> > about
> > > > that. Even dependency manager went back to old 3.2
> > > >
> > > > It seems that the regression comes from this commit:
> > > >
> > > >
> > > >
> > >
> >
> http://svn.apache.org/viewvc/felix/site/trunk/content/downloads.list?r1=1723970=1725455
> > > >
> > > > Guillaume, can you please verify your commit from revision 1723970 ?
> (
> > > >
> > >
> >
> http://svn.apache.org/viewvc/felix/site/trunk/content/downloads.list?revision=1725455=co
> > > > )
> > > >
> > > > Thank you;
> > > >
> > > > cheers;
> > > > /Pierre
> > > >
> > > > On Tue, Jan 26, 2016 at 8:20 PM, Bram Pouwelse <b...@pouwelse.com>
> > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Something seems off with the downloads section on the felix website
> > > >> http://felix.apache.org/downloads.cgi
> > > >>
> > > >> For example the Framework version in the table is 4.6.0 and http is
> > back
> > > >> to
> > > >> version 2.3.2.
> > > >>
> > > >> Regards,
> > > >> Bram
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Downloads page on website contains old content

[Pierre De Rop]

Hi Bram;

Thanks for pointing out this ! Arjun Panday also just contacted me about
that. Even dependency manager went back to old 3.2

It seems that the regression comes from this commit:

http://svn.apache.org/viewvc/felix/site/trunk/content/downloads.list?r1=1723970=1725455

Guillaume, can you please verify your commit from revision 1723970 ? (
http://svn.apache.org/viewvc/felix/site/trunk/content/downloads.list?revision=1725455=co
)

Thank you;

cheers;
/Pierre

On Tue, Jan 26, 2016 at 8:20 PM, Bram Pouwelse  wrote:

> Hi,
>
> Something seems off with the downloads section on the felix website
> http://felix.apache.org/downloads.cgi
>
> For example the Framework version in the table is 4.6.0 and http is back to
> version 2.3.2.
>
> Regards,
> Bram
>

Re: Downloads page on website contains old content

[Pierre De Rop]

I think I just fixed it.


cheers;
/Pierre

On Wed, Jan 27, 2016 at 10:09 AM, Pierre De Rop <pierre.de...@gmail.com>
wrote:

> Hi Bram;
>
> Thanks for pointing out this ! Arjun Panday also just contacted me about
> that. Even dependency manager went back to old 3.2
>
> It seems that the regression comes from this commit:
>
>
> http://svn.apache.org/viewvc/felix/site/trunk/content/downloads.list?r1=1723970=1725455
>
> Guillaume, can you please verify your commit from revision 1723970 ? (
> http://svn.apache.org/viewvc/felix/site/trunk/content/downloads.list?revision=1725455=co
> )
>
> Thank you;
>
> cheers;
> /Pierre
>
> On Tue, Jan 26, 2016 at 8:20 PM, Bram Pouwelse <b...@pouwelse.com> wrote:
>
>> Hi,
>>
>> Something seems off with the downloads section on the felix website
>> http://felix.apache.org/downloads.cgi
>>
>> For example the Framework version in the table is 4.6.0 and http is back
>> to
>> version 2.3.2.
>>
>> Regards,
>> Bram
>>
>
>

[ANN] Apache Felix Dependency Manager Release R6

[Pierre De Rop]

The Felix team is pleased to announce the release of the Apache Felix
Dependency Manager release R6.

This release is available from:

http://felix.apache.org/site/downloads.cgi

The instructions to build the Dependency Manager from the source
distribution can be found here:


http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/development.html

Release Notes - Felix - Version  org.apache.felix.dependencymanager-r6

** Bug
* [FELIX-4974] - DM filter indices not enabled if the dependencymanager
bundle is started first
* [FELIX-5045] - DM Optional callbacks may sometimes be invoked before
start callback
* [FELIX-5046] - Gradle wrapper is not included in DM source release

** Improvement
* [FELIX-4921] - Ensure binary equality of the same bundle between
successive DM releases
* [FELIX-4922] - Simplify DM changelog management
* [FELIX-5054] - Clean-up instance bound dependencies when component is
destroyed
* [FELIX-5055] - Upgrade DM to BndTools 3.0.0
* [FELIX-5104] - Call a conf dependency callback Instance with an
instantiated component
* [FELIX-5113] - Remove useless wrong test in
ConfigurationDependencyImpl
* [FELIX-5114] - Schedule configuration update in Component executor
synchronously

Enjoy!

-The Felix team

Re: How To Build Apache Felix Dependency Manager

[Pierre De Rop]

Hi Hubert,

Good to know it works.

Ok; I will upload the already released 4.1.1 version for the
org.apache.felix.dependencymanager.jar artifact asap, and will let you know.

cheers
/Pierre

On Thu, Sep 17, 2015 at 10:50 AM, Hubert Felber <hubert.fel...@abacus.ch>
wrote:

>
> -Changed to java 7
> -the sources are from
> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager
> -did not know gradlew (first contact) after making gradlew available
> and setting the proxies I could compile  -- even on windows ;-)
>
>
> Thank you!!
>
> It seams that the latest release is DM 4.1.1
> But this is not available in
>
> http://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.dependencymanager
>
>
> The latest release there is 4.1.0
>
>
> If 4.1.1 is released, could somebody please make 4.1.1  available on
> mavenrepository?
>
> Hubert
>
>
> >>> Pierre De Rop <pierre.de...@gmail.com> 16.09.2015 23:29 >>>
> It looks like you are building DM with java 8, but java 7 is required.
>
> Now, using java7, can you try  gradlew instead of gradle:
>
> ./gradlew org.apache.felix.dependencymanager.annotation:jar
>
> Can you also confirm me that you are building the felix-trunk  version
> ? or
> are you building the latest released sources from
>
> http://apache.websitebeheerjd.nl//felix/org.apache.felix.dependencymanager-r5-src.zip
>
> ?
>
> it seems that you are building under windows. I'm working under linux,
> but
> will try to build under windows in order to see if I'm able to
> reproduce
> the same issue, and I will let you know.
>
> Also, are you using an http proxy ? if yes, then can you verify that
> you
> are using the GRADLE_OPTS environment variable and that this variable
> is
> set to the proper http proxy (it is used by gradle in order to
> download
> dependencies).
>
> For example, under linux:
>
> export GRADLE_OPTS="-Dhttps.proxyHost=
> -Dhttps.proxyPort="
>
> let me know !
>
>
> cheers;
> /Pierre
>
> On Wed, Sep 16, 2015 at 10:47 PM, Hubert Felber
> <hubert.fel...@abacus.ch>
> wrote:
>
> > Pierre,
> > Thank you
> >
> > gradle org.apache.felix.dependencymanager.annotation:jar
> >
> > gives me a lot of errors, it seams I miss some dependencies
> >
> > do you have me a hint?
> >
> > p.s.
> > I try to compile this, because the code in current
> > ComponentImpl#calculateNewState is hard to read, and I noticed that
> it
> > was rewritten on trunk.
> >
> > Hubert
> >
> > E:\dependencymanager>gradle
> > org.apache.felix.dependencymanager.annotation:jar
> > :org.apache.felix.dependencymanager.annotation:compileJava
> > warning: [options] bootstrap class path not set in conjunction with
> > -source 1.7
> >
> >
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:52:
> > error: package aQute.bnd.osgi does not exist
> > import aQute.bnd.osgi.Annotation;
> >  ^
> >
> >
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:53:
> > error: package aQute.bnd.osgi does not exist
> > import aQute.bnd.osgi.ClassDataCollector;
> >  ^
> >
> >
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:54:
> > error: package aQute.bnd.osgi does not exist
> > import aQute.bnd.osgi.Clazz;
> >  ^
> >
> >
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:55:
> > error: package aQute.bnd.osgi.Descriptors does not exist
> > import aQute.bnd.osgi.Descriptors.TypeRef;
> >
> >
> >
> > >>> Pierre De Rop <pierre.de...@gmail.com> 16.09.2015 21:10 >>>
> > Hello Hubert,
> >
> > This is an old documentation. We are now using BndTools and Gradle
> and
> > the
> > latest documentation is located at [1]. More specifically, how to
> build
> > DM
> > is described at [2]
> >
> > Don't hesitate to ping here if you need more helps.
> >
> > cheers;
> > /Pierre
> >
> > [1]
> >
> >
>
> http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
>
> >
> > [2]
> >
> >
>
> http://felix.apache.org/documentation/subpro

Re: How To Build Apache Felix Dependency Manager

[Pierre De Rop]

Hi Hubert,

the org.apache.felix.dependencymanager-4.1.1.jar artifact has been uploaded
to maven central, see [1]

/Pierre

[1]
http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.dependencymanager/4.1.1/

On Thu, Sep 17, 2015 at 10:50 AM, Hubert Felber <hubert.fel...@abacus.ch>
wrote:

>
> -Changed to java 7
> -the sources are from
> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager
> -did not know gradlew (first contact) after making gradlew available
> and setting the proxies I could compile  -- even on windows ;-)
>
>
> Thank you!!
>
> It seams that the latest release is DM 4.1.1
> But this is not available in
>
> http://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.dependencymanager
>
>
> The latest release there is 4.1.0
>
>
> If 4.1.1 is released, could somebody please make 4.1.1  available on
> mavenrepository?
>
> Hubert
>
>
> >>> Pierre De Rop <pierre.de...@gmail.com> 16.09.2015 23:29 >>>
> It looks like you are building DM with java 8, but java 7 is required.
>
> Now, using java7, can you try  gradlew instead of gradle:
>
> ./gradlew org.apache.felix.dependencymanager.annotation:jar
>
> Can you also confirm me that you are building the felix-trunk  version
> ? or
> are you building the latest released sources from
>
> http://apache.websitebeheerjd.nl//felix/org.apache.felix.dependencymanager-r5-src.zip
>
> ?
>
> it seems that you are building under windows. I'm working under linux,
> but
> will try to build under windows in order to see if I'm able to
> reproduce
> the same issue, and I will let you know.
>
> Also, are you using an http proxy ? if yes, then can you verify that
> you
> are using the GRADLE_OPTS environment variable and that this variable
> is
> set to the proper http proxy (it is used by gradle in order to
> download
> dependencies).
>
> For example, under linux:
>
> export GRADLE_OPTS="-Dhttps.proxyHost=
> -Dhttps.proxyPort="
>
> let me know !
>
>
> cheers;
> /Pierre
>
> On Wed, Sep 16, 2015 at 10:47 PM, Hubert Felber
> <hubert.fel...@abacus.ch>
> wrote:
>
> > Pierre,
> > Thank you
> >
> > gradle org.apache.felix.dependencymanager.annotation:jar
> >
> > gives me a lot of errors, it seams I miss some dependencies
> >
> > do you have me a hint?
> >
> > p.s.
> > I try to compile this, because the code in current
> > ComponentImpl#calculateNewState is hard to read, and I noticed that
> it
> > was rewritten on trunk.
> >
> > Hubert
> >
> > E:\dependencymanager>gradle
> > org.apache.felix.dependencymanager.annotation:jar
> > :org.apache.felix.dependencymanager.annotation:compileJava
> > warning: [options] bootstrap class path not set in conjunction with
> > -source 1.7
> >
> >
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:52:
> > error: package aQute.bnd.osgi does not exist
> > import aQute.bnd.osgi.Annotation;
> >  ^
> >
> >
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:53:
> > error: package aQute.bnd.osgi does not exist
> > import aQute.bnd.osgi.ClassDataCollector;
> >  ^
> >
> >
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:54:
> > error: package aQute.bnd.osgi does not exist
> > import aQute.bnd.osgi.Clazz;
> >  ^
> >
> >
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:55:
> > error: package aQute.bnd.osgi.Descriptors does not exist
> > import aQute.bnd.osgi.Descriptors.TypeRef;
> >
> >
> >
> > >>> Pierre De Rop <pierre.de...@gmail.com> 16.09.2015 21:10 >>>
> > Hello Hubert,
> >
> > This is an old documentation. We are now using BndTools and Gradle
> and
> > the
> > latest documentation is located at [1]. More specifically, how to
> build
> > DM
> > is described at [2]
> >
> > Don't hesitate to ping here if you need more helps.
> >
> > cheers;
> > /Pierre
> >
> > [1]
> >
> >
>
> http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
>
> >
> > [2]
> >
> >
>
> http://felix.apache

Re: Dependency Manager does not behave as expected

[Pierre De Rop]

Hi Hubert,

I'm sorry but don't understand when you say:

" ... DM should not try to start the service before I finally add the
component
to DM, but now it tries to start the service, as soon as add a
ServiceDependency ..."

Indeed, DM never do that. The service component is started only after you
add it to the DependencyManager. If you really observe this, then please
open a JIRA issue and a mini project that reproduces this issue.

Now, let's talk about what you observed: when a Dependency is added before
the Component is added to the DependencyManager object, the task that is
scheduled in the Component.add(Dependency) method registers the dependency
(ies) and calls the handleChange method, which in turns calls
calculateNewState. I do agree with this, but all this is made by design.
And if the Component is not yet added, the component won't be started at
all since we remain in the Inactive state.

We systematically calls handleChange when a Dependency is added, because if
some dependencies are added dynamically after the component is added (and
probably started), then we have to recalculate the state changes (if you
add a missing dependency to a started component, then it has to be stopped).

And we do all this inside the runnable task that is scheduled in the
component executor because all  events (like dynamic dependencies that are
added after the Component is added, or service injections, or service
removal, or bundle start/stop events, etc ...) are handled in a lock-free
way, through the SerialExecutor. This reduces the complexity, avoid
potential dead locks, and we want to minimize the usage of tricky
synchronization logic. We just want to systematically react to events
through the Executor, like in an Actor based thread-model.

I hope that my response will help.

Again, if you have a working sample code that demonstrates that a component
is started before it is actually added to the DependencyManager, then
please open a jira issue and we'll investigate it.

kind regards;
/Pierre





On Thu, Sep 17, 2015 at 12:29 PM, Hubert Felber <hubert.fel...@abacus.ch>
wrote:

> Hi Pierre,
>
> Thank you for all your efforts!
>
> unfortunately I could not check it out using svn.
> I get a "Redirect cycle detected for URL '
> http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager.test'"
> on both linux and windows
>
>
> And I don´t have Eclipse installed since we work with IntelliJ Idea
>
> nevertheless I was able to load the relevant files via http and try them.
>
> I made the same observation: as soon as a add a ServiceDependency
> then ComponentImpl#startDependencies() is called -- before I added the
> component
> to DM.
> Of course the service cannot be started then, the state remains inactive,
> but DM tries to do so and
> maybe can do this, before I finished the component configuration.
>
> I reduced the snippet:
>
> Component comp = createComponent()
> //.setInterface(toString(LoggingConfService.class,
> //ManagedService.class), null)
> //.setImplementation(LoggingConfigServiceImpl.class)
>
> // after this, DM tries to start the service -> state remains INACTIVE
>
>
> .add(createServiceDependency().setService(LoggingService.class).setRequired(true));
>
> // before I add the component to DM
>
> System.out.println("Adding component to dependency manager");
> dependencyManager.add(comp);
>
>
> after this, DM tries to start the service agein -> state now is
> WAITING_FOR_REQUIRED
> which is what I expected. The service will start as soon as the dependency
> is resolved.
>
>
> You should be able to see this with a breakpoint on
> ComponentImpl#calculateNewState
> after adding the service dependency.
> In my opinion DM should not try to start the service before I finally add
> the component
> to DM, but now it tries to start the service, as soon as add a
> ServiceDependency.
>
> Tested with DM 4.1.0
>
> Thank you again
> Hubert
>
>
> >>> Pierre De Rop <pierre.de...@gmail.com> 17.09.2015 01:03 >>>
> Hi Hubert;
>
> I don't understand how this is possible, because a DM component initial
> state is Inactive, and remains in this state until you add it to a
> DependencyManager object.
>
> So, your service implementation can not be called in start() before you add
> the component to the dm object.
>
> Ok, in order to go ahead, I have made a (temporary) commit of a
> dependencymanager.test project in my sandbox (see [1]).
>
> So, can you please take a look at it ? I tried to follow your samples by
> creating two bundles:
>
> dependencymanager.test.log.jar -> contains the LoggingService + its
> Activator
> dependencymanager.te

Re: How To Build Apache Felix Dependency Manager

[Pierre De Rop]

Hello Hubert,

This is an old documentation. We are now using BndTools and Gradle and the
latest documentation is located at [1]. More specifically, how to build DM
is described at [2]

Don't hesitate to ping here if you need more helps.

cheers;
/Pierre

[1]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
[2]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/development.html



On Wed, Sep 16, 2015 at 8:54 PM, Hubert Felber 
wrote:

> Hi,
>
> How can I build  "Felix Dependency Manager" ?
>
> I followed these instructions, checked out trunk and tried to build
>
>
> https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Dependency+Manager+-+How+To+Build
>
> but there is no pom.xml.
>
> I then installed gradle and did a "gradle build" which gives me 98
> errors
>
> 98 errors
> 4 warnings
> :org.apache.felix.dependencymanager:compileJava FAILED
>
> So how can I build DM ?
>
> Thank you
> Hubert
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: How To Build Apache Felix Dependency Manager

[Pierre De Rop]

It looks like you are building DM with java 8, but java 7 is required.

Now, using java7, can you try  gradlew instead of gradle:

./gradlew org.apache.felix.dependencymanager.annotation:jar

Can you also confirm me that you are building the felix-trunk  version ? or
are you building the latest released sources from
http://apache.websitebeheerjd.nl//felix/org.apache.felix.dependencymanager-r5-src.zip
?

it seems that you are building under windows. I'm working under linux, but
will try to build under windows in order to see if I'm able to reproduce
the same issue, and I will let you know.

Also, are you using an http proxy ? if yes, then can you verify that you
are using the GRADLE_OPTS environment variable and that this variable is
set to the proper http proxy (it is used by gradle in order to download
dependencies).

For example, under linux:

export GRADLE_OPTS="-Dhttps.proxyHost=
-Dhttps.proxyPort="

let me know !


cheers;
/Pierre

On Wed, Sep 16, 2015 at 10:47 PM, Hubert Felber <hubert.fel...@abacus.ch>
wrote:

> Pierre,
> Thank you
>
> gradle org.apache.felix.dependencymanager.annotation:jar
>
> gives me a lot of errors, it seams I miss some dependencies
>
> do you have me a hint?
>
> p.s.
> I try to compile this, because the code in current
> ComponentImpl#calculateNewState is hard to read, and I noticed that it
> was rewritten on trunk.
>
> Hubert
>
> E:\dependencymanager>gradle
> org.apache.felix.dependencymanager.annotation:jar
> :org.apache.felix.dependencymanager.annotation:compileJava
> warning: [options] bootstrap class path not set in conjunction with
> -source 1.7
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:52:
> error: package aQute.bnd.osgi does not exist
> import aQute.bnd.osgi.Annotation;
>  ^
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:53:
> error: package aQute.bnd.osgi does not exist
> import aQute.bnd.osgi.ClassDataCollector;
>  ^
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:54:
> error: package aQute.bnd.osgi does not exist
> import aQute.bnd.osgi.Clazz;
>  ^
>
> E:\dependencymanager\org.apache.felix.dependencymanager.annotation\src\org\apache\felix\dm\annotation\plugin\bnd\AnnotationCollector.java:55:
> error: package aQute.bnd.osgi.Descriptors does not exist
> import aQute.bnd.osgi.Descriptors.TypeRef;
>
>
>
> >>> Pierre De Rop <pierre.de...@gmail.com> 16.09.2015 21:10 >>>
> Hello Hubert,
>
> This is an old documentation. We are now using BndTools and Gradle and
> the
> latest documentation is located at [1]. More specifically, how to build
> DM
> is described at [2]
>
> Don't hesitate to ping here if you need more helps.
>
> cheers;
> /Pierre
>
> [1]
>
> http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
>
> [2]
>
> http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/development.html
>
>
>
>
> On Wed, Sep 16, 2015 at 8:54 PM, Hubert Felber
> <hubert.fel...@abacus.ch>
> wrote:
>
> > Hi,
> >
> > How can I build  "Felix Dependency Manager" ?
> >
> > I followed these instructions, checked out trunk and tried to build
> >
> >
> >
>
> https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Dependency+Manager+-+How+To+Build
>
> >
> > but there is no pom.xml.
> >
> > I then installed gradle and did a "gradle build" which gives me 98
> > errors
> >
> > 98 errors
> > 4 warnings
> > :org.apache.felix.dependencymanager:compileJava FAILED
> >
> > So how can I build DM ?
> >
> > Thank you
> > Hubert
> >
> >
> -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Dependency Manager does not behave as expected

[Pierre De Rop]

Hi Hubert;

I don't understand how this is possible, because a DM component initial
state is Inactive, and remains in this state until you add it to a
DependencyManager object.

So, your service implementation can not be called in start() before you add
the component to the dm object.

Ok, in order to go ahead, I have made a (temporary) commit of a
dependencymanager.test project in my sandbox (see [1]).

So, can you please take a look at it ? I tried to follow your samples by
creating two bundles:

dependencymanager.test.log.jar -> contains the LoggingService + its
Activator
dependencymanager.test.logconfig.jar -> contains the LoggingConfigService
that depends on the LoggingService.

Here is the Activator for the dependencymanager.test.logconfig.jar bundle
(I made it a bit more compact, by reusing the methods available from the
DependencyActivatorBase)

public class Activator extends DependencyActivatorBase {

@Override
public void init(BundleContext ctx, DependencyManager dm) throws
Exception {
Component comp = createComponent()
.setInterface(toString(LoggingConfigService.class,
ManagedService.class), null)
.setImplementation(LoggingConfigServiceImpl.class)

.add(createServiceDependency().setService(LoggingService.class).setRequired(true));

System.out.println("Adding component to dependency manager");
dm.add(comp);
}

// Helper used to convert an array of classes to an array of class
strings
String[] toString(Class ... services) {
return Stream.of(services).map(c ->
c.getName()).toArray(String[]::new);
}

}


So, can you install an Eclipse mars + java8 + latest bndtool (Use the
dependencymanager.test directory as the eclipse workspace directory).

Then open the bndtools perspective.

Then click on File -> Import -> General -> Existing Projects into workspace
-> Browse -> Ok -> Finish

Then click on the dependencymanager.test/bnd.bnd file -> Run tab -> Run
OSGi.

You will then see in the console:

   Adding component to dependency manager
   LoggingConfigServiceImpl is starting.

So, the "Adding component to dependency manager" message is displayed, then
after, when the component is added to the DependencyManager "dm" object,
then when the component is injected with the LoggingService, it is then
started and you see the log "LoggingConfigServiceImpl is starting" message.

You can also type "dm" shell command in the console:

dm

[8] dependencymanager.test.logconfig
 [0] dependencymanager.test.logconf.LoggingConfigService,
org.osgi.service.cm.ManagedService registered
dependencymanager.test.log.LoggingService service required available
[9] dependencymanager.test.log
 [1] dependencymanager.test.log.LoggingService registered


So, maybe if you try to play with this sample, you will then be able to
figure out what is going wrong in your own project ?

hope this helps;
/Pierre

[1]
http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager.test/






On Wed, Sep 16, 2015 at 10:43 PM, Hubert Felber 
wrote:

> Hi,
>
> as soon as I add a ServiceDependency to my component, Felix tries to
> start the service  --  before I set the implementation and before I add
> the the component to the DM.
>
> I would expect, it waits until I finally add the component to the DM?
>
> Am I doing something wrong?
>
> Thank you
> Hubert
>
> public void init(BundleContext bundleContext, DependencyManager
> dependencyManager) throws Exception {
>   Component component =  dependencyManager.createComponent();
>
> ServiceDependency serviceDependency = createServiceDependency();
> serviceDependency.setService(LoggingServiceImpl.class);
> serviceDependency.setRequired(true);
>
> 
> component.add(serviceDependency);   // goes to
> ComponentImpl#calculateNewState() from here
> >>>
> component.setImplementation(LoggingConfigService.class);
> String[] classes = new
> String[]{LoggingConfigService.class.getName(),
> ManagedService.class.getName()};
>
> component.setInterface(classes, properties);
> dependencyManager.add(component); // thought it should go
> to calculateNewState() from here ??
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Cannot build project from source

[Pierre De Rop]

Hello Ken,

oops, yes, Marcel is right: I forgot to remove the dependencymanager from
the toplevel pom.xml (DM is now built using bndtools instead of maven).

I just committed in rv 1692952 the toplevel pom.xml.

I also added the resolver module in the toplevel pom.xml (the framework is
now dependending on it).

Now, I think there is one remaining issue (see [1]): the framework is
currently needing java8 to build. So, for now, please try again, but using
java8.

cheers;
/Pierre

[1] http://www.mail-archive.com/dev@felix.apache.org/msg37248.html

On Mon, Jul 27, 2015 at 10:26 PM, Marcel Offermans 
marcel.offerm...@luminis.nl wrote:

 On 27 Jul 2015 at 20:11:02 , Ken Gilmer (kgil...@gmail.com) wrote:
 /Users/kggilmer/dev/repos/felix/dependencymanager/pom.xml of
 /Users/kggilmer/dev/repos/felix/pom.xml does not exist @
 [exec] @
 Dependency Manager no longer uses a Maven based build, so it should
 probably be excluded from a list somewhere.

 Greetings, Marcel

[ANN] Apache Felix Dependency Manager 4 (top-level release R5) Released

[Pierre De Rop]

The Felix team is pleased to announce the release of the Apache Felix
Dependency Manager 4 top-level release R5.

This release is available from:

http://felix.apache.org/site/downloads.cgi

The instructions to build the Dependency Manager from the source
distribution can be found here:


http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/development.html

Release Notes - Felix - Version  org.apache.felix.dependencymanager-r5

** Bug
* [FELIX-4907] - ConfigurationDependency calls updated(null) when
component is stopped.
* [FELIX-4910] - ComponentExecutorFactory does not allow to return null
from getExecutorFor method.
* [FELIX-4913] - DM Optional callbacks may sometimes be invoked twice

** Improvement
* [FELIX-4876] - DM Annotations bnd plugin compatibility with Bndtools
2.4.1 / 3.0.0 versions
* [FELIX-4877] - DM Annotations should detect service type using more
method signatures.
* [FELIX-4915] - Skip unnecessary manifest headers in DM bnd file

Enjoy!

-The Felix team

[ANN] Apache Felix Dependency Manager 4 (top-level release R3) Released

[Pierre De Rop]

The Felix team is pleased to announce the release of the Apache Felix
Dependency Manager 4 top-level release R3.

This release is available from:

http://felix.apache.org/site/downloads.cgi

The instructions to build the Dependency Manager from the source
distribution can be found here:


http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/development.html


Release Notes - Version org.apache.felix.dependencymanager-r3

** Bug
* [FELIX-4858] - DependencyManager: missing createCopy method in timed
service dependency
* [FELIX-4869] - Callbacks not invoked for dependencies that are added
after the component is initialized

** Improvement
* [FELIX-4614] - Factory create() method should have access to the
component definition
* [FELIX-4873] - Enhance DM API to get missing and circular dependencies
* [FELIX-4876] - DM Annotations bnd plugin compatibility with Bndtools
2.4.1 / 3.0.0 versions
* [FELIX-4877] - DM Annotations should detect service type using more
method signatures.
* [FELIX-4878] - Support more signatures for Dependency callbacks
* [FELIX-4880] - Missing callback instance support for some adapters
* [FELIX-4889] - Refactor dm shell command to use the
org.apache.dm.diagnostics api

** Wish
* [FELIX-4875] - Update DM integration test with latest ConfigAdmin

Enjoy!

-The Felix team

Re: Servlet whiteboard registration vs. direct registration - Filter not working

[Pierre De Rop]

Hello Thomas,

Just a remark, when you define a DM @Component annotation on a class which
implements an interface, then the interface is automatically registered in
the OSGi service registry. So, in the case of your MyManualServlet, since
you are registering it manually from the @Start method, then I think you
should add the provides={} attribute in the @Component annotation in
order to indicate that you don't want the annotation to auto-register your
servlet.

Something like this:

@Component(provides={})
public class MyManualServlet implements Servlet {
 @ServiceDependency
 private volatile HttpService httpService;

@Start
public void start(){
try {
   httpService.registerServlet(/testtwo, this, null, null);
} catch (ServletException e) {
  e.printStackTrace();
} catch (NamespaceException e) {
  e.printStackTrace();
}
}
...

Now, I did not yet played with the latest http servlet from felix-trunk.
So, can you please indicate me the exact list of bundles you are using at
runtime ?  I will then try to do what you are trying to do what you are
trying to do, and will see if I reproduce the problem.

Looking at the previous posts you did, it sounds like you are using the
http api/base/runtime bundles at runtime ?

kind regards;
/Pierre

On Fri, May 22, 2015 at 12:50 PM, Thomas Driessen 
thomas.dries...@ds-lab.org wrote:

 Hi again,

 I have two Servlets and one Filter.
 The first servlet is registrated via whiteboard like this:

 @Component(properties={
 @Property(name=osgi.http.whiteboard.servlet.name, value=MyServlet),
 @Property(name=osgi.http.whiteboard.servlet.pattern, value=/testone)})
 public class MyWhiteboardServlet implements Servlet {
 ...

 The second Servlet is registrated directly via HttpService like this:

 @Component
 public class MyManualServlet implements Servlet {
  @ServiceDependency
 private volatile HttpService httpService;
  @Start
 public void start(){
 try {
 httpService.registerServlet(/testtwo, this, null, null);
 } catch (ServletException e) {
 e.printStackTrace();
 } catch (NamespaceException e) {
 e.printStackTrace();
 }
 }
 ...

 Then I added a Filter also via whiteboard registration like this:

 @Component(properties={
 @Property(name=osgi.http.whiteboard.filter.name, value=MyFilter),
 @Property(name=osgi.http.whiteboard.filter.pattern, value=/*)})
 public class MyFilter implements Filter {
 ...

 Everythings starts up fine, but when it comes to requests, only the
 MyWhiteboardServlet is filtered correctly. When I try to access the
 MyManualServlet nothing happens and the Filter is not invoked.

 Is this an intended behaviour?

 I know I'm mixing up different registration styles, but I assumed, that
 internally both are registered the same way?
 In my current project I'm forced to support both styles, as some third
 party libraries I use, are using the direct registration, while others use
 the whiteboard registration.

 Any advice on this problem is appreciated :)

 Best regards,
 Thomas
 --
 M.Sc. Thomas Driessen
 Software Methodologies for Distributed Systems
 Institute of Computer Science
 University of Augsburg
 Universitätsstr. 6a
 86135 Augsburg, Germany

 Tel:+49 821 598-2486
 email: thomas.dries...@informatik.uni-augsburg.de

Re: DependencyManager and bundle-private components

[Pierre De Rop]

Hello Simon,

DM, like DS does not implement a private service registry to intra-bundle
components (well, except for optimized DM filter indices, but this is
another story).

I think Ipojo do support what you are describing, but I prefer to let other
people respond about this since I'm not enough experienced in iPojo. See
[1] about this, which comes from the osgi mailing list.

Now, I tend to agree with Neil, and intra-bundle private services can
simply be instantiated with the new keyword.
Alternatively, with DM, you can also use a composition of service
components: this allows you to:

- only register one single service for the bundle in the OSGi service
registry (or even only one DM component if it does not provide any services
at all, but just needs to define some dependencies to external services
(outside the bundle).

- and define a composition of objects that will get injected with the
external services.
For example, you can take a look at [2] for a concrete sample code of a
bundle which defines a component that is instantiated using a
CompositionManager pojo that is first injected with a configuration. And
from the configuration, the pojo may then create an implementation for the
service that the bundle provides, and also, some other pojo objects that
are part of the service implementation. The pojos will then be injected
with all the external service dependencies defined in the Activator (either
using field injection of bind method callbacks).

There is also another example which does not use a Factory, but only a
service composition in [3].

Finally, I would like to say that it's a not a real problem to have many
services registered in the Osgi service registry.
Registering services is cheap. And DM now supports an actor based thread
model which allows to activate, manage, and bind service components
concurrently, using a shared threadpool, and there is no startup time
degradation (I often start around 2 services and my Felix Framework
starts in few of seconds). The new thread model is descriped in [4].

Also, regarding service diagnostics, even if you have thousands of micro
services registered in the OSGi registry, then DM gogo shell supports
advanced commands that allows you to quickly make some diagnostics (like
loop detection, missing service root causes, service lookup using filters,
etc ...).

[1] https://mail.osgi.org/pipermail/osgi-dev/2014-February/004310.html
[2]
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/compositefactory/
[3]
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/composite/
[4]
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/thread-model.html

kind regards;
/Pierre

On Thu, May 21, 2015 at 4:52 PM, Simon Kitching si...@vonos.net wrote:

 Hi,

 In blueprint it is possible to define arbitrary objects (beans) which are
 not published to the service registry but nevertheless can be injected into
 other beans.

 AFAICT, in both declarative-services and felix-dm, the only objects that
 can be injected are references to services from the OSGi registry. Is this
 correct?

 I understand that with DS and DM, components follow the standard OSGi
 lifecycles, in contrast to the Blueprint approach of hiding the
 lifecycle. In particular, in DS and DM when a component's mandatory
 dependency is deregistered then the component is also deregistered (which
 can cascade further). And the kind of tracking of dependencies required to
 make this happen is exactly what a service registry does.

 However it's common for a bundle to have objects which are purely internal
 implementation details of the bundle, and are not for external use. Yet as
 far as I can see, in order to manage them with DS or DM, such internal
 objects need to be published into the global service registry - just to be
 able to then inject them back into components in the same bundle.

 Have I misunderstood something?

 Thanks,
 Simon

 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: ServletContextListener

[Pierre De Rop]

Hello Thomas,

if you are using DM annotations, you can try to add the service property
mentioned by Raymond using the following:

@Component(properties = @Property(name = osgi.http.whiteboard.listener,
value = true))
public class MyContextListener implements ServletContextListener {
...
}

And if your component also depends on other services, you might also need
to check proper activation of your component using the dm shell
command,like dm b bundle id.

hope this helps;
/Pierre

On Tue, May 12, 2015 at 3:09 PM, Raymond Auge raymond.a...@liferay.com
wrote:

 You are missing the required service property
 osgi.http.whiteboard.listener=true on your SCL.

 Sincerely,
 - Ray

 On Tue, May 12, 2015 at 6:51 AM, Thomas Driessen 
 thomas.dries...@ds-lab.org
  wrote:

  Hi Carsten,
 
  forget my last question, I still used felix 4.4.1 as my OSGI Framework. I
  switched this to 5.1.0.SNAPSHOT and everything got resolved as expected.
 
  But still my ServletContextListener seems not to be invoked, as i get no
  outputs on contextInitialized.
 
  This is my ServletContextListener:
 
  @Component(provides=ServletContextListener.class)
  public class MyContextListener implements ServletContextListener {
 
  @Override
  public void contextDestroyed(ServletContextEvent arg0) {
  // TODO Auto-generated method stub
  System.out.println(MyContextListener.contextDestroyed());
  }
 
  @Override
  public void contextInitialized(ServletContextEvent arg0) {
  // TODO Auto-generated method stub
  System.out.println(MyContextListener.contextInitialized());
  }
  }
 
  Might it be that the DM-Annotations are not working? Or do I have to add
  some attributes?
  Sorry for all those questions but right now I'm pretty confused :(
 
  Thanks for all your advice :)
 
  Thomas
 
  2015-05-12 12:08 GMT+02:00 Thomas Driessen thomas.dries...@ds-lab.org:
 
   Hi Carsten,
  
   I added http.jetty (3.0.3.SNAPSHOT) and http.api (3.0.0.SNAPSHOT) to my
   runrequirements but now it says it is missing the package org.osgi.dto
 ?
   I tried to add org.osgi.core (6.0.0) but that didn't help.
  
   Do I have to add some other bundles on which http.jetty and http.api
 are
   relying?
  
   Thomas
  
   2015-05-11 19:20 GMT+02:00 Carsten Ziegeler cziege...@apache.org:
  
   Am 11.05.15 um 18:51 schrieb Scott Lewis:
On 5/11/2015 9:45 AM, Carsten Ziegeler wrote:
stuff deleted
Is there a release scheduled that will include all the http service
changes for R6 final?
   
Yes, once there is an official final R6 version, we can do a
 release.
   
Any schedule around such a release?   I know that the R6 spec is not
done/approved/frozen, etc., but I'm just asking what plans exist.
   
   I assume somewhere in Q3
  
   Carsten
  
  
   --
   Carsten Ziegeler
   Adobe Research Switzerland
   cziege...@apache.org
  
   -
   To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
   For additional commands, e-mail: users-h...@felix.apache.org
  
  
  
  
   --
   M.Sc. Thomas Driessen
   Software Methodologies for Distributed Systems
   Institute of Computer Science
   University of Augsburg
   Universitätsstr. 6a
   86135 Augsburg, Germany
  
   Tel:+49 821 598-2486
   email: thomas.dries...@informatik.uni-augsburg.de
  
 
 
 
  --
  M.Sc. Thomas Driessen
  Software Methodologies for Distributed Systems
  Institute of Computer Science
  University of Augsburg
  Universitätsstr. 6a
  86135 Augsburg, Germany
 
  Tel:+49 821 598-2486
  email: thomas.dries...@informatik.uni-augsburg.de
 



 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect *Liferay, Inc.* http://www.liferay.com
  (@Liferay)
 Board Member  EEG Co-Chair, OSGi Alliance http://osgi.org
 (@OSGiAlliance)

Re: ServletContextListener

[Pierre De Rop]

Thomas,

I suggest to not include the api bundles in the runtime (osgi.enterprise,
and osgi.residential), which should only be used at build time, not at
runtime.

so, can you please remove them and also add event admin, metatype, and log
service, like this:

1|Active |1|Apache Felix Bundle Repository (2.0.4)
2|Active |1|Apache Felix Configuration Admin Service (1.8.4)
3|Active |1|Apache Felix Gogo Command (0.14.0)
4|Active |1|Apache Felix Gogo Runtime (0.16.2)
5|Active |1|Apache Felix Gogo Shell (0.10.0)
6|Active |1|Apache Felix Http Api (3.0.0.SNAPSHOT)
7|Active |1|Apache Felix Http Jetty (3.0.3.SNAPSHOT)
8|Active |1|Apache Felix Servlet API (1.1.1.SNAPSHOT)
9|Active |1|Apache Felix Metatype Service (1.0.12)
   10|Active |1|Apache Felix EventAdmin (1.4.2)
   11|Active |1|Apache Felix Log Service (1.0.1)

(by the way, the  integration tests are failing when building jetty, and I
had to use -Dmaven.test.skip=true in order to build Http Jetty).


cheers;
/Pierre


On Tue, May 12, 2015 at 4:56 PM, Thomas Driessen thomas.dries...@ds-lab.org
 wrote:

 Hey,

 First: Thanks for all your advices.

 I tried the Property as Pierre mentioned, but still my setup is not
 recognizing my SCL.
 I'll copy my console printout so maybe you can spot something wrong with my
 setup:


 2015-05-12 16:32:38.153:INFO::main: Logging initialized @998ms
 2015-05-12 16:32:38.193:INFO:oejs.Server:main: jetty-9.2.9.v20150224
 
 Welcome to Apache Felix Gogo

 g! 2015-05-12 16:32:38.254:INFO:oejsh.ContextHandler:main: Started
 o.e.j.s.ServletContextHandler@7c417213{/,null,AVAILABLE}
 2015-05-12 16:32:38.254:INFO:oejs.Server:main: Started @1092ms
 2015-05-12 16:32:38.325:INFO:oejs.ServerConnector:main: Started
 ServerConnector@7b355613{HTTP/1.1}{0.0.0.0:8080}
 [INFO] Started Jetty 9.2.9.v20150224 at port(s) HTTP:8080 on context path /
 Hello
 lb
 START LEVEL 1
ID|State  |Level|Name
 0|Active |0|System Bundle (5.1.0.SNAPSHOT)
 1|Active |1|Apache Felix Configuration Admin Service (1.8.0)
 2|Active |1|Apache Felix Dependency Manager (4.0.1)
 3|Active |1|Apache Felix Dependency Manager Runtime (4.0.1)
 4|Active |1|Apache Felix Dependency Manager Shell (4.0.1)
 5|Active |1|Apache Felix Gogo Command (0.14.0)
 6|Active |1|Apache Felix Gogo Runtime (0.10.0)
 7|Active |1|Apache Felix Gogo Shell (0.10.0)
 8|Active |1|Apache Felix Http Api (3.0.0.SNAPSHOT)
 9|Active |1|Apache Felix Http Jetty (3.0.3.SNAPSHOT)
10|Active |1|Apache Felix Servlet API (1.1.0)
11|Active |1|osgi.enterprise (4.2.0.201003190513)
12|Active |1|osgi.residential (4.3.0.20022239)
13|Active |1|testit.test (0.0.0.201505121432)
 g! dm
 [3] org.apache.felix.dependencymanager.runtime
  [0] org.apache.felix.dm.runtime.DependencyManagerRuntime registered
 active (DependencyManager-Component=*) bundle optional available
 org.osgi.service.packageadmin.PackageAdmin service required available
 org.osgi.service.log.LogService service optional unavailable
 [13] testit.test
  [1]
 javax.servlet.ServletContextListener(osgi.http.whiteboard.listener=true)
 registered

 Bundle [13] is merely my SCL:

 @Component(properties =
 @Property(name=osgi.http.whiteboard.listener,value=true))
 public class MyContextListener implements ServletContextListener {

 @Override
 public void contextDestroyed(ServletContextEvent arg0) {
 // TODO Auto-generated method stub
 System.out.println(MyContextListener.contextDestroyed());
 }

 @Override
 public void contextInitialized(ServletContextEvent arg0) {
 // TODO Auto-generated method stub
 System.out.println(MyContextListener.contextInitialized());
 }
  @Start
 public void start(){
 System.out.println(Hello);
 }
 }


 I tried the same Setup with http.whiteboard and http.basic explicitly added
 to my runrequirements, but neihter of those worked.


 Two small notes:
 1) the mentioned property osgi.http.whiteboard.listener is never
 mentioned in RFC-189 - should it be mentioned?
 2) Two dependency chains of http.jetty.3.0.3.SNAPSHOT leads to two jetty
 bundles being automatically resolved by bndtools.

 The 1st chain is: jetty.3.0.3 - org.osgi.metatype.1.1.0 -
 osgi.enterprise.4.2.0 -  felix.http.jetty.2.2.2
 The 2nd chain is: jetty.3.0.3 - org.osgi.useradmin.1.1.0 -
 osgi.enterprise.4.2.0 -  felix.http.jetty.2.2.2

 Is this an intended behaviour?

 Best regards ant thanks for your patience,
 Thomas

 2015-05-12 15:43 GMT+02:00 Pierre De Rop pierre.de...@gmail.com:

  Hello Thomas,
 
  if you are using DM annotations, you can try to add the service property
  mentioned by Raymond using the following:
 
  @Component(properties = @Property(name = osgi.http.whiteboard.listener,
  value = true))
  public class MyContextListener

Re: ServletContextListener

[Pierre De Rop]

... oops, the 3 dm bundles was missing in my previous mail:

0|Active |0|System Bundle (5.0.0)
1|Active |1|Apache Felix Bundle Repository (2.0.4)
2|Active |1|Apache Felix Configuration Admin Service (1.8.4)
3|Active |1|Apache Felix Dependency Manager (4.0.1)
4|Active |1|Apache Felix Dependency Manager Runtime (4.0.1)
5|Active |1|Apache Felix Dependency Manager Shell (4.0.1)
6|Active |1|Apache Felix EventAdmin (1.4.2)
7|Active |1|Apache Felix Gogo Command (0.14.0)
8|Active |1|Apache Felix Gogo Runtime (0.16.2)
9|Active |1|Apache Felix Gogo Shell (0.10.0)
   10|Active |1|Apache Felix Http Api (3.0.0.SNAPSHOT)
   11|Active |1|Apache Felix Http Jetty (3.0.3.SNAPSHOT)
   12|Active |1|Apache Felix Servlet API (1.1.1.SNAPSHOT)
   13|Active |1|Apache Felix Log Service (1.0.1)
   14|Active |1|Apache Felix Metatype Service (1.0.12)


/Pierre

On Tue, May 12, 2015 at 5:30 PM, Pierre De Rop pierre.de...@gmail.com
wrote:

 Thomas,

 I suggest to not include the api bundles in the runtime (osgi.enterprise,
 and osgi.residential), which should only be used at build time, not at
 runtime.

 so, can you please remove them and also add event admin, metatype, and log
 service, like this:

 1|Active |1|Apache Felix Bundle Repository (2.0.4)
 2|Active |1|Apache Felix Configuration Admin Service (1.8.4)
 3|Active |1|Apache Felix Gogo Command (0.14.0)
 4|Active |1|Apache Felix Gogo Runtime (0.16.2)
 5|Active |1|Apache Felix Gogo Shell (0.10.0)
 6|Active |1|Apache Felix Http Api (3.0.0.SNAPSHOT)
 7|Active |1|Apache Felix Http Jetty (3.0.3.SNAPSHOT)
 8|Active |1|Apache Felix Servlet API (1.1.1.SNAPSHOT)
 9|Active |1|Apache Felix Metatype Service (1.0.12)
10|Active |1|Apache Felix EventAdmin (1.4.2)
11|Active |1|Apache Felix Log Service (1.0.1)

 (by the way, the  integration tests are failing when building jetty, and I
 had to use -Dmaven.test.skip=true in order to build Http Jetty).


 cheers;
 /Pierre


 On Tue, May 12, 2015 at 4:56 PM, Thomas Driessen 
 thomas.dries...@ds-lab.org wrote:

 Hey,

 First: Thanks for all your advices.

 I tried the Property as Pierre mentioned, but still my setup is not
 recognizing my SCL.
 I'll copy my console printout so maybe you can spot something wrong with
 my
 setup:


 2015-05-12 16:32:38.153:INFO::main: Logging initialized @998ms
 2015-05-12 16:32:38.193:INFO:oejs.Server:main: jetty-9.2.9.v20150224
 
 Welcome to Apache Felix Gogo

 g! 2015-05-12 16:32:38.254:INFO:oejsh.ContextHandler:main: Started
 o.e.j.s.ServletContextHandler@7c417213{/,null,AVAILABLE}
 2015-05-12 16:32:38.254:INFO:oejs.Server:main: Started @1092ms
 2015-05-12 16:32:38.325:INFO:oejs.ServerConnector:main: Started
 ServerConnector@7b355613{HTTP/1.1}{0.0.0.0:8080}
 [INFO] Started Jetty 9.2.9.v20150224 at port(s) HTTP:8080 on context path
 /
 Hello
 lb
 START LEVEL 1
ID|State  |Level|Name
 0|Active |0|System Bundle (5.1.0.SNAPSHOT)
 1|Active |1|Apache Felix Configuration Admin Service (1.8.0)
 2|Active |1|Apache Felix Dependency Manager (4.0.1)
 3|Active |1|Apache Felix Dependency Manager Runtime (4.0.1)
 4|Active |1|Apache Felix Dependency Manager Shell (4.0.1)
 5|Active |1|Apache Felix Gogo Command (0.14.0)
 6|Active |1|Apache Felix Gogo Runtime (0.10.0)
 7|Active |1|Apache Felix Gogo Shell (0.10.0)
 8|Active |1|Apache Felix Http Api (3.0.0.SNAPSHOT)
 9|Active |1|Apache Felix Http Jetty (3.0.3.SNAPSHOT)
10|Active |1|Apache Felix Servlet API (1.1.0)
11|Active |1|osgi.enterprise (4.2.0.201003190513)
12|Active |1|osgi.residential (4.3.0.20022239)
13|Active |1|testit.test (0.0.0.201505121432)
 g! dm
 [3] org.apache.felix.dependencymanager.runtime
  [0] org.apache.felix.dm.runtime.DependencyManagerRuntime registered
 active (DependencyManager-Component=*) bundle optional available
 org.osgi.service.packageadmin.PackageAdmin service required available
 org.osgi.service.log.LogService service optional unavailable
 [13] testit.test
  [1]
 javax.servlet.ServletContextListener(osgi.http.whiteboard.listener=true)
 registered

 Bundle [13] is merely my SCL:

 @Component(properties =
 @Property(name=osgi.http.whiteboard.listener,value=true))
 public class MyContextListener implements ServletContextListener {

 @Override
 public void contextDestroyed(ServletContextEvent arg0) {
 // TODO Auto-generated method stub
 System.out.println(MyContextListener.contextDestroyed());
 }

 @Override
 public void contextInitialized(ServletContextEvent arg0) {
 // TODO Auto-generated method stub
 System.out.println

Re: SCR Annotations BndTools: Service-Component entry can not be located in JAR

[Pierre De Rop]

Hello Bernd,

Sorry for this, indeed I just reproduced the issue with bndtools 2.4.1 (but
as far as I remember, the tutorial worked fine with previous bndtools
versions, or may be there is a regression somewhere).

I will investigate this and will get back to you asap.

PS: if you are using Apache Scr annotations, there is no need to supply the
-dsannotations:  *, which is only required when using standard scr
annotations, not scrplugin annotation).



best regards;
/Pierre



On Thu, Mar 26, 2015 at 3:38 AM, Bernd Prager be...@prager.ws wrote:

 Hello.

 I am walking to the tutorial here: http://felix.apache.org/
 documentation/subprojects/apache-felix-maven-scr-plugin/
 apache-felix-scr-bndtools-use.html

 Everything goes according to plan until the very end, when I get hit with
 the error message:
 Service-Component entry can not be located in JAR: 
 OSGI-INF/greeting.impl.GreetingImpl.xml~
   bnd.bnd /greetingUnknownBndtools Problem Marker

 The created directory structure looks like:
 ./.classpath
 ./.gitignore
 ./.project
 ./.settings
 ./.settings/org.eclipse.jdt.core.prefs
 ./bin
 ./bin/greeting
 ./bin/greeting/api
 ./bin/greeting/api/Greeting.class
 ./bin/greeting/impl
 ./bin/greeting/impl/GreetingImpl.class
 ./bin/OSGI-INF
 ./bin/OSGI-INF/greeting.impl.GreetingImpl.xml
 ./bin_test
 ./bnd.bnd
 ./generated
 ./launch.bndrun
 ./src
 ./src/greeting
 ./src/greeting/api
 ./src/greeting/api/Greeting.java
 ./src/greeting/impl
 ./src/greeting/impl/GreetingImpl.java
 ./test

 Also the generated metatype descriptor greeting.impl.GreetingImpl.xml
 looks ok to me:

 ?xml version=1.0 encoding=UTF-8?
 scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0;
 immediate=true name=greeting.impl.GreetingImpl activate=start
 implementation class=greeting.impl.GreetingImpl/
 service servicefactory=false
 provide interface=greeting.api.Greeting/
 /service
 property name=service.pid value=greeting.impl.GreetingImpl/
 /scr:component

 The bnd.bnd file is:
 -buildpath:  \
 osgi.core,\
 osgi.cmpn,\
 biz.aQute.bnd.annotation,\
 ${junit}
 Bundle-Version: 0.0.0.${tstamp}
 -buildpath: ${plugin-dir}/org.apache.felix.scr.bnd/org.apache.
 felix.scr.bnd-1.3.1-SNAPSHOT.jar;version=file
 -plugin: org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;log=debug
 Private-Package: greeting.impl
 Export-Package: greeting.api
 -dsannotations:  \
 *
 javac.source = 1.7
 javac.target = 1.7


 Any ideas what might have gone wrong?

 Thank you for any help,
 -- Bernd

 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: SCR Annotations BndTools: Service-Component entry can not be located in JAR

[Pierre De Rop]

Ok, Bernd;

I understand what is going on: now with BndTools 2.4.1 and with latest
bndtools,  the SCR bnd plugin is now invoked twice (i don't know the reason
why).

So, I will commit a quick fix so you can go ahead with the trunk version.


best regards;
/Pierre

On Thu, Mar 26, 2015 at 9:18 AM, Pierre De Rop pierre.de...@gmail.com
wrote:

 Hello Bernd,

 Sorry for this, indeed I just reproduced the issue with bndtools 2.4.1
 (but as far as I remember, the tutorial worked fine with previous bndtools
 versions, or may be there is a regression somewhere).

 I will investigate this and will get back to you asap.

 PS: if you are using Apache Scr annotations, there is no need to supply
 the -dsannotations:  *, which is only required when using standard scr
 annotations, not scrplugin annotation).



 best regards;
 /Pierre



 On Thu, Mar 26, 2015 at 3:38 AM, Bernd Prager be...@prager.ws wrote:

 Hello.

 I am walking to the tutorial here: http://felix.apache.org/
 documentation/subprojects/apache-felix-maven-scr-plugin/
 apache-felix-scr-bndtools-use.html

 Everything goes according to plan until the very end, when I get hit with
 the error message:
 Service-Component entry can not be located in JAR:
 OSGI-INF/greeting.impl.GreetingImpl.xml~bnd.bnd /greeting
 UnknownBndtools Problem Marker

 The created directory structure looks like:
 ./.classpath
 ./.gitignore
 ./.project
 ./.settings
 ./.settings/org.eclipse.jdt.core.prefs
 ./bin
 ./bin/greeting
 ./bin/greeting/api
 ./bin/greeting/api/Greeting.class
 ./bin/greeting/impl
 ./bin/greeting/impl/GreetingImpl.class
 ./bin/OSGI-INF
 ./bin/OSGI-INF/greeting.impl.GreetingImpl.xml
 ./bin_test
 ./bnd.bnd
 ./generated
 ./launch.bndrun
 ./src
 ./src/greeting
 ./src/greeting/api
 ./src/greeting/api/Greeting.java
 ./src/greeting/impl
 ./src/greeting/impl/GreetingImpl.java
 ./test

 Also the generated metatype descriptor greeting.impl.GreetingImpl.xml
 looks ok to me:

 ?xml version=1.0 encoding=UTF-8?
 scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0;
 immediate=true name=greeting.impl.GreetingImpl activate=start
 implementation class=greeting.impl.GreetingImpl/
 service servicefactory=false
 provide interface=greeting.api.Greeting/
 /service
 property name=service.pid value=greeting.impl.GreetingImpl/
 /scr:component

 The bnd.bnd file is:
 -buildpath:  \
 osgi.core,\
 osgi.cmpn,\
 biz.aQute.bnd.annotation,\
 ${junit}
 Bundle-Version: 0.0.0.${tstamp}
 -buildpath: ${plugin-dir}/org.apache.felix.scr.bnd/org.apache.
 felix.scr.bnd-1.3.1-SNAPSHOT.jar;version=file
 -plugin: org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;log=debug
 Private-Package: greeting.impl
 Export-Package: greeting.api
 -dsannotations:  \
 *
 javac.source = 1.7
 javac.target = 1.7


 Any ideas what might have gone wrong?

 Thank you for any help,
 -- Bernd

 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: SCR Annotations BndTools: Service-Component entry can not be located in JAR

[Pierre De Rop]

I just created a jira issue (FELIX-4836) and committed a candidate fix in
revision 1669348.
Also, I had to fix some wrong versions in the bnd and scrtask pom.xml
files: now these two poms are depending on org.apache.felix.scr.annotations
with version=1.9.11-SNAPSHOT instead of old 1.9.9-SNAPSHOT.

You can now recompile the scrplugin project from the trunk. To rebuid the
trunk:

cd /tmp/
svn checkout http://svn.apache.org/repos/asf/felix/trunk/scrplugin scrplugin
cd scrplugin
mvn clean package -Dmaven.test.skip=true

Then copy bnd-scr-plugin/target/org.apache.felix.scr.bnd-1.3.1-SNAPSHOT.jar
to your workspace bndtools project, in
cnf/plugins/org.apache.felix.scr.bnd/ directory, and update the bndtools
plugin path and the -buildpath options in order to use the 1.3.1-SNAPSHOT
version instead of the 1.3.0 snapshot.

Hope it will work in your environment (I just tested it).

cheers
/Pierre

On Thu, Mar 26, 2015 at 12:46 PM, Bernd Prager be...@prager.ws wrote:

 Thank you very much Pierre for the quick response. Good job.

 Sent from my iPhone

  On Mar 26, 2015, at 7:30 AM, Pierre De Rop pierre.de...@gmail.com
 wrote:
 
  Ok, Bernd;
 
  I understand what is going on: now with BndTools 2.4.1 and with latest
  bndtools,  the SCR bnd plugin is now invoked twice (i don't know the
 reason
  why).
 
  So, I will commit a quick fix so you can go ahead with the trunk version.
 
 
  best regards;
  /Pierre
 
  On Thu, Mar 26, 2015 at 9:18 AM, Pierre De Rop pierre.de...@gmail.com
  wrote:
 
  Hello Bernd,
 
  Sorry for this, indeed I just reproduced the issue with bndtools 2.4.1
  (but as far as I remember, the tutorial worked fine with previous
 bndtools
  versions, or may be there is a regression somewhere).
 
  I will investigate this and will get back to you asap.
 
  PS: if you are using Apache Scr annotations, there is no need to supply
  the -dsannotations:  *, which is only required when using standard scr
  annotations, not scrplugin annotation).
 
 
 
  best regards;
  /Pierre
 
 
 
  On Thu, Mar 26, 2015 at 3:38 AM, Bernd Prager be...@prager.ws wrote:
 
  Hello.
 
  I am walking to the tutorial here: http://felix.apache.org/
  documentation/subprojects/apache-felix-maven-scr-plugin/
  apache-felix-scr-bndtools-use.html
 
  Everything goes according to plan until the very end, when I get hit
 with
  the error message:
  Service-Component entry can not be located in JAR:
  OSGI-INF/greeting.impl.GreetingImpl.xml~bnd.bnd /greeting
  UnknownBndtools Problem Marker
 
  The created directory structure looks like:
  ./.classpath
  ./.gitignore
  ./.project
  ./.settings
  ./.settings/org.eclipse.jdt.core.prefs
  ./bin
  ./bin/greeting
  ./bin/greeting/api
  ./bin/greeting/api/Greeting.class
  ./bin/greeting/impl
  ./bin/greeting/impl/GreetingImpl.class
  ./bin/OSGI-INF
  ./bin/OSGI-INF/greeting.impl.GreetingImpl.xml
  ./bin_test
  ./bnd.bnd
  ./generated
  ./launch.bndrun
  ./src
  ./src/greeting
  ./src/greeting/api
  ./src/greeting/api/Greeting.java
  ./src/greeting/impl
  ./src/greeting/impl/GreetingImpl.java
  ./test
 
  Also the generated metatype descriptor greeting.impl.GreetingImpl.xml
  looks ok to me:
 
  ?xml version=1.0 encoding=UTF-8?
  scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0;
  immediate=true name=greeting.impl.GreetingImpl activate=start
 implementation class=greeting.impl.GreetingImpl/
 service servicefactory=false
 provide interface=greeting.api.Greeting/
 /service
 property name=service.pid value=greeting.impl.GreetingImpl/
  /scr:component
 
  The bnd.bnd file is:
  -buildpath:  \
 osgi.core,\
 osgi.cmpn,\
 biz.aQute.bnd.annotation,\
 ${junit}
  Bundle-Version: 0.0.0.${tstamp}
  -buildpath: ${plugin-dir}/org.apache.felix.scr.bnd/org.apache.
  felix.scr.bnd-1.3.1-SNAPSHOT.jar;version=file
  -plugin:
 org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;log=debug
  Private-Package: greeting.impl
  Export-Package: greeting.api
  -dsannotations:  \
 *
  javac.source = 1.7
  javac.target = 1.7
 
 
  Any ideas what might have gone wrong?
 
  Thank you for any help,
  -- Bernd
 
  -
  To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
  For additional commands, e-mail: users-h...@felix.apache.org
 

 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: SCR Annotations BndTools: Service-Component entry can not be located in JAR

[Pierre De Rop]

cool !
:-)


On Thu, Mar 26, 2015 at 4:17 PM, Bernd Prager be...@prager.ws wrote:

 I confirm, it's working.
 Thank you!


 On 26.03.2015 08:26, Pierre De Rop wrote:

 I just created a jira issue (FELIX-4836) and committed a candidate fix in
 revision 1669348.
 Also, I had to fix some wrong versions in the bnd and scrtask pom.xml
 files: now these two poms are depending on org.apache.felix.scr.
 annotations
 with version=1.9.11-SNAPSHOT instead of old 1.9.9-SNAPSHOT.

 You can now recompile the scrplugin project from the trunk. To rebuid the
 trunk:

 cd /tmp/
 svn checkout http://svn.apache.org/repos/asf/felix/trunk/scrplugin
 scrplugin
 cd scrplugin
 mvn clean package -Dmaven.test.skip=true

 Then copy bnd-scr-plugin/target/org.apache.felix.scr.bnd-1.3.1-
 SNAPSHOT.jar
 to your workspace bndtools project, in
 cnf/plugins/org.apache.felix.scr.bnd/ directory, and update the bndtools
 plugin path and the -buildpath options in order to use the 1.3.1-SNAPSHOT
 version instead of the 1.3.0 snapshot.

 Hope it will work in your environment (I just tested it).

 cheers
 /Pierre

 On Thu, Mar 26, 2015 at 12:46 PM, Bernd Prager be...@prager.ws wrote:

  Thank you very much Pierre for the quick response. Good job.

 Sent from my iPhone

  On Mar 26, 2015, at 7:30 AM, Pierre De Rop pierre.de...@gmail.com
 wrote:
 
  Ok, Bernd;
 
  I understand what is going on: now with BndTools 2.4.1 and with latest
  bndtools,  the SCR bnd plugin is now invoked twice (i don't know the
 reason
  why).
 
  So, I will commit a quick fix so you can go ahead with the trunk
 version.
 
 
  best regards;
  /Pierre
 
  On Thu, Mar 26, 2015 at 9:18 AM, Pierre De Rop pierre.de...@gmail.com
 
  wrote:
 
  Hello Bernd,
 
  Sorry for this, indeed I just reproduced the issue with bndtools 2.4.1
  (but as far as I remember, the tutorial worked fine with previous
 bndtools
  versions, or may be there is a regression somewhere).
 
  I will investigate this and will get back to you asap.
 
  PS: if you are using Apache Scr annotations, there is no need to
 supply
  the -dsannotations:  *, which is only required when using standard scr
  annotations, not scrplugin annotation).
 
 
 
  best regards;
  /Pierre
 
 
 
  On Thu, Mar 26, 2015 at 3:38 AM, Bernd Prager be...@prager.ws
 wrote:
 
  Hello.
 
  I am walking to the tutorial here: http://felix.apache.org/
  documentation/subprojects/apache-felix-maven-scr-plugin/
  apache-felix-scr-bndtools-use.html
 
  Everything goes according to plan until the very end, when I get hit
 with
  the error message:
  Service-Component entry can not be located in JAR:
  OSGI-INF/greeting.impl.GreetingImpl.xml~bnd.bnd /greeting
  UnknownBndtools Problem Marker
 
  The created directory structure looks like:
  ./.classpath
  ./.gitignore
  ./.project
  ./.settings
  ./.settings/org.eclipse.jdt.core.prefs
  ./bin
  ./bin/greeting
  ./bin/greeting/api
  ./bin/greeting/api/Greeting.class
  ./bin/greeting/impl
  ./bin/greeting/impl/GreetingImpl.class
  ./bin/OSGI-INF
  ./bin/OSGI-INF/greeting.impl.GreetingImpl.xml
  ./bin_test
  ./bnd.bnd
  ./generated
  ./launch.bndrun
  ./src
  ./src/greeting
  ./src/greeting/api
  ./src/greeting/api/Greeting.java
  ./src/greeting/impl
  ./src/greeting/impl/GreetingImpl.java
  ./test
 
  Also the generated metatype descriptor greeting.impl.GreetingImpl.xml
  looks ok to me:
 
  ?xml version=1.0 encoding=UTF-8?
  scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0;
  immediate=true name=greeting.impl.GreetingImpl activate=start
 implementation class=greeting.impl.GreetingImpl/
 service servicefactory=false
 provide interface=greeting.api.Greeting/
 /service
 property name=service.pid value=greeting.impl.GreetingImpl/
  /scr:component
 
  The bnd.bnd file is:
  -buildpath:  \
 osgi.core,\
 osgi.cmpn,\
 biz.aQute.bnd.annotation,\
 ${junit}
  Bundle-Version: 0.0.0.${tstamp}
  -buildpath: ${plugin-dir}/org.apache.felix.scr.bnd/org.apache.
  felix.scr.bnd-1.3.1-SNAPSHOT.jar;version=file
  -plugin:
 org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;log=debug
  Private-Package: greeting.impl
  Export-Package: greeting.api
  -dsannotations:  \
 *
  javac.source = 1.7
  javac.target = 1.7
 
 
  Any ideas what might have gone wrong?
 
  Thank you for any help,
  -- Bernd
 
  
 -
  To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
  For additional commands, e-mail: users-h...@felix.apache.org
 


 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org




 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

[ANN] Apache Felix Dependency Manager 4 (top-level release R2) Released

[Pierre De Rop]

The Felix team is pleased to announce the release of the Apache Felix
Dependency Manager 4 top-level release R2.

This R2 release provides an important fix for the previous R1 release which
had a bug regarding Iterable autoconfig fields.

This release is available from:

http://felix.apache.org/site/downloads.cgi

The instructions to build the Dependency Manager from the source
distribution can be found here:


http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/development.html


Release Notes - Version org.apache.felix.dependencymanager-r2

Bug:

[FELIX-4832] - ClassCastException with autoconfig Iterable fields
[FELIX-4833] - Revisit some javadocs in the DM annotations.

Enjoy!

-The Felix team

Re: DependencyManager: notify third party object of changed adaptee properties

[Pierre De Rop]

Hello Philipp,

I think that currently, it is not possible to specify a third party
callback object to be notified when the adaptee services properties are
changed, and only your adapter will be notified.

One possible alternative could consist in letting the adapter impl provide
an adapted interface and you could then track the adapted interface itself,
because when the adaptee (Device) service properties are changed, the
Device changed properties are then also propagated to the service
properties provided by the adapter (if the adapter provides an adapted
service).

For example, when you create your adapter, you can manage to let it provide
a service (like 'DeviceAdapter' service):

mgr.add(createAdapterService(Device.class,null)
   .setImplementation(DeviceAdapter.class)
   .setInterface(DeviceAdapter.class, null)
   .setCallbacks(init, start, stop, destroy));

Then you could manage to define your DeviceManager as a DM component, and
that component could listen to all DeviceAdapter services, including
propagated service properties change events:

mgr.add(createComponent()
   .setImplementation(DeviceManager.class)
   .add(createServiceDependency(DeviceAdapter.class).setRequired(true)
.setCallbacks(added, changed, removed)));

then your DeviceManager could be called back it its changed method when a
DeviceAdapter propagates its adapted Device service properties change
events.

This should work, but I don't know if this would be compatible with your
current application design ?
(maybe you could describe a but what is doing your DeviceManager ?)

Now unfortunately, regarding your last question, I think that the work
around won't work, because when the adaptee services comes up, the first
dependency (the one that your work around has modified) is removed and
replaced by another dependency (see the AdapterServiceImpl.
AdapterImpl.createService() method()).

Now, if you really need to be able to specify a callback instance to be
called when the adaptee service properties are changed (Device), then can
you please create a Jira issue for it, and I will add a
createAdapterService signature allowing to specify a callbackObject,
similar to what is currently done int the createResourceAdapterService
methods.
(Marcel, would you be OK for this new feature ?)

kind regards;
/Pierre

On Wed, Oct 15, 2014 at 2:52 PM, Bulu b...@romandie.com wrote:

 Addition to my own question:
 I came up with the following, but the callbacks seem not to get called on
 the deviceManager...

 Component adapter = createAdapterService(Device.class,null)
   .setImplementation(DeviceAdapter.class)
   .setCallbacks(deviceManager, INIT_METHOD, START_METHOD, STOP_METHOD,
 DESTROY_METHOD);

 // Ugly: supposing the adapter has always the adaptee as first service
 dependency
 ServiceDependency dep = (ServiceDependency) adapter.getDependencies().get(
 0);
 logger.debug(Dependency is {}, dep); // OK, in my tests it's the right
 dependency
 dep.setCallbacks(deviceManager, BIND_METHOD, CHANGED_METHOD,
 UNBIND_METHOD);
 mgr.add(adapter);

 Is this the right way?

 Regards Philipp


 On 15.10.2014 14:12, Bulu wrote:

 Hello All

 Using Dependency Manager, I declare adapters like this:
 mgr.add(createAdapterService(Device.class,null)
 .setImplementation(DeviceAdapter.class)
   .setCallbacks(deviceManager, init, start, stop, destroy));

 So deviceManager gets notified when the adapters appear. Now I also want
 deviceManager to be notified when the properties of any of the adaptees
 (Device.class) change (need to update the UI).

 For normal ServiceDependency I can specify callbacks to be called on a
 third party object with
   ServiceDependency.setCallbacks(Object instance, String added, String
 changed, String removed);

 For adapters and I can specify the callbacks, but only calling the
 adapter itself:
   createAdapterService(Device.class.name, null, add, change,
 remove)

 How can I tell the adapter to use callbacks on a third party object
 (deviceManager) when the adaptee's properties change?

 Thanks  regards
   Philipp





 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: DependencyManager: start order relevant for adapters?

[Pierre De Rop]

Hello Philipp;


On Wed, Oct 1, 2014 at 9:34 AM, Bulu b...@romandie.com wrote:

 Hello Pierre
 Thanks. Indeed my additional conditions were not added atomically.

 Should the setInstanceBound(true) be called on each dependency separately
 before being added to the list?
 Does setInstanceBound() make only sense on adapters or should I call it
 for all type of components when dependencies are added in init()? (the
 JavaDoc  Sets this dependency to be instance bound or not. is not so
 helpful).

 Is it only for adapters that additional conditions must be added
 atomically or for all type of components?


for all types of components (and for all required dependencies defined
within the init method); and you can then add each dependency in the list
safely; then after, you can add the list atomically, using
component.add(List dependencies) method.

For instance:

class MyComponent {
void init(Component c) {
DependencyManager dm = c.getDependencyManager();
List l = new ArrayList();

l.add(dm.createServiceDependency()
 .setInstanceBound(true)
 .setService(OtherService1.class, (name=xxx))
 .setRequired(true));

l.add(dm.createServiceDependency()
 .setInstanceBound(true)
 .setService(OtherService2.class, (name=yyy))
 .setRequired(true));

// atomically adds the list to our component
c.add(l);
}


To clarify, in dm 3.2.0, when you add some extra-dependencies from your
init() method, the setInstanceBound(true) method ensures that when your
component is being created (because it has been injected with all initial
required dependencies defined from the Activator), then it then won't be
immediately destroyed if the dynamically added dependencies from the init
method are not yet available.

But in the DM 4.0.0, using the setInstanceBound method for all init's
dependencies has been relaxed it is not necessary to use it anymore. But we
also changed the add method, using varargs list of dependencies, so you can
define multiple extra-dependencies without using a List:

// Using DM 4.0

class MyComponent {
void init(Component component) {
DependencyManager dm = c.getDependencyManager();

// Atomically adds two dependencies in our component.

component.add(
 dm.createServiceDependency()
 .setInstanceBound(true)
 .setService(OtherService1.class, (name=xxx))
 .setRequired(true),
 dm.createServiceDependency()
 .setInstanceBound(true)
 .setService(OtherService2.class, (name=yyy))
 .setRequired(true))
);
}
}

kind regards;
/pierre

Regards Philipp



 On 30.09.2014 23:03, Pierre De Rop wrote:

 Hello Philipp,

 I don't know if this may help, but if you are using DM 3.2.0, please don't
 forget that if you are declaring some extra-service dependencies from your
 init() methods (in your adapter for example), then you have to declare
 them
 as instance bound dependencies: you have to make a call to the
 setInstanceBound(true) method on the extra dependency declared from your
 init methods.

 And also, if you have more than one dependency to add in your init()
 method, then you should add them atomically using a list of Dependencies,
 passed to the dm.add(List dependencies) method.

 You can take a look at [1] for an example.

 kind regards;
 /Pierre

 [1]
 http://svn.apache.org/viewvc/felix/trunk/dependencymanager/
 test/src/test/java/org/apache/felix/dm/test/integration/api/
 MultipleExtraDependenciesTest.java?revision=1532440view=markup

 On Tue, Sep 30, 2014 at 7:46 PM, Bulu b...@romandie.com wrote:

  Obviously it works great on the small example... :-)
 Ergo: the problem is in my code or more complex than explained...


 On 30.09.2014 19:14, Marcel Offermans wrote:

  On 30 Sep 2014, at 9:50 am, Bulu b...@romandie.com wrote:

   Hi all

 Using DM I declare adapter services like this

 // without filter
 mgr.add(createAdapterService(SomeClass.class,null)
  .setImplementation(...)
  .setCallbacks(...));

 // with filter
 String someFilter = ...
 mgr.add(createAdapterService(OtherClass.class, someFilter))
  .setImplementation(...)
  .setCallbacks(...));

 I notice that, if I first start this adapter bundle and later the
 SomeClass and OtherClass appear, all get picked up correctly and
 forwarded
 to the callbacks.

 However, if first the SomeClass and OtherClass service are present and
 later the Adapter gets started, it only picks up the ones without
 filter
 (in the example the SomeClass, but not the OtherClass services).

 I know the filter is correct, as it does work when done in the right
 order. The services are the same in both cases.

 Has anybody

Re: DependencyManager: start order relevant for adapters?

[Pierre De Rop]

Hello Philipp,

I don't know if this may help, but if you are using DM 3.2.0, please don't
forget that if you are declaring some extra-service dependencies from your
init() methods (in your adapter for example), then you have to declare them
as instance bound dependencies: you have to make a call to the
setInstanceBound(true) method on the extra dependency declared from your
init methods.

And also, if you have more than one dependency to add in your init()
method, then you should add them atomically using a list of Dependencies,
passed to the dm.add(List dependencies) method.

You can take a look at [1] for an example.

kind regards;
/Pierre

[1]
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/test/src/test/java/org/apache/felix/dm/test/integration/api/MultipleExtraDependenciesTest.java?revision=1532440view=markup

On Tue, Sep 30, 2014 at 7:46 PM, Bulu b...@romandie.com wrote:

 Obviously it works great on the small example... :-)
 Ergo: the problem is in my code or more complex than explained...


 On 30.09.2014 19:14, Marcel Offermans wrote:

 On 30 Sep 2014, at 9:50 am, Bulu b...@romandie.com wrote:

  Hi all

 Using DM I declare adapter services like this

 // without filter
 mgr.add(createAdapterService(SomeClass.class,null)
 .setImplementation(...)
 .setCallbacks(...));

 // with filter
 String someFilter = ...
 mgr.add(createAdapterService(OtherClass.class, someFilter))
 .setImplementation(...)
 .setCallbacks(...));

 I notice that, if I first start this adapter bundle and later the
 SomeClass and OtherClass appear, all get picked up correctly and forwarded
 to the callbacks.

 However, if first the SomeClass and OtherClass service are present and
 later the Adapter gets started, it only picks up the ones without filter
 (in the example the SomeClass, but not the OtherClass services).

 I know the filter is correct, as it does work when done in the right
 order. The services are the same in both cases.

 Has anybody else noticed this? Is the problem in my code?

 Not sure, could you provide a small working example or test?

 Greetings, Marcel


 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: Dependency Manager: publish adapter with properties of the adapted service

[Pierre De Rop]

Hi Philipp;

On Thu, Sep 25, 2014 at 8:54 AM, Bulu b...@romandie.com wrote:

 Hello all

 (sorry for asking so many questions - they come-up as I write my code)


no problem at all :-)



 In DM, how can you adapt a certain service and re-publish under a new
 interface using some properties of the adapted service?


When you define an adapter (DeviceConsumer), the service properties of the
adapted service (Device) are automatically propagated to the new adapter
interface (DeviceConsumer).






 Example:
 interface Device{
   int getId();
 }
 each published with property
 device.id=xxx
 where xxx is the int from getId()

 elsewhere, we want to adapt the Device services
 mgr.add(createAdapterService(Device.class,null)
   .setImplementation(DeviceConsumerImpl.class)
   .setInterface(DeviceConsumer.class.getName(), props);

 here, props should again contain the device.id=xxx value, but its not
 yet available, so the above cannot work.


since the adapted service properties are propagated, I think you don't need
to pass a props to the setInterface method; just pass null:

mgr.add(createAdapterService(Device.class,null)
  .setImplementation(DeviceConsumerImpl.class)
  .setInterface(DeviceConsumer.class.getName(), null);

If you pass some properties to the setInterface method, those properties
will be appended to the service properties of the original adapted service,
so in the end the re-publised service will contain the adapted service
properties + the properties you pass to the setInterface methods.



does this help ?


regards
/Pierre


 We could inject it in the service's init method:
 class DeviceConsumerImpl {
   Device d;
   public void init(Component c){
 DictionaryString, Object props = new Hashtable();
 props.put(device.id, d.getId())
 c.setInterface(DeviceConsumer.class.getName(), props);
 }

 but this fails with IllegalStateException (it seems you cannot publish
 (ie. setInterface) a new service while the object is being initialized).

 So how should it be done?

 I came up with a workaround, which is to publish the service at first with
 incomplete properties, and just update them in the init method when the
 values are present. But that seems like a hack... Is there a better way?

 Thanks Philipp





 On 24.09.2014 18:09, Pierre De Rop wrote:

 Hi Philipp;

 see my response, inlined below:


 On Wed, Sep 24, 2014 at 4:46 PM, Bulu b...@romandie.com wrote:

  Hello all

 If the published property of a service is based on a value in the actual
 service object, and that value later changes, how can I update the
 properties using DM?

 Example: You have Device objects (and the corresponding impl)
 public interface Device{
public int getRoom();
public void setRoom(int i);
 }

 Maybe you originally register the device like this

 Device d = new DeviceImpl();
 s.setRoom(12);
 DictionaryString, Object props = new Hashtable();
 props.put(room, d.getRoom());
 mgr.add(createComponent()
 .setImplementation(d)
 .setInterface(Device.class.getName(), props));

 ... later somebody else (maybe a consumer of the service...) calls
 d.setRoom(13)

 How can I update the room property of the service?

 I believe I could keep the Component from start(Component c) and later
 use
 its setServiceProperties() but is that clean/correct?

  This is indeed possible, but alternatively, you could also declare a
 ServiceRegistration field in your implementation class, which will be
 injected once the device service has been registered.
 And later, from the setRoot(int id)  you can then use the service
 registration in order to modify or add some service properties.



  like so:
 class DeviceImpl implements Device {
private Component c;
private int room;
public void start(Component c){
  this.c = c;
}

public void setRoom(int i){
  room = i;
  c.setServiceProperties(c.getServiceProperties().put(room, i));
}
 }

 Is this correct? Is there a better method or pattern to use? Any problems
 to expect from keeping the Component around?

  if you use this pattern instead of using the ServiceRegistration, as
 described before, then yes, it would also work, except that there is a
 little mistake in the above example: the setServiceProperties takes a
 Dictionary as parameter, while the c.getServiceProperties().put(room, i)
 returns an object.

 Since the Component.getServiceProperties() method returns a copy of the
 actual service properties, you could then do like this:

 Dictionary props = component.getServiceProperties();
 props.put(room, i);
 component.setServiceProperties(props);


  Also, what happens when the service consumer which is calling setRoom(),
 is actually filtering on that property, so that his object gets removed
 still while he is calling the method?

  there are two cases:

 1) using DM 3.2.0, if your consumer calls the device.setRoom(int id)
 method, then at the time this methods calls
 component.setServiceProperties(), then the consumer

Re: Dependency Manager: publish adapter with properties of the adapted service

[Pierre De Rop]

Ah ok; I understand.

From your adapter (DeviceConsumerImpl), in the init() method, just call
component.setServiceProperties()  instead of component.setInterface method.

Something like this:

class DeviceConsumerImpl implements DeviceConsumer
void init(Component c) {
DependencyManager dm = c.getDependencyManager();

// add a dynamic dependency on the DeviceParameter ...
c.add(dm.createServiceDependency()
.setService(DeviceParameter.class, (device.id= +
device.getDeviceId() + ))
.setRequired(true));

// Now, set our adapter service properties, which will be appended
to the republished
// adapted service properties !

Hashtable props = new Hashtable();
props.put(EventConstants.EVENT_TOPIC, my/device/events);
props.put(EventConstants.EVENT_FILTER,(device.id= +
device.getDeviceId() + ));
c.setServiceProperties(props);
}

This works with DM 4.0.0, but should also work with DM 3.2.0 (but I did not
have time to test).

regards
/Pierre

On Thu, Sep 25, 2014 at 11:07 AM, Bulu b...@romandie.com wrote:

 Hello Pierre

 My example was too simple, I would like to republish the adapter with
 values from the adapted service, but under new keys.

 Specifically, the new interface is EventHandler and I want to build the
 EVENT_FILTER from the adapted service (ie. Device) properties..


 Dictionary props =new  Hashtable();
 props.put(EventConstants.EVENT_TOPIC, my/device/events);

 props.put(EventConstants.EVENT_FILTER,(device.id=xxx)); // xxx comes
 from the Device instance

 mgr.add(createAdapterService(Device.class,null)
   .setImplementation(DeviceConsumerImpl.class)
   .setInterface(EventHandler.class.getName(), props);

 Philipp


 On 25.09.2014 10:53, Pierre De Rop wrote:

 Hi Philipp;

 On Thu, Sep 25, 2014 at 8:54 AM, Bulu b...@romandie.com wrote:

  Hello all

 (sorry for asking so many questions - they come-up as I write my code)

  no problem at all :-)


  In DM, how can you adapt a certain service and re-publish under a new
 interface using some properties of the adapted service?

  When you define an adapter (DeviceConsumer), the service properties of
 the
 adapted service (Device) are automatically propagated to the new adapter
 interface (DeviceConsumer).





  Example:
 interface Device{
int getId();
 }
 each published with property
 device.id=xxx
 where xxx is the int from getId()

 elsewhere, we want to adapt the Device services
 mgr.add(createAdapterService(Device.class,null)
.setImplementation(DeviceConsumerImpl.class)
.setInterface(DeviceConsumer.class.getName(), props);

 here, props should again contain the device.id=xxx value, but its not
 yet available, so the above cannot work.

  since the adapted service properties are propagated, I think you don't
 need
 to pass a props to the setInterface method; just pass null:

 mgr.add(createAdapterService(Device.class,null)
.setImplementation(DeviceConsumerImpl.class)
.setInterface(DeviceConsumer.class.getName(), null);

 If you pass some properties to the setInterface method, those properties
 will be appended to the service properties of the original adapted
 service,
 so in the end the re-publised service will contain the adapted service
 properties + the properties you pass to the setInterface methods.



 does this help ?


 regards
 /Pierre


  We could inject it in the service's init method:
 class DeviceConsumerImpl {
Device d;
public void init(Component c){
  DictionaryString, Object props = new Hashtable();
  props.put(device.id, d.getId())
  c.setInterface(DeviceConsumer.class.getName(), props);
 }

 but this fails with IllegalStateException (it seems you cannot publish
 (ie. setInterface) a new service while the object is being initialized).

 So how should it be done?

 I came up with a workaround, which is to publish the service at first
 with
 incomplete properties, and just update them in the init method when the
 values are present. But that seems like a hack... Is there a better way?

 Thanks Philipp





 On 24.09.2014 18:09, Pierre De Rop wrote:

  Hi Philipp;

 see my response, inlined below:


 On Wed, Sep 24, 2014 at 4:46 PM, Bulu b...@romandie.com wrote:

   Hello all

 If the published property of a service is based on a value in the
 actual
 service object, and that value later changes, how can I update the
 properties using DM?

 Example: You have Device objects (and the corresponding impl)
 public interface Device{
 public int getRoom();
 public void setRoom(int i);
 }

 Maybe you originally register the device like this

 Device d = new DeviceImpl();
 s.setRoom(12);
 DictionaryString, Object props = new Hashtable();
 props.put(room, d.getRoom());
 mgr.add(createComponent()
  .setImplementation(d)
  .setInterface(Device.class.getName(), props));

 ... later somebody else (maybe a consumer of the service...) calls
 d.setRoom(13)

 How can I update the room property

Re: Dependency Manager: how to update service properties

[Pierre De Rop]

Hi Philipp;

see my response, inlined below:


On Wed, Sep 24, 2014 at 4:46 PM, Bulu b...@romandie.com wrote:

 Hello all

 If the published property of a service is based on a value in the actual
 service object, and that value later changes, how can I update the
 properties using DM?

 Example: You have Device objects (and the corresponding impl)
 public interface Device{
   public int getRoom();
   public void setRoom(int i);
 }

 Maybe you originally register the device like this

 Device d = new DeviceImpl();
 s.setRoom(12);
 DictionaryString, Object props = new Hashtable();
 props.put(room, d.getRoom());
 mgr.add(createComponent()
.setImplementation(d)
.setInterface(Device.class.getName(), props));

 ... later somebody else (maybe a consumer of the service...) calls
 d.setRoom(13)

 How can I update the room property of the service?

 I believe I could keep the Component from start(Component c) and later use
 its setServiceProperties() but is that clean/correct?


This is indeed possible, but alternatively, you could also declare a
ServiceRegistration field in your implementation class, which will be
injected once the device service has been registered.
And later, from the setRoot(int id)  you can then use the service
registration in order to modify or add some service properties.




 like so:
 class DeviceImpl implements Device {
   private Component c;
   private int room;
   public void start(Component c){
 this.c = c;
   }

   public void setRoom(int i){
 room = i;
 c.setServiceProperties(c.getServiceProperties().put(room, i));
   }
 }

 Is this correct? Is there a better method or pattern to use? Any problems
 to expect from keeping the Component around?


if you use this pattern instead of using the ServiceRegistration, as
described before, then yes, it would also work, except that there is a
little mistake in the above example: the setServiceProperties takes a
Dictionary as parameter, while the c.getServiceProperties().put(room, i)
returns an object.

Since the Component.getServiceProperties() method returns a copy of the
actual service properties, you could then do like this:

Dictionary props = component.getServiceProperties();
props.put(room, i);
component.setServiceProperties(props);



 Also, what happens when the service consumer which is calling setRoom(),
 is actually filtering on that property, so that his object gets removed
 still while he is calling the method?


there are two cases:

1) using DM 3.2.0, if your consumer calls the device.setRoom(int id)
method, then at the time this methods calls
component.setServiceProperties(), then the consumer will be synchronously
called in it's changed callback if one has been defined and if the
dependency filter on the device service is still satisfied.

And if the consumer dependency filter is not satisfied anymore, then the
consumer will be synchronously called in its stop callback (because the
consumer is losing the device service, and the consumer component will then
being stopped), and then the consumer unbind(Device) callback will be
called (if defined).

And at this point, you will then return from the intial invocation of the
device.setRoot(int id) method.

2) using DM 4.0.0 (not yet in the trunk, only in sandbox), the same as
above applies except if the
 parallel Dependency Manager is enabled.

Indeed, In DM 4.0.0, you can now optionally register a threadpool in the
service registry, in order to handle all component events concurrently
(service depenency management, and lifecycle callbacks).
So, in this case, when you would call component.setServiceProperties(), or
serviceRegistration.setProperties() method, you would then be
asynchronously called in your consumer.stop / consumer.unbind(Device)
method.

regards;
/Pierre





 Regards Philipp



 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: Dependency Manager: depend on several linked services

[Pierre De Rop]

Hi Philipp;

so;  regarding your first question, the
DependencyManager.createComponent()  method returns a singleton component
(only one instance is created).

But the createAdapterService() method is a bit different: it's a kind of
adapter pattern applied to OSGi services. An adapter is actually a
factory that creates another component on top of an existing service that
is adapted to another interface.

But in the previous example, the DeviceConsumer component is not providing
an interface (because it seems that you don't need this ?). So, if you have
two Devices, then two DeviceConsumer components will be created, and each
one will be bound to a Device/DeviceParameter pair.

I have committed a sample code [1], which is illustrating all this, except
that I adapted the Device interface to a DeviceAccess interface, and the
DeviceConsumer just tracks the DeviceAccess adapted interface (this example
has nothing to do with the OSGi device access spec, which I don't know
about).

Notice that the DeviceAccess adapter service inherits from the Device
service properties (see the DeviceAccessConsumer code).


Regarding your second question, yes you can obtain the service instance
from the Component interface.
But there is an api break between DM 3.2.0 and DM 4.0.0.

in DM 3.2.0, you can get the service instance using component.getService()
method, which returns the Object instance.

but in DM 4.0.0, you will have to call the Component.getInstances() method
which returns all the component instances. When you use a component
implemented with several compositions, then you can have multiple object
instances.

hope this helps;
cheers;

/Pierre


[1]
http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/device/

On Mon, Sep 22, 2014 at 6:04 PM, Bulu b...@romandie.com wrote:

 Hello Pierre
 Yes, this is exactly what I need! Thanks so much.

 A few more questions:
 - How does createAdapterService differ from createComponent, if you don't
 publish any service?

 - When setting custom lifecycle callback methods targetting a separate
 object

 createComponent()
 .setImplementation(Consumer.class)
 ...
 .setCallbacks(myManager, init, start, stop,
 destroy));

 the myManager instance gets the Component object passed in the lifecycle
 methods
 (  start(Component c)  ). Can I get the actual object (here the Consumer
 instance) from this Component?

 Regards Philipp



 On 22.09.2014 17:41, Pierre De Rop wrote:

 Hello Philipp,

 So, let's see if I understand you correctly:

 - you have N Device services (each having a device.id service
 propery).
 - then you have N corresponding DeviceParameter instances, each one also
 having a device.id service property, matching a corresponding Device.
 - and you want to consume each pair of Device / DeviceParameter (having
 both the same value for the device.id service property).

 So, one possible solution (if I my understanding is correct) could consist
 in implementing your Consumer as a DependencyManager Adapter component,
 and this adapter would then define dynamically from it's init() method an
 extra dependency on the DeviceParameter, by reusing the id from the
 original Device service.

 Let's see what it could look like using a sample code. First here are the
 sample for the Device/DeviceParameter related classes:

 public interface Device {
  int getDeviceId();
 }

 public class DeviceImpl implements Device {
  final int id;

  DeviceImpl(int id) {
  this.id = id;
  }

  @Override
  public int getDeviceId() {
  return id;
  }
 }

 public interface DeviceParameter {
  int getDeviceId();
 }

 public class DeviceParameterImpl implements DeviceParameter {
  final int id;

  DeviceParameterImpl(int id) {
  this.id = id;
  }

  @Override
  public int getDeviceId() {
  return id;
  }
 }

 Now, let's define an Activator which creates two pair of
 Device/DeviceParameter:


 public class Activator extends DependencyActivatorBase {
  @Override
  public void init(BundleContext context, DependencyManager dm) throws
 Exception {
  createDeviceAndParameter(dm, 1);
  createDeviceAndParameter(dm, 2);
  }

  private void createDeviceAndParameter(DependencyManager dm, int id)
 {
  HashtableString, Object props = new Hashtable();
  props.put(device.id, id);
  dm.add(createComponent()
  .setImplementation(new
 DeviceImpl(id)).setInterface(Device.class.getName(), props));

  props = new Hashtable();
  props.put(device.id, id);
  dm.add(createComponent()
  .setImplementation(new
 DeviceParameterImpl(id)).setInterface(DeviceParameter.class.getName(),
 props));
  }
 }

 Now, here is the DeviceConsumer: First, let's add a declaration

Re: Dependency Manager: depend on several linked services

[Pierre De Rop]

yes Philipp, this is correct.

kind regards
/pierre


On Tue, Sep 23, 2014 at 9:00 AM, Bulu b...@romandie.com wrote:

 Ok, if I understand correctly:
 - createComponent only ever builds one component, as soon as the first
 tracked service (ie. dependency) appears. (1 to n relation)
 - createAdapter creates a new component *for each* tracked service which
 appears. (n to n relation)

 Note: I'm on DM 3.2 for now, so Component.getService() is what I was
 looking for.

 Thanks  regards Philipp


 On 23.09.2014 08:41, Pierre De Rop wrote:

 Hi Philipp;

 so;  regarding your first question, the
 DependencyManager.createComponent()  method returns a singleton component
 (only one instance is created).

 But the createAdapterService() method is a bit different: it's a kind of
 adapter pattern applied to OSGi services. An adapter is actually a
 factory that creates another component on top of an existing service that
 is adapted to another interface.

 But in the previous example, the DeviceConsumer component is not providing
 an interface (because it seems that you don't need this ?). So, if you
 have
 two Devices, then two DeviceConsumer components will be created, and
 each
 one will be bound to a Device/DeviceParameter pair.

 I have committed a sample code [1], which is illustrating all this, except
 that I adapted the Device interface to a DeviceAccess interface, and the
 DeviceConsumer just tracks the DeviceAccess adapted interface (this
 example
 has nothing to do with the OSGi device access spec, which I don't know
 about).

 Notice that the DeviceAccess adapter service inherits from the Device
 service properties (see the DeviceAccessConsumer code).


 Regarding your second question, yes you can obtain the service instance
 from the Component interface.
 But there is an api break between DM 3.2.0 and DM 4.0.0.

 in DM 3.2.0, you can get the service instance using component.getService()
 method, which returns the Object instance.

 but in DM 4.0.0, you will have to call the Component.getInstances() method
 which returns all the component instances. When you use a component
 implemented with several compositions, then you can have multiple object
 instances.

 hope this helps;
 cheers;

 /Pierre


 [1]
 http://svn.apache.org/viewvc/felix/sandbox/pderop/
 dependencymanager-prototype/org.apache.felix.
 dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/
 device/

 On Mon, Sep 22, 2014 at 6:04 PM, Bulu b...@romandie.com wrote:

  Hello Pierre
 Yes, this is exactly what I need! Thanks so much.

 A few more questions:
 - How does createAdapterService differ from createComponent, if you don't
 publish any service?

 - When setting custom lifecycle callback methods targetting a separate
 object

 createComponent()
  .setImplementation(Consumer.class)
  ...
  .setCallbacks(myManager, init, start, stop,
 destroy));

 the myManager instance gets the Component object passed in the lifecycle
 methods
 (  start(Component c)  ). Can I get the actual object (here the Consumer
 instance) from this Component?

 Regards Philipp



 On 22.09.2014 17:41, Pierre De Rop wrote:

  Hello Philipp,

 So, let's see if I understand you correctly:

 - you have N Device services (each having a device.id service
 propery).
 - then you have N corresponding DeviceParameter instances, each one also
 having a device.id service property, matching a corresponding Device.
 - and you want to consume each pair of Device / DeviceParameter (having
 both the same value for the device.id service property).

 So, one possible solution (if I my understanding is correct) could
 consist
 in implementing your Consumer as a DependencyManager Adapter
 component,
 and this adapter would then define dynamically from it's init() method
 an
 extra dependency on the DeviceParameter, by reusing the id from the
 original Device service.

 Let's see what it could look like using a sample code. First here are
 the
 sample for the Device/DeviceParameter related classes:

 public interface Device {
   int getDeviceId();
 }

 public class DeviceImpl implements Device {
   final int id;

   DeviceImpl(int id) {
   this.id = id;
   }

   @Override
   public int getDeviceId() {
   return id;
   }
 }

 public interface DeviceParameter {
   int getDeviceId();
 }

 public class DeviceParameterImpl implements DeviceParameter {
   final int id;

   DeviceParameterImpl(int id) {
   this.id = id;
   }

   @Override
   public int getDeviceId() {
   return id;
   }
 }

 Now, let's define an Activator which creates two pair of
 Device/DeviceParameter:


 public class Activator extends DependencyActivatorBase {
   @Override
   public void init(BundleContext context, DependencyManager dm)
 throws
 Exception {
   createDeviceAndParameter(dm, 1);
   createDeviceAndParameter(dm, 2

Re: Dependency Manager: depend on several linked services

[Pierre De Rop]

Hello Philipp,

So, let's see if I understand you correctly:

- you have N Device services (each having a device.id service propery).
- then you have N corresponding DeviceParameter instances, each one also
having a device.id service property, matching a corresponding Device.
- and you want to consume each pair of Device / DeviceParameter (having
both the same value for the device.id service property).

So, one possible solution (if I my understanding is correct) could consist
in implementing your Consumer as a DependencyManager Adapter component,
and this adapter would then define dynamically from it's init() method an
extra dependency on the DeviceParameter, by reusing the id from the
original Device service.

Let's see what it could look like using a sample code. First here are the
sample for the Device/DeviceParameter related classes:

public interface Device {
int getDeviceId();
}

public class DeviceImpl implements Device {
final int id;

DeviceImpl(int id) {
this.id = id;
}

@Override
public int getDeviceId() {
return id;
}
}

public interface DeviceParameter {
int getDeviceId();
}

public class DeviceParameterImpl implements DeviceParameter {
final int id;

DeviceParameterImpl(int id) {
this.id = id;
}

@Override
public int getDeviceId() {
return id;
}
}

Now, let's define an Activator which creates two pair of
Device/DeviceParameter:


public class Activator extends DependencyActivatorBase {
@Override
public void init(BundleContext context, DependencyManager dm) throws
Exception {
createDeviceAndParameter(dm, 1);
createDeviceAndParameter(dm, 2);
}

private void createDeviceAndParameter(DependencyManager dm, int id) {
HashtableString, Object props = new Hashtable();
props.put(device.id, id);
dm.add(createComponent()
.setImplementation(new
DeviceImpl(id)).setInterface(Device.class.getName(), props));

props = new Hashtable();
props.put(device.id, id);
dm.add(createComponent()
.setImplementation(new
DeviceParameterImpl(id)).setInterface(DeviceParameter.class.getName(),
props));
}
}

Now, here is the DeviceConsumer: First, let's add a declaration in the
Activator.init method, which defines the DeviceConsumer as an Adapter:

dm.add(createAdapterService(Device.class, null)
.setImplementation(DeviceConsumer.class));

This says that we'll instantiate a DeviceConsumer component (which is here
not providing a service) when a Device services comes up.

And now, we define the DeviceConsumer like this:
(Notice the init method, where we declare an extra dependency, dynamically
created using the device id of the initially injected Device object)

public class DeviceConsumer {
volatile Device device; // injected before init()
volatile DeviceParameter deviceParameter; // extra dependency defined
from init(), but injected before start()

void init(Component c) {
// Dynamically add a dependency on the corresponding
DeviceParameter service.
DependencyManager dm = c.getDependencyManager();
c.add(dm.createServiceDependency()
.setService(DeviceParameter.class, (device.id= +
device.getDeviceId() + ))
.setRequired(true));
}

void start() {
// At this point, we have been injected with
theDevice/DeviceParameter pair.
System.out.println(Created a DeviceConsumer for device id  +
device.getDeviceId() + , device parameter id 
+ deviceParameter.getDeviceId());
}
}

So, in the init() method, we are using the id of the injected Device in
order to create an extra dependency on the corresponding DeviceParameter.
And, when the init() method returns, Dependency Manager will recalculate
the dependencies, and when the corresponding DeviceParameter comes in, then
it will be auto-injected in the deviceParameter field and then, your
start () method will be called, where you can manipulate the pair of
Device/DeviceParameter.

One important remark: the above code works with the upcomming DM 4.0.0
(currently committed in the Felix sandbox, from [1]), but if you are using
the currently released DM (3.2.0), then in your init() method, you will
have to call an extra setInstanceBound(true) method:

void init(Component c) {
DependencyManager dm = c.getDependencyManager();
c.add(dm.createServiceDependency()
.setService(DeviceParameter.class, (device.id= +
device.getDeviceId() + ))
.setRequired(true)
.setInstanceBound(true));
}

This setInstanceBound method has been removed in the DM 4.0.0 (currently
committed in [1]), but in the DM 3.2.0, you still have to call this method
when you declare extra dependencies from any component's init methods.

Does this help ? Does this corresponds to what you would need ?

Since this example is interesting (hope it corresponds to your needs), I

[ANN] DependencyManager 3.2.0 and related subprojects released

[Pierre De Rop]

The Apache Felix team is pleased to announce the release of Felix
Dependency Manager 3.2.0,
Dependency Manager Shell 3.2.0, Dependency Manager Annotation 3.2.0, and
Dependency Manager Runtime 3.2.0

This is a maintenance release with several bug fixes and with some
improvements made in the
dependency manager shell.


http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html


This release is available from
http://felix.apache.org/site/downloads.cgi and Maven:

  dependency
groupIdorg.apache.felix/groupId
artifactIdorg.apache.felix.dependencymanager/artifactId
version3.2.0/version
  /dependency

  dependency
groupIdorg.apache.felix/groupId
artifactIdorg.apache.felix.dependencymanager.shell/artifactId
version3.2.0/version
  /dependency

  dependency
groupIdorg.apache.felix/groupId
artifactIdorg.apache.felix.dependencymanager.runtime/artifactId
version3.2.0/version
  /dependency

  dependency
groupIdorg.apache.felix/groupId
artifactIdorg.apache.felix.dependencymanager.annotation/artifactId
version3.2.0/version
  /dependency

Release Notes:

Release Notes - Felix - Version dependencymanager.shell-3.2.0

** Improvement
* [FELIX-4294] - Dependency Manager Shell improvements
* [FELIX-4352] - Extend shell command to give better insight in
where the problem is
* [FELIX-4357] - Support types beside String/String[] in @Property
annotation.


Release Notes - Felix - Version dependencymanager.runtime-3.2.0

** Bug
* [FELIX-4050] - Named dependencies are not injected if new
dependencies are added at init phase.
* [FELIX-4233] - Race condition in dependency manager runtime SerialExecutor

** Improvement
* [FELIX-3869] - Fragment support for DependencyManager-Component

Release Notes - Felix - Version dependencymanager.annotations-3.2.0

** Bug
* [FELIX-3873] - Make the reference to json.org consistent in DM artifacts

** Improvement
* [FELIX-3996] - Upgrade to latest bnd version
* [FELIX-4357] - Support types beside String/String[] in @Property
annotation.

Release Notes - Felix - Version dependencymanager-3.2.0

** Bug
* [FELIX-3910] - Race conditions in DependencyManager
* [FELIX-4002] - ComponentStateListener.started is invoked twice
when the listener is added in the start method.
* [FELIX-4014] - handleAspectAwareRemoved in ServiceDependencyImpl
can cause a possible deadlock
* [FELIX-4186] - NPE in DependencyManager Logger
* [FELIX-4334] - ServiceDependency properties change callback issue
* [FELIX-4361] - Possible ConcurrentModificationException in
DependencyManager.getComponents()
* [FELIX-4395] - DependencyManager Configuration Dependency does
not clone some class fields

** Improvement
* [FELIX-4097] - Allow debug logging for specific instances of
service dependencies to debug wiring issues.
* [FELIX-4098] - Aspect swap sometimes invokes the callbacks in
the wrong order in a multithreaded application.
* [FELIX-4226] - Add option to have the dependency manager log
against a single BundleContext's LogService.
* [FELIX-4285] - Remove abstract modifier from
DependencyActivatorBase.destroy()
* [FELIX-4294] - Dependency Manager Shell improvements
* [FELIX-4305] - DependencyMananer Adapters - service properties propagation

** Wish
* [FELIX-4099] - Add support for negations in the multi property
filter index


Enjoy!

-The Felix team

Re: Building better OSGi applications

[Pierre De Rop]

Hi Philipp;

I'm using DM and DS in some large applications (~400 bundles, ~1000
services), and I confirm that both DM and DS are fast.

If you want to give a try to DM java API, you can take a look at [1]. it's
a simple but powerful API, which allows to not only declare simple
services, but also service aspects (interceptors), service adapters,
configuration dependencies, etc ...

DS will also allow you to declare your services easily. As suggested by
Ferry, you can take a look at the bndtools faq from [2], but the FAQ from
[3] is also useful and concise.

[1] http://felix.apache.org/site/apache-felix-dependency-manager.html
[2] http://bndtools.org/tutorial.html
[3] http://wiki.osgi.org/wiki/Declarative_Services

hope this helps;

kind regards;
/Pierre


On Thu, Jul 17, 2014 at 10:19 AM, Paul Bakker paul.bak...@luminis.eu
wrote:

 Definetly use either Felix Dependency Manager (that's what I use on all
 projects) or Declarative Services. DS is slightly simpler, DM is more
 powerful. The main difference is that DM can also be used from code to
 register/deregister components at any given time.
 Both solutions will solve the problem you are describing, which is a very
 common one :-)

 Cheers,

 Paul


 On Thu, Jul 17, 2014 at 10:04 AM, Bulu b...@romandie.com wrote:

  Hi all
 
  I'm building an application on an embedded system which will contain ~20
  bundles.
 
  There are many dependencies of services - say for example to provide its
  service, module A (several classes) needs services B,C,D.
  In order to fully account for the dynamics of OSGi, I have to monitor
  B,C,D to stop A when any of these 3 goes away. This unregisters service
 A,
  which in turn will disrupt all clients of A.
  If additionally you want to handle part case (A should still provide a
  reduced service, if only B and C are available but not D) it gets messy
  rapidly.
 
  In the end, I realize that I am mostly writing life cycle code instead of
  business logic and I have lots of OSGi dependencies, with the
 BundleContect
  passed around nearly everywhere. This smells like bad design.
 
  Could you share insights or recommend reading on how to structure OSGi
  services for cohesion and modularity, to avoid the problems above?
  Are there ways to reduce the boiler plate?
  Should I be investigating declarative services, iPojo or others (in
  general I prefer writing code than XML...). As this is an embedded
 system,
  should I be worried about the performance impact of DS?
 
 
  Thanks for your insights
Philipp
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
  For additional commands, e-mail: users-h...@felix.apache.org
 
 

Re: Dependency Manager Shell - IllegalStateException: Invalid BundleContext after update of some bundles

[Pierre De Rop]

Hi Andras,

I will see with Marcel if we can make a release this week, and will let you
know;

best regards
/Pierre


On Fri, Jun 27, 2014 at 10:17 AM, Andras Szerdahelyi 
andras.szerdahe...@gmail.com wrote:

 Hello Pierre,

 i can not reproduce the problem with trunk dmshell. woohoo!
 Any ETA on a release?

 thanks!
 Andras


 On 27 June 2014 08:42, Pierre De Rop pierre.de...@gmail.com wrote:

  Hello Andras;
 
  just to say I saw your post. I'm just lacking of time this week, but I
 will
  look into your problem this WE;
 
  in the mean time, it would be helpful if you could confirm that you also
  have the problem with the dm and shell trunk versions ?
 
  thanks;
 
  kind regards;
  /Pierre
 
 
  On Wed, Jun 25, 2014 at 2:54 PM, Andras Szerdahelyi 
  andras.szerdahe...@gmail.com wrote:
 
   hello list,
  
i use the DM Shell bundle to debug service dependency problems in my
   DM-managed components. Its been working great for the most part, that
 is
   until i try to update an active bundle in the framework. I see the
  expected
   framework events logged in log debug, DM or the DM shell bundle is
  never
   stopped. Yet after the update, the dm gogo command returns with
  
   g! dm
  
   gogo: IllegalStateException: Invalid BundleContext.
  
   g!
  
  
   the full output of log debug for reference:
  
   2014.06.25 14:47:38 INFO - Bundle:
  myproduct-service-budgeting-memcached -
   [com.mycompany.myproduct.service.budgeting.api.BudgetingService] -
   ServiceEvent REGISTERED
  
   2014.06.25 14:47:38 INFO - Bundle: myproduct-channel-http -
   [com.mycompany.myproduct.channel.api.myproductChannel] - ServiceEvent
   REGISTERED
  
   2014.06.25 14:47:38 INFO - Bundle: myproduct-processor-jul-concurrent -
   [com.mycompany.myproduct.processor.api.ProcessorService] - ServiceEvent
   REGISTERED
  
   2014.06.25 14:47:38 INFO - Bundle:
  myproduct-service-budgeting-memcached -
   BundleEvent STARTED
  
   2014.06.25 14:47:38 INFO - Bundle:
  myproduct-service-budgeting-memcached -
   [org.osgi.service.cm.ManagedServiceFactory] - ServiceEvent REGISTERED
  
   2014.06.25 14:47:38 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   [com.mycompany.myproduct.configuration.myproductConfigurationFactory] -
   ServiceEvent REGISTERED
  
   2014.06.25 14:47:38 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   BundleEvent RESOLVED
  
   2014.06.25 14:47:38 INFO - Bundle: org.apache.felix.framework -
   FrameworkEvent PACKAGES REFRESHED
  
   2014.06.25 14:47:38 INFO - Bundle: org.apache.felix.framework -
   FrameworkEvent PACKAGES REFRESHED
  
   2014.06.25 14:47:38 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   BundleEvent UPDATED
  
   2014.06.25 14:47:38 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   BundleEvent UNRESOLVED
  
   2014.06.25 14:47:38 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   BundleEvent STOPPED
  
   2014.06.25 14:47:38 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   [com.mycompany.myproduct.service.budgeting.api.BudgetingService] -
   ServiceEvent UNREGISTERING
  
   2014.06.25 14:47:37 INFO - Bundle: myproduct-channel-http -
   [com.mycompany.myproduct.channel.api.myproductChannel] - ServiceEvent
   UNREGISTERING
  
   2014.06.25 14:47:37 INFO - Bundle: myproduct-processor-jul-concurrent -
   [com.mycompany.myproduct.processor.api.ProcessorService] - ServiceEvent
   UNREGISTERING
  
   2014.06.25 14:47:37 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   [com.mycompany.myproduct.configuration.myproductConfigurationFactory] -
   ServiceEvent UNREGISTERING
  
   2014.06.25 14:47:37 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   [org.osgi.service.cm.ManagedServiceFactory] - ServiceEvent
 UNREGISTERING
  
   2014.06.25 14:47:36 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   [com.mycompany.myproduct.service.budgeting.api.BudgetingService] -
   ServiceEvent REGISTERED
  
   2014.06.25 14:47:36 INFO - Bundle: myproduct-channel-http -
   [com.mycompany.myproduct.channel.api.myproductChannel] - ServiceEvent
   REGISTERED
  
   2014.06.25 14:47:36 INFO - Bundle: myproduct-processor-jul-concurrent -
   [com.mycompany.myproduct.processor.api.ProcessorService] - ServiceEvent
   REGISTERED
  
   2014.06.25 14:47:36 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   BundleEvent STARTED
  
   2014.06.25 14:47:36 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   [org.osgi.service.cm.ManagedServiceFactory] - ServiceEvent REGISTERED
  
   2014.06.25 14:47:36 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   [com.mycompany.myproduct.configuration.myproductConfigurationFactory] -
   ServiceEvent REGISTERED
  
   2014.06.25 14:47:36 INFO - Bundle:
 myproduct-service-budgeting-memcached
  -
   BundleEvent RESOLVED
  
   2014.06.25 14:47:36 INFO - Bundle: org.apache.felix.framework -
   FrameworkEvent PACKAGES REFRESHED
  
   2014.06.25 14:47:36 INFO - Bundle

Re: Dependency Manager Shell - IllegalStateException: Invalid BundleContext after update of some bundles

[Pierre De Rop]

Hello Andras;

just to say I saw your post. I'm just lacking of time this week, but I will
look into your problem this WE;

in the mean time, it would be helpful if you could confirm that you also
have the problem with the dm and shell trunk versions ?

thanks;

kind regards;
/Pierre


On Wed, Jun 25, 2014 at 2:54 PM, Andras Szerdahelyi 
andras.szerdahe...@gmail.com wrote:

 hello list,

  i use the DM Shell bundle to debug service dependency problems in my
 DM-managed components. Its been working great for the most part, that is
 until i try to update an active bundle in the framework. I see the expected
 framework events logged in log debug, DM or the DM shell bundle is never
 stopped. Yet after the update, the dm gogo command returns with

 g! dm

 gogo: IllegalStateException: Invalid BundleContext.

 g!


 the full output of log debug for reference:

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 [com.mycompany.myproduct.service.budgeting.api.BudgetingService] -
 ServiceEvent REGISTERED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-channel-http -
 [com.mycompany.myproduct.channel.api.myproductChannel] - ServiceEvent
 REGISTERED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-processor-jul-concurrent -
 [com.mycompany.myproduct.processor.api.ProcessorService] - ServiceEvent
 REGISTERED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent STARTED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 [org.osgi.service.cm.ManagedServiceFactory] - ServiceEvent REGISTERED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 [com.mycompany.myproduct.configuration.myproductConfigurationFactory] -
 ServiceEvent REGISTERED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent RESOLVED

 2014.06.25 14:47:38 INFO - Bundle: org.apache.felix.framework -
 FrameworkEvent PACKAGES REFRESHED

 2014.06.25 14:47:38 INFO - Bundle: org.apache.felix.framework -
 FrameworkEvent PACKAGES REFRESHED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent UPDATED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent UNRESOLVED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent STOPPED

 2014.06.25 14:47:38 INFO - Bundle: myproduct-service-budgeting-memcached -
 [com.mycompany.myproduct.service.budgeting.api.BudgetingService] -
 ServiceEvent UNREGISTERING

 2014.06.25 14:47:37 INFO - Bundle: myproduct-channel-http -
 [com.mycompany.myproduct.channel.api.myproductChannel] - ServiceEvent
 UNREGISTERING

 2014.06.25 14:47:37 INFO - Bundle: myproduct-processor-jul-concurrent -
 [com.mycompany.myproduct.processor.api.ProcessorService] - ServiceEvent
 UNREGISTERING

 2014.06.25 14:47:37 INFO - Bundle: myproduct-service-budgeting-memcached -
 [com.mycompany.myproduct.configuration.myproductConfigurationFactory] -
 ServiceEvent UNREGISTERING

 2014.06.25 14:47:37 INFO - Bundle: myproduct-service-budgeting-memcached -
 [org.osgi.service.cm.ManagedServiceFactory] - ServiceEvent UNREGISTERING

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 [com.mycompany.myproduct.service.budgeting.api.BudgetingService] -
 ServiceEvent REGISTERED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-channel-http -
 [com.mycompany.myproduct.channel.api.myproductChannel] - ServiceEvent
 REGISTERED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-processor-jul-concurrent -
 [com.mycompany.myproduct.processor.api.ProcessorService] - ServiceEvent
 REGISTERED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent STARTED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 [org.osgi.service.cm.ManagedServiceFactory] - ServiceEvent REGISTERED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 [com.mycompany.myproduct.configuration.myproductConfigurationFactory] -
 ServiceEvent REGISTERED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent RESOLVED

 2014.06.25 14:47:36 INFO - Bundle: org.apache.felix.framework -
 FrameworkEvent PACKAGES REFRESHED

 2014.06.25 14:47:36 INFO - Bundle: org.apache.felix.framework -
 FrameworkEvent PACKAGES REFRESHED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent UPDATED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent UNRESOLVED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 BundleEvent STOPPED

 2014.06.25 14:47:36 INFO - Bundle: myproduct-service-budgeting-memcached -
 [com.mycompany.myproduct.service.budgeting.api.BudgetingService] -
 ServiceEvent UNREGISTERING

 2014.06.25 14:47:35 INFO - Bundle: myproduct-channel-http -
 [com.mycompany.myproduct.channel.api.myproductChannel] - ServiceEvent
 UNREGISTERING

 2014.06.25 

Re: IPojo performance benchmark

[Pierre De Rop]

Hi Clement,

I finally committed a stress test for dependency manager 4 in
https://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager-prototype/

So, I included in it a scenario using iPojo, and it seems that registering
around 300 services seems to take an important amount of time, so you might
want to look into the scenario test.

I hope I used the iPojo API correctly, I followed the documentation from
here:
http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.html#a-simple-example;
so if you have time to take a look, let me know if there is something wrong
with the test and I will correct it.

The stress test is a subproject of dm and is located in
http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/

I haved added a README here:
http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/README?view=co

And the code used to declare iPojo components (using the iPojo API) is
located here:

http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/src/org/apache/felix/dm/benchmark/ipojo/IpojoScenario.java?revision=1605212view=co

hope this helps (and also that I used correctly the iPojo APi)

cheers;
/Pierre


On Sun, Jun 22, 2014 at 10:36 AM, Clement Escoffier 
clement.escoff...@gmail.com wrote:

 Hi,


 On 22 juin 2014 at 00:14:26, Pierre De Rop (pierre.de...@gmail.com) wrote:

 Hello Clement,

 I'm also working on some benchmark related to dependency manager,
 declarative service, and after reading this post, I tried to incorporate a
 scenario using iPojo in my benchmark.
 And it seems that I'm also observing a performance problem.

 I will try to commit somewhere my benchmark program soon in my sandbox,
 however, I just made a quick jvisualvm, and it looks like I'm spending 95
 %
 of the time in the
 org.apache.felix.ipojo.IPojoFactory$RetryNameGenerator.generate method.


 That would make sense. This class is ensuring uniqueness, which is
 particularly expensive. It's something quite new, and for sure there are
 room for optimizations.

 Clement





 Here is a stacktrace, if this may help:

 Thread-2 #30 prio=5 os_prio=0 tid=0x635f7c00 nid=0x47c1 runnable
 [0x62cfd000]
 java.lang.Thread.State: RUNNABLE
 at

 org.apache.felix.ipojo.IPojoFactory$RetryNameGenerator.generate(IPojoFactory.java:1149)
 at

 org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:302)
 - locked 0x67652198 (a
 java.util.Collections$SynchronizedRandomAccessList)
 - locked 0x95055f50 (a org.apache.felix.ipojo.ComponentFactory)
 at

 org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240)
 at

 org.apache.felix.ipojo.api.ComponentType.createInstance(ComponentType.java:79)
 at

 org.apache.felix.dm.benchmark.ipojo.IPojoActivator$$Lambda$108/3740909.apply(Unknown
 Source)
 at
 org.apache.felix.dm.benchmark.controller.Helper.lambda$1(Helper.java:85)
 at

 org.apache.felix.dm.benchmark.controller.Helper$$Lambda$36/6147827.apply(Unknown
 Source)
 at
 java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
 at

 java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1359)
 at
 java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512)
 at

 java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)
 at
 java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
 at
 java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
 at
 java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
 at

 org.apache.felix.dm.benchmark.ipojo.IPojoActivator.__M_start(IPojoActivator.java:96)
 at

 org.apache.felix.dm.benchmark.ipojo.IPojoActivator.start(IPojoActivator.java)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:483)
 at org.apache.felix.ipojo.util.Callback.call(Callback.java:237)
 at org.apache.felix.ipojo.util.Callback.call(Callback.java:193)
 at

 org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86)
 at

 org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:162)
 at

 org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
 at
 org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:560)
 at
 org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:440)
 at

 org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:179)
 at

 org.apache.felix.ipojo.IPojoFactory.createComponentInstance

Re: IPojo performance benchmark

[Pierre De Rop]

Hi Guillaume;

Thanks for reviewing;

But if I should only use three component types, then when creating each
component instance, is there a way to configure a given component instance
service dependency filter ?

May I provide such filter in the dictionary that I pass to the
ComponentType.createInstance(Dictionary conf) method ? (like passing a
target filter with declarative service ComponentFactory ?). Should I use
another iPOJO api (like an iPojo Factory ?)

In my scenario, I have for example a first Artist instance depending on
an Album instance with the filter id=1.
then another Artist instance depending on another Album instance, but
with service filter id=2, etc ...


cheers;
/Pierre





On Wed, Jun 25, 2014 at 3:42 PM, Guillaume Sauthier (OW2) 
guillaume@gmail.com wrote:

 Maybe I don't fully understand Java 8 style code, but it looks like you're
 creating too many PrimitiveComponentType instances, right ?

 In iPOJO, a component type is really like a class, you define its contract
 (the provided specification, aka interface), it's properties (with
 potential default values), … And then, you create instances out of 1
 component type (that is a de-facto factory): an instance being a simple
 configuration (a dictionnary).

 So, in your benchmark, you should create only 3 PrimitiveComponentType: 1
 for artist, 1 for album and 1 for track.
 Then, you'll have to create instances by providing a configuration with
 instance specific values (like identifier, ...):

 http://felix.apache.org/ipojo/api/1.11.0/org/apache/felix/ipojo/api/ComponentType.html#createInstance(java.util.Dictionary)

 Thanks
 —G
 Le 25 juin 2014 à 12:05:29, Pierre De Rop (pierre.de...@gmail.com) a
 écrit:

 Hi Clement,

 I finally committed a stress test for dependency manager 4 in

 https://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager-prototype/

 So, I included in it a scenario using iPojo, and it seems that registering
 around 300 services seems to take an important amount of time, so you might
 want to look into the scenario test.

 I hope I used the iPojo API correctly, I followed the documentation from
 here:

 http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.html#a-simple-example
 ;
 so if you have time to take a look, let me know if there is something wrong
 with the test and I will correct it.

 The stress test is a subproject of dm and is located in

 http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/

 I haved added a README here:

 http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/README?view=co

 And the code used to declare iPojo components (using the iPojo API) is
 located here:


 http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/src/org/apache/felix/dm/benchmark/ipojo/IpojoScenario.java?revision=1605212view=co

 hope this helps (and also that I used correctly the iPojo APi)

 cheers;
 /Pierre


 On Sun, Jun 22, 2014 at 10:36 AM, Clement Escoffier 
 clement.escoff...@gmail.com wrote:

  Hi,
 
 
  On 22 juin 2014 at 00:14:26, Pierre De Rop (pierre.de...@gmail.com)
 wrote:
 
  Hello Clement,
 
  I'm also working on some benchmark related to dependency manager,
  declarative service, and after reading this post, I tried to incorporate
 a
  scenario using iPojo in my benchmark.
  And it seems that I'm also observing a performance problem.
 
  I will try to commit somewhere my benchmark program soon in my sandbox,
  however, I just made a quick jvisualvm, and it looks like I'm spending 95
  %
  of the time in the
  org.apache.felix.ipojo.IPojoFactory$RetryNameGenerator.generate method.
 
 
  That would make sense. This class is ensuring uniqueness, which is
  particularly expensive. It's something quite new, and for sure there are
  room for optimizations.
 
  Clement
 
 
 
 
 
  Here is a stacktrace, if this may help:
 
  Thread-2 #30 prio=5 os_prio=0 tid=0x635f7c00 nid=0x47c1 runnable
  [0x62cfd000]
  java.lang.Thread.State: RUNNABLE
  at
 
 
 org.apache.felix.ipojo.IPojoFactory$RetryNameGenerator.generate(IPojoFactory.java:1149)
  at
 
 
 org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:302)
  - locked 0x67652198 (a
  java.util.Collections$SynchronizedRandomAccessList)
  - locked 0x95055f50 (a org.apache.felix.ipojo.ComponentFactory)
  at
 
 
 org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240)
  at
 
 
 org.apache.felix.ipojo.api.ComponentType.createInstance(ComponentType.java:79)
  at
 
 
 org.apache.felix.dm.benchmark.ipojo.IPojoActivator$$Lambda$108/3740909.apply(Unknown
  Source)
  at
  org.apache.felix.dm.benchmark.controller.Helper.lambda$1(Helper.java:85)
  at
 
 
 org.apache.felix.dm.benchmark.controller.Helper$$Lambda$36/6147827.apply(Unknown
  Source

Re: IPojo performance benchmark

[Pierre De Rop]

thanks Guillaume,

Then, for now, the conclusion is that my scenario seems invalid (sorry for
all the noise !)
So, I will follow your suggestion and refactor the benchmark.

cheers
/Pierre


On Wed, Jun 25, 2014 at 4:45 PM, Guillaume Sauthier (OW2) 
guillaume@gmail.com wrote:

 Sure, you have multiple options:
 1. you use an ipojo reserved property name in the configuration where you
 can specify the filter of an identified dependency

 http://felix.apache.org/site/ipojo-reference-card.html#iPOJO-Reference-Card-Configuringthe%7B%7Bfilter%7D%7Dattribute

 2. you can uses a variable substitution in the filter of the dependency
 The value will be substituted automatically.
 You can use any property name of your component , they will be recognized.

 —G

 Le 25 juin 2014 à 16:12:05, Pierre De Rop (pierre.de...@gmail.com) a
 écrit:

 Hi Guillaume;

 Thanks for reviewing;

 But if I should only use three component types, then when creating each
 component instance, is there a way to configure a given component instance
 service dependency filter ?

 May I provide such filter in the dictionary that I pass to the
 ComponentType.createInstance(Dictionary conf) method ? (like passing a
 target filter with declarative service ComponentFactory ?). Should I use
 another iPOJO api (like an iPojo Factory ?)

 In my scenario, I have for example a first Artist instance depending on
 an Album instance with the filter id=1.
 then another Artist instance depending on another Album instance, but
 with service filter id=2, etc ...


 cheers;
 /Pierre





 On Wed, Jun 25, 2014 at 3:42 PM, Guillaume Sauthier (OW2) 
 guillaume@gmail.com wrote:

  Maybe I don't fully understand Java 8 style code, but it looks like
 you're
  creating too many PrimitiveComponentType instances, right ?
 
  In iPOJO, a component type is really like a class, you define its
 contract
  (the provided specification, aka interface), it's properties (with
  potential default values), … And then, you create instances out of 1
  component type (that is a de-facto factory): an instance being a simple
  configuration (a dictionnary).
 
  So, in your benchmark, you should create only 3 PrimitiveComponentType: 1
  for artist, 1 for album and 1 for track.
  Then, you'll have to create instances by providing a configuration with
  instance specific values (like identifier, ...):
 
 
 http://felix.apache.org/ipojo/api/1.11.0/org/apache/felix/ipojo/api/ComponentType.html#createInstance(java.util.Dictionary)
 
  Thanks
  —G
  Le 25 juin 2014 à 12:05:29, Pierre De Rop (pierre.de...@gmail.com) a
  écrit:
 
  Hi Clement,
 
  I finally committed a stress test for dependency manager 4 in
 
 
 https://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager-prototype/
 
  So, I included in it a scenario using iPojo, and it seems that
 registering
  around 300 services seems to take an important amount of time, so you
 might
  want to look into the scenario test.
 
  I hope I used the iPojo API correctly, I followed the documentation from
  here:
 
 
 http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.html#a-simple-example
  ;
  so if you have time to take a look, let me know if there is something
 wrong
  with the test and I will correct it.
 
  The stress test is a subproject of dm and is located in
 
 
 http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/
 
  I haved added a README here:
 
 
 http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/README?view=co
 
  And the code used to declare iPojo components (using the iPojo API) is
  located here:
 
 
 
 http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/src/org/apache/felix/dm/benchmark/ipojo/IpojoScenario.java?revision=1605212view=co
 
  hope this helps (and also that I used correctly the iPojo APi)
 
  cheers;
  /Pierre
 
 
  On Sun, Jun 22, 2014 at 10:36 AM, Clement Escoffier 
  clement.escoff...@gmail.com wrote:
 
   Hi,
  
  
   On 22 juin 2014 at 00:14:26, Pierre De Rop (pierre.de...@gmail.com)
  wrote:
  
   Hello Clement,
  
   I'm also working on some benchmark related to dependency manager,
   declarative service, and after reading this post, I tried to
 incorporate
  a
   scenario using iPojo in my benchmark.
   And it seems that I'm also observing a performance problem.
  
   I will try to commit somewhere my benchmark program soon in my sandbox,
   however, I just made a quick jvisualvm, and it looks like I'm spending
 95
   %
   of the time in the
   org.apache.felix.ipojo.IPojoFactory$RetryNameGenerator.generate method.
  
  
   That would make sense. This class is ensuring uniqueness, which is
   particularly expensive. It's something quite new, and for sure there
 are
   room for optimizations.
  
   Clement
  
  
  
  
  
   Here is a stacktrace

Re: IPojo performance benchmark

[Pierre De Rop]

Hello Clement,

I'm also working on some benchmark related to dependency manager,
declarative service, and after reading this post, I tried to incorporate a
scenario using iPojo in my benchmark.
And it seems that I'm also observing a performance problem.

I will try to commit somewhere my benchmark program soon in my sandbox,
however, I just made a quick jvisualvm, and it looks like I'm spending 95 %
of the time in the
org.apache.felix.ipojo.IPojoFactory$RetryNameGenerator.generate method.

Here is a stacktrace, if this may help:

Thread-2 #30 prio=5 os_prio=0 tid=0x635f7c00 nid=0x47c1 runnable
[0x62cfd000]
   java.lang.Thread.State: RUNNABLE
at
org.apache.felix.ipojo.IPojoFactory$RetryNameGenerator.generate(IPojoFactory.java:1149)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:302)
- locked 0x67652198 (a
java.util.Collections$SynchronizedRandomAccessList)
- locked 0x95055f50 (a org.apache.felix.ipojo.ComponentFactory)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240)
at
org.apache.felix.ipojo.api.ComponentType.createInstance(ComponentType.java:79)
at
org.apache.felix.dm.benchmark.ipojo.IPojoActivator$$Lambda$108/3740909.apply(Unknown
Source)
at
org.apache.felix.dm.benchmark.controller.Helper.lambda$1(Helper.java:85)
at
org.apache.felix.dm.benchmark.controller.Helper$$Lambda$36/6147827.apply(Unknown
Source)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1359)
at
java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)
at
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at
java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at
org.apache.felix.dm.benchmark.ipojo.IPojoActivator.__M_start(IPojoActivator.java:96)
at
org.apache.felix.dm.benchmark.ipojo.IPojoActivator.start(IPojoActivator.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.apache.felix.ipojo.util.Callback.call(Callback.java:237)
at org.apache.felix.ipojo.util.Callback.call(Callback.java:193)
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86)
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:162)
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
at
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:560)
at
org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:440)
at
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:179)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:319)
- locked 0x6e5340d0 (a org.apache.felix.ipojo.ComponentFactory)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240)
at
org.apache.felix.ipojo.api.ComponentType.createInstance(ComponentType.java:79)
at
org.apache.felix.dm.benchmark.ipojo.Activator.start(Activator.java:31)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2152)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2070)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963)
at
org.apache.felix.dm.benchmark.controller.impl.BenchmarkControllerImpl.startAndStop(BenchmarkControllerImpl.java:190)
at
org.apache.felix.dm.benchmark.controller.impl.BenchmarkControllerImpl.lambda$17(BenchmarkControllerImpl.java:104)
at
org.apache.felix.dm.benchmark.controller.impl.BenchmarkControllerImpl$$Lambda$17/24713481.run(Unknown
Source)
at
org.apache.felix.dm.benchmark.controller.impl.BenchmarkControllerImpl.durationOf(BenchmarkControllerImpl.java:229)
at
org.apache.felix.dm.benchmark.controller.impl.BenchmarkControllerImpl.lambda$11(BenchmarkControllerImpl.java:104)
at
org.apache.felix.dm.benchmark.controller.impl.BenchmarkControllerImpl$$Lambda$15/17116744.applyAsLong(Unknown
Source)
at 

Re: Declarative Services

[Pierre De Rop]

Hi David,

I'm not sure whether I fully understand or not, can you please clarify and
describe with more details the circular dependency involved in this problem
?

As far as I understand what you are describing:

- C is immediate, enabled, and has two required references on both A, B.
- A is enabled and activating. And from it's activate method, A manually
registers B (using bundleContext.registerService).

Then, where is the dependency cycle ?

C - A, B

but are A and/or B also depending on C ?


thanks;
/Pierre




On Fri, Nov 1, 2013 at 7:53 AM, David Jencks david_jen...@yahoo.com wrote:

 After some investigation offline we determined that there was effectively
 a circular dependency that was sometimes preventing some of the services
 from activating immediately.  Abstracting slightly…
 component/service A registered service B in its activate method. Immediate
 component C has mandatory dependencies on A and B.  If C is enabled before
 A, then A's activation will result in a problem as B will be registered
 while the thread is still in A's activate method, so the component instance
 cannot be returned from a getService call.  Sometimes this circle is
 detected by the service registry and sometimes by the DS circular
 dependency detector.

 One solution is to register B in a separate thread started from A's
 activate method.

 In general, this illustrates that registering services from within DS
 lifecycle methods is apt to cause locking problems and should be avoided if
 at all possible.

 thanks
 david jencks

 On Oct 30, 2013, at 3:10 PM, Dave Smith dave.sm...@candata.com wrote:

  Never see it. I will send you a copy of the full log off list. The only
  other interesting thing is the Activate method in ServiceRunner does
  register 3 other services that will be injected in components.
 
  Dave Smith
  Candata Ltd.
  416-493-9020x2413
  Direct: 416-855-2413
 
 
  On Wed, Oct 30, 2013 at 5:52 PM, David Jencks david_jen...@yahoo.com
 wrote:
 
  Does the activate method on ServiceRunnerImpl return? there should be a
  log entry from
 
 logger.log( LogService.LOG_DEBUG, invoked {0}: {1}:
  parameters {2}, new Object[]
 { getMethodNamePrefix(), getMethodName(),
  Arrays.asList( params ) }, null );
 
  Are there really no log statements between found bind method and
 could
  not get service?
 
  thanks
  david jencks
 
 
  On Oct 30, 2013, at 2:03 PM, Dave Smith dave.sm...@candata.com wrote:
 
  OK. So I managed to pull the Snapshot from last night. Same problem.
 
  So here is where it registers
 
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)] dm
  KeyValueDAO tracking 5 SingleStatic added
  {com.candata.util.common.services.KeyValueDAO}=
  {component.name=com.candata.util.server.impl.KeyValueDAOImpl,
  component.id=39, service.exported.interfaces=*, service.id=130}
  (enter) com.candata.core.server_1.0.0 [141] null null
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)]
  ActivateInternal com.candata.core.server_1.0.0 [141] null null
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)]
  Activating component from state 4 com.candata.core.server_1.0.0 [141]
  null null
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)]
  registration change queue [registered] com.candata.core.server_1.0.0
  [141] null null
  2013-10-30 04:34:15 3 ServiceEvent REGISTERED
  com.candata.core.server_1.0.0 [141]
  {com.candata.core.server.services.ServiceConfiguration}=
  {component.name=com.candata.core.server.impl.ServiceConfigurationImpl,
  component.id=220, service.id=133} null
 
 
 
  And when it is injecting the references ...
 
 
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)] Declared
  Method
 
 com.candata.core.server.impl.ServiceConfigurationImpl.setRunAsService([interface
  org.osgi.framework.ServiceReference]) not found
  com.candata.core.server_1.0.0 [141] null null
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)]
  getParameterClass: Looking for interface class
  com.candata.core.server.services.RunAsService through loader of
  com.candata.core.server.impl.ServiceConfigurationImpl
  com.candata.core.server_1.0.0 [141] null null
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)]
  getParameterClass: Found class
  com.candata.core.server.services.RunAsService
  com.candata.core.server_1.0.0 [141] null null
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)]
  doFindMethod: No method taking ServiceReference found, checking method
  taking com.candata.core.server.services.RunAsService
  com.candata.core.server_1.0.0 [141] null null
  2013-10-30 04:34:15 4
  [com.candata.core.server.impl.ServiceConfigurationImpl(220)] Found
  bind method: protected void
 
 
 

Re: Articles about the Apache Felix Dependency Manager

[Pierre De Rop]

Hi Marcel,

Nice articles, I will look into them with pleasure.

As Bram suggested, I also added the links in Felix documentation:


http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/apache-felix-dependency-manager-resources.html

best regards;
/Pierre


On Tue, Oct 29, 2013 at 11:40 PM, Marcel Offermans 
marcel.offerm...@luminis.nl wrote:

 For everybody that is interested in the Dependency Manager, my colleague
 Peter is working on a series of articles about it:

 http://arnhem.luminis.eu/introduction-apache-felix-dependency-manager/

 http://arnhem.luminis.eu/introduction-apache-felix-dependencymanager-part-2/

 I personally think they do a very good job of explaining the basics, which
 is why I'm sharing these links here. Any feedback is of course more than
 welcome!

 Greetings, Marcel


 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: SCR Bug?

[Pierre De Rop]

Hi Dave,

Could you give a try to the trunk version of the SCR (I think that the code
changed a lot in the trunk since 1.6.2).

regards;
/Pierre


On Wed, Sep 18, 2013 at 10:09 PM, Dave Smith dave.sm...@candata.com wrote:

 1.6.2

 Dave Smith
 Candata Ltd.
 416-493-9020x2413
 Direct: 416-855-2413


 On Wed, Sep 18, 2013 at 4:05 PM, Felix Meschberger fmesc...@adobe.com
 wrote:

  Hi
 
  I agree, that this is probably noise due to some race condition.
 
  Yet, to be really able to confirm, I would need to know which version of
  the Apache Felix SCR bundle you are actually using.
 
  Regards
  Felix
 
  Am 18.09.2013 um 21:59 schrieb Dave Smith:
 
   I get the following bt occasionally in my logs. Not sure when it
 happens
   but it does not seem to be a BIG deal just noise. But would like to
 know
  if
   it is a bug or something I am doing wrong..
  
   java.lang.IllegalStateException deactivate: Disposed
   at
  
 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Disposed.deactivate(AbstractComponentManager.java:1818)
   at
  
 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:555)
   at
  
 
 org.apache.felix.scr.impl.manager.DependencyManager.serviceRemoved(DependencyManager.java:451)
   at
  
 
 org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:274)
   at
  
 
 org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
   at
  
 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
   at
  
 
 org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
   at
  
 
 org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
   at
  
 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
   at
  
 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
   at
  
 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:225)
   at
  
 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:702)
   at
  
 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$State.doDeactivate(AbstractComponentManager.java:1301)
   at
  
 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.dispose(AbstractComponentManager.java:1617)
   at
  
 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:574)
   at
  
 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:404)
   at
  
 
 org.apache.felix.scr.impl.config.ImmediateComponentHolder.disposeComponents(ImmediateComponentHolder.java:371)
   at
  
 
 org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:320)
   at
  
 org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:316)
   at
   org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:183)
   at
  
 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:847)
   at
  
 
 org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
   at
  
 
 org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
   at
  
 
 org.eclipse.osgi.framework.internal.core.Framework.publishBundleEventPrivileged(Framework.java:1568)
   at
  
 
 org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1504)
   at
  
 
 org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1499)
   at
  
 
 org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:506)
   at
  
 
 org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
   at
  
 
 org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1206)
   at
  
 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:592)
   at
  
 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:257)
   at
  
 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:215)
   at
  
 
 org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:284)
   at
  
 
 org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:692)
   at
  
 
 org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:600)
   at
  
 
 

Re: configadmin: no visibility to configuration

[Pierre De Rop]

Hi Jean-Philippe,

in addition to the responses made by Felix and Roland, you can also refer
to configuration admin specification, especially in the chapter 104.4.1 of
the 4.3 OSGi compendium, which explains what is a configuration location
binding (the second parameter of the getConfiguration(String pid, String
location) method).

best regards;
/Pierre


On Tue, Sep 10, 2013 at 12:04 PM, Roland w...@ids.de wrote:

 Hi,
 I assume you try to configure a service that was created by another bundle.
 The bundle which creates the configuration has no visibility to the
 service.

 Try to use one of the following:

 getConfiguration(pid, ?);

 createFactoryConfiguration(msf, ?);

 or

 getConfiguration(pid, null);

 createFactoryConfiguration(msf, null);

 Regards
 Roland



 --
 View this message in context:
 http://apache-felix.18485.x6.nabble.com/configadmin-no-visibility-to-configuration-tp5004904p5004906.html
 Sent from the Apache Felix - Users mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: Compendium Services managed properties and multiple bundles

[Pierre De Rop]

Hi Tim,

I don't know if gemini BP is compatible with CM from OSGi compendium 4.3,
but using a 4.3 CM allows to share the same configuration PID across
multiple bundles if the configuration is created using a specific ?
location binding (see 104.4.1 chapter, in compendium 4.3).

Technically, creating a shared configuration (using 4.3 ConfigurationAdmin)
can be done like in this example:

void configure(ConfigurationAdmin ca) {
conf = ca.getConfiguration(org.foo.pid, ?);
}

Using the ? location allows to make the configuration be visible by
multiple bundles.

Now, the question is: how do you configure your components ? Are you using
a custom configurator which you could modify in order to use the
multi-location binding ?


kind regards;
/Pierre


On Thu, Aug 22, 2013 at 11:01 PM, mit_jones t...@mccarthy.co.nz wrote:

 Hi,

 I am trying to use the Compendium Services managed properties as per

 http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/compendium.html
 to inject changes in configuration across multiple bundles but according to
 the spec this is not allowed:

 Do not share the same persistent-id (PID) between multiple bundles or
 definitions, as only one of them will receive notifications.
 managed-properties relies on org.osgi.service.cm.ManagedService contract
 which mandates that each ManagedService instance must be identified with
 its
 own unique PID. Please see the Configuration Admin spec
 (http://www.osgi.org/download/r4-v4.2-cmpn-draft-20090310.pdf),
 specifically
 section 104.3 and 104.5

 Is there a common pattern/approach to achieving this, e.g. in my case I
 have
 a property that should turn 'auditing' on or off but this property needs to
 be visible across multiple bundles.

 Thanks,

 Tim



 --
 View this message in context:
 http://apache-felix.18485.x6.nabble.com/Compendium-Services-managed-properties-and-multiple-bundles-tp5004675.html
 Sent from the Apache Felix - Users mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: handle org.apache.servicemix.bundles.freemarker package conflict in Felix?

[Pierre De Rop]

Hi Christiano,

I think that Felix was talking about adding the following property in your
framework conf/config.properties:

org.osgi.framework.system.packages.extra=org.w3c.dom.traversal;
version=...


You can refer to
http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html

Now, I also faced in the past the same kind of problem you are facing, and
what you described in your previous mail is also an option: you can package
the api
in a fragment, as an extension bundle, but I think the system bundle is
system.bundle:

Fragment-Host: system.bundle;extension:=framework


You can possibly refer to the following post, which might help you (see
solution A: extension bundle):

http://blog.springsource.org/2009/01/19/exposing-the-boot-classpath-in-osgi/


hope this helps;
/Pierre





On Mon, May 27, 2013 at 2:48 PM, Cristiano Gavião cvgav...@gmail.comwrote:

 Hi Felix,

 are you talking about to drop org.apache.servicemix.specs.**jaxp-api-1.4,
 create a bundle fragment with the head below and expose the
 org.w3c.dom.traversal package from JDK?

 *Fragment-Host: org.eclipse.osgi;extension:=**framework*


 Btw, the interesting fact is that I could run the same test [1] with same
 bundles at Equinox :/

 this should mean that Equinox don't export any XML package from JDK, right?


 [1] - https://github.com/jbehave/**jbehave-osgi/blob/master/**
 jbehave-osgi-examples/trader-**felix-pomfirst-paxexam/org.**
 jbehave.osgi.examples.trader.**pomfirst.paxexam/src/test/**
 java/org/jbehave/osgi/**examples/trader/pomfirst/**paxexam/embedder/**
 TraderEmbedderOsgiForPaxExam.**javahttps://github.com/jbehave/jbehave-osgi/blob/master/jbehave-osgi-examples/trader-felix-pomfirst-paxexam/org.jbehave.osgi.examples.trader.pomfirst.paxexam/src/test/java/org/jbehave/osgi/examples/trader/pomfirst/paxexam/embedder/TraderEmbedderOsgiForPaxExam.java

 best regards,

 Cristiano


 On 27/05/13 02:44, Felix Meschberger wrote:

 Hi

 Looks like you have a conflict on your platform (and yes, this DOM stuff
 is nasty, as is all XML, unfortunately)

 If your Java Platform provides the org.w3c.dom.traversal package, you
 might want to expose it through the system bundle using the
 org.osgi.framework.system.**packages.extra framework property

 Regards
 Felix

 Am 27.05.2013 um 05:24 schrieb Cristiano Gavião:

 Hello,

 I'm trying to use
 mvn:org.apache.servicemix.**bundles/org.apache.servicemix.**
 bundles.freemarker/2.3.19_1

 When I used it alone I got this error:

 ERROR: Bundle org.apache.servicemix.bundles.**freemarker [16] Error
 starting
 mvn:org.apache.servicemix.**bundles/org.apache.servicemix.**
 bundles.freemarker/2.3.19_1
 (org.osgi.framework.**BundleException: Unresolved constraint in bundle
 org.apache.servicemix.bundles.**freemarker [16]: Unable to resolve 16.0:
 missing requirement [16.0] osgi.wiring.package;
 (osgi.wiring.package=org.w3c.**dom.traversal))
 org.osgi.framework.**BundleException: Unresolved constraint in bundle
 org.apache.servicemix.bundles.**freemarker [16]: Unable to resolve 16.0:
 missing requirement [16.0] osgi.wiring.package;
 (osgi.wiring.package=org.w3c.**dom.traversal)
 at
 org.apache.felix.framework.**Felix.resolveBundleRevision(**
 Felix.java:3974)
 at org.apache.felix.framework.**Felix.startBundle(Felix.java:**2037)
 at
 org.apache.felix.framework.**Felix.setActiveStartLevel(**Felix.java:1291)
 at
 org.apache.felix.framework.**FrameworkStartLevelImpl.run(**
 FrameworkStartLevelImpl.java:**304)
 at java.lang.Thread.run(Thread.**java:722)
 So, I search for a bundle that provides that package:
 org.apache.servicemix.specs.**jaxp-api-1.4. But now I'm get this error:

 ERROR: Bundle org.apache.servicemix.bundles.**freemarker [16] Error
 starting
 mvn:org.apache.servicemix.**bundles/org.apache.servicemix.**
 bundles.freemarker/2.3.19_1
 (org.osgi.framework.**BundleException: Uses constraint violation. Unable
 to resolve bundle revision org.apache.servicemix.bundles.**freemarker
 [16.0] because it is exposed to package 'org.w3c.dom' from bundle
 revisions org.apache.servicemix.specs.**jaxp-api-1.4 [17.0] and
 org.apache.felix.framework [0] via two dependency chains.

 Chain 1:
   org.apache.servicemix.bundles.**freemarker [16.0]
 import: (osgi.wiring.package=org.w3c.**dom)
  |
 export: osgi.wiring.package=org.w3c.**dom
   org.apache.servicemix.specs.**jaxp-api-1.4 [17.0]

 Chain 2:
   org.apache.servicemix.bundles.**freemarker [16.0]
 import: (osgi.wiring.package=javax.**swing.tree)
  |
 export: osgi.wiring.package=javax.**swing.tree; uses:=org.w3c.dom
 export: osgi.wiring.package=org.w3c.**dom
   org.apache.felix.framework [0])
 could someone point me any way to handle this conflict?

 thanks,

 Cristiano

 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@felix.**apache.orgusers-unsubscr...@felix.apache.org
 

Re: Question about scr release schedule

[Pierre De Rop]

Hello Adam;

I don't know when David or Felix plans to cut a release, but looking at
your trace, it seems that your maven crashed ?
Maybe you ran out of memory ?

Can you retry with more memory, using MAVEN_OPTS=-Xmx512m -Xms512m
-server ?

if some tests are still failing, can you then provide the logs from
target/failsafe-reports/*.txt which corresponds to the failing tests ?

regards;
/Pierre

On Thu, May 23, 2013 at 4:17 PM, Adam Purkiss ajpurk...@hotmail.com wrote:

 Recently a high priority bug was fixed
 https://issues.apache.org/jira/browse/FELIX-4069. I was wondering what
 the release schedule is like for SCR as while we can use a snapshot build
 for now ideally we would like the bug to be officially rolled out. I was
 hoping someone could help me understand when the next maintenance release
 is likely to be shipped?

 My concern at the moment is that the unit tests locally fail with the
 below error so I am not sure if that means the current state of scr is that
 it is broken or if I can just skip the tests and run with the snap shot
 as the below error is due to my dev environment setup.


 [org.apache.felix.scr.integration.components.concurrency.C] (exit)log
 level: 4 D=13:20:10,796 T=Thread[Thread-4,5,main]:
 [org.apache.felix.scr.integration.components.concurrency.C(21310)] Unset
 and deconfigured implementationobject for component
 org.apache.felix.scr.integration.components.concurrency.C in
 deleteComponent for reason Component disabledlog level: 4 D=13:20:10,796
 T=Thread[Thread-4,5,main]:
 [org.apache.felix.scr.integration.components.concurrency.C(21310)]
 Deactivating dependency managerslog level: 4 D=13:20:10,796
 T=Thread[Thread-4,5,main]:
 [org.apache.felix.scr.integration.components.concurrency.C(21310)]
 Disabling dependency managersResults :Tests run: 17, Failures: 0, Errors:
 0, Skipped: 0[INFO]
 [INFO]
 BUILD FAILURE[INFO]
 [INFO]
 Total time: 8:16.128s[INFO] Finished at: Tue May 21 13:27:10 EDT 2013[INFO]
 Final Memory: 12M/247M[INFO]
 [ERROR]
 Failed to execute goal
 org.apache.maven.plugins:maven-failsafe-plugin:2.12:integration-test
 (default) on project org.apache.felix.scr: Execution default of goal
 org.apache.maven.plugins:maven-failsafe-plugin:2.12:integration-test
 failed: The forked VM terminated without saying properly goodbye. VM crash
 or System.exit called ? - [Help 1][ERROR][ERROR] To see the full stack
 trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven
 using the -X switch to enable full debug logging.[ERROR][ERROR] For more
 information about the errors and possible solutions, please read the
 following articles:[ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
 thanks
 Adam Purkiss

Re: DependencyManager - osgi.cmpn-4.3.1

[Pierre De Rop]

Hi Bokie,

I reproduced the problem with config-admin 1.6.0. Are you also using it ?

Anyway, Felix found the root cause: it's because of a duplicate export of
the CM api (org.osgi.service.cm package):

1) config-admin 1.6.0 exports org.osgi.service.cm with version=1.5 (because
it implements the latest enterprise osgi compendium).

2) and dependencymanager core imports the org.osgi.service.cm with the
version range [1.3,2), because DM has been compiled with compendium 4.2.0

Now, depending on the start order, we may have the following situation:

- if config-admin is resolved/started *before* dependencymanager, then we
don't have the problem: dependencymanager is wired to the correct
org.osgi.service.cm package with version 1.5 (exported by config-admin
1.6.0).

- but if config-admin is resolved/started *after* dependencymanager, then
we have the problem: that is: dependencymanager bundle is wired to the
wrong 1.4 cm package, exported by the org.osgi.compendium-4.3.1 bundle).

For example, using the following pax-runner command file, I reproduce the
problem:

pax-run.sh  commands.txt

and here is the commands.txt file:

file:bundles/org.apache.felix.gogo.command-0.12.0.jar@1
file:bundles/org.apache.felix.gogo.runtime-0.10.0.jar@1
file:bundles/org.apache.felix.gogo.shell-0.10.0.jar@5
file:bundles/org.apache.felix.webconsole.jar@5
file:bundles/org.apache.felix.gogo.runtime-0.10.0.jar@5
file:bundles/biz.aQute.bndlib-1.43.0.jar@5
file:bundles/org.apache.felix.dependencymanager-3.0.0.jar@5
# start config admin *after* dependencymanager
file:bundles/org.apache.felix.configadmin-1.6.0.jar@5
file:bundles/org.apache.felix.metatype-1.0.7-SNAPSHOT.jar@5
file:bundles/org.apache.felix.dependencymanager.shell-3.0.0.jar@5
file:bundles/test.dm-1.0.jar@5
file:bundles/org.apache.felix.http.jetty.jar@5
file:bundles/org.apache.felix.shell-1.4.3.jar@5
file:bundles/org.apache.felix.dependencymanager.runtime-3.0.0.jar@5
file:bundles/org.osgi.compendium-4.3.1.jar@5
file:bundles/org.apache.felix.bundlerepository-1.6.6.jar@5

now, if we manage to start config-admin before dependencymanager, then it
works:

file:bundles/org.apache.felix.gogo.command-0.12.0.jar@1
file:bundles/org.apache.felix.gogo.runtime-0.10.0.jar@1
file:bundles/org.apache.felix.gogo.shell-0.10.0.jar@5
file:bundles/org.apache.felix.webconsole.jar@5
file:bundles/org.apache.felix.gogo.runtime-0.10.0.jar@5
file:bundles/biz.aQute.bndlib-1.43.0.jar@5
# start config admin *before* dependencymanager
file:bundles/org.apache.felix.configadmin-1.6.0.jar@5
file:bundles/org.apache.felix.dependencymanager-3.0.0.jar@5
file:bundles/org.apache.felix.metatype-1.0.7-SNAPSHOT.jar@5
file:bundles/org.apache.felix.dependencymanager.shell-3.0.0.jar@5
file:bundles/test.dm-1.0.jar@5
file:bundles/org.apache.felix.http.jetty.jar@5
file:bundles/org.apache.felix.shell-1.4.3.jar@5
file:bundles/org.apache.felix.dependencymanager.runtime-3.0.0.jar@5
file:bundles/org.osgi.compendium-4.3.1.jar@5
file:bundles/org.apache.felix.bundlerepository-1.6.6.jar@5


so, shortly speaking: if you really need to use the
org.osgi.compendium-4.3.1 bundle, and if you are also using config-admin
1.6.0, then you have to manage to start the config-admin 1.6.0 bundle
before dependencymanager.

now ...

there is something which is troubling me:

as far as I know, the framework should wire dependencymanager to the 
org.osgi.service.cm package with the highest exported version (that is:
the one exported by config-admin 1.6.0).

So, I'm not sure why we should really start config-admin first.

The other problem that troubles me is we don't have any problems at all
with equinox (that is: using pax-run.sh --p=equinox commands.txt).

So, I wonder if there is (or not) a problem to be investigated in the
framework ?

Felix, what do you think ?

kind regards;
/Pierre


On Mon, Nov 12, 2012 at 7:24 AM, Felix Meschberger fmesc...@adobe.comwrote:

 Hi,

 Am 11.11.2012 um 14:26 schrieb bokie:

  Hi,
 
  When I deploy the osgi.cmpn-4.3.1.jar file as apposed to
 osgi.cmpn-4.2.0.jar

 Is there a reason for deploying this ?


  file I get the following exception:
  org.apache.felix.dm.impl.dependencies.ConfigurationDependencyImpl cannot
 be
  cast to org.osgi.service.cm.ManagedService

 It looks very much there is a duplicate export of the Configuration Admin
 API at two different versions, one from the osgi.cmpn bundle and one from
 the Configuration Admin bundle. These do not seem to be the same (you might
 consider updating the Configuration Admin bundle) and thus the
 Configuration Admin service wires to its own export (because it looks to be
 an older version not implementing the newer version exported by the 4.3.1
 osgi.cmpn bundle). The Dependency Manager bundle wires to the newer API and
 thus these two are not compatible.

 Still this exception looks strange.

 
  Can someone provide some input on this?

 See above.

  Should I even be trying to deploy the 4.3.1 version of the cmpn with
 felix
  4.0.3?

 Good question. The 

Re: DependencyManager - osgi.cmpn-4.3.1

[Pierre De Rop]

Hi Bokie,

I did a quick test with a simple DM activator, using a
ConfigurationDependnecy, and also using osgi.cmpn-4.3.1.jar, but I could
not reproduce the problem.

Can you please give us the list of the bundles you are using ?

From my side, I used the following bundles (with osgi.cmpn-4.3.1.jar):

   ID|State  |Level|Name
0|Active |0|System Bundle (4.1.0.SNAPSHOT)
1|Active |1|aQute Bundle Tool Library (1.43.0)
2|Active |1|Log4j (1.2609.1)
3|Active |1|Apache Felix Bundle Repository (1.6.6)
4|Active |1|Apache Felix Configuration Admin Service (1.6.0)
5|Active |1|Apache Felix Dependency Manager (3.0.0)
6|Active |1|Apache Felix Dependency Manager Runtime (3.0.0)
7|Active |1|Apache Felix Dependency Manager Shell (3.0.0)
8|Active |1|Apache Felix Gogo Command (0.12.0)
9|Active |1|Apache Felix Gogo Runtime (0.10.0)
   10|Active |1|Apache Felix Gogo Shell (0.10.0)
   11|Active |1|Apache Felix Http Jetty (2.2.0)
   12|Active |1|Apache Felix Shell Service (1.4.3)
   13|Active |1|Apache Felix Web Management Console (3.1.8)
   14|Active |1|osgi.cmpn (4.3.1.201210102024)
   15|Active |1|Dependency Manager Test (1.0.0)


best regards;
/Pierre

On Sun, Nov 11, 2012 at 2:26 PM, bokie jms.cer...@gmail.com wrote:

 Hi,

 When I deploy the osgi.cmpn-4.3.1.jar file as apposed to
 osgi.cmpn-4.2.0.jar
 file I get the following exception:
 org.apache.felix.dm.impl.dependencies.ConfigurationDependencyImpl cannot be
 cast to org.osgi.service.cm.ManagedService

 Can someone provide some input on this?
 Should I even be trying to deploy the 4.3.1 version of the cmpn with felix
 4.0.3?

 Thanks,
 Bokie




 --
 View this message in context:
 http://apache-felix.18485.n6.nabble.com/DependencyManager-osgi-cmpn-4-3-1-tp5000342.html
 Sent from the Apache Felix - Users mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix SCR for Declarative Services 1.2

[Pierre De Rop]

Hi Caspar,

The SCR from the Felix trunk is compiled with compendium 4.3.
Can you recompile scr from trunk and do a test with it ?
I think it should work.

regards;
/Pierre

On Thu, Oct 4, 2012 at 7:40 PM, Caspar MacRae ear...@gmail.com wrote:

 Hello,

 Is there a version of Felix SCR that works with OSGi 4.3.0?

 My activate methods aren't being called as they're compiled against
 org.osgi.service.component;version=[1.2,2) and org.apache.felix.scr is
 using org.osgi.service.component;version=[1.1,1.2).  I can't (easily)
 remove the dependencies on ComponentContext at the moment.


 https://repository.apache.org/content/groups/snapshots/org/apache/felix/org.apache.felix.scr/1.6.1-SNAPSHOT/org.apache.felix.scr-1.6.1-20120705.183852-4.jaris
 also using 1.1 and I can't find anything newer.

 Apologies if this is documented somewhere, I searched but did not find.


 thanks,
 Caspar

Re: configurationAdmin update handler

[Pierre De Rop]

Hi Mohica,

I think I have reproduced the issue you describe, and after having checked,
the root cause of the problem is probably the following:

By default, fileinstall listens to  configuration updates, using the
ConfigAdmin interface org.osgi.service.cm.ConfigurationListener interface.
So, when you programatically change the configuration pid from your web
interface, using org.osgi.service.cm.Configuration.update() method, then
fileinstall is notified, and then writes back the configuration update in
your etc/mypid.cfg file. This behavior has the side effect of re-updating
the configuration pid, that's why your pojo's updated callback is invoked
twice.

Now, if you set the following fileinstall system propery in your felix
config.properties, the the problem disappears:

felix.fileinstall.disableConfigSave=false

You can have a look at the fileinstall online documentation, about this
property:

https://cwiki.apache.org/FELIX/apache-felix-file-install.html


kind regards;
/Pierre

On Thu, Feb 2, 2012 at 4:42 PM, Mohica Jasha mohica.ja...@gmail.com wrote:

 Hi,

 I have the following configuration dependency and its corresponding update
 handler method:

 @ConfigurationDependency(pid = mypid, propagate = true)
 void updated(DictionaryString, ? properties) throws
 ConfigurationException {

 }

 If I change the configuration of mypid either by editing the etc/mypid.cfg
 or by editing the configurion through the felix-webconsole everything works
 fine and the above updated method will be called EXACTLY ONCE to handle
 the new configuration.

 Let's say the content of etc/mypid.cfg is the following:
 oldParam = oldValue

 THE PART THAT I DON'T GET:
 I have implemented a webinterface for my service within the same bundle,
 the webinterface through the following operations tries to update the
 configuration of mypid:

 Configuration config = configurationAdmin.getConfiguration(mypid, null);
 Dictionary properties = new HashtableString, String();
 properties.put(felix.fileinstall.filename,
 file:/Users/mohica/apps/apache-karaf-2.2.5/etc/mypid.cfg);
 properties.put(newParam, newValue);
 config.update(properties);

 Now the problem is that the updated method will be called TWICE:

 First with the following properties:
 {service.pid=mypid, newparam=newValue,

 felix.fileinstall.filename=file:/Users/mohica/apps/apache-karaf-2.2.5/etc/mypid.cfg}

 and the second time with the following properties:
 {service.pid=mypid, newparam=newValue,

 felix.fileinstall.filename=file:/Users/mohica/apps/apache-karaf-2.2.5/etc/mypid.cfg,
 oldparam=oldValue}


 Why is it called twice? Am I doing anything wrong?

 Mohica

Re: multiple configuration dependency

[Pierre De Rop]

Hi Mohica,

After more investigations, there is no bugs, and I forgot to tell you about
the changed attribute from the ServiceDependency annotation.

The changed attribute allows to define a callback method when the service
properties are updated, so coming back to the second case in the previous
example, where both services are packaged in different bundles, then in
service2, you can define the dependency over service1 using the changed
callback attribute, and the service2 changed callback will then be
invoked when you update the the service1 configuration:

@Component
public class Service2
{
 // ...

 // Use a ServiceDependency instead of a ConfigurationDependency
 // on Service2, and retrieve service2 configuration using service2
 // osgi service properties.
 // Also define a changed callback in order to see service1 service
properties
 // modification

 @ServiceDependency(changed=updateService1)
 void bindService1(MapString, ? config, Service1Interfaceservice1)
 {
System.out.println(Service2 got Service1 properties:  + config);
 }

 void updateService1(MapString, ? config, Service1Interfaceservice1)
 {
System.out.println(Service2 updated with Service1 properties:  +
config);
 }
}

kind regards;
/Pierre



On Tue, Jan 31, 2012 at 10:33 AM, Pierre De Rop pierre.de...@gmail.comwrote:

 Hi Mohica,

 This sounds like a bug, I will investigate asap.

 regards
 /pierre


 On Mon, Jan 30, 2012 at 9:56 PM, Mohica Jasha mohica.ja...@gmail.comwrote:

 On Mon, Jan 30, 2012 at 8:11 AM, Pierre De Rop pierre.de...@gmail.com
 wrote:

  // Use a ServiceDependency instead of a ConfigurationDependency on
  Service2, and
  // retrieve service2 configuration using service2 osgi service
  properties
 @ServiceDependency
 protected void bindService1(MapString, ? config, Service1Interface
  service1)
 {
 System.out.println(Service2 got Service1 properties:  +
 config);
 }
  }
 
 
 Thanks you very much for you elaborate answer.
 I think the bindService1 is invoked just once, and if service1's
 configuration is changed then service2 does not get informed. Am I right?
 Is there any easy workaround solution for getting updates of service1's
 configuration?

 Thanks,
 Mohica




  Hope this helps,
  /Pierre
 
  On Fri, Jan 27, 2012 at 7:00 PM, Mohica Jasha mohica.ja...@gmail.com
  wrote:
 
   I have two OSGi services: service1 and service2 and each has its own
   service PIDs: service1.pid and service2.pid
  
   service1 only depends on its own configuration, but service2 depends
 on
   both its configuration and service2 configuration and should also get
   informed of any updates of service2's configuration.
   Is it possible to use dependency manager annotation, i.e.,
   @ConfigurationDependency, to specify both of configuration
 dependencies
  of
   service2?
  
   Thanks in advance,
   M
  
 

Re: multiple configuration dependency

[Pierre De Rop]

Hi Mohica,

Assuming that service2 needs configuration from service1.pid and
service2.pid, then there are two cases:

1) case 1: if both services (service1/service2) are packaged in the same
bundle, then yes, service2 may define two configuration dependencies on
both pids, for instance like this:

First, let's define the configuration for service1: (we also define the
meta type params, allowing to configure the service1.pid from webconsole):

@Component
public class Service1
{
@ConfigurationDependency(pid=service1.pid,
heading = Service1 configuration,
description = Service1 configuration description,
metadata = {
@PropertyMetaData(heading = Service1 property,
  description = Service1 property
description,
  defaults = { def },
  id = service1.property,
  cardinality = 0)
}
)
protected void updated(DictionaryString, ? config)
{
System.out.println(Service1 got config:  + config);
}
}

Now, let's define the service2, which depend on both configurations (but
here, when defining the configuration dependency over service1.pid, we only
indicate the pid, not the metatype infos, which already have been defined
in Service1 class):

@Component
public class Service2
{
@ConfigurationDependency(pid=service2.pid,
 heading = Service2 configuration,
 description = Service2 configuration
description,
 metadata = {
 @PropertyMetaData(heading = Service2
property,
   description = Service2
property description,
   defaults = { def },
   id =
service2.property,
   cardinality = 0)
 }
 )
protected void service2updated(DictionaryString, ? config)
{
System.out.println(Service2 got config:  + config);
}

@ConfigurationDependency(pid=service1.pid)
protected void service2updatedWithService1Properties(DictionaryString,
? config)
{
System.out.println(Service2 got Service1 properties:  + config);
}
}

2) case 2: if the two services (service1 and service2) are packaged in
different bundles, then the service2 won't be able to see the configuration
pid from service1. it is the configadmin spec which specifies this
restriction, but this restriction has been relaxed in osgi 4.3, and I don't
know if it has been implemented in the current configadmin from the trunk).

So, in this case, one option consists in doing the following: you can
manage to let the service1 expose itself as a service, and also propagate
the service1 configuration properties to the service1 osgi service
properties. In this way, service2 may depend on the service1 osgi service,
which will be injected with the service properties (including the service1
configuration).

For instance, let's define the service1 with the propagage=true optional
parameter in the configurationdependency: this properties will ensure that
configuration is propagated to the osgi service properties:

@Component
public class Service1 implements Service1Interface /* we provide the
Service1Interface service in service registry */
{
@ConfigurationDependency(pid=service1.pid,
propagate = true, // configuration is propagated to our osgi
service properties
heading = Service1 configuration,
description = Service1 configuration description,
metadata = {
@PropertyMetaData(heading = Service1 property,
  description = Service1 property
description,
  defaults = { def },
  id = service1.property,
  cardinality = 0)
}
)
protected void updated(DictionaryString, ? config)
{
System.out.println(Service1 got config:  + config);
}
}

Then if we get back to the service2; we can now depend on the
Service1Interface, and use a Map parameter in order to receive the service1
service properties, like this:

@Component
public class Service2
{
// ...

 // Use a ServiceDependency instead of a ConfigurationDependency on
Service2, and
 // retrieve service2 configuration using service2 osgi service
properties
@ServiceDependency
protected void bindService1(MapString, ? config, Service1Interface
service1)
{
System.out.println(Service2 got Service1 properties:  + config);
}
}

Hope this helps,
/Pierre

On Fri, Jan 27, 2012 at 7:00 PM, Mohica Jasha mohica.ja...@gmail.comwrote:

 I have two OSGi services: service1 and service2 and each has its own
 

Re: Felix DependencyManager with annotation/eclipse

[Pierre De Rop]

Hi Mohica,

Currently, the dependencymanager annotation plugin is only able to generate
the descriptor files (META-INF/dependencymanager/*) in the target bundle,
not in the maven project directory (that is: under
com.myannotation.project/com.
myannotation.testbundle/META-INF/).

So, it seems that karaf/eik (or equinox ?) is not using the target bundle
when launching/debugging the bundle, but is instead internally
reconstructing the bundle from the eclipse project ? (something similar to
exploded karaf bundles ?)

Anyway, if it is helpful to you, I propose the following: I can add a new
optional parameter (generated-output-dir) in the dependencymanager
annotation maven plugin, in order to let you specify a path (starting from
the project base directory), and the maven plugin will then generate the
extra descriptors files in that path.

For instance, in the following, the optional generated-output-dir
parameter is set to ., and allows to generate the descriptors
(META-INF/*) in the root project directory (in
com.myannotation.project/com.myannotation.testbundle/):

plugin
groupIdorg.apache.felix/groupId

artifactIdorg.apache.felix.dependencymanager.annotation/artifactId
version3.1.0-SNAPSHOT/version
executions
execution
goals
goalscan/goal
/goals
configuration
logwarn/log
generated-output-dir./generated-output-dir
/configuration
/execution
/executions
/plugin


But this will only be possible if you use the maven-plugin, and not the bnd
plugin, in osgi.bnd.
If you are OK with the above proposal, then please open a change request
jira issue for dependencymanager, and I will commit a candidate patch.

PS: I tried to install karaf/eik, like you suggested but could not
reproduce the issue (probably because I'm not enough experienced with pde
plugins and with eik/karaf), so may be you should describe the exacts steps
in the jira issue in order to let me quickly validate the patch before
committing).

kind regards;
/pierre

On Wed, Jan 18, 2012 at 7:12 PM, Mohica Jasha mohica.ja...@gmail.comwrote:

 Hi Pierre,

 Sorry for my late response.


 How I debug in Eclipse:

 I am using http://karaf.apache.org/ as my target platform and
 http://code.google.com/a/eclipselabs.org/p/eik/ plugin which integrates
 karaf with eclipse for debugging.
 The way it works is that: I don't need to deploy the generated jar files
 manually, but eclipse launches my existing Plug-in Project within the Karaf
 OSGi-Framework.

 I am not sure but I think the above method is under the Using Pax Cursor
 to launch easily any supported OSGi framework inside Eclipse. category
 in the link you sent,
 https://cwiki.apache.org/FELIX/integrating-felix-with-eclipse.html



 As I mentioned in the previous email, the jar file generated using mvn
 package is flawless. The jar file HAS the META-INF/dependencymanager
 sub-directory.

 I have attached my project source code. After unzipping it you can simply
 execute the following command to build it:
 mvn clean package eclipse:eclipse -Declipse.pde install

 The problem is eclipse needs META-INF/dependencymanager/ not only in the
 jar file but also in the project folder hierarchy, i.e.,
 com.myannotation.project/com.myannotation.testbundle/META-INF

 After executing the mvn command the generated jar file has the
 META-INF/dependencymanager/ subdirectory. But there is no dependencymanager
 sub-directory inside the
 com.myannotation.project/com.myannotation.testbundle/META-INF . So I cannot
 debug from eclipse. If I manually copy dependencymanager from the jar file
 to com.myannotation.project/com.myannotation.testbundle/META-INF/, then
 debugging within eclipse will start to work.

 My Question:
 What modification should I make to my pom files to put dependencymanager
 not only in the jar file but also in the project folder hierarchy, i.e.,
 com.myannotation.project/com.myannotation.testbundle/META-INF/ ?

 Thanks,
 Mohica




 On Thu, Jan 12, 2012 at 10:42 AM, Pierre De Rop pierre.de...@gmail.comwrote:

 Hi Mohica,

 Good to know that you found how to debug using eclipse, may be you have
 read the following link ?

 https://cwiki.apache.org/FELIX/integrating-felix-with-eclipse.html

 Now, I have tried to reproduce the issue you are describing, but I can't.
 When you change the annotation in the source file, you indeed have to
 recompile the project, by typing mvn package, or mvn install, and the
 descriptors are automatically generated and stored in the target bundle,
 under META-INF/dependencymanager/ subdirectory.

 The question is, how are you debugging ? Are you doing something similar
 to
 what is described in the above link ?

 /Pierre

 On Wed, Jan 11, 2012 at 6:31 PM, Mohica Jasha mohica.ja

Re: Felix GoGo bundle example with DS

[Pierre De Rop]

Hi Cristiano;

The following link describe the service properties which must be provided
by gogo commands:

https://cwiki.apache.org/FELIX/rfc-147-overview.html

kind regards;
/Pierre

On Sat, Jan 14, 2012 at 8:31 PM, Cristiano Gavião cvgav...@gmail.comwrote:

 Hi Felix,

 I'm not using the DS Annotation, but I could understand it...

 GoGo is interested in the properties... hummm :)

 just for the records I could find one example here:
 http://felix.apache.org/site/**apache-felix-dependency-**
 manager-using-annotations-**quick-tour.htmlhttp://felix.apache.org/site/apache-felix-dependency-manager-using-annotations-quick-tour.html

 thank you very much.

 cheers

 Cristiano



 On 14/01/12 15:27, Felix Meschberger wrote:

 Hi,

 Am 14.01.2012 um 18:49 schrieb Cristiano Gavião:

  Hi,

 I would like to create a bundle to add my commands to the felix gogo
 console.

 Could someone point me to any example how can I achieve this, please?

 I could find some examples, but all related to karaf, but it uses
 blueprint and I would like to use Declarative Service.

 Assuming you are using DS Annotations (my example uses the Apache Felix
 ones), this is really simple:

 @Component
 @Service(MyCommand.class)
 @Properties({
   @Property(name=osgi.command.**scope, value=myScope),
   @Property(name=osgi.command.**function, value={cmd1, cmd2})
 })
 public class MyCommand {
   ...
   // methods with Gogo Annotations
   ...
 }

 This class must be registered as a service for Gogo to pick it up but the
 actual interface is irrelevant, so just register with the class name (your
 concrete use may be different).

 Hope this helps.

 Regards
 Felix

  thanks a lot

 Cristiano

 --**--**
 -
 To unsubscribe, e-mail: 
 users-unsubscribe@felix.**apache.orgusers-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org


 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@felix.**apache.orgusers-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org



 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@felix.**apache.orgusers-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: Declarative Services, determining reference satisfaction with target services

[Pierre De Rop]

Hi David,

Indeed I have also reproduce the problem you are describing.
I think I have a working patch; so I will create a JIRA issue and will
attach the patch to it.

kind regards;
/Pierre

On Fri, Aug 26, 2011 at 11:58 PM, david.humen...@l-3com.com wrote:

 It looks like part of the problem is that the ComponentFactoryImpl
 doesn't look at the target service properties for some reason so it
 accepts services even if the target doesn't match.  When the component
 instance is created, the ComponentFactoryNewInstance does check the
 target properties so the instantiation fails.

 I think this is a bug.

 David Humeniuk

 -Original Message-
 From: david.humen...@l-3com.com [mailto:david.humen...@l-3com.com]
 Sent: Friday, August 26, 2011 3:33 PM
 To: users@felix.apache.org
 Subject: Declarative Services, determining reference satisfaction with
 target services

 I have a factory component (call it ComponentA) with a service reference
 (call it X).  The service reference X has an interface of Y and a target
 of (name=Z)



 If a service is registered with an interface of Y, but a name service
 property of something other than Z, I would expect the service reference
 X to not be satisfied.  However, using Felix SCR, I'm seeing that the
 reference is satisfied.  When I go to create an instance with the
 factory, I then get a ComponentException saying the dependency is not
 satisfied.



 David Humeniuk

 Software Engineer

 L-3 Nova Engineering

 4393 Digital Way

 Mason, Ohio 45040

 513-204-7628 (Direct)

 513-204-7600 (Main)

 513-204-8999 (Main Fax)

 www.L-3com.com/Nova




 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: Declarative Services, determining reference satisfaction with target services

[Pierre De Rop]

David,

I created the FELIX-3090 issue, and attached a patch to it.
can you test it ? thanks.

/pierre

On Sat, Aug 27, 2011 at 11:50 PM, Pierre De Rop pierre.de...@gmail.comwrote:

 Hi David,

 Indeed I have also reproduce the problem you are describing.
 I think I have a working patch; so I will create a JIRA issue and will
 attach the patch to it.

 kind regards;
 /Pierre


 On Fri, Aug 26, 2011 at 11:58 PM, david.humen...@l-3com.com wrote:

 It looks like part of the problem is that the ComponentFactoryImpl
 doesn't look at the target service properties for some reason so it
 accepts services even if the target doesn't match.  When the component
 instance is created, the ComponentFactoryNewInstance does check the
 target properties so the instantiation fails.

 I think this is a bug.

 David Humeniuk

 -Original Message-
 From: david.humen...@l-3com.com [mailto:david.humen...@l-3com.com]
 Sent: Friday, August 26, 2011 3:33 PM
 To: users@felix.apache.org
 Subject: Declarative Services, determining reference satisfaction with
 target services

 I have a factory component (call it ComponentA) with a service reference
 (call it X).  The service reference X has an interface of Y and a target
 of (name=Z)



 If a service is registered with an interface of Y, but a name service
 property of something other than Z, I would expect the service reference
 X to not be satisfied.  However, using Felix SCR, I'm seeing that the
 reference is satisfied.  When I go to create an instance with the
 factory, I then get a ComponentException saying the dependency is not
 satisfied.



 David Humeniuk

 Software Engineer

 L-3 Nova Engineering

 4393 Digital Way

 Mason, Ohio 45040

 513-204-7628 (Direct)

 513-204-7600 (Main)

 513-204-8999 (Main Fax)

 www.L-3com.com/Nova




 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: AspectService for dynamic reference

[Pierre De Rop]

Hi Vladimir,

I'm not sure to understand: when you are talking about AspectService, are
you talking about DependencyManager AspectService ?
if true, then I don't think it works in your case, because DM AspectService
only work if you track  MetadataProvider with DependencyManager
ServiceDependency.
in other words, I don't think it's possible to mix DM AspectService with
DeclarativeService, but may be Marcel have to confirm this ?

So, coming back to your use case, if you don't want to use DM
ServiceDependency for tracking the MetadataProvider, but DeclarativeService
(as it seems to be the case),  then may be you could take a look at service
hooks ?

The following tutorial explains how to intercept all service method
invocation using Event/Find Hooks:

http://java.dzone.com/articles/osgi-service-hook-log-all

and you can checkout the sample code from:

svn checkout http://osgiservicelogger.googlecode.com/svn/trunk/

If, however, you would like to consider using DependencyManager
ServiceDependency for tracking the MetadataProvider services, then you could
implement the following thing:

import org.apache.felix.dm.annotation.api.Component;

@Component
public class MetadataProviderTracker {
 @ServiceDependency(required=false, removed=unbindMetadataProvider)
 protected void bindMetadataProvider(MetadataProvider mp) {
 providerMap.put(mp.getType(), mp);
 }

 protected void unbindMetadataProvider(MetadataProvider mp) {
providerMap.remove(mp.getType());
}

// ...
}


and simply define your MetadataProvider interceptor, like this:

@AspectService(ranking = 10 /* the ranking of this Aspect service used to
chain aspects in the proper order */ )
public class MetadataProviderInterceptor implements MetadataProvider
{
   /**
 * This is the MetadataProvider this interceptor is applying to
(injected by reflection).
 */
private volatile MetadataProvider originalMetadataProvider;

   public void callMethod() {
  // Intercept method call, and eventually invoke
this.originalMetadataProvider.callMehod() , if required
   }
}


Alternatively, you  can also use AspectService with a real DynamicProxy:

@AspectService(ranking = 10, service=MetadataProvider.class,
factoryMethod=create)
public class MetadataProviderInterceptor implements InvocationHandler {
   static Object create() {
return
Proxy.newProxyInstance(MetadataProviderInterceptor.class.getClassLoader(),
  new Class[] {
MetadataProviderInterceptor.class },
  new MetadataProviderInterceptor());
   }

   // Injected by reflection
   private volatile MetadataProvider originalMetadataProvider;

  public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
  if (method.getName().equals(callMethod)) {
  // Intercept callMethod
  } else {
  return method.invoke(this.originalMetadataProvider, args);
  }
  }
}



Dos this correspond to your actual needs ?

Kind Regards;
/pierre





On Mon, Mar 14, 2011 at 4:51 PM, TVladimir
vladimirs.tihomir...@gmail.comwrote:


 Hello,
 Could you please suggest solution for the following issue:

 Description:
 There are number of implementations of MetadataProvider interface, these
 implementations are collected into map as described below, and then used by
 application logic

 @Reference(name = metadataProvider, strategy = ReferenceStrategy.EVENT,
 policy = ReferencePolicy.DYNAMIC, referenceInterface =
 MetadataProvider.class, cardinality =
 ReferenceCardinality.OPTIONAL_MULTIPLE)


 protected void bindMetadataProvider(MetadataProvider mp) {
   providerMap.put(mp.getType(), mp);
 }

 protected void unbindMetadataProvider(MetadataProvider mp) {
   providerMap.remove(mp.getType());
 }


 Task:
 I would like to decorate/intercept one of the implementation's method.
 If you do: providerMap.get(“type”).callMethod(), callMethod() should be
 intercepted.

 Issue:
 AspectService approach doesn’t work here.  When I created  AspectService
 for
 MetadataProvider interface, “bind” registered all implementations + aspect
 services for all implementations.

 Any ideas how to make it?

 Thanks,
 Vladimir

 --
 View this message in context:
 http://old.nabble.com/AspectService-for-dynamic-reference-tp31145479p31145479.html
 Sent from the Apache Felix - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: How to handle java.lang.IllegalStateException: The EventAdmin is stopped during shutdown

[Pierre De Rop]

Hi Alexander;

Are you using the dependencymanager from the trunk ?
If so, then I assume that you are also using the dependencymanager
compatibility bundle, because I see that you are using the old
org.apache.felix.dependencymanager package ?

In this case, you might have found a bug from the DM compatibility bundle.
Please open a jira issue for DM, and attach to it your sample code, I will
then investigate.
(I think that your Sender.stop method is not properly invoked by the DM
compat bundle).

Thanks;
/pierre


On Tue, Jan 11, 2011 at 2:42 PM, Alexander Broekhuis
a.broekh...@gmail.comwrote:

 Hi,

 I created a small example with 2 bundles.

 When stopping execution using ctrl-c the interrupted exception is
 thrown. Somehow the stacktrace isn't show now, but only the warning is
 given,
 and the shutdown stops. Trying to list bundles results in
 IllegalStateException. The only way to stop it is by killing the
 process.

 The code is a simple sender and receiver. The Dependency manager is
 used to get a reference to the EventAdmin.


 On 7 January 2011 12:47, Carsten Ziegeler cziege...@apache.org wrote:
  Alexander Broekhuis  wrote
 
  From the stacktrace below I have the feeling that the AbcGenerator is
  using the EventAdmin although the service is already down. How do you
  handle the unregister event of the event admin service?
 
  The EventAdmin is tracked using the DependencyManager. If the service
  is actually down, I would expect a NPE at the point where I use the
  EventAdmin, not an exception from within the EventAdmin. Or is this a
  wrong assumption?
 
  I don't know the DependencyManager :) But maybe you can show the code,
  you use?
 
  Regards
  Carsten
  --
  Carsten Ziegeler
  cziege...@apache.org
 
  -
  To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
  For additional commands, e-mail: users-h...@felix.apache.org
 
 



 --
 Met vriendelijke groet,

 Alexander Broekhuis


 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

Re: unable to build todays Snapshot of Felix Project

[Pierre De Rop]

Hello Matthias,

Yes, it's a know problem, which still has to be fixed.
The DependencyManager sub-project is still in flux, so, please, just comment
the test module in dependencymanager/pom.xml,
or just run maven with the -Dmaven.*test*.*skip*=true option.

Kind Regards;
/pierre

On Fri, Apr 16, 2010 at 2:51 PM, Matthias Neubert 
dipl.inf.matthias.neub...@googlemail.com wrote:

 Hello,

 I'm unable to build todays Snapshot of Felix Project

 For this I use:

 Commands:

 svn checkout http://svn.apache.org/repos/asf/felix/trunk felix
 cd felix
 mvn -Dpackaging=plugins install
 mvn -Dpackaging=bundle install


 Environment:

 Mac OS X 10.6.3
 Java 1.6
 Maven 2.2.1

 Console parameters:
 MAVEN_OPTS=-Xmx512m
 JAVA_OPTS=-Xmx1024M

 Error:

 when executing mvn -Dpackaging=bundle install

 
 Results :

 Tests in error:

  
 testResourceAdapterAnnotation(org.apache.felix.dm.test.annotation.ResourceAnnotationTest)

  
 testRequiredServiceRegistrationAndConsumption(org.apache.felix.dm.test.FELIX2078_ServiceDependencyTest)

 Tests run: 33, Failures: 0, Errors: 2, Skipped: 0

 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] There are test failures.

 Please refer to
 /Users/matthiasneubert/Javadev/felix/dependencymanager/test/target/surefire-reports
 for the individual test results.
 [INFO]
 
 [INFO] For more information, run Maven with the -e switch
 [INFO]
 
 [INFO] Total time: 6 minutes 51 seconds
 [INFO] Finished at: Fri Apr 16 14:40:35 CEST 2010
 [INFO] Final Memory: 106M/199M
 [INFO]
 
 

 I this known? Is it my failure?

 regards
 Matthias