[jira] [Commented] (FELIX-5028) ServiceFactory for components might return null

[Pierre De Rop (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14746309#comment-14746309
 ] 

Pierre De Rop commented on FELIX-5028:
--

ok, I see your point; let's forget about this extra check.

> ServiceFactory for components might return null
> ---
>
> Key: FELIX-5028
> URL: https://issues.apache.org/jira/browse/FELIX-5028
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.0.2
>
>
> There seems to be an uneven handling of locking/status information in 
> getService/ungetService of the service factory registered by the 
> SingleComponentManager. (I didn't check the other factories)
> We have a concurrent get/ungetService for the same service. While the unget 
> service uses a lock around decrementing the counter, incrementing the counter 
> and other actions in getService are not using the lock. There is a partial 
> lock there. 
> But this can lead to the problem that while the preconditions for getService 
> are still fine, ungetService cleans up which then makes getService to return 
> null.
> We have a huge app where we can reproduce the problem, I'll try to trim this 
> down to a simple test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (FELIX-5028) ServiceFactory for components might return null

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14746245#comment-14746245
 ] 

Carsten Ziegeler edited comment on FELIX-5028 at 9/15/15 9:32 PM:
--

I don't think this is needed, because this extra check assumes that the 
framework is wrong
We could change m_useCount.decrementAndGet() == 0 to 
m_useCount.decrementAndGet() <= 0 as in this processing of ungetService the 
count is reset to zero.
A simple check of m_useCount.get() > 0 && m_useCount.decrementAndGet() == 0 
would catch the situation where the framework calls ungetService more often, 
but it doesn't reset the counter to 0, so e.g. if it's -1 , the next call to 
getService gets it to 0 - which would be wrong
Forgot to mention that the previous code did check the count and then 
decremented it outside of the state lock, so while the count would have been 
higher than zero, it might have got to zero by the time decrement is called, 
getting it to -1


was (Author: cziegeler):
I don't think this is needed, because this extra check assumes that the 
framework is wrong
We could change m_useCount.decrementAndGet() == 0 to 
m_useCount.decrementAndGet() <= 0 as in this processing of ungetService the 
count is reset to zero.
A simple check of m_useCount.get() > 0 && m_useCount.decrementAndGet() == 0 
would catch the situation where the framework calls ungetService more often, 
but it doesn't reset the counter to 0, so e.g. if it's -1 , the next call to 
getService gets it to 0 - which would be wrong
Forgot to mention that the previous code did check the count and then 
decremented it outside of the release lock, so while the count would have been 
higher than zero, it might have got to zero by the time decrement is called, 
getting it to -1

> ServiceFactory for components might return null
> ---
>
> Key: FELIX-5028
> URL: https://issues.apache.org/jira/browse/FELIX-5028
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.0.2
>
>
> There seems to be an uneven handling of locking/status information in 
> getService/ungetService of the service factory registered by the 
> SingleComponentManager. (I didn't check the other factories)
> We have a concurrent get/ungetService for the same service. While the unget 
> service uses a lock around decrementing the counter, incrementing the counter 
> and other actions in getService are not using the lock. There is a partial 
> lock there. 
> But this can lead to the problem that while the preconditions for getService 
> are still fine, ungetService cleans up which then makes getService to return 
> null.
> We have a huge app where we can reproduce the problem, I'll try to trim this 
> down to a simple test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (FELIX-5028) ServiceFactory for components might return null

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14746245#comment-14746245
 ] 

Carsten Ziegeler edited comment on FELIX-5028 at 9/15/15 9:32 PM:
--

I don't think this is needed, because this extra check assumes that the 
framework is wrong
We could change m_useCount.decrementAndGet() == 0 to 
m_useCount.decrementAndGet() <= 0 as in this processing of ungetService the 
count is reset to zero.
A simple check of m_useCount.get() > 0 && m_useCount.decrementAndGet() == 0 
would catch the situation where the framework calls ungetService more often, 
but it doesn't reset the counter to 0, so e.g. if it's -1 , the next call to 
getService gets it to 0 - which would be wrong
Forgot to mention that the previous code did check the count and then 
decremented it outside of the release lock, so while the count would have been 
higher than zero, it might have got to zero by the time decrement is called, 
getting it to -1


was (Author: cziegeler):
I don't think this is needed, because this extra check assumes that the 
framework is wrong
We could change m_useCount.decrementAndGet() == 0 to 
m_useCount.decrementAndGet() <= 0 as in this processing of ungetService the 
count is reset to zero.
A simple check of m_useCount.get() > 0 && m_useCount.decrementAndGet() == 0 
would catch the situation where the framework calls ungetService more often, 
but it doesn't reset the counter to 0, so e.g. if it's -1 , the next call to 
getService gets it to 0 - which would be wrong


> ServiceFactory for components might return null
> ---
>
> Key: FELIX-5028
> URL: https://issues.apache.org/jira/browse/FELIX-5028
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.0.2
>
>
> There seems to be an uneven handling of locking/status information in 
> getService/ungetService of the service factory registered by the 
> SingleComponentManager. (I didn't check the other factories)
> We have a concurrent get/ungetService for the same service. While the unget 
> service uses a lock around decrementing the counter, incrementing the counter 
> and other actions in getService are not using the lock. There is a partial 
> lock there. 
> But this can lead to the problem that while the preconditions for getService 
> are still fine, ungetService cleans up which then makes getService to return 
> null.
> We have a huge app where we can reproduce the problem, I'll try to trim this 
> down to a simple test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5028) ServiceFactory for components might return null

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14746245#comment-14746245
 ] 

Carsten Ziegeler commented on FELIX-5028:
-

I don't think this is needed, because this extra check assumes that the 
framework is wrong
We could change m_useCount.decrementAndGet() == 0 to 
m_useCount.decrementAndGet() <= 0 as in this processing of ungetService the 
count is reset to zero.
A simple check of m_useCount.get() > 0 && m_useCount.decrementAndGet() == 0 
would catch the situation where the framework calls ungetService more often, 
but it doesn't reset the counter to 0, so e.g. if it's -1 , the next call to 
getService gets it to 0 - which would be wrong


> ServiceFactory for components might return null
> ---
>
> Key: FELIX-5028
> URL: https://issues.apache.org/jira/browse/FELIX-5028
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.0.2
>
>
> There seems to be an uneven handling of locking/status information in 
> getService/ungetService of the service factory registered by the 
> SingleComponentManager. (I didn't check the other factories)
> We have a concurrent get/ungetService for the same service. While the unget 
> service uses a lock around decrementing the counter, incrementing the counter 
> and other actions in getService are not using the lock. There is a partial 
> lock there. 
> But this can lead to the problem that while the preconditions for getService 
> are still fine, ungetService cleans up which then makes getService to return 
> null.
> We have a huge app where we can reproduce the problem, I'll try to trim this 
> down to a simple test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: SCR 2.0.2 release?

[Pierre De Rop]

Hello Carsten,

Please take a look at FELIX-5028 before releasing, I just added a small
comment.

thank you;
/Pierre

On Tue, Sep 15, 2015 at 11:10 PM, Carsten Ziegeler 
wrote:

> Am 15.09.15 um 19:09 schrieb David Jencks:
> > Well, I think there’s still the issue Peter seems to have reproduced on
> the bnd list.  I didn’t have enough time to look at it last weekend and
> won’t next weekend.  I _think_ the solution is going to be to use the
> abstract tracker framework to write a configuration tracker.
> >
> > I opened https://issues.apache.org/jira/browse/FELIX-5036 <
> https://issues.apache.org/jira/browse/FELIX-5036> to help make this more
> visible.  I would rather this got fixed in the next release but if no one
> has time to look right now we could have a 2.0.4 soon if you are impatient
> for another rebase :-)
>
> I would love to have a release in the next two weeks, so I think I'll go
> for a 2.0.2 with what we have.
>
> >
> > I still have some more work I’d like to do on circular references, but
> since these should be avoided anyway I wouldn’t hold up the release for it.
>
> Ok, should we marked FELIX-4984 then for the release after 2.0.2 ?
>
> >
> > Are you OK with my formatting changes to SCRInfo?
>
> Yes, I'm ok with it - as you say it has all the relevant info and that's
> the important bit
>
> >
> > I haven’t been able to figure out how to get help to appear for the scr
> gogo command.  I think that the only way to get it to work properly is to
> put the actual gogo command into a separate bundle that requires the gogo
> package and of course sdrInfo.  I think we should do this….
> >
>
> Yepp, sounds logical to me, we can easily cut a 2.1.0 of the scr bundle
> with all these changes soon.
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Commented] (FELIX-5028) ServiceFactory for components might return null

[Pierre De Rop (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14746219#comment-14746219
 ] 

Pierre De Rop commented on FELIX-5028:
--

Carsten,

I looked at the last commit from rv 1703178 and now it seems that the 
ungetService() is not checking anymore bad cases where the framework calls 
ungetService() more than it calls getServices(). So, don't you think that the 
following patch would be better:

{code}
public void ungetService( Bundle bundle, ServiceRegistration 
serviceRegistration, S o )
{
obtainStateLock( );
try
{
// unget the service instance if no bundle is using it
// any longer unless delayed component instances have to
// be kept (FELIX-3039).
// We also check if the useCount does not go below zero (when 
ungetService is
// called more times than getService is called).
if (  m_useCount.get() > 0 && m_useCount.decrementAndGet() == 0 && 
!isImmediate() && !keepInstances() )
{
ungetService( );
}
}
finally
{
releaseStateLock(  );
}
}
{code}

> ServiceFactory for components might return null
> ---
>
> Key: FELIX-5028
> URL: https://issues.apache.org/jira/browse/FELIX-5028
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.0.2
>
>
> There seems to be an uneven handling of locking/status information in 
> getService/ungetService of the service factory registered by the 
> SingleComponentManager. (I didn't check the other factories)
> We have a concurrent get/ungetService for the same service. While the unget 
> service uses a lock around decrementing the counter, incrementing the counter 
> and other actions in getService are not using the lock. There is a partial 
> lock there. 
> But this can lead to the problem that while the preconditions for getService 
> are still fine, ungetService cleans up which then makes getService to return 
> null.
> We have a huge app where we can reproduce the problem, I'll try to trim this 
> down to a simple test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: SCR 2.0.2 release?

[Carsten Ziegeler]

Am 15.09.15 um 19:09 schrieb David Jencks:
> Well, I think there’s still the issue Peter seems to have reproduced on the 
> bnd list.  I didn’t have enough time to look at it last weekend and won’t 
> next weekend.  I _think_ the solution is going to be to use the abstract 
> tracker framework to write a configuration tracker.
> 
> I opened https://issues.apache.org/jira/browse/FELIX-5036 
>  to help make this more 
> visible.  I would rather this got fixed in the next release but if no one has 
> time to look right now we could have a 2.0.4 soon if you are impatient for 
> another rebase :-)

I would love to have a release in the next two weeks, so I think I'll go
for a 2.0.2 with what we have.

> 
> I still have some more work I’d like to do on circular references, but since 
> these should be avoided anyway I wouldn’t hold up the release for it.

Ok, should we marked FELIX-4984 then for the release after 2.0.2 ?

> 
> Are you OK with my formatting changes to SCRInfo?

Yes, I'm ok with it - as you say it has all the relevant info and that's
the important bit

> 
> I haven’t been able to figure out how to get help to appear for the scr gogo 
> command.  I think that the only way to get it to work properly is to put the 
> actual gogo command into a separate bundle that requires the gogo package and 
> of course sdrInfo.  I think we should do this….
> 

Yepp, sounds logical to me, we can easily cut a 2.1.0 of the scr bundle
with all these changes soon.

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: SCR 2.0.2 release?

[David Jencks]

Well, I think there’s still the issue Peter seems to have reproduced on the bnd 
list.  I didn’t have enough time to look at it last weekend and won’t next 
weekend.  I _think_ the solution is going to be to use the abstract tracker 
framework to write a configuration tracker.

I opened https://issues.apache.org/jira/browse/FELIX-5036 
 to help make this more 
visible.  I would rather this got fixed in the next release but if no one has 
time to look right now we could have a 2.0.4 soon if you are impatient for 
another rebase :-)

I still have some more work I’d like to do on circular references, but since 
these should be avoided anyway I wouldn’t hold up the release for it.

Are you OK with my formatting changes to SCRInfo?

I haven’t been able to figure out how to get help to appear for the scr gogo 
command.  I think that the only way to get it to work properly is to put the 
actual gogo command into a separate bundle that requires the gogo package and 
of course sdrInfo.  I think we should do this….


thanks
david jencks

 
> On Sep 15, 2015, at 9:56 AM, Carsten Ziegeler  wrote:
> 
> It seems we have now fixed the most serious issues which we should get
> out asap.
> 
> Is anything really preventing us from a release? (I think we can do all
> kinds of improvements in another release)
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Created] (FELIX-5036) [DS] bundle start order problem with config admin

[David Jencks (JIRA)]

David Jencks created FELIX-5036:
---

 Summary: [DS] bundle start order problem with config admin
 Key: FELIX-5036
 URL: https://issues.apache.org/jira/browse/FELIX-5036
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-2.0.0
Reporter: David Jencks


There was a discussion on the bndtools list about a problem with start order of 
DS and config admin.  I'm pasting Peter's email where he describes how to 
reproduce the problem.

 think I nailed down the issue, my guess it is in Felix SCR and suggest you 
file an issue.

The ordering problem is caused by:

1: a component C with configuration policy require (no dependency on 
config admin)
2: a component Z that sets an instance for bundle 1’s component 
(dependency on config admin)
3: config admin
4: scr

Any other ordering works :-)

About the code you submitted, some tips. Next time please try to bring it down 
to a smaller sample. If you have such a problem you invariably find the problem 
by removing code in chunks until you see a change in behavior. The nice thing 
is then that at the end it is obvious what is going on. It also helps in this 
phase to aggressively refactor the code so you use 1 character names that are 
easier to separate then very similar (or in your case identical messages/names).

Included are the bundles that fail, you might want to add them to the Felix SCR 
issue. They include their source code.

Kind regards,

Peter Kriens


c bundle:
=
package csample;

package csample;

import java.io.IOException;
import java.util.Map;

import org.osgi.framework.InvalidSyntaxException;

import aQute.bnd.annotation.component.Activate;
import aQute.bnd.annotation.component.Component;
import aQute.bnd.annotation.component.ConfigurationPolicy;

@Component(
name = "sample.cm.require",
configurationPolicy = ConfigurationPolicy.require,
immediate = true)
public class C {

@Activate
public void startup(Map props) throws 
InvalidSyntaxException, IOException {
String name = (String) props.get("sample.cm.require.name");
System.out.println("C : startup -> " + name);
}
}

z bundle:
=
package zsample;

import java.io.IOException;
import java.util.Dictionary;
import java.util.Hashtable;

import org.osgi.framework.InvalidSyntaxException;
import org.osgi.service.cm.Configuration;
import org.osgi.service.cm.ConfigurationAdmin;
import org.osgi.service.component.ComponentContext;

import aQute.bnd.annotation.component.Activate;
import aQute.bnd.annotation.component.Component;
import aQute.bnd.annotation.component.Deactivate;
import aQute.bnd.annotation.component.Reference;

@Component(immediate = true)
public class Z {

private ConfigurationAdmin configAdmin;

@Activate
public void startup(ComponentContext ctx) throws 
InvalidSyntaxException, IOException {
System.out.println("Z Startup");
Dictionary props = new Hashtable<>();

String pid = "sample.cm.require";
Configuration config = 
configAdmin.createFactoryConfiguration(pid, null);

props.put("sample.cm.require.name", "from Z");

config.update(props);
}

@Deactivate
public void shutdown(ComponentContext ctx) {
System.out.println("Z Shutdown");
}

@Reference
public void setConfigAdmin(ConfigurationAdmin configAdmin) {
this.configAdmin = configAdmin;
System.out.println("Z setConfigAdmin");
}
}


bndrun file:

-runbundles: \
c;version=latest,\
z;version=latest,\
org.apache.felix.configadmin,\
org.apache.felix.scr

-runfw: org.apache.felix.framework;version='[4.4.1,4.4.1]'
-runee: JavaSE-1.8



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5007) Manipulator error : "Prohibited package name: java.io" when a maven dependency defines java.io.IOException

[Pierre Bourret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Bourret updated FELIX-5007:
--
Attachment: Fix_FELIX-5007_(proposal).patch

Here is a patch proposal.
It overrides the {{IsolatedClassLoader.findClass()}} method. If {{name}} starts 
with {{"java."}} it preventively throws a {{ClassNotFoundException}}.
The calling {{loadClass()}} method then delegates to its parent (if any).

> Manipulator error : "Prohibited package name: java.io" when a maven 
> dependency defines java.io.IOException
> --
>
> Key: FELIX-5007
> URL: https://issues.apache.org/jira/browse/FELIX-5007
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Affects Versions: ipojo-manipulator-1.12.1
> Environment: OS name: "linux", version: "3.13.0-62-generic", arch: 
> "amd64", family: "unix"
> Java version: 1.8.0_60, vendor: Oracle Corporation
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
> 2015-04-22T13:57:37+02:00)
>Reporter: Pierre Bourret
>Priority: Minor
> Attachments: Fix_FELIX-5007_(proposal).patch
>
>
> While building a project with many sub-modules, the maven-ipojo-plugin fails 
> and gives me this error:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle (default) on project 
> roboconf-dm-rest-services: Execution default of goal 
> org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle failed: 
> java.lang.SecurityException: Prohibited package name: java.io -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle (default) on 
> project roboconf-dm-rest-services: Execution default of goal 
> org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle failed: 
> java.lang.SecurityException: Prohibited package name: java.io
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
>   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:497)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default of goal org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle 
> failed: java.lang.SecurityException: Prohibited package name: java.io
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>   ... 20 more
> Caused by: java.lang.RuntimeException: java.lang.SecurityException: 
> Prohibited package name: java.io
>   at 
> org.apache.felix.ipojo.manipulation.ClassLoaderAwareClassWriter.getCommonSuperClass(ClassLoaderAwareClassWriter.java:74)
>   at org.objectweb.asm.ClassWriter.a(Unknown Source)
>   at org.objectweb.asm.Frame.a(Unknown Source)
>   at org.objectweb.asm.Frame.a(Unknown Source)
>   at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source)
>   at org.objectweb.asm.MethodVisitor.visitMaxs(Unknown Source)
>   at org.ob

[jira] [Resolved] (FELIX-5001) scr:list Gogo command should display component descriptions and configurations

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved FELIX-5001.
-
Resolution: Fixed

I think we can resolve this for now - if there is anything to improve on the 
output, we can open a new issue

> scr:list Gogo command should display component descriptions and configurations
> --
>
> Key: FELIX-5001
> URL: https://issues.apache.org/jira/browse/FELIX-5001
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Neil Bartlett
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: scr-2.0.2
>
>
> The gogo command scr:list has changed drastically since version 1.8.2 and is 
> now unusable. The component IDs are not displayed and so there is no way for 
> the user to pass this ID to the scr:info command.
> Here is the current output:
> {noformat}
> g! scr:list
>  Name  BundleId DefaultEnabled
> [org.example.exchange.orderentry.OrderEntry] [  11] [true]
> [org.example.exchange.prices.feed] [   2] [true]
> [org.example.osgi.exchange.impl.ExchangeImpl] [   2] [true]
> {noformat}
> For reference, here was the much more useful output from 1.8.2:
> {noformat}
> g! scr:list
>  Id   State BundleId Name
> [   0] [active  ] [   2] org.example.osgi.exchange.impl.ExchangeImpl
> [   1] [active  ] [   2] org.example.exchange.prices.feed
> [   2] [active  ] [  11] org.example.exchange.orderentry.OrderEntry
> [   3] [active  ] [   2] org.example.exchange.prices.feed
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4714) Felix should sort bundles by alphabetical name from "deploy" directory

[metatech (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745526#comment-14745526
 ] 

metatech commented on FELIX-4714:
-

This patch only works when "felix.fileinstall.disableNio2=true".  The same 
change is needed in the "WatcherScanner".


> Felix should sort bundles by alphabetical name from "deploy" directory
> --
>
> Key: FELIX-4714
> URL: https://issues.apache.org/jira/browse/FELIX-4714
> Project: Felix
>  Issue Type: Improvement
>  Components: File Install
> Environment: ServiceMix 4.5.3
>Reporter: metatech
>Priority: Minor
> Attachments: felix_sort_bundles_in_deploy_dir_v3.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Felix File Install should sort alphabetically the bundles names which are 
> detected in the "deploy" directory.
> This helps preserving sanity when searching through a list of 50 bundles.
> Here is a patch which implements it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: SCR 2.0.2 release?

[Carsten Ziegeler]

It seems we have now fixed the most serious issues which we should get
out asap.

Is anything really preventing us from a release? (I think we can do all
kinds of improvements in another release)

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (FELIX-4266) findbugs reported errors related to arrays being stored/returned directly

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745477#comment-14745477
 ] 

Carsten Ziegeler commented on FELIX-4266:
-

The class is not part of the code base anymore

> findbugs reported errors related to arrays being stored/returned directly 
> --
>
> Key: FELIX-4266
> URL: https://issues.apache.org/jira/browse/FELIX-4266
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.2.1
>Reporter: Sahoo
>Assignee: Sahoo
>Priority: Minor
>
> FindBugs on Felix reported following two issues:
> - Should change code to make a clone of the return value and return the copy, 
> not the internal representation.
> - Should change code to store a clone of the external mutable object.
> Below are the fixes to these two issues:  
> framework/src/main/java/org/apache/felix/framework/util/manifestparser/R4Library.java
>   (revision 1528211)
> +++ 
> framework/src/main/java/org/apache/felix/framework/util/manifestparser/R4Library.java
>   (working copy)
> @@ -18,10 +18,11 @@
>   */
>  package org.apache.felix.framework.util.manifestparser;
> +import org.osgi.framework.Constants;
> +
>  import java.util.ArrayList;
>  import java.util.List;
>  import java.util.Map;
> -import org.osgi.framework.Constants;
>  public class R4Library
>  {
> @@ -37,10 +38,10 @@
>  String[] languages, String selectionFilter) throws Exception
>  {
>  m_libraryFile = libraryFile;
> -m_osnames = osnames;
> -m_processors = processors;
> -m_osversions = osversions;
> -m_languages = languages;
> +m_osnames = osnames == null ? osnames : osnames.clone();
> +m_processors = processors == null ? processors : processors.clone();
> +m_osversions = osversions == null ? osversions : osversions.clone();
> +m_languages = languages == null ? languages : languages.clone();
>  m_selectionFilter = selectionFilter;
>  }
> @@ -51,22 +52,22 @@
>  public String[] getOSNames()
>  {
> -return m_osnames;
> +return m_osnames == null ? m_osnames : m_osnames.clone();
>  }
>  public String[] getProcessors()
>  {
> -return m_processors;
> +return m_processors == null ? m_processors : m_processors.clone();
>  }
>  public String[] getOSVersions()
>  {
> -return m_osversions;
> +return m_osversions == null ? m_osversions : m_osversions.clone();
>  }
>  public String[] getLanguages()
>  {
> -return m_languages;
> +return m_languages == null ? m_languages : m_languages.clone();
>  }
>  public String getSelectionFilter()
> @@ -184,4 +185,4 @@
>  }
>  return "*";
>  }
> -}
> \ No newline at end of file
> +} 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4266) findbugs reported errors related to arrays being stored/returned directly

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated FELIX-4266:

Fix Version/s: (was: framework-5.4.0)

> findbugs reported errors related to arrays being stored/returned directly 
> --
>
> Key: FELIX-4266
> URL: https://issues.apache.org/jira/browse/FELIX-4266
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.2.1
>Reporter: Sahoo
>Assignee: Sahoo
>Priority: Minor
>
> FindBugs on Felix reported following two issues:
> - Should change code to make a clone of the return value and return the copy, 
> not the internal representation.
> - Should change code to store a clone of the external mutable object.
> Below are the fixes to these two issues:  
> framework/src/main/java/org/apache/felix/framework/util/manifestparser/R4Library.java
>   (revision 1528211)
> +++ 
> framework/src/main/java/org/apache/felix/framework/util/manifestparser/R4Library.java
>   (working copy)
> @@ -18,10 +18,11 @@
>   */
>  package org.apache.felix.framework.util.manifestparser;
> +import org.osgi.framework.Constants;
> +
>  import java.util.ArrayList;
>  import java.util.List;
>  import java.util.Map;
> -import org.osgi.framework.Constants;
>  public class R4Library
>  {
> @@ -37,10 +38,10 @@
>  String[] languages, String selectionFilter) throws Exception
>  {
>  m_libraryFile = libraryFile;
> -m_osnames = osnames;
> -m_processors = processors;
> -m_osversions = osversions;
> -m_languages = languages;
> +m_osnames = osnames == null ? osnames : osnames.clone();
> +m_processors = processors == null ? processors : processors.clone();
> +m_osversions = osversions == null ? osversions : osversions.clone();
> +m_languages = languages == null ? languages : languages.clone();
>  m_selectionFilter = selectionFilter;
>  }
> @@ -51,22 +52,22 @@
>  public String[] getOSNames()
>  {
> -return m_osnames;
> +return m_osnames == null ? m_osnames : m_osnames.clone();
>  }
>  public String[] getProcessors()
>  {
> -return m_processors;
> +return m_processors == null ? m_processors : m_processors.clone();
>  }
>  public String[] getOSVersions()
>  {
> -return m_osversions;
> +return m_osversions == null ? m_osversions : m_osversions.clone();
>  }
>  public String[] getLanguages()
>  {
> -return m_languages;
> +return m_languages == null ? m_languages : m_languages.clone();
>  }
>  public String getSelectionFilter()
> @@ -184,4 +185,4 @@
>  }
>  return "*";
>  }
> -}
> \ No newline at end of file
> +} 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5028) ServiceFactory for components might return null

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved FELIX-5028.
-
Resolution: Fixed

I've hopefully fixe this in rev 1703178 by increasing the use count on 
getService and protecting it through the lock. At least manual tests proof that 
with this in place, the problem is not occuring anymore

> ServiceFactory for components might return null
> ---
>
> Key: FELIX-5028
> URL: https://issues.apache.org/jira/browse/FELIX-5028
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.0.2
>
>
> There seems to be an uneven handling of locking/status information in 
> getService/ungetService of the service factory registered by the 
> SingleComponentManager. (I didn't check the other factories)
> We have a concurrent get/ungetService for the same service. While the unget 
> service uses a lock around decrementing the counter, incrementing the counter 
> and other actions in getService are not using the lock. There is a partial 
> lock there. 
> But this can lead to the problem that while the preconditions for getService 
> are still fine, ungetService cleans up which then makes getService to return 
> null.
> We have a huge app where we can reproduce the problem, I'll try to trim this 
> down to a simple test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (FELIX-5028) ServiceFactory for components might return null

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned FELIX-5028:
---

Assignee: Carsten Ziegeler

> ServiceFactory for components might return null
> ---
>
> Key: FELIX-5028
> URL: https://issues.apache.org/jira/browse/FELIX-5028
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.0.2
>
>
> There seems to be an uneven handling of locking/status information in 
> getService/ungetService of the service factory registered by the 
> SingleComponentManager. (I didn't check the other factories)
> We have a concurrent get/ungetService for the same service. While the unget 
> service uses a lock around decrementing the counter, incrementing the counter 
> and other actions in getService are not using the lock. There is a partial 
> lock there. 
> But this can lead to the problem that while the preconditions for getService 
> are still fine, ungetService cleans up which then makes getService to return 
> null.
> We have a huge app where we can reproduce the problem, I'll try to trim this 
> down to a simple test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5028) ServiceFactory for components might return null

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated FELIX-5028:

Attachment: (was: simple_fix.patch)

> ServiceFactory for components might return null
> ---
>
> Key: FELIX-5028
> URL: https://issues.apache.org/jira/browse/FELIX-5028
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: Carsten Ziegeler
> Fix For: scr-2.0.2
>
>
> There seems to be an uneven handling of locking/status information in 
> getService/ungetService of the service factory registered by the 
> SingleComponentManager. (I didn't check the other factories)
> We have a concurrent get/ungetService for the same service. While the unget 
> service uses a lock around decrementing the counter, incrementing the counter 
> and other actions in getService are not using the lock. There is a partial 
> lock there. 
> But this can lead to the problem that while the preconditions for getService 
> are still fine, ungetService cleans up which then makes getService to return 
> null.
> We have a huge app where we can reproduce the problem, I'll try to trim this 
> down to a simple test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5012) Start/stop bundles in parallel for better performance

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745370#comment-14745370
 ] 

Carsten Ziegeler commented on FELIX-5012:
-

This is at least slightly related to FELIX-3034

> Start/stop bundles in parallel for better performance
> -
>
> Key: FELIX-5012
> URL: https://issues.apache.org/jira/browse/FELIX-5012
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.0.1
> Environment: Multicore
>Reporter: Joel Richard
>  Labels: performance, shutdown, startup
>
> Since most computers have multicore processors by now, it would make sense to 
> start/stop all bundles with the same start level in parallel. This has the 
> potential to greatly decrease the startup/shutdown time and would be a good 
> investment into the future since it's likely that the number of cores will 
> increase further.
> In our environment, 69% of all bundles have the default start level of 20. 
> The next 19% of the bundles share 4 different start levels.
> Before this change is implemented, it has to be checked if it is compatible 
> with the OSGi specification.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5034) Reduce and correct locking related to the hook registry

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved FELIX-5034.
-
Resolution: Fixed

I've corrected the syncing and removed it completely for the more common read 
case. I've also removed some proxy methods from the Felix class and simply give 
access to the HookRegistry.

> Reduce and correct locking related to the hook registry
> ---
>
> Key: FELIX-5034
> URL: https://issues.apache.org/jira/browse/FELIX-5034
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.2.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: framework-5.4.0
>
>
> Right now the HookRegistry is using heavy locking, even on reading. Even 
> worse when the set of hooks is read, it creates a copy of the collection. 
> Other things like the blacklist are not synchronized at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] felix pull request: FELIX-5018: Create factory configuration link

[zsigmond-czine-everit]

Github user zsigmond-czine-everit closed the pull request at:

https://github.com/apache/felix/pull/35


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (FELIX-5019) [webconsole] "referer" parameter for configuration open/create link

[Zsigmond Czine (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745042#comment-14745042
 ] 

Zsigmond Czine commented on FELIX-5019:
---

The code merged and solved conflicts in https://github.com/apache/felix/pull/36 
pull request.

> [webconsole] "referer" parameter for configuration open/create link
> ---
>
> Key: FELIX-5019
> URL: https://issues.apache.org/jira/browse/FELIX-5019
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.2.10
>Reporter: Balazs Zsoldos
>
> It is possible to open/create configuration by linking the configuration 
> screen with the following format:
> {code}
> /system/console/configMgr/configurationPid
> {code}
> I propose a new parameter that can tell where to redirect after the 
> configuration dialog is closed. E.g.:
> {code}
> /system/console/configMgr/configurationPid?referer=/system/console/componentView
> {code}
> If you like this proposal, pull request comes within 1-2 days.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5018) [webconsole] "create factory configuration" link for config screen

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745024#comment-14745024
 ] 

ASF GitHub Bot commented on FELIX-5018:
---

Github user zsigmond-czine-everit closed the pull request at:

https://github.com/apache/felix/pull/35


> [webconsole] "create factory configuration" link for config screen
> --
>
> Key: FELIX-5018
> URL: https://issues.apache.org/jira/browse/FELIX-5018
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.2.10
>Reporter: Balazs Zsoldos
>Assignee: Valentin Valchev
> Fix For: webconsole-4.2.12
>
>
> At the moment, it is possible to create a link to the configuration screen 
> that:
>  * opens an existing configuration
>  * creates a non-factory configuration if it does not exist yet
> It would be nice to be able to create a link that can be used to create 
> configuration for factories.
> At the moment can look like this:
> {code}
> /system/console/configMgr/myPid
> {code}
> We propose the _factoryCreate_ parameter. When it is true, a new 
> configuration will be created for that factory. The link could be used like 
> this:
> {code}
> /system/console/configMgr/myPid?factoryCreate=true
> {code}
> If you agree, the pull request will come within 1-2 days.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Deleted] (FELIX-5035) Reduce and correct locking related to the hook registry

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler deleted FELIX-5035:



> Reduce and correct locking related to the hook registry
> ---
>
> Key: FELIX-5035
> URL: https://issues.apache.org/jira/browse/FELIX-5035
> Project: Felix
>  Issue Type: Improvement
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>
> Right now the HookRegistry is using heavy locking, even on reading. Even 
> worse when the set of hooks is read, it creates a copy of the collection. 
> Other things like the blacklist are not synchronized at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5035) Reduce and correct locking related to the hook registry

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created FELIX-5035:
---

 Summary: Reduce and correct locking related to the hook registry
 Key: FELIX-5035
 URL: https://issues.apache.org/jira/browse/FELIX-5035
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-5.2.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: framework-5.4.0


Right now the HookRegistry is using heavy locking, even on reading. Even worse 
when the set of hooks is read, it creates a copy of the collection. Other 
things like the blacklist are not synchronized at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5034) Reduce and correct locking related to the hook registry

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created FELIX-5034:
---

 Summary: Reduce and correct locking related to the hook registry
 Key: FELIX-5034
 URL: https://issues.apache.org/jira/browse/FELIX-5034
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-5.2.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: framework-5.4.0


Right now the HookRegistry is using heavy locking, even on reading. Even worse 
when the set of hooks is read, it creates a copy of the collection. Other 
things like the blacklist are not synchronized at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5033) Can not export package which defined in fragment bundle

[Huang.yun (JIRA)]

Huang.yun created FELIX-5033:


 Summary: Can not export package which defined in fragment bundle
 Key: FELIX-5033
 URL: https://issues.apache.org/jira/browse/FELIX-5033
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-5.2.0
 Environment: win10,jdk8,idea-14,x64
Reporter: Huang.yun


Host bundle:

=
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: javax.persistence.extra
Bundle-SymbolicName: javax.persistence.extra
Bundle-Version: 2.1.0
Bundle-Vendor: Huangyun
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Bundle-ClassPath: .,
 lib/javax.persistence_2.1.0.jar
Export-Package: javax.persistence,
 javax.persistence.criteria,
 javax.persistence.extra,
 javax.persistence.metamodel,
 javax.persistence.spi
Service-Component: OSGi-INF/*.xml


fragment bundle:

===
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Hibernate
Bundle-SymbolicName: javax.persistence.extra.hibernate
Bundle-Version: 5.0.0
Fragment-Host: javax.persistence.extra;bundle-version="2.1.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Bundle-ClassPath: .,
 lib/hibernate-core-5.0.0.Final.jar,
 lib/hibernate-entitymanager-5.0.0.Final.jar,
 lib/antlr-2.7.7.jar,
 lib/dom4j-1.6.1.jar,
 lib/geronimo-jta_1.1_spec-1.1.1.jar,
 lib/hibernate-commons-annotations-5.0.0.Final.jar,
 lib/jandex-1.2.2.Final.jar,
 lib/javassist-3.18.1-GA.jar,
 lib/jboss-logging-3.3.0.Final.jar
Export-Package: javassist.util.proxy,
 javax.persistence.extra.hibernate.impl,
 org.hibernate.proxy
Import-Package: org.osgi.service.component;version="1.2.2"


it run ok in equinox-SDK-Mars, and run failure in felix-framework-5.2.0.
the error text is org.hibernate.proxy.HibernateProxy not find




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)