[jira] [Closed] (FELIX-4987) Dynamic package resolution with unresolvable or fragment package exports can lead to invalid wirings
[ https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson closed FELIX-4987. Thanks. I merged the latest felix into my twatson/newResolver branch. I'm still doing some work to figure out the best settings to use for the executor for the framework's use of the resolver. You have any idea what the felix framework is going to do here? Dynamic package resolution with unresolvable or fragment package exports can lead to invalid wirings Key: FELIX-4987 URL: https://issues.apache.org/jira/browse/FELIX-4987 Project: Felix Issue Type: Bug Components: Resolver Environment: All Reporter: Thomas Watson Assignee: Guillaume Nodet Fix For: resolver-1.6.0 With the latest code in trunk calling org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Resource, Requirement, ListCapability) with a ListCapability containing a Capability from a fragment will lead to an invalid Wire. This looks similar to FELIX-4897 and appears to be a regression. There are two types of failures. 1) Where the fragment has a valid host to resolve against. In this case I would expect the Wire.getProvider() to be the host revision for the fragment, but the current code returns the fragment revision 2) Where the fragment has no valid host available. In this case I would expect no Wire to be returned in the result from the ResolverImpl.resolve call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4987) Dynamic package resolution with unresolvable or fragment package exports can lead to invalid wirings
[
https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706960#comment-14706960
]
Guillaume Nodet commented on FELIX-4987:
Currently, it lets the ResolverImpl handle threading with the default
parameters, i.e. no Executor and a parallelisation equals to the number of
cores.
The drawback is that it creates threads for each resolution.
I suppose the best settings would be to give the ResolverImpl an Executor
created with
{{Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())}}
with a lifecycle controlled by the framework.
Dynamic package resolution with unresolvable or fragment package exports can
lead to invalid wirings
Key: FELIX-4987
URL: https://issues.apache.org/jira/browse/FELIX-4987
Project: Felix
Issue Type: Bug
Components: Resolver
Environment: All
Reporter: Thomas Watson
Assignee: Guillaume Nodet
Fix For: resolver-1.6.0
With the latest code in trunk calling
org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Resource,
Requirement, ListCapability) with a ListCapability containing a
Capability from a fragment will lead to an invalid Wire.
This looks similar to FELIX-4897 and appears to be a regression.
There are two types of failures.
1) Where the fragment has a valid host to resolve against. In this case I
would expect the Wire.getProvider() to be the host revision for the fragment,
but the current code returns the fragment revision
2) Where the fragment has no valid host available. In this case I would
expect no Wire to be returned in the result from the ResolverImpl.resolve
call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4987) Dynamic package resolution with unresolvable or fragment package exports can lead to invalid wirings
[
https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14707184#comment-14707184
]
Thomas Watson commented on FELIX-4987:
--
I'm going to try something like the following so that the pool of threads
quickly can go to zero threads when idle which is shortly after startup.
new ThreadPoolExecutor(
// Always want to go to zero threads when idle
0,
// use the number of processors - 1 because we use the current thread
when rejected
Math.max(Runtime.getRuntime().availableProcessors() - 1, 1),
// idle timeout; make it short to get rid of threads quickly after
resolve
5,
// unit for timeout
TimeUnit.SECONDS,
// use sync queue to force thread creation
new SynchronousQueueRunnable(),
// try to name the threads with useful name
new ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
return new Thread(r, Resolver thread - +
adaptor.toString()); //$NON-NLS-1$
}
},
// use a rejection policy that simply runs the task in the current
thread once the max threads is reached
new RejectedExecutionHandler() {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor
exe) {
r.run();
}
});
I register a different instance of the resolver as a service, for that I will
likely use the default behavior which will create/shutdown the internal
executor. If that proves to be an issue then I may register it using a
PrototypeSeviceFactory such that the executor is created/shutdown when the new
service object is created/destroyed.
Dynamic package resolution with unresolvable or fragment package exports can
lead to invalid wirings
Key: FELIX-4987
URL: https://issues.apache.org/jira/browse/FELIX-4987
Project: Felix
Issue Type: Bug
Components: Resolver
Environment: All
Reporter: Thomas Watson
Assignee: Guillaume Nodet
Fix For: resolver-1.6.0
With the latest code in trunk calling
org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Resource,
Requirement, ListCapability) with a ListCapability containing a
Capability from a fragment will lead to an invalid Wire.
This looks similar to FELIX-4897 and appears to be a regression.
There are two types of failures.
1) Where the fragment has a valid host to resolve against. In this case I
would expect the Wire.getProvider() to be the host revision for the fragment,
but the current code returns the fragment revision
2) Where the fragment has no valid host available. In this case I would
expect no Wire to be returned in the result from the ResolverImpl.resolve
call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5007) Manipulator error : Prohibited package name: java.io when a maven dependency defines java.io.IOException
Pierre Bourret created FELIX-5007:
-
Summary: 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
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.objectweb.asm.util.CheckMethodAdapter.visitMaxs(Unknown Source)
at org.objectweb.asm.commons.LocalVariablesSorter.visitMaxs(Unknown
Source)
at org.objectweb.asm.ClassReader.a(Unknown Source)
at org.objectweb.asm.ClassReader.b(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
org.apache.felix.ipojo.manipulation.Manipulator.manipulate(Manipulator.java:135)
at
org.apache.felix.ipojo.manipulator.ManipulationEngine.generate(ManipulationEngine.java:142)
at
[jira] [Assigned] (FELIX-4969) cd refuses to leave initial directory
[
https://issues.apache.org/jira/browse/FELIX-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks reassigned FELIX-4969:
---
Assignee: David Jencks
cd refuses to leave initial directory
--
Key: FELIX-4969
URL: https://issues.apache.org/jira/browse/FELIX-4969
Project: Felix
Issue Type: Bug
Components: Gogo Command
Affects Versions: gogo.command-0.12.0
Reporter: Benson Margulies
Assignee: David Jencks
Actually observed in gogo command 0.14.0.
The implementation of the cd command in Files.java won't permit an absolute
pathname with ordinary syntax. If I type extra slashes, it stops complaining
-- but it also doesn't change the directory.
{noformat}
basis-osgi cd /tmp
gogo: IOException: Directory does not exist
basis-osgi
basis-osgi cd //tmp
Name gogo
Parent /Users/benson/x/rosette-osgi
CanonicalPath/Users/benson/x/rosette-osgi/gogo
Path /Users/benson/x/rosette-osgi/gogo
ParentFile /Users/benson/x/rosette-osgi
AbsolutePath /Users/benson/x/rosette-osgi/gogo
AbsoluteFile /Users/benson/x/rosette-osgi/gogo
CanonicalFile/Users/benson/x/rosette-osgi/gogo
TotalSpace 999334871040
FreeSpace247179890688
UsableSpace 246917746688
{noformat}
It's also awfully noisy.
A patch will be forthcoming to the refusal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4969) cd refuses to leave initial directory
[
https://issues.apache.org/jira/browse/FELIX-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved FELIX-4969.
-
Resolution: Fixed
Fix Version/s: gogo.command-0.16.0
I applied the patch from github and committed in r1697070. I couldn't figure
out how to use git to merge, perhaps because the felix tree has changed so much
recently. I think you will need to close the github pull request.
cd refuses to leave initial directory
--
Key: FELIX-4969
URL: https://issues.apache.org/jira/browse/FELIX-4969
Project: Felix
Issue Type: Bug
Components: Gogo Command
Affects Versions: gogo.command-0.12.0
Reporter: Benson Margulies
Assignee: David Jencks
Fix For: gogo.command-0.16.0
Actually observed in gogo command 0.14.0.
The implementation of the cd command in Files.java won't permit an absolute
pathname with ordinary syntax. If I type extra slashes, it stops complaining
-- but it also doesn't change the directory.
{noformat}
basis-osgi cd /tmp
gogo: IOException: Directory does not exist
basis-osgi
basis-osgi cd //tmp
Name gogo
Parent /Users/benson/x/rosette-osgi
CanonicalPath/Users/benson/x/rosette-osgi/gogo
Path /Users/benson/x/rosette-osgi/gogo
ParentFile /Users/benson/x/rosette-osgi
AbsolutePath /Users/benson/x/rosette-osgi/gogo
AbsoluteFile /Users/benson/x/rosette-osgi/gogo
CanonicalFile/Users/benson/x/rosette-osgi/gogo
TotalSpace 999334871040
FreeSpace247179890688
UsableSpace 246917746688
{noformat}
It's also awfully noisy.
A patch will be forthcoming to the refusal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4984) Issues in CircularReferenceTest
[
https://issues.apache.org/jira/browse/FELIX-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706347#comment-14706347
]
Pierre De Rop commented on FELIX-4984:
--
I just tested the patch and the problem seems to be resolved:
- Under bndtools, I ran 50 successful times the CircularReferenceTest (under
bndtools).
- Ran all tests successfully under bndtools.
- Ran all tests with gradle org.apache.felix.dependencymanager.ds.itest:check.
Please give me some time so I can fully understand the patch (I will study it
this week-end).
Currently, I tend to agree with the fact that it might be necessary to ensure
that all references are satisfied before scheduling the bind later tasks (I
need to study the patch).
thanks !
Issues in CircularReferenceTest
---
Key: FELIX-4984
URL: https://issues.apache.org/jira/browse/FELIX-4984
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Reporter: Pierre De Rop
Priority: Minor
Fix For: scr-2.0.2
Attachments: felix-4984.diff,
org.apache.felix.scr.integration.CircularReferenceTest.test_A11_B0n_delayed_B_first.log
This issue is described in the dev mailing list, in
http://www.mail-archive.com/dev@felix.apache.org/msg37281.html
while working on FELIX-4955, I sometimes have the CircularReferenceTest
failing.
Everything is located in my sandbox, in
http://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager.ds/
To reproduce the test:
install eclipse Mars
install latest bndtools using install new software from Eclipse, and then
add latest stable release from http://dl.bintray.com/bndtools/bndtools/latest/
install a java8 runtime (I'm using oracle java8 1.8.0_45, 64 bit version).
The whole new dependencymanager.ds project is intented to be build in java8.
checkout my sandbox:
$ svn checkout
http://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager.ds
go to dependencymanager.ds directory:
$ cd dependencymanager.ds/
due to a pending issue, you have to first build the DM bnd annotation plugin
before importing the project into eclipse. to do so, just type:
$ ./gradlew org.apache.felix.dependencymanager.annotation:jar
now launch eclipse and use the the dependencymanager/ds directory as the
workspace dir for Eclipse.
switch to BndTools perpective.
import the bndtools project into eclipse: Import - Existing Projects into
Workspace - Browse - select dependencymanager.ds directory (it is proposed
by default).
normally, and hopefully, everything should compile fine. Junit tests are left
in org.apache.felix.dependencymanager.ds/ directory and integration tests are
located in org.apache.felix.dependencymanager.ds.itest/ directory.
Open under Eclipse the
org.apache.felix.dependencymanager.ds.itest/src/org/apache/felix/scr/integration/CircularReferenceTest.java
I slightly modified it in order to dump stack traces when A component is
bound multiple times to the same B instance.
(I believe that only delayed components are concerned by the issue).
For example, in the test_A11_B0n_delayed_A_first() method, I added a call to
assertABoundToOneB(a) like this:
{code}
@Test
public void test_A11_B0n_delayed_A_first() throws InvalidSyntaxException
{
String componentNameA = 4.1.A.1.1.dynamic;
final ComponentConfigurationDTO componentA =
findComponentConfigurationByName( componentNameA,
ComponentConfigurationDTO.SATISFIED );
String componentNameB = 4.1.B.0.n.dynamic;
final ComponentConfigurationDTO componentB =
findComponentConfigurationByName( componentNameB,
ComponentConfigurationDTO.SATISFIED );
delay();
A a = getServiceFromConfiguration(componentA, A.class);
assertABoundToOneB(a);
delay(); //async binding of a to b after circular ref detected
B b = getServiceFromConfiguration(componentB, B.class);
assertEquals( 1, b.getAs().size() );
}
{code}
the assertABoundToOneB(a) call does this:
{code}
private void assertABoundToOneB(A a) {
if (a.getBs().size() != 1) {
System.err.println(detected problem ...);
a.dumpStackTracesWhenBWasBound();
}
assertEquals( 1, a.getBs().size());
}
{code}
And stacktraces will be dumped in order to determine why A was bound two
times to the same B instance.
it's possible that you have to run several times the CircularReferenceTest
test before having a failure (and some stacktraces).
Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: I would really like to get the Felix Framework released sometime soon
Awesome, thanks ! Regards JB On 08/21/2015 10:19 AM, David Bosschaert wrote: Yay! That's great news! Cheers, David On 20 August 2015 at 20:59, Karl Pauls karlpa...@gmail.com wrote: Great. I'll do a release on the weekend. regards, Karl On Thu, Aug 20, 2015 at 9:37 PM, Guillaume Nodet gno...@apache.org wrote: This should be ok now. The 3 issues have been fixed. 2015-08-19 12:15 GMT+02:00 Karl Pauls karlpa...@gmail.com: Cool. IIrc, we are only waiting on the 3 issues David mentions - hence, if you can get FELIX-4987 resolved I'll go ahead and cut a release on the weekend. regards, Karl On Wed, Aug 19, 2015 at 9:31 AM, Guillaume Nodet gno...@apache.org wrote: I'll start working on those issues today. I'd also like to have a release soon. 2015-08-17 11:16 GMT+02:00 David Bosschaert david.bosscha...@gmail.com : Hi all, I would really like to get the Framework released soon, but there are a number of issues related to the recent Resolver refactorings that hold this up. The issues are: FELIX-4987 FELIX-4988 FELIX-4989 Guillaume, since you worked on the Resolver refactoring, would you have time to look at these? Many thanks, David -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: I would really like to get the Felix Framework released sometime soon
Yay! That's great news! Cheers, David On 20 August 2015 at 20:59, Karl Pauls karlpa...@gmail.com wrote: Great. I'll do a release on the weekend. regards, Karl On Thu, Aug 20, 2015 at 9:37 PM, Guillaume Nodet gno...@apache.org wrote: This should be ok now. The 3 issues have been fixed. 2015-08-19 12:15 GMT+02:00 Karl Pauls karlpa...@gmail.com: Cool. IIrc, we are only waiting on the 3 issues David mentions - hence, if you can get FELIX-4987 resolved I'll go ahead and cut a release on the weekend. regards, Karl On Wed, Aug 19, 2015 at 9:31 AM, Guillaume Nodet gno...@apache.org wrote: I'll start working on those issues today. I'd also like to have a release soon. 2015-08-17 11:16 GMT+02:00 David Bosschaert david.bosscha...@gmail.com : Hi all, I would really like to get the Framework released soon, but there are a number of issues related to the recent Resolver refactorings that hold this up. The issues are: FELIX-4987 FELIX-4988 FELIX-4989 Guillaume, since you worked on the Resolver refactoring, would you have time to look at these? Many thanks, David -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
