Re: Make DependencyManager API more fluent?
Hello Paul,
indeed, the DM4 code is very close to the old 3.2 API, and it would be
unfortunate if breaking the API too much would make slower the adoption of
the new version.
I gave immense effort to bring to life the new thread model introduced by
Marcel and Xander, and now we also have a nice actor thread model allowing
concurrent activation of Components while staying single threaded
internally ...
so I will check what has changed in the new 4.0 API and will manage to make
it closer to the old 3.2 API as much as possible (but some methods have
been removed, like the setInstanceBound method, for example).
Regarding your suggestion, adding specific builder classes could also be an
interesting way to go.
I would even consider to make some specific API bundles, like:
org.apache.felix.dependencymanager - the current 4.0 API, and it should be
close to the old 3.2 API as much as possible (Marcel, what is your opinion
?)
org.apache.felix.dependencymanager.scala - we could leverage DM API to
scala
org.apache.felix.dependencymanager.groovy - same for groovy
etc ...
All this could be discussed with more details in the jira issue that
Christian created.
kind regards
/Pierre
On Tue, Nov 11, 2014 at 8:55 AM, Paul Bakker paul.bak...@luminis.eu wrote:
One thing to consider is that although DM 4 is a major version bump, it so
far seems to be very close to a drop-in replacement of DM 3. Changing the
API itself would break all existing code. This is technically ok for a
major version, but will make adoption of the new version a lot slower.
On the other hand, I do like the proposal :-) Maybe it's possible to add a
new API, while keeping the existing one. E.g. introduce a builder class
specifically for this reason, user can than gradually move towards the new
API. Potentially there could even be builders for multiple JVM languages,
leveraging the DSL functionality of language Groovy etc.
Cheers,
Paul
On Tue, Nov 11, 2014 at 12:39 AM, Pierre De Rop pierre.de...@gmail.com
wrote:
Hello Christian;
The improvements you are proposing would require a major version bump
since
it's an incompatible API change. But I personally like what you are
suggesting, and I could quickly do it in the upcoming Dependency Manager
4.0.0, which is a new major version.
But before, I need to know if Marcel is agree to go ahead with all this;
so
for the moment, may be you can just create a Jira issue, and let's wait
for
Marcel to see if he's OK.
Just one remark: the setters can be easily removed, however I think we
can't manage to make the component() method automatically add the
Component to the DependencyManager, because technically; when you add a
Component to a DependencyManager, the Component is actually *activated*,
and at this point, all the necessary dependencies have to be already in
place.
So, the only possible improvement I'm thinking about for now could have
the
form of this:
public void init(BundleContext context, DependencyManager manager)
throws Exception {
component()
.implementation(DataGenerator.class)
.add(serviceDependency(Store.class).required())
.add(serviceDependency(LogService.class))
.addTo(manager);
}
(notice the addTo method at the end of the sample above, which could just
add the fully built component to the DependencyManager manager object).
but I propose you first create the Jira issue and see what Marcel thinks.
I will possible add more suggestions in your Jira issue once you will
have
created it (like also using a builder pattern for the aspects/adapters:
this would allow to reduce the number of method signatures for the
createAdapter/createAspect methods).
kind regards (and thanks for proposing to improve Dependency Manager :-))
/Pierre
On Mon, Nov 10, 2014 at 11:40 AM, Christian Schneider
ch...@die-schneider.net wrote:
I wonder if the DependencyManager API could be made a bit more fluent.
Technically it already uses the fluent builder pattern
but all the builder verbs still look a lot like traditional setters.
I know what I propose is mostly syntactic sugar but I think the result
looks more readable and crisp. See below for some ideas.
Christian
This is from samples.dependonservice:
public void init(BundleContext context, DependencyManager manager)
throws Exception {
manager.add(createComponent()
.setImplementation(DataGenerator.class)
.add(createServiceDependency()
.setService(Store.class)
.setRequired(true)
)
.add(createServiceDependency()
.setService(LogService.class)
.setRequired(false)
)
);
}
Why not make it look like this:
public void init(BundleContext context, DependencyManager
Re: Make DependencyManager API more fluent?
Hello Christian,
We could indeed deprecate all the setters methods, and introduce your
proposed builder methods. And I do agree that we could also manage to let
the new DependencyActivatorBase.component() method maintain the list of
created components, and we could then auto-add all the created components
in the DependencyManager object once the DependencyActivatorBase.init()
method returns.
So, let's continue to discuss with Marcel about all of this in the jira
issue you have created, and we also have to think about what Paul is
proposing.
For your information, the code from felix-trunk/dependencymanager is out
dated, and I'm working since several months on a new DM 4.0.0 version,
which is currently in [1].
We are using a new thread model which is described in [2] and in the
presentation I recently added in [3] (see the what's new in DM 4.0
section at the end of the presentation)
For now the code is still unstable and I need some more time to finalize
the API (one week I think).
And then once finalized (I will email), then you could try to attach a
patch in the jira issue (but on the sandbox codebase). This will help
Marcel to decide.
Cheers;
/Pierre
[1]
http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/
[2]
http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/design.txt
[3]
http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/doc/A_Glance_At_DependencyManager.odp
On Tue, Nov 11, 2014 at 9:22 AM, Christian Schneider
ch...@die-schneider.net wrote:
Hi Pierre,
I think we can and should do this without a major version bump.
We could simply add the new builders and keep the old ones in parallel in
deprecated status.
This would allow people some time to switch to the new syntax. For the
major version we can then later remove the deprecated syntax.
About auto adding. How about this:
Inside component() we add the component to a separate list of pending
components in dependency manager.
Then after init we call a method in the manager to finally add all pending
components into the active structure.
In that method we could then also convert from the class with the new
syntax to the existing class. So the changes for the new syntax would have
minimal impact to the rest of the code.
I created an issue for this:
https://issues.apache.org/jira/browse/FELIX-4689
As I would like to work on becoming a felix committer in the long term I
would ideally like to work this out and create a patch for the issue. If
you prefer to do it yourself I am also fine of course. In any case I agree
that we should first wait for feedback from Marcel.
Christian
On 11.11.2014 00:39, Pierre De Rop wrote:
Hello Christian;
The improvements you are proposing would require a major version bump
since
it's an incompatible API change. But I personally like what you are
suggesting, and I could quickly do it in the upcoming Dependency Manager
4.0.0, which is a new major version.
But before, I need to know if Marcel is agree to go ahead with all this;
so
for the moment, may be you can just create a Jira issue, and let's wait
for
Marcel to see if he's OK.
Just one remark: the setters can be easily removed, however I think we
can't manage to make the component() method automatically add the
Component to the DependencyManager, because technically; when you add a
Component to a DependencyManager, the Component is actually *activated*,
and at this point, all the necessary dependencies have to be already in
place.
So, the only possible improvement I'm thinking about for now could have
the
form of this:
public void init(BundleContext context, DependencyManager manager)
throws Exception {
component()
.implementation(DataGenerator.class)
.add(serviceDependency(Store.class).required())
.add(serviceDependency(LogService.class))
.addTo(manager);
}
(notice the addTo method at the end of the sample above, which could just
add the fully built component to the DependencyManager manager object).
but I propose you first create the Jira issue and see what Marcel thinks.
I will possible add more suggestions in your Jira issue once you will have
created it (like also using a builder pattern for the aspects/adapters:
this would allow to reduce the number of method signatures for the
createAdapter/createAspect methods).
kind regards (and thanks for proposing to improve Dependency Manager :-))
/Pierre
On Mon, Nov 10, 2014 at 11:40 AM, Christian Schneider
ch...@die-schneider.net wrote:
I wonder if the DependencyManager API could be made a bit more fluent.
Technically it already uses the fluent builder pattern
but all the builder verbs still look a lot like traditional setters.
I know what I propose is mostly syntactic sugar but I think the result
looks more readable and crisp. See below for some
Re: Make DependencyManager API more fluent?
Hi Pierre,
Don't worry, I don't think it's a problem at all if some things changed.
It's a huge new release after all! I was only suggesting that we shouldn't
get rid of the component registration API completely in favour of a better
API. For the methods that don't longer exist etc. I don't see much problem,
this are more special cases anyway.
I know about the new threading mechanism btw, very good stuff :-)
Cheers,
Paul
On Wed, Nov 12, 2014 at 9:13 AM, Pierre De Rop pierre.de...@gmail.com
wrote:
Hello Paul,
indeed, the DM4 code is very close to the old 3.2 API, and it would be
unfortunate if breaking the API too much would make slower the adoption of
the new version.
I gave immense effort to bring to life the new thread model introduced by
Marcel and Xander, and now we also have a nice actor thread model allowing
concurrent activation of Components while staying single threaded
internally ...
so I will check what has changed in the new 4.0 API and will manage to make
it closer to the old 3.2 API as much as possible (but some methods have
been removed, like the setInstanceBound method, for example).
Regarding your suggestion, adding specific builder classes could also be an
interesting way to go.
I would even consider to make some specific API bundles, like:
org.apache.felix.dependencymanager - the current 4.0 API, and it should be
close to the old 3.2 API as much as possible (Marcel, what is your opinion
?)
org.apache.felix.dependencymanager.scala - we could leverage DM API to
scala
org.apache.felix.dependencymanager.groovy - same for groovy
etc ...
All this could be discussed with more details in the jira issue that
Christian created.
kind regards
/Pierre
On Tue, Nov 11, 2014 at 8:55 AM, Paul Bakker paul.bak...@luminis.eu
wrote:
One thing to consider is that although DM 4 is a major version bump, it
so
far seems to be very close to a drop-in replacement of DM 3. Changing the
API itself would break all existing code. This is technically ok for a
major version, but will make adoption of the new version a lot slower.
On the other hand, I do like the proposal :-) Maybe it's possible to add
a
new API, while keeping the existing one. E.g. introduce a builder class
specifically for this reason, user can than gradually move towards the
new
API. Potentially there could even be builders for multiple JVM languages,
leveraging the DSL functionality of language Groovy etc.
Cheers,
Paul
On Tue, Nov 11, 2014 at 12:39 AM, Pierre De Rop pierre.de...@gmail.com
wrote:
Hello Christian;
The improvements you are proposing would require a major version bump
since
it's an incompatible API change. But I personally like what you are
suggesting, and I could quickly do it in the upcoming Dependency
Manager
4.0.0, which is a new major version.
But before, I need to know if Marcel is agree to go ahead with all
this;
so
for the moment, may be you can just create a Jira issue, and let's wait
for
Marcel to see if he's OK.
Just one remark: the setters can be easily removed, however I think we
can't manage to make the component() method automatically add the
Component to the DependencyManager, because technically; when you add a
Component to a DependencyManager, the Component is actually
*activated*,
and at this point, all the necessary dependencies have to be already in
place.
So, the only possible improvement I'm thinking about for now could have
the
form of this:
public void init(BundleContext context, DependencyManager manager)
throws Exception {
component()
.implementation(DataGenerator.class)
.add(serviceDependency(Store.class).required())
.add(serviceDependency(LogService.class))
.addTo(manager);
}
(notice the addTo method at the end of the sample above, which could
just
add the fully built component to the DependencyManager manager
object).
but I propose you first create the Jira issue and see what Marcel
thinks.
I will possible add more suggestions in your Jira issue once you will
have
created it (like also using a builder pattern for the aspects/adapters:
this would allow to reduce the number of method signatures for the
createAdapter/createAspect methods).
kind regards (and thanks for proposing to improve Dependency Manager
:-))
/Pierre
On Mon, Nov 10, 2014 at 11:40 AM, Christian Schneider
ch...@die-schneider.net wrote:
I wonder if the DependencyManager API could be made a bit more
fluent.
Technically it already uses the fluent builder pattern
but all the builder verbs still look a lot like traditional setters.
I know what I propose is mostly syntactic sugar but I think the
result
looks more readable and crisp. See below for some ideas.
Christian
This is from
Re: Make DependencyManager API more fluent?
Sounds good to me. For me it is not time critical so I can wait till you signal me that the code is in good shape. Christian On 12.11.2014 09:14, Pierre De Rop wrote: Hello Christian, We could indeed deprecate all the setters methods, and introduce your proposed builder methods. And I do agree that we could also manage to let the new DependencyActivatorBase.component() method maintain the list of created components, and we could then auto-add all the created components in the DependencyManager object once the DependencyActivatorBase.init() method returns. So, let's continue to discuss with Marcel about all of this in the jira issue you have created, and we also have to think about what Paul is proposing. For your information, the code from felix-trunk/dependencymanager is out dated, and I'm working since several months on a new DM 4.0.0 version, which is currently in [1]. We are using a new thread model which is described in [2] and in the presentation I recently added in [3] (see the what's new in DM 4.0 section at the end of the presentation) For now the code is still unstable and I need some more time to finalize the API (one week I think). And then once finalized (I will email), then you could try to attach a patch in the jira issue (but on the sandbox codebase). This will help Marcel to decide. Cheers; /Pierre -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Assigned] (FELIX-4622) Regression: SCR spec version detection incorrect for activate method
[
https://issues.apache.org/jira/browse/FELIX-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-4622:
---
Assignee: Carsten Ziegeler
Regression: SCR spec version detection incorrect for activate method
Key: FELIX-4622
URL: https://issues.apache.org/jira/browse/FELIX-4622
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.20.0
Reporter: Konrad Windszus
Assignee: Carsten Ziegeler
Priority: Critical
Fix For: maven-scr-plugin 1.21.0
In all versions from 1.11.0 till (including 1.20.0) the following method
signature does not enforce the right scr version(1.1.0).
{code}
public void activate(@SuppressWarnings(rawtypes) final Map properties,
final ComponentContext context) throws Exception
{code}
With all previous versions of the maven-scr-plugin the DS version was
correctly set to 1.1.
It does work though even in newer version of the maven-scr-plugin if I
annotate that method with @Activate. Please fix the version detection
mechanism so that these OSGi components generate a descriptor with version
1.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4622) Regression: SCR spec version detection incorrect for activate method
[
https://issues.apache.org/jira/browse/FELIX-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-4622:
Fix Version/s: maven-scr-plugin 1.21.0
Regression: SCR spec version detection incorrect for activate method
Key: FELIX-4622
URL: https://issues.apache.org/jira/browse/FELIX-4622
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.20.0
Reporter: Konrad Windszus
Priority: Critical
Fix For: maven-scr-plugin 1.21.0
In all versions from 1.11.0 till (including 1.20.0) the following method
signature does not enforce the right scr version(1.1.0).
{code}
public void activate(@SuppressWarnings(rawtypes) final Map properties,
final ComponentContext context) throws Exception
{code}
With all previous versions of the maven-scr-plugin the DS version was
correctly set to 1.1.
It does work though even in newer version of the maven-scr-plugin if I
annotate that method with @Activate. Please fix the version detection
mechanism so that these OSGi components generate a descriptor with version
1.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4413) Update maven-scr-plugin to use standard OSGi annotations
[
https://issues.apache.org/jira/browse/FELIX-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-4413:
Fix Version/s: maven-scr-plugin 1.20.0
Update maven-scr-plugin to use standard OSGi annotations
Key: FELIX-4413
URL: https://issues.apache.org/jira/browse/FELIX-4413
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.15.0
Reporter: Alex Blewitt
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.20.0
The maven-scr-1.15.0 plugin complains when org.apache.felix.scr.annotations
is missing, and even when present appears to ignore components registered
with the standard OSGi annotations in the OSGi Enterprise 5.0 specification.
This class generates the maven scr data:
import org.apache.felix.scr.annotations.Component;
//import org.osgi.service.component.annotations.Component;
@Component(name = Test)
public class Test implements Runnable {
public void run() {
}
}
This one does not:
//import org.apache.felix.scr.annotations.Component;
import org.osgi.service.component.annotations.Component;
@Component(name = Test)
public class Test implements Runnable {
public void run() {
}
}
This was compiled with the following dependencies set:
dependencies
dependency
groupIdorg.apache.felix/groupId
artifactIdorg.apache.felix.scr.annotations/artifactId
version1.9.6/version
/dependency
dependency
groupIdorg.osgi/groupId
artifactIdorg.osgi.enterprise/artifactId
version5.0.0/version
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-scr-plugin/artifactId
version1.15.0/version
executions
execution
idgenerate-scr-scrdescriptor/id
goals
goalscr/goal
/goals
/execution
/executions
/plugin
/plugins
/build
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4413) Update maven-scr-plugin to use standard OSGi annotations
[
https://issues.apache.org/jira/browse/FELIX-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-4413.
-
Resolution: Fixed
This is documented now
Update maven-scr-plugin to use standard OSGi annotations
Key: FELIX-4413
URL: https://issues.apache.org/jira/browse/FELIX-4413
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.15.0
Reporter: Alex Blewitt
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.20.0
The maven-scr-1.15.0 plugin complains when org.apache.felix.scr.annotations
is missing, and even when present appears to ignore components registered
with the standard OSGi annotations in the OSGi Enterprise 5.0 specification.
This class generates the maven scr data:
import org.apache.felix.scr.annotations.Component;
//import org.osgi.service.component.annotations.Component;
@Component(name = Test)
public class Test implements Runnable {
public void run() {
}
}
This one does not:
//import org.apache.felix.scr.annotations.Component;
import org.osgi.service.component.annotations.Component;
@Component(name = Test)
public class Test implements Runnable {
public void run() {
}
}
This was compiled with the following dependencies set:
dependencies
dependency
groupIdorg.apache.felix/groupId
artifactIdorg.apache.felix.scr.annotations/artifactId
version1.9.6/version
/dependency
dependency
groupIdorg.osgi/groupId
artifactIdorg.osgi.enterprise/artifactId
version5.0.0/version
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-scr-plugin/artifactId
version1.15.0/version
executions
execution
idgenerate-scr-scrdescriptor/id
goals
goalscr/goal
/goals
/execution
/executions
/plugin
/plugins
/build
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-4691) Empty string value for property causes build failure
Mikael Åsberg created FELIX-4691: Summary: Empty string value for property causes build failure Key: FELIX-4691 URL: https://issues.apache.org/jira/browse/FELIX-4691 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.5.3 Reporter: Mikael Åsberg Hi, when I upgraded from maven-bundle-plugin version 2.4.0 to version 2.5.3, I noticed a build failure when I performed mvn clean install on one of my OSGi services. The error is related to a service property of type String where the value has been set to empty string: @Property (value = ) private static final String MY_PROPERTY = foo; The error is: [INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @ servicepropertytest --- [ERROR] Bundle org.mindcooler:servicepropertytest:bundle:0.1.0 : No value after '=' sign for attribute foo [ERROR] Error(s) found in bundle configuration I see the same problem versions 2.5.2, 2.5.1, and 2.5.0 of maven-bundle-plugin, but if I go back to version 2.4.0 of maven-bundle-plugin, but change nothing else, the problem disappears. Have I found a problem here or is my code incorrect? I have attached a minimal sample Maven project -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4691) Empty string value for property causes build failure
[ https://issues.apache.org/jira/browse/FELIX-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Åsberg updated FELIX-4691: - Attachment: servicepropertytest.zip Minimal Maven sample project illustrating the failure. See it by issuing mvn clean install, change to maven-bundle-plugin version 2.4.0 and mvn clean install does not fail. Empty string value for property causes build failure Key: FELIX-4691 URL: https://issues.apache.org/jira/browse/FELIX-4691 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.5.3 Reporter: Mikael Åsberg Attachments: servicepropertytest.zip Hi, when I upgraded from maven-bundle-plugin version 2.4.0 to version 2.5.3, I noticed a build failure when I performed mvn clean install on one of my OSGi services. The error is related to a service property of type String where the value has been set to empty string: @Property (value = ) private static final String MY_PROPERTY = foo; The error is: [INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @ servicepropertytest --- [ERROR] Bundle org.mindcooler:servicepropertytest:bundle:0.1.0 : No value after '=' sign for attribute foo [ERROR] Error(s) found in bundle configuration I see the same problem versions 2.5.2, 2.5.1, and 2.5.0 of maven-bundle-plugin, but if I go back to version 2.4.0 of maven-bundle-plugin, but change nothing else, the problem disappears. Have I found a problem here or is my code incorrect? I have attached a minimal sample Maven project -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4692) Improve Service access time
Felix Meschberger created FELIX-4692: Summary: Improve Service access time Key: FELIX-4692 URL: https://issues.apache.org/jira/browse/FELIX-4692 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-4.4.1 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: framework-4.6.0 Currently the ServiceRegistry takes roughly 1ms to access a single service. In a reasonably large system, this may over time consume considerable time. For example in our inhouse system sporting roughly 5000 services with 15'000 service accesses during startup, these accesses acount for almost 15 seconds or roughly 25-30% of the total startup time. Internally all accesses to services are handled with a Filter even if the service is simply retrieved with the service name without a filter. This causes a considerable overhead. A simple improvement is to keep services not only in a global Capabitliy Set accessible through generic filters but also keep such a set for each registered service name. The measured improvement of this change is substantial: accessing these 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4692: - Attachment: FELIX-4692.diff Patch with the proposed change. Improve Service access time --- Key: FELIX-4692 URL: https://issues.apache.org/jira/browse/FELIX-4692 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-4.4.1 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: framework-4.6.0 Attachments: FELIX-4692.diff Currently the ServiceRegistry takes roughly 1ms to access a single service. In a reasonably large system, this may over time consume considerable time. For example in our inhouse system sporting roughly 5000 services with 15'000 service accesses during startup, these accesses acount for almost 15 seconds or roughly 25-30% of the total startup time. Internally all accesses to services are handled with a Filter even if the service is simply retrieved with the service name without a filter. This causes a considerable overhead. A simple improvement is to keep services not only in a global Capabitliy Set accessible through generic filters but also keep such a set for each registered service name. The measured improvement of this change is substantial: accessing these 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Improve Service Access (FELIX-4692)
Hi I have created a patch to improve the Service Access time. With this patch applied I measure 4-5 times faster access to the service registry in our application which in general access services simply by its name and almost never uses a filter. I expect that this patch also significantly improves service access if both a filter and a service name is supplied. I expect no change if no service name is supplied, though, since then the complete service registry has to be searched. See issue FELIX-4692. It would be great if this patch could be quickly reviewed before I actually apply it. Thanks Felix [1] https://issues.apache.org/jira/browse/FELIX-4692
[jira] [Commented] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208081#comment-14208081 ] Richard S. Hall commented on FELIX-4692: Did you investigate whether or not there was something that could be modified in the lookup path to improve performance. If the service lookup is being done by className and no filter, then I would expect that this would be reasonably straightforward since internally the ServiceRegistry.getServiceReferences() method converts this to internal filter format (i.e., no parsing is required) and then does a CapabilitySet.match() with the filter that should immediately it the index for objectClass and return the matching result. It would be interesting to know where it was spending its time to see if there was a general fix for the issue. Perhaps there is no general fix and it is just the mechanics of doing it generically that causes the slow down, but it would be nice to know more precisely. Improve Service access time --- Key: FELIX-4692 URL: https://issues.apache.org/jira/browse/FELIX-4692 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-4.4.1 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: framework-4.6.0 Attachments: FELIX-4692.diff Currently the ServiceRegistry takes roughly 1ms to access a single service. In a reasonably large system, this may over time consume considerable time. For example in our inhouse system sporting roughly 5000 services with 15'000 service accesses during startup, these accesses acount for almost 15 seconds or roughly 25-30% of the total startup time. Internally all accesses to services are handled with a Filter even if the service is simply retrieved with the service name without a filter. This causes a considerable overhead. A simple improvement is to keep services not only in a global Capabitliy Set accessible through generic filters but also keep such a set for each registered service name. The measured improvement of this change is substantial: accessing these 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Improve Service Access (FELIX-4692)
On 11/12/14 09:17 , Felix Meschberger wrote: Hi I have created a patch to improve the Service Access time. With this patch applied I measure 4-5 times faster access to the service registry in our application which in general access services simply by its name and almost never uses a filter. I expect that this patch also significantly improves service access if both a filter and a service name is supplied. I expect no change if no service name is supplied, though, since then the complete service registry has to be searched. See issue FELIX-4692. It would be great if this patch could be quickly reviewed before I actually apply it. I commented on the bug. I don't see any issue with the patch per se, but I'd be interested in knowing where in the execution path for find a service by objectClass we are seeing overhead. For the most part, it looks like this should just create an already parsed filter call CapSet.match() which would internally call another match(), where we would hit the index and return the result. It seems like the only overhead besides creating the parsed simple filter is a a couple method calls and some conditionals. Would it make a difference if we simply checked for the special case of an objectClass filter immediately rather than making it the else? Seems hard to believe it would, but you never know. - richard Thanks Felix [1] https://issues.apache.org/jira/browse/FELIX-4692
[jira] [Created] (FELIX-4693) When exception is thrown in onArrival method of iPojo white board pattern handler, related iPojo instance seems to be dead
Olivier Bigard created FELIX-4693: - Summary: When exception is thrown in onArrival method of iPojo white board pattern handler, related iPojo instance seems to be dead Key: FELIX-4693 URL: https://issues.apache.org/jira/browse/FELIX-4693 Project: Felix Issue Type: Wish Components: iPOJO Affects Versions: ipojo-runtime-1.8.6 Reporter: Olivier Bigard When the onArrival method of iPojo white board pattern handler throws an uncaught exception, the related iPojo instance seems to be dead... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4622) Regression: SCR spec version detection incorrect for activate method
[
https://issues.apache.org/jira/browse/FELIX-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-4622:
Assignee: (was: Carsten Ziegeler)
Regression: SCR spec version detection incorrect for activate method
Key: FELIX-4622
URL: https://issues.apache.org/jira/browse/FELIX-4622
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.20.0
Reporter: Konrad Windszus
Priority: Critical
Fix For: maven-scr-plugin 1.21.0
In all versions from 1.11.0 till (including 1.20.0) the following method
signature does not enforce the right scr version(1.1.0).
{code}
public void activate(@SuppressWarnings(rawtypes) final Map properties,
final ComponentContext context) throws Exception
{code}
With all previous versions of the maven-scr-plugin the DS version was
correctly set to 1.1.
It does work though even in newer version of the maven-scr-plugin if I
annotate that method with @Activate. Please fix the version detection
mechanism so that these OSGi components generate a descriptor with version
1.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Framework compilation problems
Hello everyone; I would like to test the patch provided by Felix for the FELIX-4692 issue (Improve Service access time). But before applying the patch provided by Felix, I just can't compile the framework (the tests does not seem to compile): I'm on a linux fc19, uname -a = Linux nx0012 3.14.22-100.fc19.i686.PAE #1 SMP Wed Oct 15 13:06:27 UTC 2014 i686 i686 i386 GNU/Linux and my jdk is 1.7.0_67: I have attached the compile errors I'm having. it looks like there is a problem with my framework os version (with the jvm org.osgi.framework.os.version system property). But I tried to compile on another linux box and I'm having the same kind of errors. can anyone please take a look ? thanks; kind regards /Pierre
Re: Make DependencyManager API more fluent?
Hey all,
On 11 Nov 2014, at 0:39 am, Pierre De Rop pierre.de...@gmail.com wrote:
The improvements you are proposing would require a major version bump since
it's an incompatible API change. But I personally like what you are
suggesting, and I could quickly do it in the upcoming Dependency Manager
4.0.0, which is a new major version.
Agreed, we cannot introduce something like this any sooner than in version 4.
However, it is probably not too hard to implement this yourself on top of the
current release either, since 80% of what Christian is proposing is just
renaming existing methods:
If you create your own version of DependencyManagerBase and also wrap classes
like Component and ServiceDependency/ConfigurationDependency it is quite
straightforward to delegate from your new set of methods to the existing ones.
This goes in the direction that Paul proposes as well with the builder class.
But before, I need to know if Marcel is agree to go ahead with all this; so
for the moment, may be you can just create a Jira issue, and let's wait for
Marcel to see if he's OK.
I am fairly neutral on this.
Yes, the proposed methods are better aligned with most fluent APIs. However,
two downsides I see is that it does break the existing API, making it harder
for people to migrate to version 4 (and, for various reasons, they should do
that). Also, you are not required to use the fluent style, in some cases you
end up invoking individual setter methods on DM components and in those cases,
the fluent style methods might look a bit strange.
Because of this, maybe we should explore the separate builder class that Paul
suggested!?
Just one remark: the setters can be easily removed, however I think we
can't manage to make the component() method automatically add the
Component to the DependencyManager, because technically; when you add a
Component to a DependencyManager, the Component is actually *activated*,
and at this point, all the necessary dependencies have to be already in
place.
Yes, and there are a few other scenarios as well where you don’t want to
combine creating and adding a component, so I think we should leave that part
alone.
So, the only possible improvement I'm thinking about for now could have the
form of this:
public void init(BundleContext context, DependencyManager manager)
throws Exception {
component()
.implementation(DataGenerator.class)
.add(serviceDependency(Store.class).required())
.add(serviceDependency(LogService.class))
.addTo(manager);
}
(notice the addTo method at the end of the sample above, which could just
add the fully built component to the DependencyManager manager object).
I don’t think that makes the code better. You still have two calls (one to
create, one to add) and if you forget the addTo(…) it will probably still be
hard to spot that that was the “bug”.
but I propose you first create the Jira issue and see what Marcel thinks.
I will possible add more suggestions in your Jira issue once you will have
created it (like also using a builder pattern for the aspects/adapters:
this would allow to reduce the number of method signatures for the
createAdapter/createAspect methods).
kind regards (and thanks for proposing to improve Dependency Manager :-))
Agreed, this is a good discussion, thanks for the input!
Greetings, Marcel
Re: Make DependencyManager API more fluent?
Hey Paul, On 11 Nov 2014, at 8:55 am, Paul Bakker paul.bak...@luminis.eu wrote: One thing to consider is that although DM 4 is a major version bump, it so far seems to be very close to a drop-in replacement of DM 3. Changing the API itself would break all existing code. This is technically ok for a major version, but will make adoption of the new version a lot slower. So far our approach has been to fix the things we really wanted to fix but leave everything we don’t need to change as is, exactly because of the reason you mention. We want people to move to the new release as painless as possible. On the other hand, I do like the proposal :-) Maybe it's possible to add a new API, while keeping the existing one. E.g. introduce a builder class specifically for this reason, user can than gradually move towards the new API. Potentially there could even be builders for multiple JVM languages, leveraging the DSL functionality of language Groovy etc. I like this suggestion, like I stated in my previous mail it might require wrapping a few classes but it’s definitely doable and probably a good way to get some experience under our belts with this approach. Greetings, Marcel
Re: Make DependencyManager API more fluent?
Hello Christian, On 11 Nov 2014, at 9:22 am, Christian Schneider ch...@die-schneider.net wrote: About auto adding. How about this: Inside component() we add the component to a separate list of pending components in dependency manager. Then after init we call a method in the manager to finally add all pending components into the active structure. In that method we could then also convert from the class with the new syntax to the existing class. So the changes for the new syntax would have minimal impact to the rest of the code. The problem with this approach is that the API can be used outside of the init method as well, so I don’t like adding code that only works in a specific scenario. Greetings, Marcel
Re: Make DependencyManager API more fluent?
Hello Pierre, On 12 Nov 2014, at 9:13 am, Pierre De Rop pierre.de...@gmail.com wrote: Regarding your suggestion, adding specific builder classes could also be an interesting way to go. I would even consider to make some specific API bundles, like: org.apache.felix.dependencymanager - the current 4.0 API, and it should be close to the old 3.2 API as much as possible (Marcel, what is your opinion ?) Yes, we can keep this as close to the existing API to ease migration. org.apache.felix.dependencymanager.scala - we could leverage DM API to scala org.apache.felix.dependencymanager.groovy - same for groovy etc … All this could be discussed with more details in the jira issue that Christian created. Makes sense, and we could introduce a .java package (and bundle) for the API that Christian proposed. That fits nicely in our plans (just like we have the .runtime and annotations if you like that style) and possibly also our future support for the declarative services API. Greetings, Marcel
Re: Framework compilation problems
Hi Pierre, I don't see your attachment with the errors. Did you forget to attach it? Cheers, David On 12 November 2014 13:49, Pierre De Rop pierre.de...@gmail.com wrote: Hello everyone; I would like to test the patch provided by Felix for the FELIX-4692 issue (Improve Service access time). But before applying the patch provided by Felix, I just can't compile the framework (the tests does not seem to compile): I'm on a linux fc19, uname -a = Linux nx0012 3.14.22-100.fc19.i686.PAE #1 SMP Wed Oct 15 13:06:27 UTC 2014 i686 i686 i386 GNU/Linux and my jdk is 1.7.0_67: I have attached the compile errors I'm having. it looks like there is a problem with my framework os version (with the jvm org.osgi.framework.os.version system property). But I tried to compile on another linux box and I'm having the same kind of errors. can anyone please take a look ? thanks; kind regards /Pierre
