[jira] [Commented] (FELIX-3411) The implementation of org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the spec
[
https://issues.apache.org/jira/browse/FELIX-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253359#comment-13253359
]
Richard S. Hall commented on FELIX-3411:
Ok, I think I understand your point now, you think it should attempt to restart
bundles that are below the current active start level (effectively blacklisting
them). I'm not sure this is what the spec means. I'll investigate.
> The implementation of
> org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the
> spec
>
>
> Key: FELIX-3411
> URL: https://issues.apache.org/jira/browse/FELIX-3411
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Yasuhiro Kawame
>
> I think that the implementation of Changing the Active Start Level is
> different from Spec.
> see:
> OSGi Service Platform Core Specification Release 4, Version 4.3, Figure 8.2
> page154
> Move to requested start level R, active level is A, B is a bundle's start
> level
> Spec:
> if (A < R)
> while (A < R) {
> A = A + 1
> Start All bundles where B = A
> }
> Implementation:
> if (A < R)
> Start All bundles where B <= R
> A = R
> Similarly, if A > R.
> Javadoc:
> http://www.osgi.org/javadoc/r4v43/org/osgi/service/startlevel/StartLevel.html#setStartLevel%28int%29
> http://www.osgi.org/javadoc/r4v43/org/osgi/framework/startlevel/FrameworkStartLevel.html#setStartLevel(int,
> org.osgi.framework.FrameworkListener...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3455) Framework JARs for JDK 7
[ https://issues.apache.org/jira/browse/FELIX-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252500#comment-13252500 ] Richard S. Hall commented on FELIX-3455: Not really. Until then, just recompile it yourself. > Framework JARs for JDK 7 > > > Key: FELIX-3455 > URL: https://issues.apache.org/jira/browse/FELIX-3455 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 > Environment: Linux Kubuntu 11.04 >Reporter: Florian Brunner > Labels: build > Fix For: framework-4.2.0 > > > In Java SE 7 projects I get the following error: > [WARNING] Signature attribute introduced in version 49.0 class files is > ignored in version 48.0 class files > ... > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] error: incompatible types > [ERROR] Object > I've read about this issue here: > http://www.mail-archive.com/users@felix.apache.org/msg11574.html > and here: > http://stackoverflow.com/questions/4058661/java-compilers-target-version-jsr14-with-jdk7-8 > The according JDK bug report has been closed as "Not a Defect": > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078419 > So this has to be fixed on Apache Felix side. > Please deploy a version to Maven Central which works with Java SE 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3455) Framework JARs for JDK 7
[ https://issues.apache.org/jira/browse/FELIX-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252483#comment-13252483 ] Richard S. Hall commented on FELIX-3455: I'm fine if we switch the framework to target Java 5 by default rather than jsr14, which should solve the issue, but that will have to wait for the next release. > Framework JARs for JDK 7 > > > Key: FELIX-3455 > URL: https://issues.apache.org/jira/browse/FELIX-3455 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 > Environment: Linux Kubuntu 11.04 >Reporter: Florian Brunner >Priority: Blocker > Labels: build > Fix For: framework-4.2.0 > > > In Java SE 7 projects I get the following error: > [WARNING] Signature attribute introduced in version 49.0 class files is > ignored in version 48.0 class files > ... > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] error: incompatible types > [ERROR] Object > I've read about this issue here: > http://www.mail-archive.com/users@felix.apache.org/msg11574.html > and here: > http://stackoverflow.com/questions/4058661/java-compilers-target-version-jsr14-with-jdk7-8 > The according JDK bug report has been closed as "Not a Defect": > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078419 > So this has to be fixed on Apache Felix side. > Please deploy a version to Maven Central which works with Java SE 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3411) The implementation of org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the spec
[
https://issues.apache.org/jira/browse/FELIX-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249976#comment-13249976
]
Richard S. Hall commented on FELIX-3411:
I have looked at the spec, but I don't see where is says bundles should be
blacklisted if they throw an exception during a start level change. Could you
point me to where you believe the spec says this?
> The implementation of
> org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the
> spec
>
>
> Key: FELIX-3411
> URL: https://issues.apache.org/jira/browse/FELIX-3411
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Yasuhiro Kawame
>
> I think that the implementation of Changing the Active Start Level is
> different from Spec.
> see:
> OSGi Service Platform Core Specification Release 4, Version 4.3, Figure 8.2
> page154
> Move to requested start level R, active level is A, B is a bundle's start
> level
> Spec:
> if (A < R)
> while (A < R) {
> A = A + 1
> Start All bundles where B = A
> }
> Implementation:
> if (A < R)
> Start All bundles where B <= R
> A = R
> Similarly, if A > R.
> Javadoc:
> http://www.osgi.org/javadoc/r4v43/org/osgi/service/startlevel/StartLevel.html#setStartLevel%28int%29
> http://www.osgi.org/javadoc/r4v43/org/osgi/framework/startlevel/FrameworkStartLevel.html#setStartLevel(int,
> org.osgi.framework.FrameworkListener...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3447) Optimize read only collections by using a specific class and not a wrapper which is slower
[ https://issues.apache.org/jira/browse/FELIX-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248339#comment-13248339 ] Richard S. Hall commented on FELIX-3447: Just curious as to whether you have some empirical evidence that this is an issue or if you are just guessing? It would be nice to see a comparison. > Optimize read only collections by using a specific class and not a wrapper > which is slower > -- > > Key: FELIX-3447 > URL: https://issues.apache.org/jira/browse/FELIX-3447 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.0.2 >Reporter: Guillaume Nodet > Fix For: framework-4.2.0 > > Attachments: FELIX-3447.patch > > > The unmodifiable collection wrappers are .. wrappers and as such add a > slight overhead. > In the case of felix, the resolution process does use a lot of those maps for > bundle capabilities and requirements and the overhead tends to become non > negligible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3419) Bad aggregation of org.apache.felix.framework into org.apache.felix.main
[ https://issues.apache.org/jira/browse/FELIX-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244433#comment-13244433 ] Richard S. Hall commented on FELIX-3419: If you know of some way to tell Maven to include the source of framework into the main source JAR, then I wouldn't have a problem with it, but I prefer to keep them as separate projects that create an aggregated JAR since that is more convenient. > Bad aggregation of org.apache.felix.framework into org.apache.felix.main > > > Key: FELIX-3419 > URL: https://issues.apache.org/jira/browse/FELIX-3419 > Project: Felix > Issue Type: Bug > Components: Framework, Main >Affects Versions: framework-4.0.2 >Reporter: Jesse Glick >Priority: Minor > Labels: maven > > org.apache.felix.felix-4.0.2.jar in Maven Central > (org.apache.felix:org.apache.felix.main:4.0.2:jar) aggregates classes from > org.apache.felix.framework, as a convenience I suppose. But it is not very > convenient when trying to analyze stack traces, debug, etc. from Maven > projects, because while > org.apache.felix:org.apache.felix.main:4.0.2:sources:jar > (org.apache.felix.main-4.0.2-sources.jar) exists, it includes just the two > classes in the org.apache.felix.main package. > Simpler and better would be to distribute felix.framework and felix.main as > disjoint artifacts, but if you do want to produce an aggregated JAR, its > source artifact needs to include matches for all the compiled classes in the > JAR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3411) The implementation of org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the spec
[
https://issues.apache.org/jira/browse/FELIX-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244411#comment-13244411
]
Richard S. Hall commented on FELIX-3411:
So, is your issue that the framework should not attempt to start Bundle_02
again?
Perhaps so, but your original issue description didn't says something
completely different. If the extra attempt to start the bundle is your concern,
we should edit this issue to more clearly state that fact. Let me know. Thanks.
> The implementation of
> org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the
> spec
>
>
> Key: FELIX-3411
> URL: https://issues.apache.org/jira/browse/FELIX-3411
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Yasuhiro Kawame
>
> I think that the implementation of Changing the Active Start Level is
> different from Spec.
> see:
> OSGi Service Platform Core Specification Release 4, Version 4.3, Figure 8.2
> page154
> Move to requested start level R, active level is A, B is a bundle's start
> level
> Spec:
> if (A < R)
> while (A < R) {
> A = A + 1
> Start All bundles where B = A
> }
> Implementation:
> if (A < R)
> Start All bundles where B <= R
> A = R
> Similarly, if A > R.
> Javadoc:
> http://www.osgi.org/javadoc/r4v43/org/osgi/service/startlevel/StartLevel.html#setStartLevel%28int%29
> http://www.osgi.org/javadoc/r4v43/org/osgi/framework/startlevel/FrameworkStartLevel.html#setStartLevel(int,
> org.osgi.framework.FrameworkListener...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3413) NPE and thread blocked in org.osgi.service.packageadmin.PackageAdmin#refreshPackages(Bundle[])
[
https://issues.apache.org/jira/browse/FELIX-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241352#comment-13241352
]
Richard S. Hall commented on FELIX-3413:
Technically, I don't think you should be passing in null there, but I suppose
we can check for it.
> NPE and thread blocked in
> org.osgi.service.packageadmin.PackageAdmin#refreshPackages(Bundle[])
> --
>
> Key: FELIX-3413
> URL: https://issues.apache.org/jira/browse/FELIX-3413
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Yasuhiro Kawame
>
> NPE and thread is blocked, when PackageAdmin#refreshPackages(bundleArray) is
> called under the following conditions:
> Bundle[] bundleArray = {BundleA, null, BundleB}
> call PackageAdmin#refreshPackages(bundleArray)
> StackTrace:
> Exception in thread "FelixFrameworkWiring" java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleRevisionDependencies.getDependentBundles(BundleRevisionDependencies.java:163)
> at
> org.apache.felix.framework.Felix.populateDependentGraph(Felix.java:4059)
> at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3898)
> at
> org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:172)
> at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3411) The implementation of org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the spec
[
https://issues.apache.org/jira/browse/FELIX-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241348#comment-13241348
]
Richard S. Hall commented on FELIX-3411:
Your description of the framework's behavior is not correct. If you check
Felix.setActiveStartLevel() you can see that it takes a sorted snapshot of the
existing bundles:
// Get a sorted snapshot of all installed bundles
// to be processed during the start level change.
// We also snapshot the start level here, since it
// may change and we don't want to consider any
// changes since they will be queued for the start
// level thread.
bundles = getBundles();
for (Bundle b : bundles)
{
m_startLevelBundles.add(
new StartLevelTuple(
(BundleImpl) b,
((BundleImpl) b).getStartLevel(
getInitialBundleStartLevel(;
}
It then processes this list (which is sorted by bundle start level and then
bundle ID) in forward or reverse order depending on whether it is raising or
lowering:
if (lowering)
{
tuple = m_startLevelBundles.last();
}
else
{
tuple = m_startLevelBundles.first();
}
And for each bundle processed in order it counts up or down the framework's
current active start level depending upon whether we are lowering or raising,
e.g.:
// Count up the active start level.
if (m_activeStartLevel != tuple.m_level)
{
m_activeStartLevel = tuple.m_level;
}
So, while it is possible there are some bugs, it definitely is attempting to
implement the spec as described. There is the potential for a bundle to be
started/stopped out of order if you are manipulating its state at the same time
the start level operation is going on, but it is a small window and will still
end up in the proper state.
At any rate, if you experience any bugs, would it be possible to create an
example to demonstrate the issue? Thanks.
> The implementation of
> org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the
> spec
>
>
> Key: FELIX-3411
> URL: https://issues.apache.org/jira/browse/FELIX-3411
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Yasuhiro Kawame
>
> I think that the implementation of Changing the Active Start Level is
> different from Spec.
> see:
> OSGi Service Platform Core Specification Release 4, Version 4.3, Figure 8.2
> page154
> Move to requested start level R, active level is A, B is a bundle's start
> level
> Spec:
> if (A < R)
> while (A < R) {
> A = A + 1
> Start All bundles where B = A
> }
> Implementation:
> if (A < R)
> Start All bundles where B <= R
> A = R
> Similarly, if A > R.
> Javadoc:
> http://www.osgi.org/javadoc/r4v43/org/osgi/service/startlevel/StartLevel.html#setStartLevel%28int%29
> http://www.osgi.org/javadoc/r4v43/org/osgi/framework/startlevel/FrameworkStartLevel.html#setStartLevel(int,
> org.osgi.framework.FrameworkListener...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2787) [File Install] Do not perform management activities while framework is starting/stopping
[ https://issues.apache.org/jira/browse/FELIX-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232013#comment-13232013 ] Richard S. Hall commented on FELIX-2787: Perhaps, but I can't say for certain without looking into it in more detail. I did try at one time to fix this issue by trying to make the activator start/stop its threads based on the framework state, but when I looked into it, I would have required a bit of work to get it to work like that. However, if you just modify the thread loop like you suggest, it might be good enough. > [File Install] Do not perform management activities while framework is > starting/stopping > > > Key: FELIX-2787 > URL: https://issues.apache.org/jira/browse/FELIX-2787 > Project: Felix > Issue Type: Improvement > Components: File Install >Affects Versions: fileinstall-3.1.4 >Reporter: Richard S. Hall >Assignee: Guillaume Nodet > > File Install has been known to cause deadlocks, race conditions, and other > sorts of spurious issues. One of the main reasons for this is that File > Install is pretty aggressive in its management of bundles. This has caused us > to improve the framework to deal with its aggressiveness, but still it is not > perfect. We have seen people wanting to introduce a delay value for > management, etc. We also see issues where the framework is trying to shut > down and File Install is going right behind the framework restarting bundles > as the framework stops them. It would be better if File Install monitored the > starting/stopping status for the framework and only performed its management > activities while the framework were active. This means File Install's > management threads should not do their processing when the framework is not > in the ACTIVE state. This will be a good improvement, although it won't > completely eliminate the window, since this is a check-then-act situation. > However, as long as the threads check the status on each process loop, the > window will be significantly reduced. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2787) [File Install] Do not perform management activities while framework is starting/stopping
[ https://issues.apache.org/jira/browse/FELIX-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231292#comment-13231292 ] Richard S. Hall commented on FELIX-2787: Depends on how it is implemented, but I'm not certain. For example, if the framework is shutting down and it's start level is at 1 when the shutdown begins. I believe it will stay at 1 until it has shutdown all active bundles with start level 1. Assume the "active level" of File Install is set to 1 and that we have 1000 active bundles and File Install will be the last bundle stopped. The situation we saw was the File Install was restarting bundles that the framework was stopping, e.g., framework stops bundle 999, then File Install restarts bundle 999, etc. The key here is not the start level, but that the framework state is "STOPPING" and therefore File Install should do no management at all at that time. Likewise when the framework is "STARTING". > [File Install] Do not perform management activities while framework is > starting/stopping > > > Key: FELIX-2787 > URL: https://issues.apache.org/jira/browse/FELIX-2787 > Project: Felix > Issue Type: Improvement > Components: File Install >Affects Versions: fileinstall-3.1.4 >Reporter: Richard S. Hall >Assignee: Guillaume Nodet > > File Install has been known to cause deadlocks, race conditions, and other > sorts of spurious issues. One of the main reasons for this is that File > Install is pretty aggressive in its management of bundles. This has caused us > to improve the framework to deal with its aggressiveness, but still it is not > perfect. We have seen people wanting to introduce a delay value for > management, etc. We also see issues where the framework is trying to shut > down and File Install is going right behind the framework restarting bundles > as the framework stops them. It would be better if File Install monitored the > starting/stopping status for the framework and only performed its management > activities while the framework were active. This means File Install's > management threads should not do their processing when the framework is not > in the ACTIVE state. This will be a good improvement, although it won't > completely eliminate the window, since this is a check-then-act situation. > However, as long as the threads check the status on each process loop, the > window will be significantly reduced. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3397) NPE when trying to resolve invalid fragments
[ https://issues.apache.org/jira/browse/FELIX-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231257#comment-13231257 ] Richard S. Hall commented on FELIX-3397: Yeah, the BundleRevisionImpl.getTypes() implementation is probably too simplistic, since it only checks for the existence of the header, not whether the bundle is R4 or not. > NPE when trying to resolve invalid fragments > > > Key: FELIX-3397 > URL: https://issues.apache.org/jira/browse/FELIX-3397 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 >Reporter: Guillaume Nodet > > The main reason is that the manifest parser ignores the Fragment-Host header > if the Manifest-Version attribute is not set, while > BundleRevisionImpl#getTypes() returns that the bundle is a fragment, leading > a the host requirement not being found in Candidates#populateFragmentOndemand > method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3395) Make preferences persistence location configurable
[
https://issues.apache.org/jira/browse/FELIX-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229474#comment-13229474
]
Richard S. Hall commented on FELIX-3395:
Yep, as I said, it is certainly do-able. The only downside is there is no
cross-bundle solution for this. So, I'm not arguing against it in Preferences,
just pointing out you run the risk of swimming against the tide if you use the
OSGi framework in a way that it wasn't intended.
Regarding your "update" issue with Pax Runner...if they really only support
clean cache provisioning, I'd recommend looking into a different solution.
> Make preferences persistence location configurable
> --
>
> Key: FELIX-3395
> URL: https://issues.apache.org/jira/browse/FELIX-3395
> Project: Felix
> Issue Type: Wish
> Components: Preferences Service
>Reporter: Pieter
>
> I want Preference Service to persist stored preferences and have them survive
> system restarts. Preference Service stores its stuff in the OSGi frameworks'
> cache region, which get cleared on restart (by Pax Runner, which is what I
> use). Trying to get around this was problematic, so I figured it would be
> nice to be able have the preferences database outside the cache directory. A
> system property like "felix.prefs.rootdir" could be used to set the location.
> I patched the Preference Service from trunk to get this feature and the
> changes are minimal, I just added the following lines to the
> DataFileBackingStoreImpl constructor:
> String configuredRootDir = System.getProperty("felix.prefs.rootdir");
> this.rootDirectory = configuredRootDir == null ?
> context.getDataFile("") : new File(configuredRootDir);
> this.rootDirectory.mkdirs();
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3395) Make preferences persistence location configurable
[
https://issues.apache.org/jira/browse/FELIX-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229429#comment-13229429
]
Richard S. Hall commented on FELIX-3395:
You could probably do that, but technically the Preferences impl is doing the
right thing, since it should store data in its private data area. It seems like
you should configure Pax Runner to not delete the cache for each run otherwise
you'll run into this issue with every bundle that "correctly" saves data to is
private data area.
> Make preferences persistence location configurable
> --
>
> Key: FELIX-3395
> URL: https://issues.apache.org/jira/browse/FELIX-3395
> Project: Felix
> Issue Type: Wish
> Components: Preferences Service
>Reporter: Pieter
>
> I want Preference Service to persist stored preferences and have them survive
> system restarts. Preference Service stores its stuff in the OSGi frameworks'
> cache region, which get cleared on restart (by Pax Runner, which is what I
> use). Trying to get around this was problematic, so I figured it would be
> nice to be able have the preferences database outside the cache directory. A
> system property like "felix.prefs.rootdir" could be used to set the location.
> I patched the Preference Service from trunk to get this feature and the
> changes are minimal, I just added the following lines to the
> DataFileBackingStoreImpl constructor:
> String configuredRootDir = System.getProperty("felix.prefs.rootdir");
> this.rootDirectory = configuredRootDir == null ?
> context.getDataFile("") : new File(configuredRootDir);
> this.rootDirectory.mkdirs();
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3393) Possible deadlock with reentrant calls
[
https://issues.apache.org/jira/browse/FELIX-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229219#comment-13229219
]
Richard S. Hall commented on FELIX-3393:
Just out of curiousity, I did some source code archeology and it appears that
this bug has existed since we switched to our current locking approach around
framework 1.6.0, so it is a good catch. Not sure how often we run into this,
but it is good to have it fixed.
> Possible deadlock with reentrant calls
> --
>
> Key: FELIX-3393
> URL: https://issues.apache.org/jira/browse/FELIX-3393
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: framework-4.2.0
>
>
> This happen when a thread which has a bundle lock has some reentrant call
> while the global lock is held by another thread (see stack trace below)
> In the code Felix#acquireBundleLock, the comment on the loop says "Wait if
> the desired bundle is already locked by someone else or if any thread has the
> global lock, unless the current thread holds the global lock or the bundle
> lock already." which makes total sense, but I don't think the code handle the
> case where the lock is already held by the current thread *and* the global
> lock is held by a different thread.
> Possible patch below.
> {code}
> diff --git a/framework/src/main/java/org/apache/felix/framework/Felix.java
> b/framework/src/main/java/org/apache/felix/framework/Felix.java
> index 6504f13..0965d8b 100644
> --- a/framework/src/main/java/org/apache/felix/framework/Felix.java
> +++ b/framework/src/main/java/org/apache/felix/framework/Felix.java
> @@ -5002,7 +5002,8 @@ public class Felix extends BundleImpl implements
> Framework
> // holds the global lock or the bundle lock already.
> while (!bundle.isLockable() ||
> ((m_globalLockThread != null)
> -&& (m_globalLockThread != Thread.currentThread(
> +&& (m_globalLockThread != Thread.currentThread())
> +&& (bundle.getLockingThread() !=
> Thread.currentThread(
> {
> // Check to make sure the bundle is in a desired state.
> // If so, keep waiting. If not, throw an exception.
> {code}
> {code}
> "FelixStartLevel" daemon prio=5 tid=7fb1b2ac7800 nid=0x44000 in
> Object.wait() [42000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7e039bc90> (a [Ljava.lang.Object;)
> at java.lang.Object.wait(Object.java:485)
> at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:5025)
> - locked <7e039bc90> (a [Ljava.lang.Object;)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3282)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:408)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:184)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:666)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:334)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:230)
> - locked <7f5898750> (a java.util.concurrent.atomic.AtomicBoolean)
> - locked <7f5898740> (a java.util.concurrent.atomic.AtomicBoolean)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.checkBundle(BlueprintExtender.java:325)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:244)
> at
> org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:471)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:495)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:1)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:238)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:457)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:870)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:791)
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:515)
>
[jira] [Commented] (FELIX-3382) Update servicebased SimpleShapes example to create an embedded framework using org.osgi.framework.launch
[ https://issues.apache.org/jira/browse/FELIX-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13228535#comment-13228535 ] Richard S. Hall commented on FELIX-3382: I've applied your patches, they looked ok to me. Regarding your questions: 1. Actually, framework.jar embeds the OSGi packages and main.jar embeds all of framework.jar. Mainly so we can customize some OSGi classes that have implementations and so we can have a self-contained framework. 2. I believe that is correct, since we are not transforming the objects, see: http://njbartlett.name/2010/08/10/generic-osgi.html Please close this issue if you are satisfied. Thanks. > Update servicebased SimpleShapes example to create an embedded framework > using org.osgi.framework.launch > > > Key: FELIX-3382 > URL: https://issues.apache.org/jira/browse/FELIX-3382 > Project: Felix > Issue Type: Improvement >Reporter: Benedikt Ritter >Priority: Trivial > Attachments: FELIX-3382_circle.txt, FELIX-3382_host.txt, > FELIX-3382_square.txt, FELIX-3382_trapezoid.txt, FELIX-3382_triangle.txt > > > Apply the same changes to the servicebased SimpleShape example as described > in FELIX-3379 for the extenderbased SimpleShape example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3388) Complex uses resolver failure
[ https://issues.apache.org/jira/browse/FELIX-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227761#comment-13227761 ] Richard S. Hall commented on FELIX-3388: I'm not exactly sure what you are telling me, but if you are saying that it is failing on the on the separately packaged resolver, then that's possible. Not sure. You should test it on the real framework, since the separate resolver is just a throw away. When I create a new separate resolver, I'll do it from the framework code base, not from that existing one. > Complex uses resolver failure > - > > Key: FELIX-3388 > URL: https://issues.apache.org/jira/browse/FELIX-3388 > Project: Felix > Issue Type: Bug >Reporter: Thomas Diesler > Attachments: test.log, test_#2.log > > > Consider this > // Bundle-SymbolicName: javax.servlet.api > // ExportPackage: javax.servlet;version=2.5 > // Bundle-SymbolicName: enterprise.jar > // ExportPackage: > org.osgi.service.http;version=1.2.1;uses:=javax.servlet > // ImportPackage: javax.servlet;resolution:=optional > // Bundle-SymbolicName: http.service.provider > // ExportPackage: javax.servlet;version=2.5 > // ExportPackage: org.ops4j.pax.web.service;uses:=javax.servlet > // ExportPackage: > org.osgi.service.http;version=1.2.0;uses:=javax.servlet > // ImportPackage: > javax.servlet;version="[2.3.0,2.6.0)";resolution:=optional > Install, resolve and apply results for the above. > Verify that package requirement javax.servlet wires to javax.servlet.api > // Bundle-SymbolicName: war.extender.jar > // ImportPackage: org.ops4j.pax.web.service > // ImportPackage: javax.servlet;version="[2.3,3.0)" > Install, resolve and apply results for the above. > Verify that package requirement javax.servlet wires to javax.servlet.api > The test is here: > https://github.com/tdiesler/jbosgi-resolver/blob/master/felix/src/test/java/org/jboss/test/osgi/resolver/UsesDirectiveResolverTest.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3388) Complex uses resolver failure
[ https://issues.apache.org/jira/browse/FELIX-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227585#comment-13227585 ] Richard S. Hall commented on FELIX-3388: For unresolved bundles, the environment may return any of the capabilities since they are all potential matches. However, for resolved bundles the environment will never return Export-Package capabilities that have been substituted, because they are no longer viable candidates. Regarding your patch, I say it is not really necessary since it apparently is trying to cope with a faulty environment that is returning substituted capabilities (i.e., invalid candidates). Technically, though, it probably wouldn't do any harm, it is just unnecessary if they environment does its job. > Complex uses resolver failure > - > > Key: FELIX-3388 > URL: https://issues.apache.org/jira/browse/FELIX-3388 > Project: Felix > Issue Type: Bug >Reporter: Thomas Diesler > Attachments: test.log > > > Consider this > // Bundle-SymbolicName: javax.servlet.api > // ExportPackage: javax.servlet;version=2.5 > // Bundle-SymbolicName: enterprise.jar > // ExportPackage: > org.osgi.service.http;version=1.2.1;uses:=javax.servlet > // ImportPackage: javax.servlet;resolution:=optional > // Bundle-SymbolicName: http.service.provider > // ExportPackage: javax.servlet;version=2.5 > // ExportPackage: org.ops4j.pax.web.service;uses:=javax.servlet > // ExportPackage: > org.osgi.service.http;version=1.2.0;uses:=javax.servlet > // ImportPackage: > javax.servlet;version="[2.3.0,2.6.0)";resolution:=optional > Install, resolve and apply results for the above. > Verify that package requirement javax.servlet wires to javax.servlet.api > // Bundle-SymbolicName: war.extender.jar > // ImportPackage: org.ops4j.pax.web.service > // ImportPackage: javax.servlet;version="[2.3,3.0)" > Install, resolve and apply results for the above. > Verify that package requirement javax.servlet wires to javax.servlet.api > The test is here: > https://github.com/tdiesler/jbosgi-resolver/blob/master/felix/src/test/java/org/jboss/test/osgi/resolver/UsesDirectiveResolverTest.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3388) Complex uses resolver failure
[ https://issues.apache.org/jira/browse/FELIX-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227564#comment-13227564 ] Richard S. Hall commented on FELIX-3388: I deleted the related link, since it isn't really related at all to packaging the resolver separately, other than they both are related to the resolver. Perhaps I'm not following your steps correctly, but this is what I see: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.1.0.SNAPSHOT) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Installed |1|javax.servlet.api (0.0.0) 6|Installed |1|enterprise.jar (0.0.0) 7|Installed |1|http.service.provider (0.0.0) 8|Installed |1|war.extender.jar (0.0.0) g! resolve 5 6 7 DEBUG: WIRE: [6.0] osgi.wiring.package; (osgi.wiring.package=javax.servlet) -> [5.0] DEBUG: WIRE: [7.0] osgi.wiring.package; (&(osgi.wiring.package=javax.servlet)(version>=2.3.0)(!(version>=2.6.0))) -> [5.0] g! resolve 8 DEBUG: WIRE: [8.0] osgi.wiring.package; (osgi.wiring.package=org.ops4j.pax.web.service) -> [7.0] DEBUG: WIRE: [8.0] osgi.wiring.package; (&(osgi.wiring.package=javax.servlet)(version>=2.3.0)(!(version>=3.0.0))) -> [5.0] g! Is this not correct? And to answer your other question, no the environment should NOT return substituted capabilities since, by definition, they do not exist anymore. > Complex uses resolver failure > - > > Key: FELIX-3388 > URL: https://issues.apache.org/jira/browse/FELIX-3388 > Project: Felix > Issue Type: Bug >Reporter: Thomas Diesler > Attachments: test.log > > > Consider this > // Bundle-SymbolicName: javax.servlet.api > // ExportPackage: javax.servlet;version=2.5 > // Bundle-SymbolicName: enterprise.jar > // ExportPackage: > org.osgi.service.http;version=1.2.1;uses:=javax.servlet > // ImportPackage: javax.servlet;resolution:=optional > // Bundle-SymbolicName: http.service.provider > // ExportPackage: javax.servlet;version=2.5 > // ExportPackage: org.ops4j.pax.web.service;uses:=javax.servlet > // ExportPackage: > org.osgi.service.http;version=1.2.0;uses:=javax.servlet > // ImportPackage: > javax.servlet;version="[2.3.0,2.6.0)";resolution:=optional > Install, resolve and apply results for the above. > Verify that package requirement javax.servlet wires to javax.servlet.api > // Bundle-SymbolicName: war.extender.jar > // ImportPackage: org.ops4j.pax.web.service > // ImportPackage: javax.servlet;version="[2.3,3.0)" > Install, resolve and apply results for the above. > Verify that package requirement javax.servlet wires to javax.servlet.api > The test is here: > https://github.com/tdiesler/jbosgi-resolver/blob/master/felix/src/test/java/org/jboss/test/osgi/resolver/UsesDirectiveResolverTest.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3379) Update extenderbased SimpleShapes example to create an embedded framework using org.osgi.framework.launch
[ https://issues.apache.org/jira/browse/FELIX-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225312#comment-13225312 ] Richard S. Hall commented on FELIX-3379: BTW, I committed the patch, so please close this issue if you are satisfied. Thanks. > Update extenderbased SimpleShapes example to create an embedded framework > using org.osgi.framework.launch > - > > Key: FELIX-3379 > URL: https://issues.apache.org/jira/browse/FELIX-3379 > Project: Felix > Issue Type: Improvement >Reporter: Benedikt Ritter >Priority: Trivial > Attachments: FELIX-3379.txt > > > As suggested in FELIX-3375 and discussed in the ML > (http://www.mail-archive.com/dev@felix.apache.org/msg24668.html), the > SimpleShape example should be changed to create an embedded framework in a > non-Felix-specific way, using org.osgi.framework.launch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3379) Update extenderbased SimpleShapes example to create an embedded framework using org.osgi.framework.launch
[ https://issues.apache.org/jira/browse/FELIX-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225311#comment-13225311 ] Richard S. Hall commented on FELIX-3379: Seems reasonable, just be careful to not over-engineer the example, since it really is intended to be simple so that people can see the core issues/differences between the service-based and extender-based approaches. I assume you'll look into modifying the service-based example to completely mirror the changes here as much as possible to keep them consistent, right? If so, then I think you are in pretty good shape. Thanks a lot. > Update extenderbased SimpleShapes example to create an embedded framework > using org.osgi.framework.launch > - > > Key: FELIX-3379 > URL: https://issues.apache.org/jira/browse/FELIX-3379 > Project: Felix > Issue Type: Improvement >Reporter: Benedikt Ritter >Priority: Trivial > Attachments: FELIX-3379.txt > > > As suggested in FELIX-3375 and discussed in the ML > (http://www.mail-archive.com/dev@felix.apache.org/msg24668.html), the > SimpleShape example should be changed to create an embedded framework in a > non-Felix-specific way, using org.osgi.framework.launch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3378) class in bootclasspath cannot load osgi framework class
[ https://issues.apache.org/jira/browse/FELIX-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224599#comment-13224599 ] Richard S. Hall commented on FELIX-3378: Sounds like that Protege code is expecting to run on Equinox, then. You could add the Equinox JAR file to the class path and boot delegate that specific package too and see if that gets you any further. And, yes, the org.eclipse... package is part of the Equinox framework, but it may export the package from its system bundle so that bundles can import it, I have no idea. I'd try the above suggestion, just to see if it makes a difference, but if the code in question has internal dependencies on Equinox-specific functionality then it may not work correctly even if you give it the class that it is expecting. > class in bootclasspath cannot load osgi framework class > --- > > Key: FELIX-3378 > URL: https://issues.apache.org/jira/browse/FELIX-3378 > Project: Felix > Issue Type: Bug > Components: Framework > Environment: Windows7,64bit. Java 1.6 jdk, Protege 4.1, Felix 2.0.4, > OSGi R4 >Reporter: dave c > Labels: newbie > > I work on a java profiler project. We have added our package to the > bootdelegation path, so our code is found even though no explicit reference > exists to our package. The problem seems to come when our code tries to load > a class that is not our own. > I am profiling Protege 4.1. We have some code running in a background thread > which gets this error. I looked at the felix code for ModuleImpl, and find > nothing obvious. Is there something I'm doing wrong that prevents our thread > from finding this class? Or is this a limitation of the OSGi framework? > java.lang.NoClassDefFoundError: > org/eclipse/osgi/framework/console/CommandProvider > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(Unknown Source) > at java.lang.ClassLoader.defineClass(Unknown Source) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1872) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:758) > at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733) > at java.lang.ClassLoader.loadClass(Unknown Source) > at > com.myprofiler.InstrumentedMethod.registerForClassDeathNotification(InstrumentedMethod.java:311) > at > com.myprofiler.InstrumentedMethod.createDeathNotificationsForNewMethods(InstrumentedMethod.java:116) > at > com.myprofiler.MyProfilerApplication$PeriodicBufferProcessingThread.run(MyProfilerApplication.java:403) > Caused by: java.lang.ClassNotFoundException: > org.eclipse.osgi.framework.console.CommandProvider > at java.net.URLClassLoader$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at > org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1554) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:765) > at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733) > at java.lang.ClassLoader.loadClass(Unknown Source) > ... 11 more > > > According to the maanifest in the bundled felix.jar: > Bundle-Version: 2.0.4 > Bundle-Name: Apache Felix > Bundle-Description: OSGi R4 framework. > Build-Jdk: 1.5.0_22 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3378) class in bootclasspath cannot load osgi framework class
[ https://issues.apache.org/jira/browse/FELIX-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224503#comment-13224503 ] Richard S. Hall commented on FELIX-3378: It's not clear to me why you are loading an Equinox OSGi framework class while running on the Felix framework, but ignoring that fact for now... Are you saying you are trying to load a class from a bundle in your class that was loaded by the application class loader? If so, there is no way that is going to work, since the application class loader does not have access to bundle classes. Perhaps if your code is intended to run on Equinox, then perhaps that is why it is trying to load an Equinox-specific class, not sure. You could also try a newer version of Felix, since that would make it easier for us to debug. > class in bootclasspath cannot load osgi framework class > --- > > Key: FELIX-3378 > URL: https://issues.apache.org/jira/browse/FELIX-3378 > Project: Felix > Issue Type: Bug > Components: Framework > Environment: Windows7,64bit. Java 1.6 jdk, Protege 4.1, Felix 2.0.4, > OSGi R4 >Reporter: dave c > Labels: newbie > > I work on a java profiler project. We have added our package to the > bootdelegation path, so our code is found even though no explicit reference > exists to our package. The problem seems to come when our code tries to load > a class that is not our own. > I am profiling Protege 4.1. We have some code running in a background thread > which gets this error. I looked at the felix code for ModuleImpl, and find > nothing obvious. Is there something I'm doing wrong that prevents our thread > from finding this class? Or is this a limitation of the OSGi framework? > java.lang.NoClassDefFoundError: > org/eclipse/osgi/framework/console/CommandProvider > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(Unknown Source) > at java.lang.ClassLoader.defineClass(Unknown Source) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1872) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:758) > at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733) > at java.lang.ClassLoader.loadClass(Unknown Source) > at > com.myprofiler.InstrumentedMethod.registerForClassDeathNotification(InstrumentedMethod.java:311) > at > com.myprofiler.InstrumentedMethod.createDeathNotificationsForNewMethods(InstrumentedMethod.java:116) > at > com.myprofiler.MyProfilerApplication$PeriodicBufferProcessingThread.run(MyProfilerApplication.java:403) > Caused by: java.lang.ClassNotFoundException: > org.eclipse.osgi.framework.console.CommandProvider > at java.net.URLClassLoader$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at > org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1554) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:765) > at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733) > at java.lang.ClassLoader.loadClass(Unknown Source) > ... 11 more > > > According to the maanifest in the bundled felix.jar: > Bundle-Version: 2.0.4 > Bundle-Name: Apache Felix > Bundle-Description: OSGi R4 framework. > Build-Jdk: 1.5.0_22 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3376) Update extenderbased SimpleShapes example to use Java 5 Features
[ https://issues.apache.org/jira/browse/FELIX-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224477#comment-13224477 ] Richard S. Hall commented on FELIX-3376: I committed these patches with only minor modifications. One thing I thought about was we could potentially replace the custom BundleTracker with the standard OSGi BundleTracker...although I'm torn on this a little since our custom BundleTracker is simpler and it does provide a good example of how to create such a thing. Please close this issue if you are satisfied. Thanks. > Update extenderbased SimpleShapes example to use Java 5 Features > > > Key: FELIX-3376 > URL: https://issues.apache.org/jira/browse/FELIX-3376 > Project: Felix > Issue Type: Improvement >Reporter: Benedikt Ritter >Priority: Trivial > Attachments: FELIX-3376-extenderbased.circle.txt, > FELIX-3376-extenderbased.host.txt, FELIX-3376-extenderbased.square.txt, > FELIX-3376-extenderbased.triangle.txt > > > This follows up on FELIX-3375. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3376) Update extenderbased SimpleShapes example to use Java 5 Features
[ https://issues.apache.org/jira/browse/FELIX-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224463#comment-13224463 ] Richard S. Hall commented on FELIX-3376: Yeah, don't worry about it. It doesn't matter really. I just noticed that your patches added them, so I removed them. I use NetBeans, I don't think it adds them. Super minor, either way. Tabs, on the other hand, are evil. ;-) > Update extenderbased SimpleShapes example to use Java 5 Features > > > Key: FELIX-3376 > URL: https://issues.apache.org/jira/browse/FELIX-3376 > Project: Felix > Issue Type: Improvement >Reporter: Benedikt Ritter >Priority: Trivial > Attachments: FELIX-3376-extenderbased.circle.txt, > FELIX-3376-extenderbased.host.txt, FELIX-3376-extenderbased.square.txt, > FELIX-3376-extenderbased.triangle.txt > > > This follows up on FELIX-3375. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3375) Update SimpleShapes example to use Java 5 Features
[ https://issues.apache.org/jira/browse/FELIX-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223573#comment-13223573 ] Richard S. Hall commented on FELIX-3375: I've applied these patches with minor modifications. You can probably just close this bug and open another one for more patches. Looking at the host, it should probably also be modified to do it in a non-Felix-specific way, now that R4.2 introduced a launching an embedding API for frameworks. This isn't too difficult, but not completely trivial either. > Update SimpleShapes example to use Java 5 Features > -- > > Key: FELIX-3375 > URL: https://issues.apache.org/jira/browse/FELIX-3375 > Project: Felix > Issue Type: Improvement >Reporter: Benedikt Ritter >Priority: Trivial > Attachments: FELIX-3375-servicebased.circle.txt, > FELIX-3375-servicebased.host.txt, FELIX-3375-servicebased.square.txt, > FELIX-3375-servicebased.trapezoid.txt, FELIX-3375-servicebased.triangle.txt > > > As discussed on the ML (see > http://www.mail-archive.com/dev@felix.apache.org/msg24645.html) the > SimpleShape example should be updated to use Java 5 features. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3375) Update SimpleShapes example to use Java 5 Features
[ https://issues.apache.org/jira/browse/FELIX-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223549#comment-13223549 ] Richard S. Hall commented on FELIX-3375: Just looking, there is a parent pom, although it doesn't appear to be up to date. > Update SimpleShapes example to use Java 5 Features > -- > > Key: FELIX-3375 > URL: https://issues.apache.org/jira/browse/FELIX-3375 > Project: Felix > Issue Type: Improvement >Reporter: Benedikt Ritter >Priority: Trivial > Attachments: FELIX-3375-servicebased.circle.txt, > FELIX-3375-servicebased.host.txt, FELIX-3375-servicebased.square.txt, > FELIX-3375-servicebased.trapezoid.txt, FELIX-3375-servicebased.triangle.txt > > > As discussed on the ML (see > http://www.mail-archive.com/dev@felix.apache.org/msg24645.html) the > SimpleShape example should be updated to use Java 5 features. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3375) Update SimpleShapes example to use Java 5 Features
[ https://issues.apache.org/jira/browse/FELIX-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223546#comment-13223546 ] Richard S. Hall commented on FELIX-3375: A parent pom might make it a little easier to change the settings, but probably not critical...it just becomes another artifact. The patches overall look fine, although we'll want to remove those tab characters. :-) The recommended style is: http://felix.apache.org/site/coding-standards.html I should be able to apply these patches, shortly. > Update SimpleShapes example to use Java 5 Features > -- > > Key: FELIX-3375 > URL: https://issues.apache.org/jira/browse/FELIX-3375 > Project: Felix > Issue Type: Improvement >Reporter: Benedikt Ritter >Priority: Trivial > Attachments: FELIX-3375-servicebased.circle.txt, > FELIX-3375-servicebased.host.txt, FELIX-3375-servicebased.square.txt, > FELIX-3375-servicebased.trapezoid.txt, FELIX-3375-servicebased.triangle.txt > > > As discussed on the ML (see > http://www.mail-archive.com/dev@felix.apache.org/msg24645.html) the > SimpleShape example should be updated to use Java 5 features. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3370) Complex Require-Bundle resolver failure
[
https://issues.apache.org/jira/browse/FELIX-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221116#comment-13221116
]
Richard S. Hall commented on FELIX-3370:
I don't think you were reporting this against framework, but I tried it on
framework and came up with the correct result:
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active |0|System Bundle (4.1.0.SNAPSHOT)
1|Active |1|Apache Felix Bundle Repository (1.6.6)
2|Active |1|Apache Felix Gogo Command (0.12.0)
3|Active |1|Apache Felix Gogo Runtime (0.10.0)
4|Active |1|Apache Felix Gogo Shell (0.10.0)
5|Installed |1|B (0.0.0)
6|Installed |1|C (0.0.0)
7|Installed |1|D (0.0.0)
8|Installed |1|E (0.0.0)
g! resolve 8
DEBUG: Candidate permutation failed due to a conflict between imports; will try
another if possible. (org.apache.felix.framework.resolver.ResolveException:
Uses constraint violation. Unable to resolve bundle revision E [8.0] because it
is exposed to package 'resources' from bundle revisions B [5.0] and C [6.0] via
two dependency chains.
Chain 1:
E [8.0]
import: (osgi.wiring.package=resources)
|
export: osgi.wiring.package=resources
B [5.0]
Chain 2:
E [8.0]
require: (osgi.wiring.bundle=D)
|
provide: [7.0] osgi.wiring.bundle; {osgi.wiring.bundle=D,
bundle-version=0.0.0}
D [7.0]
import: (&(osgi.wiring.package=resources)(bundle-symbolic-name=C))
|
export: osgi.wiring.package=resources
C [6.0])
DEBUG: WIRE: [8.0] osgi.wiring.package; (osgi.wiring.package=resources) -> [6.0]
DEBUG: WIRE: [8.0] osgi.wiring.bundle; (osgi.wiring.bundle=D) -> [7.0]
DEBUG: WIRE: [7.0] osgi.wiring.package;
(&(osgi.wiring.package=resources)(bundle-symbolic-name=C)) -> [6.0]
g!
This shows it saw the conflict and then find the correct solution in the final
wires.
> Complex Require-Bundle resolver failure
> ---
>
> Key: FELIX-3370
> URL: https://issues.apache.org/jira/browse/FELIX-3370
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Thomas Diesler
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> Consider this
> {code}
> // Bundle-SymbolicName: requirebundleB
> // Export-Package: resources
>
> // Bundle-SymbolicName: requirebundleC
> // Export-Package: resources
>
> // Bundle-SymbolicName: requirebundleD
> // Export-Package:
> org.jboss.osgi.test.classloading.export;uses:=resources
> // Import-Package: resources;bundle-symbolic-name=requirebundleC
> // Bundle-SymbolicName: requirebundleE
> // Require-Bundle: requirebundleD
> // Import-Package: resources
> Wiring wiringE = getWiring(env, resourceE);
> assertEquals(0, wiringE.getProvidedResourceWires(null).size());
> assertEquals(1,
> wiringE.getRequiredResourceWires(WIRING_PACKAGE_NAMESPACE).size());
> wire =
> wiringE.getRequiredResourceWires(WIRING_PACKAGE_NAMESPACE).get(0);
> assertEquals(resourceC, wire.getProvider());
> {code}
> The current implementation of the standalone resolver wires E to B
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3370) Complex Require-Bundle resolver failure
[
https://issues.apache.org/jira/browse/FELIX-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221088#comment-13221088
]
Richard S. Hall commented on FELIX-3370:
Yes, in this case, I'd expect to see what you are expecting too. I'll look into
it.
> Complex Require-Bundle resolver failure
> ---
>
> Key: FELIX-3370
> URL: https://issues.apache.org/jira/browse/FELIX-3370
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Thomas Diesler
> Fix For: framework-4.2.0
>
>
> Consider this
> {code}
> // Bundle-SymbolicName: requirebundleB
> // Export-Package: resources
>
> // Bundle-SymbolicName: requirebundleC
> // Export-Package: resources
>
> // Bundle-SymbolicName: requirebundleD
> // Export-Package:
> org.jboss.osgi.test.classloading.export;uses:=resources
> // Import-Package: resources;bundle-symbolic-name=requirebundleC
> // Bundle-SymbolicName: requirebundleE
> // Require-Bundle: requirebundleD
> // Import-Package: resources
> Wiring wiringE = getWiring(env, resourceE);
> assertEquals(0, wiringE.getProvidedResourceWires(null).size());
> assertEquals(1,
> wiringE.getRequiredResourceWires(WIRING_PACKAGE_NAMESPACE).size());
> wire =
> wiringE.getRequiredResourceWires(WIRING_PACKAGE_NAMESPACE).get(0);
> assertEquals(resourceC, wire.getProvider());
> {code}
> The current implementation of the standalone resolver wires E to B
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3370) Complex Require-Bundle resolver failure
[
https://issues.apache.org/jira/browse/FELIX-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220971#comment-13220971
]
Richard S. Hall commented on FELIX-3370:
I see nothing in your description that indicates this is a bug. It is
completely valid to wire E to be.
The priority decisions for candidates are made on a per bundle basis, not on a
global basis. In other words, the best candidate for resource for E is B,
assuming it was installed first, since there is no other version information.
Perhaps you really meant to file an RFE that indicates you wish that candidates
for all requirements were somehow globally optimized in general. Currently,
only "uses" constraints impact multiple-bundle candidate choices. However, I
doubt that implementing some form of further global optimization would not be a
good idea since "uses" constraints already make the algorithm slow and
complicated enough. What you are unknowingly proposing is adding some form of
implicit "uses" constraint where you try to pick the same candidate for
everyone if you can, even though you are not really constrained to do so.
So, unless I'm missing something, this should be closed as "NOT A PROBLEM" or
"WON'T FIX".
> Complex Require-Bundle resolver failure
> ---
>
> Key: FELIX-3370
> URL: https://issues.apache.org/jira/browse/FELIX-3370
> Project: Felix
> Issue Type: Bug
>Reporter: Thomas Diesler
>
> Consider this
> {code}
> // Bundle-SymbolicName: requirebundleB
> // Export-Package: resources
>
> // Bundle-SymbolicName: requirebundleC
> // Export-Package: resources
>
> // Bundle-SymbolicName: requirebundleD
> // Import-Package: resources;bundle-symbolic-name=requirebundleC
> // Bundle-SymbolicName: requirebundleE
> // Require-Bundle: requirebundleD
> // Import-Package: resources
> Wiring wiringE = getWiring(env, resourceE);
> assertEquals(0, wiringE.getProvidedResourceWires(null).size());
> assertEquals(1,
> wiringE.getRequiredResourceWires(WIRING_PACKAGE_NAMESPACE).size());
> wire =
> wiringE.getRequiredResourceWires(WIRING_PACKAGE_NAMESPACE).get(0);
> assertEquals(resourceC, wire.getProvider());
> {code}
> The current implementation of the standalone resolver wires E to B
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3368) Class loading fails on shutdown because zip is unreadable
[ https://issues.apache.org/jira/browse/FELIX-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220030#comment-13220030 ] Richard S. Hall commented on FELIX-3368: When this topic came up before, I think I looked into changing the exception, but it didn't seem easy to do at the time, since the error happens pretty deep down. Feel free to take a look. > Class loading fails on shutdown because zip is unreadable > - > > Key: FELIX-3368 > URL: https://issues.apache.org/jira/browse/FELIX-3368 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-3.2.2 >Reporter: Dustin Schultz > > If a particular module executes a shutdown hook which loads a class at > runtime, it will fail with NoClassDefFound errors because the classloader > will be unable to load the class from the jar. > ERROR: JarContent: Unable to read bytes. (java.lang.IllegalStateException: > zip file closed) > java.lang.IllegalStateException: zip file closed > at java.util.zip.ZipFile.ensureOpen(ZipFile.java:415) > at java.util.zip.ZipFile.getEntry(ZipFile.java:160) > at org.apache.felix.framework.util.ZipFileX.getEntry(ZipFileX.java:52) > at > org.apache.felix.framework.cache.JarContent.getEntryAsBytes(JarContent.java:122) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1816) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727) > at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at > org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache.doDispose(IndexedDiskCache.java:920) > at -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3369) Deadlock on org.apache.felix.framework.BundleWiringImpl
[ https://issues.apache.org/jira/browse/FELIX-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219435#comment-13219435 ] Richard S. Hall commented on FELIX-3369: I don't believe there were any changes in this area in 4.0.2 vs 4.0.1. This sounds like the typical scenario where the JVM is grabbing class loader locks, because the Felix framework doesn't hold onto class loader locks while loading classes. See: http://underlap.blogspot.com/2006_11_01_archive.html Actually, Java 7 introduced a new mechanism for this (i.e., ClassLoader.registerAsParallelCapable()), which the framework can now possibly use to fix this issue on > Java 7. If this is really what is going on here, though, there isn't anything the framework can do about it. If you are on Java 6, you could try the flags in the blog above. > Deadlock on org.apache.felix.framework.BundleWiringImpl > --- > > Key: FELIX-3369 > URL: https://issues.apache.org/jira/browse/FELIX-3369 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 >Reporter: Carlos Quiroz > > After upgrading to Felix 4.0.2 from 3.2.1 one of our legacy bundles started > failing to start > After inspection I found a deadlock on > org.apache.felix.framework.BundleWiringImpl > A downgrade to Felix 4.0.1 fixes this problem so I assume the problem started > in 4.0.2 > Found one Java-level deadlock: > = > "task": > waiting to lock monitor 103072f18 (object 7f4615700, a > org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5), > which is held by "FelixStartLevel" > "FelixStartLevel": > waiting to lock monitor 1030287e0 (object 7f625f8a8, a > org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5), > which is held by "task" > Java stack information for the threads listed above: > === > "task": > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836) > - waiting to lock <7f4615700> (a > org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at > org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317) > at > org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1558) > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1439) > at > org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:247) > at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:357) > at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:163) > at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620) > at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247) > at net.jini.loader.ClassLoading.loadClass(ClassLoading.java:138) > at > net.jini.io.MarshalInputStream.resolveClass(MarshalInputStream.java:296) > at > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) > at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:358) > at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:287) > at com.sun.jini.proxy.MarshalledWrapper.get(MarshalledWrapper.java:127) > at com.sun.jini.reggie.Item.get(Item.java:155) > at com.sun.jini.reggie.Item.toServiceItem(Item.java:191) > at com.sun.jini.reggie.Matches.get(Matches.java:76) > at com.sun.jini.reggie.RegistrarProxy.lookup(RegistrarProxy.java:138) > at > net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl$LookupTask.run(ServiceDiscoveryManager.java:929) > at > net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl$RegisterListenerTask.run(ServiceDiscoveryManager.java:901) > at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331) > "FelixStartLevel": > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836) > - waiting to lock <7
[jira] [Commented] (FELIX-3368) Class loading fails on shutdown because zip is unreadable
[ https://issues.apache.org/jira/browse/FELIX-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219321#comment-13219321 ] Richard S. Hall commented on FELIX-3368: Yes, that is correct. You cannot load classes from a bundle after the framework shuts down. There is bug really duplicates FELIX-2128, so you should check the discussion there. However, I'm still inclined to treat this as a "WON'T FIX". > Class loading fails on shutdown because zip is unreadable > - > > Key: FELIX-3368 > URL: https://issues.apache.org/jira/browse/FELIX-3368 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-3.2.2 >Reporter: Dustin Schultz > > If a particular module executes a shutdown hook which loads a class at > runtime, it will fail with NoClassDefFound errors because the classloader > will be unable to load the class from the jar. > ERROR: JarContent: Unable to read bytes. (java.lang.IllegalStateException: > zip file closed) > java.lang.IllegalStateException: zip file closed > at java.util.zip.ZipFile.ensureOpen(ZipFile.java:415) > at java.util.zip.ZipFile.getEntry(ZipFile.java:160) > at org.apache.felix.framework.util.ZipFileX.getEntry(ZipFileX.java:52) > at > org.apache.felix.framework.cache.JarContent.getEntryAsBytes(JarContent.java:122) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1816) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727) > at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at > org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache.doDispose(IndexedDiskCache.java:920) > at -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2197) Please implement something like Equinox's org.eclipse.osgi.baseadaptor.hooks.ClassLoadingHook
[
https://issues.apache.org/jira/browse/FELIX-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219319#comment-13219319
]
Richard S. Hall commented on FELIX-2197:
I assume we can close this now that we have R4.3 class weaving hooks?
> Please implement something like Equinox's
> org.eclipse.osgi.baseadaptor.hooks.ClassLoadingHook
> -
>
> Key: FELIX-2197
> URL: https://issues.apache.org/jira/browse/FELIX-2197
> Project: Felix
> Issue Type: New Feature
> Components: Framework
>Affects Versions: framework-2.0.4
> Environment: irrelevant
>Reporter: Martin Zdila
> Attachments: framework.patch
>
>
> Please implement something like Equinox's
> org.eclipse.osgi.baseadaptor.hooks.ClassLoadingHook. We need it for running
> Felix under Terracotta (there is HOWTO for Equinox:
> http://www.terracotta.org/confluence/display/wiki/Run+with+Eclipse+Equinox).
> We patched the Felix Framework for the workaround. The patch is attached. We
> use it like this:
> ...
> import org.apache.felix.framework.ClassLoaderHook;
> import org.apache.felix.framework.Felix;
> import com.tc.object.bytecode.hook.impl.ClassProcessorHelper;
> import com.tc.object.loaders.NamedClassLoader;
> ...
> final Properties properties = new Properties();
> ...
> properties.put("classLoaderHook", new ClassLoaderHook() {
> @Override
> public void classLoaderCreared(final ClassLoader classLoader) {
> if (classLoader instanceof NamedClassLoader) {
> ((NamedClassLoader)
> classLoader).__tc_setClassLoaderName(classLoader.toString());
>
> ClassProcessorHelper.registerGlobalLoader((NamedClassLoader) classLoader,
> null);
> }
> }
> });
>
> return new Felix(properties);
> ...
> Thanks in advance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3354) InterruptedException with uninformative message
[ https://issues.apache.org/jira/browse/FELIX-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216770#comment-13216770 ] Richard S. Hall commented on FELIX-3354: Do you have some suggestions for how to handle this? The difficulty is the Gogo thread has no way of knowing why it is being interrupted. For this particular case, I guess it could check the state of the framework and see if it is stopping and not print anything or something. > InterruptedException with uninformative message > --- > > Key: FELIX-3354 > URL: https://issues.apache.org/jira/browse/FELIX-3354 > Project: Felix > Issue Type: Improvement > Components: Gogo Shell >Affects Versions: gogo.shell-0.8.0 >Reporter: Lazar Kirchev >Priority: Minor > > When the OSGi framework, in which the Gogo shell is started, is stopped > before the Gogo shell has finished initializing, the following exception > occurs: > gogo: InterruptedException: sleep interrupted > java.lang.InterruptedException: sleep interrupted > at java.lang.Thread.sleep(Native Method) > at org.apache.felix.gogo.shell.Activator.run(Activator.java:72) > at java.lang.Thread.run(Unknown Source) > gogo.shell calls Thread.sleep(100) to wait for the gosh command to be > registered. The exception occurs when this wait gets interrupted by the > stopping of the framework. > Since the framework is stopping this interruption does not cause any errors, > but the message is not informative and users are getting confused that it is > caused by an error in their code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2363) [Gogo] Add annotations for creating commands with optional and out-of-order arguments
[ https://issues.apache.org/jira/browse/FELIX-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216768#comment-13216768 ] Richard S. Hall commented on FELIX-2363: There isn't any documentation on this, unfortunately, but there should be. This area was sort of in a state of flux and changed in the last version of the RFC, but since then the RFC was shelved (at least for the time being) by the OSGi Alliance. The feeling was that it would be better off to continue just as an open source project at this time. It would be nice to bring the Gogo impl up-to-date with the last changes in the RFC, but currently no one has stepped up to do this. The annotations have changed, but for the most part they are similar to what is current implemented. At this point, if you want to see how it works, the best bet is to check the source of the Gogo Command module. > [Gogo] Add annotations for creating commands with optional and out-of-order > arguments > - > > Key: FELIX-2363 > URL: https://issues.apache.org/jira/browse/FELIX-2363 > Project: Felix > Issue Type: New Feature > Components: Gogo Runtime >Affects Versions: gogo-0.4.0 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: gogo-0.6.0 > > > Gogo should have annotations for command implementations that allow for > optional and out-of-order arguments as well as descriptive information. This > will be beneficial for creating a common "help" system too. > [Technically, this work is basically done. I created this issue so the work > would be documented in the Gogo change log and also because I am going to try > to do a few changes to the existing implementation to align with some > potential future spec changes.] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3348) StartLevel thread may terminate on uncaught exception
[ https://issues.apache.org/jira/browse/FELIX-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207981#comment-13207981 ] Richard S. Hall commented on FELIX-3348: Ok, I committed the second patch too. Please close if satisfied. Thanks. > StartLevel thread may terminate on uncaught exception > - > > Key: FELIX-3348 > URL: https://issues.apache.org/jira/browse/FELIX-3348 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 >Reporter: Felix Meschberger >Assignee: Richard S. Hall > Fix For: framework-4.2.0 > > Attachments: FELIX-3348-2.patch, FELIX-3348.patch > > > It looks like an uncaught exception is able to terminate the StartLevel > thread thus causing the framework to not be properly controllable. > Sample issue: Felix.setActiveStartLevel may throw IllegalStateException if > global lock cannot be acquired. This exception is not caught and causes > StartLevel thread to terminate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3348) StartLevel thread may terminate on uncaught exception
[ https://issues.apache.org/jira/browse/FELIX-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207734#comment-13207734 ] Richard S. Hall commented on FELIX-3348: Good point, I didn't think of that. Ok, I'll take a look again. > StartLevel thread may terminate on uncaught exception > - > > Key: FELIX-3348 > URL: https://issues.apache.org/jira/browse/FELIX-3348 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 >Reporter: Felix Meschberger >Assignee: Richard S. Hall > Fix For: framework-4.2.0 > > Attachments: FELIX-3348-2.patch, FELIX-3348.patch > > > It looks like an uncaught exception is able to terminate the StartLevel > thread thus causing the framework to not be properly controllable. > Sample issue: Felix.setActiveStartLevel may throw IllegalStateException if > global lock cannot be acquired. This exception is not caught and causes > StartLevel thread to terminate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3350) ClassNotFoundException missing bundle information when bundle class loader fails to find class
[ https://issues.apache.org/jira/browse/FELIX-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207385#comment-13207385 ] Richard S. Hall commented on FELIX-3350: The class we are delegating for may be available, but classes it depends on may not, which would then result in an NCDFE. When we catch the NCDFE, we just return null because that will cause a CNFE to be thrown in the caller. We don't catch the CNFE because that is already the exception type we are expecting to throw if we fail, so we just let it pass through. Technically, we could catch either and return null if either occurred, but this assumes that the deeper CNFE never returns useful in formation. > ClassNotFoundException missing bundle information when bundle class loader > fails to find class > -- > > Key: FELIX-3350 > URL: https://issues.apache.org/jira/browse/FELIX-3350 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 >Reporter: David Humeniuk >Priority: Minor > > There is code in BundleWiringImpl, line 1460 that will throw a new > ClassNotFoundException with bundle information. However, I don't see how > this code is reached. A ClassNotFoundException will be thrown by the boot > class loader that is not caught if all other methods fail. See partial stack > trace below: > Caused by: java.lang.ClassNotFoundException: org.datanucleus.identity.OIDImpl > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > at > org.apache.felix.framework.BundleWiringImpl.doImplicitBootDelegation(BundleWiringImpl.java:1666) > at > org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1603) > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1439) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3350) ClassNotFoundException missing bundle information when bundle class loader fails to find class
[ https://issues.apache.org/jira/browse/FELIX-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207268#comment-13207268 ] Richard S. Hall commented on FELIX-3350: It appears your code is getting into implicit boot delegation, which normally shouldn't happen. You'll only get here is the framework thinks that non-bundled code (i.e., code from the application or boot class path) is trying to load a class via a bundle class loader, in which case it delegates to the app class loader. Is a non-bundled class causing this class load? > ClassNotFoundException missing bundle information when bundle class loader > fails to find class > -- > > Key: FELIX-3350 > URL: https://issues.apache.org/jira/browse/FELIX-3350 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 >Reporter: David Humeniuk >Priority: Minor > > There is code in BundleWiringImpl, line 1460 that will throw a new > ClassNotFoundException with bundle information. However, I don't see how > this code is reached. A ClassNotFoundException will be thrown by the boot > class loader that is not caught if all other methods fail. See partial stack > trace below: > Caused by: java.lang.ClassNotFoundException: org.datanucleus.identity.OIDImpl > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > at > org.apache.felix.framework.BundleWiringImpl.doImplicitBootDelegation(BundleWiringImpl.java:1666) > at > org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1603) > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1439) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3309) Dashes in qualifier get replaced by periods causing framework not to start up
[ https://issues.apache.org/jira/browse/FELIX-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189356#comment-13189356 ] Richard S. Hall commented on FELIX-3309: If the framework uses regex then it won't run on ME profiles that don't have those packages. We just need to implement something that does it by hand... > Dashes in qualifier get replaced by periods causing framework not to start up > - > > Key: FELIX-3309 > URL: https://issues.apache.org/jira/browse/FELIX-3309 > Project: Felix > Issue Type: Bug >Affects Versions: framework-3.0.9 >Reporter: Jonathan Anstey > Fix For: framework-4.2.0 > > Attachments: FELIX-3309.patch > > > For a valid OSGi version such as 1.2.3.foo-123, the > org.osgi.framework.Version class was throwing an "invalid format" error: > Could not create framework: java.lang.IllegalArgumentException: invalid format > java.lang.IllegalArgumentException: invalid format > at org.osgi.framework.Version.(Version.java:140) > at > org.apache.felix.framework.ExtensionManager$ExtensionManagerModule.(ExtensionManager.java:628) > at > org.apache.felix.framework.ExtensionManager.(ExtensionManager.java:154) > at org.apache.felix.framework.Felix.(Felix.java:385) > at > org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28) > The cause of this was that in Felix.getFrameworkVersion the '-' character in > the qualifier was getting replaced with a '.' so the version was changed to > 1.2.3.foo.123 which wasn't valid anymore. Attaching a patch shortly that > copies the code from VersionCleaner in the utils project to properly clean up > the incoming version String. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3309) Dashes in qualifier get replaced by periods causing framework not to start up
[ https://issues.apache.org/jira/browse/FELIX-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189232#comment-13189232 ] Richard S. Hall commented on FELIX-3309: I don't believe that we can use regex/pattern if we want to stay compatible with the Java ME profiles. So, we can improve the logic there, but we'll need to resort to cruder mechanisms. > Dashes in qualifier get replaced by periods causing framework not to start up > - > > Key: FELIX-3309 > URL: https://issues.apache.org/jira/browse/FELIX-3309 > Project: Felix > Issue Type: Bug >Affects Versions: framework-3.0.9 >Reporter: Jonathan Anstey > Fix For: framework-4.2.0 > > Attachments: FELIX-3309.patch > > > For a valid OSGi version such as 1.2.3.foo-123, the > org.osgi.framework.Version class was throwing an "invalid format" error: > Could not create framework: java.lang.IllegalArgumentException: invalid format > java.lang.IllegalArgumentException: invalid format > at org.osgi.framework.Version.(Version.java:140) > at > org.apache.felix.framework.ExtensionManager$ExtensionManagerModule.(ExtensionManager.java:628) > at > org.apache.felix.framework.ExtensionManager.(ExtensionManager.java:154) > at org.apache.felix.framework.Felix.(Felix.java:385) > at > org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28) > The cause of this was that in Felix.getFrameworkVersion the '-' character in > the qualifier was getting replaced with a '.' so the version was changed to > 1.2.3.foo.123 which wasn't valid anymore. Attaching a patch shortly that > copies the code from VersionCleaner in the utils project to properly clean up > the incoming version String. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3306) Lazy activation of bundles is not always working as expected
[
https://issues.apache.org/jira/browse/FELIX-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187179#comment-13187179
]
Richard S. Hall commented on FELIX-3306:
I've committed a potential fix to trunk. It works for me on your example
bundles. Let me know if it works for you.
However, currently the code does not continue activating deferred bundles if
there is an exception while activating the deferred bundles. Perhaps this
should catch all exceptions and continue to activate the other bundles in the
deferred list.
I'll keep this bug open until I address this aspect.
> Lazy activation of bundles is not always working as expected
>
>
> Key: FELIX-3306
> URL: https://issues.apache.org/jira/browse/FELIX-3306
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Bogdan Stefanescu
>Assignee: Richard S. Hall
> Fix For: framework-4.2.0
>
> Attachments: bundle1_1.0.0.201201161439.jar,
> bundle2_1.0.0.201201161439.jar, bundle3_1.0.0.201201161439.jar
>
>
> When loading a class from a "lazy" bundle (e.g. Bundle-ActivationPolicy:
> lazy) the bundle is not always activated.
> More precisely, when a bundle is triggering the activation of a chain of more
> than one lazy bundle (due to a class loading) not all the bundles in the
> chain are activated.
> Example:
> Let say we have 3 bundles: bundle1, bundle2 and bundle3. All those bundles
> are defining a lazy activation via: 'Bundle-ActivationPolicy: lazy'.
> In the activator of bundle1 we load a class from bundle2. In activator of
> bundle2 we load a class from bundle3.
> By starting (from the felix command line) the bundle1 - only the bundle2 will
> be activated even if the class from bundle3 is successfully loaded by the
> activator of bundle2.
> You can find attached 3 bundles you can use to reproduce the bug. (they also
> contains the source code)
> To reproduce the bug:
> Install a felix 4.0.2 (or 4.2.0-SNAPSHOT) and add the plugin
> "org.apache.felix.fileinstall"
> Configure the fileinstall plugin to load the bundles located inside the
> directory ./plugins:
> felix.fileinstall.dir=./plugins
> and put there the 3 bundles attached to the issue.
> After starting Felix by typing "lb -s" I have:
> {noformat}
> START LEVEL 1
>ID|State |Level|Symbolic name
> 0|Active |0|org.apache.felix.framework (4.0.2)
> 1|Active |1|org.apache.felix.bundlerepository (1.6.6)
> 2|Active |1|org.apache.felix.fileinstall (3.1.10)
> 3|Active |1|org.apache.felix.gogo.command (0.12.0)
> 4|Active |1|org.apache.felix.gogo.runtime (0.10.0)
> 5|Active |1|org.apache.felix.gogo.shell (0.10.0)
> 6|Starting |1|bundle3 (1.0.0.201201161439)
> 7|Starting |1|bundle1 (1.0.0.201201161439)
> 8|Starting |1|bundle2 (1.0.0.201201161439)
> {noformat}
> which is OK since the 3 bundles are declared as "lazy" so they will enter the
> STARTING state.
> Now start the bundle1 by typing "start 7". I have the following output:
> {noformat}
> >>> Bundle3Object loaded
> Sarted bundle: bundle2
> >>> Bundle2Object loaded
> Started Bundle: bundle1
> {noformat}
> and typing again "lb -s" I have:
> {noformat}
> START LEVEL 1
>ID|State |Level|Symbolic name
> 0|Active |0|org.apache.felix.framework (4.0.2)
> 1|Active |1|org.apache.felix.bundlerepository (1.6.6)
> 2|Active |1|org.apache.felix.fileinstall (3.1.10)
> 3|Active |1|org.apache.felix.gogo.command (0.12.0)
> 4|Active |1|org.apache.felix.gogo.runtime (0.10.0)
> 5|Active |1|org.apache.felix.gogo.shell (0.10.0)
> 6|Starting |1|bundle3 (1.0.0.201201161439)
> 7|Active |1|bundle1 (1.0.0.201201161439)
> 8|Active |1|bundle2 (1.0.0.201201161439)
> {noformat}
> Which is NOT OK, since the bundle2 is loading a class 'Bundle3Object' from
> bundle3 in the activator - the bundle3 must be activated too but it is not.
> You can see in the log made by bundle2 that Bundle3Object is correctly loaded
> (but the bundle3 not activated).
> (You can see the bundle2 was correctly activated by bundle1 by loading a
> class from bundle2 but the bundle3 is not activated when bundle2 is loading a
> class from bundle3)
> The fileinstall plugin seems to work correctly. I think the problem is in
> BundleWiringImpl$BundleClassLoader.findClass()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3306) Lazy activation of bundles is not always working as expected
[
https://issues.apache.org/jira/browse/FELIX-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187162#comment-13187162
]
Richard S. Hall commented on FELIX-3306:
I think I see the issue. The lazy activation code works properly if it is
triggered by class loads caused during the defineClass() operation, but not if
the class loads occur when a lazy bundle is being activated as a result of a
trigger (i.e., in the lazy bundle's start() method). This latter case is
demonstrated by your example bundles.
The code doesn't expect the deferred list to grow during the activation of lazy
bundles, so the lazy bundles added due to class loads during activation are
effectively ignored. The code should be changed so that it grabs the deferred
list first and inserts an empty deferred list back into the thread local before
starting to activate. That way any subsequent class loads triggering lazy
activation in the start() method will be handled in a similar fashion as any
other class load triggering lazy activation.
> Lazy activation of bundles is not always working as expected
>
>
> Key: FELIX-3306
> URL: https://issues.apache.org/jira/browse/FELIX-3306
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Bogdan Stefanescu
>Assignee: Richard S. Hall
> Fix For: framework-4.2.0
>
> Attachments: bundle1_1.0.0.201201161439.jar,
> bundle2_1.0.0.201201161439.jar, bundle3_1.0.0.201201161439.jar
>
>
> When loading a class from a "lazy" bundle (e.g. Bundle-ActivationPolicy:
> lazy) the bundle is not always activated.
> More precisely, when a bundle is triggering the activation of a chain of more
> than one lazy bundle (due to a class loading) not all the bundles in the
> chain are activated.
> Example:
> Let say we have 3 bundles: bundle1, bundle2 and bundle3. All those bundles
> are defining a lazy activation via: 'Bundle-ActivationPolicy: lazy'.
> In the activator of bundle1 we load a class from bundle2. In activator of
> bundle2 we load a class from bundle3.
> By starting (from the felix command line) the bundle1 - only the bundle2 will
> be activated even if the class from bundle3 is successfully loaded by the
> activator of bundle2.
> You can find attached 3 bundles you can use to reproduce the bug. (they also
> contains the source code)
> To reproduce the bug:
> Install a felix 4.0.2 (or 4.2.0-SNAPSHOT) and add the plugin
> "org.apache.felix.fileinstall"
> Configure the fileinstall plugin to load the bundles located inside the
> directory ./plugins:
> felix.fileinstall.dir=./plugins
> and put there the 3 bundles attached to the issue.
> After starting Felix by typing "lb -s" I have:
> {noformat}
> START LEVEL 1
>ID|State |Level|Symbolic name
> 0|Active |0|org.apache.felix.framework (4.0.2)
> 1|Active |1|org.apache.felix.bundlerepository (1.6.6)
> 2|Active |1|org.apache.felix.fileinstall (3.1.10)
> 3|Active |1|org.apache.felix.gogo.command (0.12.0)
> 4|Active |1|org.apache.felix.gogo.runtime (0.10.0)
> 5|Active |1|org.apache.felix.gogo.shell (0.10.0)
> 6|Starting |1|bundle3 (1.0.0.201201161439)
> 7|Starting |1|bundle1 (1.0.0.201201161439)
> 8|Starting |1|bundle2 (1.0.0.201201161439)
> {noformat}
> which is OK since the 3 bundles are declared as "lazy" so they will enter the
> STARTING state.
> Now start the bundle1 by typing "start 7". I have the following output:
> {noformat}
> >>> Bundle3Object loaded
> Sarted bundle: bundle2
> >>> Bundle2Object loaded
> Started Bundle: bundle1
> {noformat}
> and typing again "lb -s" I have:
> {noformat}
> START LEVEL 1
>ID|State |Level|Symbolic name
> 0|Active |0|org.apache.felix.framework (4.0.2)
> 1|Active |1|org.apache.felix.bundlerepository (1.6.6)
> 2|Active |1|org.apache.felix.fileinstall (3.1.10)
> 3|Active |1|org.apache.felix.gogo.command (0.12.0)
> 4|Active |1|org.apache.felix.gogo.runtime (0.10.0)
> 5|Active |1|org.apache.felix.gogo.shell (0.10.0)
> 6|Starting |1|bundle3 (1.0.0.201201161439)
> 7|Active |1|bundle1 (1.0.0.201201161439)
> 8|Active |1|bundle2 (1.0.0.201201161439)
> {noformat}
> Which is NOT OK, since the bundle2 is loading a class 'Bundle3Object' from
> bundle3 in the activator - the bundle3 must be activated too but it is not.
> You can see in the log made by bundle2 that Bundle3Object is correctly loaded
> (but the bundle3 not activated).
> (You can see the bundle2 was correctly activated by bundle1 by loading a
> class from bundle2 but the bundle3 is not activated when bundle2 is loading
[jira] [Commented] (FELIX-3273) Possible exception when accessing headers
[
https://issues.apache.org/jira/browse/FELIX-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170235#comment-13170235
]
Richard S. Hall commented on FELIX-3273:
Looking at the source for BundleImpl.uninstall(), it does populate with the
default locale as described in the long comment. Unless there is some bug in
the logic, it looks like it should be happening. If this is repeatable, perhaps
you can set a breakpoint in the uninstall() and see if it does get populated or
not. Issue FELIX-2840 seems potentially related.
> Possible exception when accessing headers
> -
>
> Key: FELIX-3273
> URL: https://issues.apache.org/jira/browse/FELIX-3273
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-3.0.9
>Reporter: Guillaume Nodet
> Fix For: framework-4.2.0
>
>
> {code}
> ERROR: Bundle org.ops4j.pax.logging.pax-logging-service [3] EventDispatcher:
> Error during dispatch. (java.util.NoSuchElementException)
> java.util.NoSuchElementException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:796)
> at java.util.HashMap$ValueIterator.next(HashMap.java:822)
> at
> org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:334)
> at org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1428)
> at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:311)
> at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:293)
> at
> org.ops4j.pax.logging.service.internal.PaxLoggerImpl.setDelegateContext(PaxLoggerImpl.java:101)
> at
> org.ops4j.pax.logging.service.internal.PaxLoggerImpl.debug(PaxLoggerImpl.java:131)
> at
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.log(PaxLoggingServiceImpl.java:149)
> at
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.log(PaxLoggingServiceImpl.java:115)
> at
> org.ops4j.pax.logging.service.internal.FrameworkHandler.bundleChanged(FrameworkHandler.java:93)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)
> at
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:949)
> at
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54)
> at
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:106)
> at java.lang.Thread.run(Thread.java:680)
> {code}
> The problem happened on 3.0.9 but looking at the getLocalizedHeaders method,
> nothing has changed so the bug should still be valid for 4.0.x
> I suppose the problem is in the BundleImpl#uninstall method which may clear
> the cached headers without populating with the default.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3267) Unable to resolve cause wired to two revisions of same bundle
[
https://issues.apache.org/jira/browse/FELIX-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168524#comment-13168524
]
Richard S. Hall commented on FELIX-3267:
Try setting the felix.log.level property in conf/config.properties to 4, which
will also print out intermediate resolver errors and post those back here if
they are different than the above error.
This will likely be difficult to determine what's going on if there is no way
to reproduce.
> Unable to resolve cause wired to two revisions of same bundle
> -
>
> Key: FELIX-3267
> URL: https://issues.apache.org/jira/browse/FELIX-3267
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
> Environment: Felix Framework 4.0.2
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.7.0_01
> Java home: c:\Program Files\Java\jdk1.7.0_01\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Bram de Kruijff
> Attachments: jaxrs-exporter-MANIFEST.MF, jaxrs-importer-MANIFEST.MF
>
>
> Ran into the issue below where the resolver fails to resolve (or at least
> choose) from two revisions of javax.ws.rs from the same exporting bundle. I
> can not readily reproduce it, but the message clearly show it happened.
> Quickly talked it over with Karl and decided to log the issue here:
> Two things to note are:
> 1) The bundles get updates (during) framework startup from fileinstall (maybe
> some kind of race condition).
> 2) The bundle exporting the packages has a cyclic package thing going on
> (attached manifests)
> {quote}
> org.osgi.framework.BundleException: Uses constraint violation. Unable
> to resolve bundle revision org.amdatu.web.rest.wink [21.1] because it
> is exposed to package 'javax.ws.rs' from bundle revisions
> org.amdatu.web.rest.jaxrs [18.1] and org.amdatu.web.rest.jaxrs [18.0]
> via two dependency chains.
> Chain 1:
> org.amdatu.web.rest.wink [21.1]
>import:
> (&(osgi.wiring.package=javax.ws.rs)(version>=1.1.0)(!(version>=2.0.0)))
> |
>export: osgi.wiring.package=javax.ws.rs
> org.amdatu.web.rest.jaxrs [18.1]
> Chain 2:
> org.amdatu.web.rest.wink [21.1]
>import:
> (&(osgi.wiring.package=javax.ws.rs.ext)(version>=1.1.0)(!(version>=2.0.0)))
> |
>export: osgi.wiring.package=javax.ws.rs.ext; uses:=javax.ws.rs
>export: osgi.wiring.package=javax.ws.rs
> org.amdatu.web.rest.jaxrs [18.0]
> -> refresh
> {quote}
> http://www.mail-archive.com/users@felix.apache.org/msg11524.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3263) NPE in calculateExportedPackages
[ https://issues.apache.org/jira/browse/FELIX-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166818#comment-13166818 ] Richard S. Hall commented on FELIX-3263: FELIX-2741 refers to an older version, but the fix was released in 3.2.0, which is a newer version than you reported against (3.0.9). Further, 4.0.0 saw major refactoring, so while it is possible that 3.2.0 fixed your issue, who knows what will happen in 4.0.x. Please let us know. Thanks. > NPE in calculateExportedPackages > > > Key: FELIX-3263 > URL: https://issues.apache.org/jira/browse/FELIX-3263 > Project: Felix > Issue Type: Bug >Affects Versions: framework-3.0.9 >Reporter: Ioannis Canellos >Priority: Trivial > > I've created a Karaf feature that gives me this error: > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.calculateExportedPackages(ResolverImpl.java:1212)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:594)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:601)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:90)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4033)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.Felix.resolveBundle(Felix.java:3439)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.Felix.startBundle(Felix.java:1734)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:918)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:350)[27:org.apache.karaf.features.core:2.2.4] > at > org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:280)[27:org.apache.karaf.features.core:2.2.4] > at > org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:276)[27:org.apache.karaf.features.core:2.2.4] > at > org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:62)[22:org.apache.karaf.features.command:2.2.4] > at > org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[22:org.apache.karaf.features.command:2.2.4] > at > org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.karaf.shell.console.jline.Console.run(Console.java:218)[23:org.apache.karaf.shell.console:2.2.4] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3263) NPE in calculateExportedPackages
[ https://issues.apache.org/jira/browse/FELIX-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165827#comment-13165827 ] Richard S. Hall commented on FELIX-3263: Perhaps this is a duplicate of FELIX-2741 ? Please try to recreate on the latest framework release, thanks. > NPE in calculateExportedPackages > > > Key: FELIX-3263 > URL: https://issues.apache.org/jira/browse/FELIX-3263 > Project: Felix > Issue Type: Bug >Affects Versions: framework-3.0.9 >Reporter: Ioannis Canellos > > I've created a Karaf feature that gives me this error: > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.calculateExportedPackages(ResolverImpl.java:1212)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:594)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:601)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:90)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4033)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.Felix.resolveBundle(Felix.java:3439)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.Felix.startBundle(Felix.java:1734)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:918)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.9.jar:] > at > org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:350)[27:org.apache.karaf.features.core:2.2.4] > at > org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:280)[27:org.apache.karaf.features.core:2.2.4] > at > org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:276)[27:org.apache.karaf.features.core:2.2.4] > at > org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:62)[22:org.apache.karaf.features.command:2.2.4] > at > org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[22:org.apache.karaf.features.command:2.2.4] > at > org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)[23:org.apache.karaf.shell.console:2.2.4] > at > org.apache.karaf.shell.console.jline.Console.run(Console.java:218)[23:org.apache.karaf.shell.console:2.2.4] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3260) Felix bundle repository translates filter incorrectly if the filter contains
[ https://issues.apache.org/jira/browse/FELIX-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164126#comment-13164126 ] Richard S. Hall commented on FELIX-3260: Perhaps it is an error in your issue description, but in your repo filter example: (&(package=com.obr.bundle112)(version>=1.2.0.999)(version<3.2.2.bz)(company=moon)(location=uk) Isn't it missing an parentheses at the end? > Felix bundle repository translates filter incorrectly if the filter contains < > -- > > Key: FELIX-3260 > URL: https://issues.apache.org/jira/browse/FELIX-3260 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-1.6.4 >Reporter: Emily Jiang >Priority: Minor > > When I specify the follow filter in my repository.xml, > (&(package=com.obr.bundle112)(version>=1.2.0.999)(version<3.2.2.bz)(company=moon)(location=uk), > during the runtime, the filter was translated to: > (&(package=com.obr.bundle112)(version>=1.2.0.999)(&(version<=3.2.2.bz) > (!(version<=3.2.2.bz) (company=moon)(location=uk))) > instead of > (&(package=com.obr.bundle112)(version>=1.2.0.999)(&(version<=3.2.2.bz) >(!(version=3.2.2.bz)) (company=moon)(location=uk)) > As you can see, the closing bracket for (!(version=3.2.2.bz) did not close in > the right place. It closes at the end. > This leads to LDAP exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162641#comment-13162641
]
Richard S. Hall commented on FELIX-3160:
Leave it open for now. I'll close it once I'm certain. Thanks for verifying the
fix.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
> Attachments: Activator.java, Felix3160.zip
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3242) Concurrent modification problem in StatefulResolver$ResolverStateImpl.getCandidates
[ https://issues.apache.org/jira/browse/FELIX-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162274#comment-13162274 ] Richard S. Hall commented on FELIX-3242: I see what is going on here, but I'm not sure the best way to resolve it yet. Basically, the current approach for implementing the R4.3 resolver hooks caches them at the beginning of a resolve operation and assumes that they are only accessed while holding the global lock, but this isn't true. They are also accessed in getCandidates() when trying to determine if a bundle should attempt a dynamic import, which purposely doesn't acquire the global lock to avoid lock contention for dynamic imports. I'll need to think about this some more. > Concurrent modification problem in > StatefulResolver$ResolverStateImpl.getCandidates > --- > > Key: FELIX-3242 > URL: https://issues.apache.org/jira/browse/FELIX-3242 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.1 >Reporter: David Jencks > Fix For: framework-4.2.0 > > > I occasionally see this stack trace (2 examples) starting stuff in karaf > running on felix 4.0.1 Unfortunately it happens rarely and with no pattern I > can discern. > [Blueprint Extender: 3] ERROR > org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener > - Error calling listener method public synchronized void > org.apache.karaf.shell.console.jline.ConsoleFactory.registerCommandProcessor(org.apache.felix.service.command.CommandProcessor) > throws java.lang.Exception > java.lang.reflect.InvocationTargetException >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:597) >at > org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:238) >at > org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.invokeMethods(AbstractServiceReferenceRecipe.java:460) >at > org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.bind(AbstractServiceReferenceRecipe.java:442) >at > org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.bind(AbstractServiceReferenceRecipe.java:339) >at > org.apache.aries.blueprint.container.ReferenceRecipe.bind(ReferenceRecipe.java:149) >at > org.apache.aries.blueprint.container.ReferenceRecipe.retrack(ReferenceRecipe.java:114) >at > org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.updateListeners(AbstractServiceReferenceRecipe.java:331) >at > org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:93) >at > org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:71) >at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >at java.util.concurrent.FutureTask.run(FutureTask.java:138) >at > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:79) >at > org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:220) >at > org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:154) >at > org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:630) >at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:326) >at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:228) >at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) >at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >at java.util.concurrent.FutureTask.run(FutureTask.java:138) >at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) >at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) >at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >at java.lang.Thread.run(Thread.java:680) > Caused by: java.util.ConcurrentModificationException >at > jav
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162064#comment-13162064
]
Richard S. Hall commented on FELIX-3160:
I've committed a patch that turns such an occurrence into a no-op, assuming for
now that this is the right thing to do. Please check that the trunk framework
fixes the issue for you. Thanks for your help.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
> Attachments: Activator.java, Felix3160.zip
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162062#comment-13162062
]
Richard S. Hall commented on FELIX-3160:
I was able to recreate and I've determined what is happening.
Basically, the framework auto-refreshes the bundle when you do an uninstall
(since no one depends on it), then your worker explicitly refreshes the
uninstalled bundle once it receives the UNINSTALLED event, but at this time the
bundle has already been refreshed and is now stale. That's why the content is
already null, since we end up refreshing a stale bundle.
During the refactoring for the the R4.3 API, we must have lost a check
somewhere that avoided this situation. I believe the proper thing to do here is
to just ignore stale bundles when refreshing. I'll investigate whether this is
the correct behavior and, if so, will implement a fix.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
> Attachments: Activator.java, Felix3160.zip
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161509#comment-13161509
]
Richard S. Hall commented on FELIX-3160:
Good news, thanks for figuring it out.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
> Attachments: Activator.java
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2950) [Framework] Adopt OSGi R4.3 API as framework internal API
[ https://issues.apache.org/jira/browse/FELIX-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159119#comment-13159119 ] Richard S. Hall commented on FELIX-2950: I should add, Service Tracker will be moved to the core OSGi JAR in the next spec release to avoid such an issue in the future. > [Framework] Adopt OSGi R4.3 API as framework internal API > - > > Key: FELIX-2950 > URL: https://issues.apache.org/jira/browse/FELIX-2950 > Project: Felix > Issue Type: Improvement > Components: Framework, Specification compliance >Affects Versions: framework-3.2.2 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: framework-4.0.0 > > > The R4.3 specification introduces more detailed API modeling bundle revisions > and wiring. Rather than just facading our existing abstractions for these > concepts, we should modify the framework implementation to adopt them > wholesale (i.e., replace our existing abstractions with the spec'ed > abstractions). Although the standard abstractions do not map one-to-one with > our existing abstractions, they are reasonably close and the benefit of > having an implementation that is consistent with the standard API probably > outweighs the cost of changing, since very few people actually depend on our > internal API. > This issue will only be used for this internal refactoring process and > generally will not be used as the issue for implementing new R4.3 > functionality. We'll try to introduce separate issues for new any new > functionality to make the change log more meaningful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2950) [Framework] Adopt OSGi R4.3 API as framework internal API
[ https://issues.apache.org/jira/browse/FELIX-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159118#comment-13159118 ] Richard S. Hall commented on FELIX-2950: No, there isn't, I don't believe. > [Framework] Adopt OSGi R4.3 API as framework internal API > - > > Key: FELIX-2950 > URL: https://issues.apache.org/jira/browse/FELIX-2950 > Project: Felix > Issue Type: Improvement > Components: Framework, Specification compliance >Affects Versions: framework-3.2.2 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: framework-4.0.0 > > > The R4.3 specification introduces more detailed API modeling bundle revisions > and wiring. Rather than just facading our existing abstractions for these > concepts, we should modify the framework implementation to adopt them > wholesale (i.e., replace our existing abstractions with the spec'ed > abstractions). Although the standard abstractions do not map one-to-one with > our existing abstractions, they are reasonably close and the benefit of > having an implementation that is consistent with the standard API probably > outweighs the cost of changing, since very few people actually depend on our > internal API. > This issue will only be used for this internal refactoring process and > generally will not be used as the issue for implementing new R4.3 > functionality. We'll try to introduce separate issues for new any new > functionality to make the change log more meaningful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3246) [Framework] Use OBR Resolver API in standalone resolver module
[ https://issues.apache.org/jira/browse/FELIX-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159116#comment-13159116 ] Richard S. Hall commented on FELIX-3246: I've already done this in my sandbox area: http://svn.apache.org/repos/asf/felix/sandbox/rickhall/obr-resolver > [Framework] Use OBR Resolver API in standalone resolver module > -- > > Key: FELIX-3246 > URL: https://issues.apache.org/jira/browse/FELIX-3246 > Project: Felix > Issue Type: Task > Components: Framework >Reporter: Thomas Diesler > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3240) Resolving fragments that import their host packages can't be resolved anymore
[ https://issues.apache.org/jira/browse/FELIX-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155876#comment-13155876 ] Richard S. Hall commented on FELIX-3240: Hard to say for sure, since this issue has no detailed description, but did you check this against 4.0.2? We fixed a bug where resolved fragments weren't being handled correctly. Not sure if it is related, but it could be. > Resolving fragments that import their host packages can't be resolved anymore > - > > Key: FELIX-3240 > URL: https://issues.apache.org/jira/browse/FELIX-3240 > Project: Felix > Issue Type: Bug >Affects Versions: framework-4.0.1 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Blocker > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153859#comment-13153859
]
Richard S. Hall commented on FELIX-3160:
Rob, I've reverted the patch for now, since it covers up the real issue. I'd
rather have people suffer the exception so we might find the real solution
quicker. You can always reapply the workaround after the 4.0.2 release or
locally if you want. Otherwise, continue to help me reproduce it so I can fix
it. Thanks.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
> Attachments: Activator.java
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3178) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153169#comment-13153169 ] Richard S. Hall commented on FELIX-3178: Ok, I've gotten to the bottom of this second issue. It is actually completely unrelated to the first issue, so technically we could open another bug on it, but it's probably not necessary. This second issue has existed for a while, I believe. Essentially, candidates for bundle revisions are populated in a recursive fashion. The approach must allow for cycles and does this by essentially picking up where it left off on a given revision when it tries to populate a revision that it is already populating. With this approach, it is possible that a given revision can fail at a deeper level in the recursion stack than where it started. However, there were certain scenarios where this would go unnoticed at the higher level because resolve failures do not necessarily get thrown to the top immediately. To remedy this, after returning from a deeper recursion level, the algorithm must double check to make sure that the revision it is resolving didn't already fail in a deeper level. > NPE in ResolverImpl > --- > > Key: FELIX-3178 > URL: https://issues.apache.org/jira/browse/FELIX-3178 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 > Environment: Also reproduced on 4.0.1 >Reporter: Andreas Schlosser >Assignee: Richard S. Hall >Priority: Blocker > Fix For: framework-4.2.0 > > Attachments: MANIFEST.MF, npe.z01, npe.z02, npe.zip, npe2.z01, > npe2.z02, npe2.z03, npe2.z04, npe2.zip > > > Bundle Resolution fails with NPE in both, Felix 4.0.0 and 4.0.1 > ERROR: Bundle com.springsource.com.sun.tools.xjc [119] Error starting > file:bundles/com.springsource.com.sun.tools.xjc.jar > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:856) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:659) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:609) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:181) > at > org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3811) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149247#comment-13149247
]
Richard S. Hall commented on FELIX-3160:
Well, I was hopeful. I recreated the scenario as faithfully as I could, but it
still works properly for me (and I remembered to comment out the null check).
Not sure what is going on. Maybe it is related to platform. To rule everything
else out, could you create a self-contained zip of the exact scenario that can
reproduce the situation for you and attach it here? Then I will try to use that
exactly and see what I see.
If that doesn't work, then we'll have to make sure we are testing on the same
platform (I'm on a Mac using Java 6) and go from there.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
> Attachments: Activator.java
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3202) Add generic type information to SimpleFilter
[ https://issues.apache.org/jira/browse/FELIX-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149223#comment-13149223 ] Richard S. Hall commented on FELIX-3202: Not sure I understand your (2) issue. Are you saying that the current implement assumes that the attribute to be indexed is always the same time? If so, then yes, that is probably true. In theory, though, probably not 100% correct. Even then, there is a slight exception to this already, since it allows the value to be a list type of the same type too. > Add generic type information to SimpleFilter > > > Key: FELIX-3202 > URL: https://issues.apache.org/jira/browse/FELIX-3202 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Lucas Galfaso >Priority: Minor > Attachments: felix_java5_filter.diff > > > SimpleFilter does not have Java 5 generic type information and it is very > hard to add this to the current implementation. > Devise a way to add generate type information to SimpleFilter while keeping > in mind that this is a critical component and any performance degradation > would slow down the entire framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3178) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148376#comment-13148376 ] Richard S. Hall commented on FELIX-3178: Is this something I can easily recreate with the attached zip again or do I need something else? > NPE in ResolverImpl > --- > > Key: FELIX-3178 > URL: https://issues.apache.org/jira/browse/FELIX-3178 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 > Environment: Also reproduced on 4.0.1 >Reporter: Andreas Schlosser >Assignee: Richard S. Hall >Priority: Blocker > Fix For: framework-4.2.0 > > Attachments: MANIFEST.MF, npe.z01, npe.z02, npe.zip > > > Bundle Resolution fails with NPE in both, Felix 4.0.0 and 4.0.1 > ERROR: Bundle com.springsource.com.sun.tools.xjc [119] Error starting > file:bundles/com.springsource.com.sun.tools.xjc.jar > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:856) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:659) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:609) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:181) > at > org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3811) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148334#comment-13148334
]
Richard S. Hall commented on FELIX-3160:
Rob, I'm still waiting on you to help me recreate this situation...
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3178) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148237#comment-13148237 ] Richard S. Hall commented on FELIX-3178: Great. We'll start a 4.0.2 release pretty soon. > NPE in ResolverImpl > --- > > Key: FELIX-3178 > URL: https://issues.apache.org/jira/browse/FELIX-3178 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 > Environment: Also reproduced on 4.0.1 >Reporter: Andreas Schlosser >Priority: Blocker > Fix For: framework-4.2.0 > > Attachments: MANIFEST.MF, npe.z01, npe.z02, npe.zip > > > Bundle Resolution fails with NPE in both, Felix 4.0.0 and 4.0.1 > ERROR: Bundle com.springsource.com.sun.tools.xjc [119] Error starting > file:bundles/com.springsource.com.sun.tools.xjc.jar > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:856) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:659) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:609) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:181) > at > org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3811) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3202) Add generic type information to SimpleFilter
[ https://issues.apache.org/jira/browse/FELIX-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148236#comment-13148236 ] Richard S. Hall commented on FELIX-3202: Keep in mind that the indexed case is the normal case for just about all use cases. It is how the resolver works and how the service registry works. Calling Filter.match() is not common, so its performance is less critical. Still, if we can improve it, then good. Internally, I tried to use the same code to do the match in either case to avoid duplication of code and the bugs that result, so this is likely why the matching in the single matching case in the current implementation is slower since it is more generic (and thus more complicated) than it needs to be for single matching. Still, the thing to remember is that single matching is much less important than the indexed case. > Add generic type information to SimpleFilter > > > Key: FELIX-3202 > URL: https://issues.apache.org/jira/browse/FELIX-3202 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Lucas Galfaso >Priority: Minor > Attachments: felix_java5_filter.diff > > > SimpleFilter does not have Java 5 generic type information and it is very > hard to add this to the current implementation. > Devise a way to add generate type information to SimpleFilter while keeping > in mind that this is a critical component and any performance degradation > would slow down the entire framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3202) Add generic type information to SimpleFilter
[ https://issues.apache.org/jira/browse/FELIX-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148159#comment-13148159 ] Richard S. Hall commented on FELIX-3202: If I were you, I'd start with what is there and try to improve it. > Add generic type information to SimpleFilter > > > Key: FELIX-3202 > URL: https://issues.apache.org/jira/browse/FELIX-3202 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Lucas Galfaso >Priority: Minor > Attachments: felix_java5_filter.diff > > > SimpleFilter does not have Java 5 generic type information and it is very > hard to add this to the current implementation. > Devise a way to add generate type information to SimpleFilter while keeping > in mind that this is a critical component and any performance degradation > would slow down the entire framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3178) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146113#comment-13146113 ] Richard S. Hall commented on FELIX-3178: I've committed a patch for this and deployed snapshots. Please let me know if it is working for you, thanks. I'm not completely happy with the patch, so I may make improvements if I can think of any. > NPE in ResolverImpl > --- > > Key: FELIX-3178 > URL: https://issues.apache.org/jira/browse/FELIX-3178 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 > Environment: Also reproduced on 4.0.1 >Reporter: Andreas Schlosser >Priority: Blocker > Fix For: framework-4.2.0 > > Attachments: MANIFEST.MF, npe.z01, npe.z02, npe.zip > > > Bundle Resolution fails with NPE in both, Felix 4.0.0 and 4.0.1 > ERROR: Bundle com.springsource.com.sun.tools.xjc [119] Error starting > file:bundles/com.springsource.com.sun.tools.xjc.jar > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:856) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:659) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:609) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:181) > at > org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3811) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3202) Add generic type information to SimpleFilter
[ https://issues.apache.org/jira/browse/FELIX-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146070#comment-13146070 ] Richard S. Hall commented on FELIX-3202: (3) Java basically encourages people to create classes all over the place for listeners, tasks, etc. At the .java these classes are hidden and appear cost free since they are in the same source file, but once compiled (as you probably know) they are expanded out into tons of separate classes, resulting into major class loading storms when starting an application. Granted, the framework has already grown beyond what I am happy with since the spec continues to bloat, but I still worry about these issues. The framework is intended to run on everything from small devices to servers, so everything benefits if we can keep it tight. I'd be happier with patches that removed large pieces of unnecessary junk to make it smaller, rather than adding tons of stuff to make it more readable. Clearly, this is a losing battle over time (if not lost already) and there is tension because sometimes abstractions are useful even though they may bloat the implementation. It's a balancing act and there is no clear right or wrong answer, it just depends. (4) I believe the numbers you are seeing, I questioned whether you were comparing your matching against SimpleFilter matching with indexing in CapabilitySet or with just straight matching. Looking at the patch, I see that indices don't really come into play. Still, if there are improvements that can be made to how matching is currently performed in the non-indexed case, let's figure out how we can improve the current matching algorithm without throwing everything completely away. Even though it may not seem like it, I do appreciate you looking into this. :-) > Add generic type information to SimpleFilter > > > Key: FELIX-3202 > URL: https://issues.apache.org/jira/browse/FELIX-3202 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Lucas Galfaso >Priority: Minor > Attachments: felix_java5_filter.diff > > > SimpleFilter does not have Java 5 generic type information and it is very > hard to add this to the current implementation. > Devise a way to add generate type information to SimpleFilter while keeping > in mind that this is a critical component and any performance degradation > would slow down the entire framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3202) Add generic type information to SimpleFilter
[ https://issues.apache.org/jira/browse/FELIX-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146033#comment-13146033 ] Richard S. Hall commented on FELIX-3202: (1) The spec won't change to eliminate matching by the filter, but it is still the wrong approach when trying to optimize. It is the equivalent of giving each row in a table to a SELECT and asking the SELECT if the row matches. This doesn't make sense from an optimization point of view. (2) This falls into the "eye of the beholder", so I'm not sure how to quantify. (3) Due to spending lots of time programming with class loaders, I tend to worry about number of classes and number of class loads, not lines of code. (4) I'm not sure how the tests were performed, but most of the time filters are run against a CapabilitySet which maintains indices, so I'd be surprised if 50% faster. If you are talking purely about un-indexed matching, then let's work on improving the match operation. (5) SimpleFilter is an implementation detail of the framework which is used to implement Filter for the OSGi. However, its primary purpose is to be used internally by the framework resolver to match capabilities to requirements. The internal dependency model of the Felix framework is based on a generic dependency model built on top of SimpleFilter, which requires that we reverse the matching to introduce indices, much like a database. > Add generic type information to SimpleFilter > > > Key: FELIX-3202 > URL: https://issues.apache.org/jira/browse/FELIX-3202 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Lucas Galfaso >Priority: Minor > Attachments: felix_java5_filter.diff > > > SimpleFilter does not have Java 5 generic type information and it is very > hard to add this to the current implementation. > Devise a way to add generate type information to SimpleFilter while keeping > in mind that this is a critical component and any performance degradation > would slow down the entire framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3202) Add generic type information to SimpleFilter
[ https://issues.apache.org/jira/browse/FELIX-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145248#comment-13145248 ] Richard S. Hall commented on FELIX-3202: This replaces one class with 13 to add generics? Is that correct? If so, it seems like overkill to me. I'd certainly be interested in any performance improvements you can find, but i'd prefer it to be piecemeal against the current "simple" implementation. Also, this does the matching in the filter implementation, which is not what we want, since matching needs to be run against our indices in CapabilitySet. That's why CapabilitySet does the matching currently. The OSGi spec historically reversed the direction here by having the filter do the matching, but that is not really what you want because it forces you to pass one capability at a time to the filter. > Add generic type information to SimpleFilter > > > Key: FELIX-3202 > URL: https://issues.apache.org/jira/browse/FELIX-3202 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Lucas Galfaso >Priority: Minor > Attachments: felix_java5_filter.diff > > > SimpleFilter does not have Java 5 generic type information and it is very > hard to add this to the current implementation. > Devise a way to add generate type information to SimpleFilter while keeping > in mind that this is a critical component and any performance degradation > would slow down the entire framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3179) Add generic type information
[ https://issues.apache.org/jira/browse/FELIX-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144872#comment-13144872 ] Richard S. Hall commented on FELIX-3179: Smaller patches are generally better, so go ahead and spin it into another issue. Thanks. > Add generic type information > > > Key: FELIX-3179 > URL: https://issues.apache.org/jira/browse/FELIX-3179 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Lucas Galfaso >Priority: Minor > Attachments: copyOnWriteInstalledBundles.patch, felix_java5.diff, > felix_java5.diff, felix_java5_filter.diff > > > Add the generic type information to Felix Framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3178) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140336#comment-13140336 ] Richard S. Hall commented on FELIX-3178: Just a status update, I've create a test case bug to reproduce the bug in a much simple scenario, so now I just have to figure out how the best way to resolve it. Once i get something committed, I'll start to think about a 4.0.2 framework release. > NPE in ResolverImpl > --- > > Key: FELIX-3178 > URL: https://issues.apache.org/jira/browse/FELIX-3178 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 > Environment: Also reproduced on 4.0.1 >Reporter: Andreas Schlosser >Priority: Blocker > Fix For: framework-4.2.0 > > Attachments: MANIFEST.MF, npe.z01, npe.z02, npe.zip > > > Bundle Resolution fails with NPE in both, Felix 4.0.0 and 4.0.1 > ERROR: Bundle com.springsource.com.sun.tools.xjc [119] Error starting > file:bundles/com.springsource.com.sun.tools.xjc.jar > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:856) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:659) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:609) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:181) > at > org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3811) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3179) Add generic type information
[ https://issues.apache.org/jira/browse/FELIX-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139521#comment-13139521 ] Richard S. Hall commented on FELIX-3179: It will likely take me a little while to review the patch. Looking quickly at your installed bundles patch, I can say that I'm not too keen on introducing two more classes just to avoid some casts. Although it continues to grow over time, the intent has always been to keep the framework as small as possible. Creating classes willy nilly and possibly over engineering stuff is one of the quicker paths to bloat. Regarding SimpleFilter, there are some substring tests in the source tree along with FilterImpl tests, but they are pretty lame. So, feel free to add some more. Mostly I rely on the OSGi CT, but we should have our own. I'd be really sensitive to changes in this area since SimpleFilter is critical for performance. > Add generic type information > > > Key: FELIX-3179 > URL: https://issues.apache.org/jira/browse/FELIX-3179 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Lucas Galfaso >Priority: Minor > Attachments: copyOnWriteInstalledBundles.patch, felix_java5.diff, > felix_java5.diff > > > Add the generic type information to Felix Framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3178) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134235#comment-13134235 ] Richard S. Hall commented on FELIX-3178: Ok, I see what is going on. Previously, the framework treated caps/reqs from attached fragments as if they came from the host, but the R4.3 API treats attached caps/reqs as coming from the fragment making the host/fragment tuple explicit. Internally, the resolver deals with this by wrapping any attached caps/reqs to make it look like they come from the host hiding the host/fragment tuple. Unfortunately, when calculating package sources during a resolve in getPackageSourceInternal() the wrapper is lost, which ultimately causes the NPE since the resolve subsequently tries to wire to a fragment capability directly, but cannot find its package space because it doesn't exist since it should be using the host's package space instead. I'll need to think about the proper way to resolve this issue, but given this knowledge I should be able to create a simple test case to recreate it, so I'll attempt to do that first. > NPE in ResolverImpl > --- > > Key: FELIX-3178 > URL: https://issues.apache.org/jira/browse/FELIX-3178 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 > Environment: Also reproduced on 4.0.1 >Reporter: Andreas Schlosser >Priority: Blocker > Fix For: framework-4.2.0 > > Attachments: MANIFEST.MF, npe.z01, npe.z02, npe.zip > > > Bundle Resolution fails with NPE in both, Felix 4.0.0 and 4.0.1 > ERROR: Bundle com.springsource.com.sun.tools.xjc [119] Error starting > file:bundles/com.springsource.com.sun.tools.xjc.jar > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:856) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:659) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:609) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:181) > at > org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3811) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3178) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134131#comment-13134131 ] Richard S. Hall commented on FELIX-3178: Do I just 'cat' these three files together (e.g., cat npe.z01 npe.z02 npe.zip > full.zip) or what? > NPE in ResolverImpl > --- > > Key: FELIX-3178 > URL: https://issues.apache.org/jira/browse/FELIX-3178 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 > Environment: Also reproduced on 4.0.1 >Reporter: Andreas Schlosser >Priority: Blocker > Fix For: framework-4.2.0 > > Attachments: MANIFEST.MF, npe.z01, npe.z02, npe.zip > > > Bundle Resolution fails with NPE in both, Felix 4.0.0 and 4.0.1 > ERROR: Bundle com.springsource.com.sun.tools.xjc [119] Error starting > file:bundles/com.springsource.com.sun.tools.xjc.jar > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:856) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:659) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:609) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:181) > at > org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3811) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3178) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133058#comment-13133058 ] Richard S. Hall commented on FELIX-3178: Having the manifest alone isn't sufficient, since the error occurs after it has calculated its dependencies. I tried to recreate the error from a set of bundles from the SpringSource bundle repository, but for me it ended up resolving correctly. Perhaps you could zip up and attach to this issue the set of bundles you use to see the error, then I can investigate it. Thanks. > NPE in ResolverImpl > --- > > Key: FELIX-3178 > URL: https://issues.apache.org/jira/browse/FELIX-3178 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 > Environment: Also reproduced on 4.0.1 >Reporter: Andreas Schlosser >Priority: Blocker > Fix For: framework-4.2.0 > > Attachments: MANIFEST.MF > > > Bundle Resolution fails with NPE in both, Felix 4.0.0 and 4.0.1 > ERROR: Bundle com.springsource.com.sun.tools.xjc [119] Error starting > file:bundles/com.springsource.com.sun.tools.xjc.jar > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.mergeUses(ResolverImpl.java:856) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:659) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:609) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:181) > at > org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3811) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3179) Add generic type information
[ https://issues.apache.org/jira/browse/FELIX-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132690#comment-13132690 ] Richard S. Hall commented on FELIX-3179: Thanks for the patch. It might take me a little time to review it all. I noticed one thing already. We are using a copy-on-write approach for Felix.m_installedBundles, which was an array of maps. You've separated this into two maps that can be mutated, which breaks the concurrency control approach, since we weren't locking read access to this data structure. That will have to be changed back. > Add generic type information > > > Key: FELIX-3179 > URL: https://issues.apache.org/jira/browse/FELIX-3179 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Lucas Galfaso >Priority: Minor > Attachments: felix_java5.diff > > > Add the generic type information to Felix Framework -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3177) Remove temporary inclusion of OSGi classes
[ https://issues.apache.org/jira/browse/FELIX-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131670#comment-13131670 ] Richard S. Hall commented on FELIX-3177: One tricky issue to remember, we cannot do an official release of Config Admin using provisional OSGi API: http://felix.apache.org/site/provisional-osgi-api-policy.html So, if you want to do an official release before the API is final, you'll have to put it in the Felix package namespace. > Remove temporary inclusion of OSGi classes > -- > > Key: FELIX-3177 > URL: https://issues.apache.org/jira/browse/FELIX-3177 > Project: Felix > Issue Type: Task > Components: Configuration Admin >Affects Versions: configadmin-1.4.0 >Reporter: Felix Meschberger > > Once the OSGi Alliance releases an official build of the Configuration Admin > 1.4 API classes to the central maven repository, the temporary inclusion of > the ConfigurationEvent and ConfigurationPermission classes should be reverted. > Also the export and import versions of the Configuration Admin package should > be deduced from the official library (again). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128917#comment-13128917
]
Richard S. Hall commented on FELIX-3160:
I'm still not able to recreate, so I guess we'll have to try to recreate the
exact scenario. If you can come up with something, let me know. Otherwise, I'll
tinker around with it later and see if I can come up with something.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128896#comment-13128896
]
Richard S. Hall commented on FELIX-3160:
Yeah, I think Karl is correct. I'll look into it again later, thanks.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128277#comment-13128277
]
Richard S. Hall commented on FELIX-3160:
I created a bundle like this:
public class Activator implements BundleActivator
{
public void start(final BundleContext bc)
{
bc.addFrameworkListener(new FrameworkListener() {
public void frameworkEvent(FrameworkEvent event)
{
if (event.getType() == FrameworkEvent.STARTED)
{
for (Bundle b : bc.getBundles())
{
if ((b.getBundleId() != 0)
&& (b != bc.getBundle())
&&
!b.getSymbolicName().startsWith("org.apache.felix.gogo"))
{
try
{
b.uninstall();
}
catch (Exception ex)
{
System.out.println("+++ Uninstall error: " +
ex);
}
}
}
}
}
});
}
public void stop(BundleContext bc)
{
}
}
This was working for me, it was correctly deleting any non-shell bundles on
framework restart. Perhaps there is something else I need to do to recreate.
Perhaps you could see if my code above gives you an error too. Thanks.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3163) Failed in use ConditionalPermissionAdmin
[
https://issues.apache.org/jira/browse/FELIX-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127630#comment-13127630
]
Richard S. Hall commented on FELIX-3163:
It doubt the framework hung, it looks more like it cannot resolve any bundles
thus the shell never started. So the framework is likely running, but you don't
have a shell to interact with it. Not sure why this would be happening. Did you
modify anything in the framework configuration?
> Failed in use ConditionalPermissionAdmin
>
>
> Key: FELIX-3163
> URL: https://issues.apache.org/jira/browse/FELIX-3163
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework-4.0.0, framework.security-2.0.0
>Reporter: Yanni Yan
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> I test ConditionalPermissionAdmin as follow:
> private void setLocalCPA() throws Exception {
> ServiceReference srf =
> context.getServiceReference(ConditionalPermissionAdmin.class.getName());
> if (null == srf){
> throw new BundleException("Not found service: " +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionAdmin cpa =
> (ConditionalPermissionAdmin)context.getService(srf);
> if (null == cpa){
> throw new BundleException("Failed to get service :" +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionUpdate cpu =
> cpa.newConditionalPermissionUpdate();
> // clear all exist permissions
> cpu.getConditionalPermissionInfos().clear();
>
> // assign all permission to all bundles
> ConditionalPermissionInfo cpi =
> cpa.newConditionalPermissionInfo(null, new ConditionInfo[]{
> new
> ConditionInfo(BundleLocationCondition.class.getName(),new String[]
> {context.getBundle(0).getLocation()})
> }, new PermissionInfo[]{
> new
> PermissionInfo(AllPermission.class.getName(), "*", "*")
> }, ConditionalPermissionInfo.ALLOW);
> cpu.getConditionalPermissionInfos().add(cpi);
> // deny FilePermission to current bundle
>
> cpu.commit();
> }
> After my bundle start, felix hunged. I restart felix, felix print as follow:
> D:\Workspace\Felix>java -Djava.security.policy=all.policy -Dorg.osgi.fr
> amework.security=osgi -jar bin/felix.jar
> ERROR: Bundle org.apache.felix.bundlerepository [1] Error starting
> file:/D:/Work
> space/UniAgent/Felix/bundle/org.apache.felix.bundlerepository-1.6.6.jar
> (org.osg
> i.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.bu
> ndlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi.wiring
> .package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=
> 2.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.bundlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi
> .wiring.package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(ve
> rsion>=2.0.0)))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:381
> 8)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStart
> LevelImpl.java:295)
> at java.lang.Thread.run(Unknown Source)
> ERROR: Bundle org.apache.felix.gogo.command [3] Error starting
> file:/D:/Workspac
> e/UniAgent/Felix/bundle/org.apache.felix.gogo.command-0.12.0.jar
> (org.osgi.frame
> work.BundleException: Unresolved constraint in bundle
> org.apache.felix.gogo.comm
> and [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wiring.package; (
> &(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(vers
> ion>=0.10.0)(!(version>=1.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.gogo.command [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wir
> ing.package;
> (&(osgi.wiring.package=org.apache.felix.service.command)(status=pro
> visional)(version>=0.10.0)(!(version>=1.0.0)))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:381
> 8)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org
[jira] [Commented] (FELIX-2340) Combine "type" and "help" commands into a single help facility
[ https://issues.apache.org/jira/browse/FELIX-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126664#comment-13126664 ] Richard S. Hall commented on FELIX-2340: I am thinking of having one single command that does the work of both. However, if it is not possible to do it with one command, then we can still have two commands, but have them use the same underpinnings. > Combine "type" and "help" commands into a single help facility > -- > > Key: FELIX-2340 > URL: https://issues.apache.org/jira/browse/FELIX-2340 > Project: Felix > Issue Type: Improvement > Components: Gogo Command, Gogo Shell >Affects Versions: gogo-0.6.0 >Reporter: Richard S. Hall > Fix For: gogo.shell-0.12.0, gogo.command-0.14.0 > > > Currently, we have a "type" command for exploring existing commands and I've > implemented a "help" command in the felixcommands module. They serve slightly > different purposes, but I think it would be fairly straightforward to combine > them into a single help facility. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125887#comment-13125887
]
Richard S. Hall commented on FELIX-3160:
This doesn't sound right. Do you have something to help me reproduce the
scenario? If not, are you saying it will always happen if I create a bundle
that uninstalls another bundle after receiving the STARTED event?
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-538) Create a really lightweight version of the HTTP Service
[ https://issues.apache.org/jira/browse/FELIX-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125880#comment-13125880 ] Richard S. Hall commented on FELIX-538: --- Well, your not supposed to do so, but it is probably a good first step to make sure you have the necessary permissions, etc. Make sure you do a check out of Felix using "https:"... As for the subproject directory, I was wondering about that too. Personally, I don't think we should use http/lightweight since that, to me, implies it is a module of the existing HTTP Service. I would probably just make it http.lightweight. The downside of this, though, is that it puts it in the same package namespace as the other HTTP Service impl and potentially under the same parent pom, which may not make sense since the two subprojects are independent. Another possibility is to just come up with a name for it and use it as the subproject package name, e.g., httplite, which would put it in package org.apache.felix.httplite...or whatever. Perhaps we can get some input from others? > Create a really lightweight version of the HTTP Service > --- > > Key: FELIX-538 > URL: https://issues.apache.org/jira/browse/FELIX-538 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Reporter: Richard S. Hall >Priority: Minor > Attachments: Screenshot-Apache Felix Web Console - Bundles - > Chromium.png > > > In my sandbox I have committed a very simple, multi-threaded, file-based web > server. The web server was designed so that it could easily be used in a > bundle (e.g., it can be started, stopped, and restarted) and already has an > Activator. It would be interesting if we could extend this with servlet > support and tailor it specifically for the OSGi HTTP Service specification. > If we could do this, then we could have one "heavyweight" OSGi HTTP Service > implementation based on Jetty and this really lightweight version for small > device requirements -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3154) "felix.systembundle.activators" list : there is a change in config map form felix v3 to felix v4
[ https://issues.apache.org/jira/browse/FELIX-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125326#comment-13125326 ] Richard S. Hall commented on FELIX-3154: In reality, I was actually surprised to learn about this too when it was first reported after the framework 4.0 release. I didn't realize earlier since internally the framework still uses a raw type, I believe. Had I been paying more close attention to this specific detail during the R4.3 spec writing process, I probably would have argued for Map instead of Map, but it didn't really dawn on me. At this point, the only thing that could be done is to add another method to FrameworkFactory in a future release, but I'm not convinced it is worth it. You really can mimic this behavior with the existing API, so you could probably write a utility class to do it. For example, create a utility class that accepts a list of activators, a config map, and a framework factory. It could then just do the following: 1. Create a framework instance with the supplied config map. 2. Call Framework.init(). 3. Register synchronous bundle listener to listen for system bundle STOPPING. 4. Call start() on each activator in the passed in list with Framework.getBundleContext(). 5. Call Framework.start(). Then, when a system bundle STOPPING event is received by the above synchronous listener, simply call stop() on each listener with the system bundle context. Something like that is basically identical and doesn't rely on any containerisms. > "felix.systembundle.activators" list : there is a change in config map form > felix v3 to felix v4 > > > Key: FELIX-3154 > URL: https://issues.apache.org/jira/browse/FELIX-3154 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Andrei Pozolotin > > there is a change in config map form felix v3 to felix v4 > Map > http://www.osgi.org/javadoc/r4v42/org/osgi/framework/launch/FrameworkFactory.html > Map > http://www.osgi.org/javadoc/r4v43/org/osgi/framework/launch/FrameworkFactory.html > short of raw type hack in; what is the correct way to provide > "felix.systembundle.activators" list ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3156) Implement Bundle::getDataFile and Bundle::compareTo
[ https://issues.apache.org/jira/browse/FELIX-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125178#comment-13125178 ] Richard S. Hall commented on FELIX-3156: Yeah, those appear to be some functionality we missed. Please feel free to submit a patch and I'll look into it when you do. Thanks for catching these. > Implement Bundle::getDataFile and Bundle::compareTo > --- > > Key: FELIX-3156 > URL: https://issues.apache.org/jira/browse/FELIX-3156 > Project: Felix > Issue Type: New Feature > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Lucas Galfaso > > Implement Bundle::getDataFile and Bundle::compareTo. > Both are very low hanging fruit, I am willing to post a patch for both if > needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3154) "felix.systembundle.activators" list : there is a change in config map form felix v3 to felix v4
[ https://issues.apache.org/jira/browse/FELIX-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125083#comment-13125083 ] Richard S. Hall commented on FELIX-3154: Still, once you detect it, you can then use the Felix framework constructor. There isn't much else that makes sense. We could create some new FelixFrameworkFactory, but how is that any better than just using the framework constructor directly? Although Felix' system bundle activators are a little more convenient, there is nothing they provide that can't be mimicked with the standard API, I don't believe. So, there isn't much reason to use them. > "felix.systembundle.activators" list : there is a change in config map form > felix v3 to felix v4 > > > Key: FELIX-3154 > URL: https://issues.apache.org/jira/browse/FELIX-3154 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Andrei Pozolotin > > there is a change in config map form felix v3 to felix v4 > Map > http://www.osgi.org/javadoc/r4v42/org/osgi/framework/launch/FrameworkFactory.html > Map > http://www.osgi.org/javadoc/r4v43/org/osgi/framework/launch/FrameworkFactory.html > short of raw type hack in; what is the correct way to provide > "felix.systembundle.activators" list ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3153) [Framework] refreshPackages() should stop bundles in one pass and refresh them in a second pass
[ https://issues.apache.org/jira/browse/FELIX-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124449#comment-13124449 ] Richard S. Hall commented on FELIX-3153: I don't see how the order of refresh would play a role here. Once stop is called on all bundles they should cease to execute any code. If the bundles misbehaved and continued to let their threads execute after stop(), then you might see failures. I suppose one other possibility where order could be important is for bundles whose code assumed they were active and thus had bundle contexts (e.g., lazily activated bundles). If so, that would be another good argument against lazy activation because they make your bundle dependent on deactivation order. You can open up another bug for that and I can look into it too, but not for this release. > [Framework] refreshPackages() should stop bundles in one pass and refresh > them in a second pass > --- > > Key: FELIX-3153 > URL: https://issues.apache.org/jira/browse/FELIX-3153 > Project: Felix > Issue Type: Bug >Affects Versions: framework-3.0.9, framework-3.2.2 >Reporter: Ioannis Canellos >Assignee: Richard S. Hall > Fix For: framework-4.0.1 > > > When using refreshPackages on a bundle that is used by a lot of other > bundles, it results in error. > There is no deterministic behavior and the error is not always the same, even > if I repeat the exact same test twice. > A typical example on how I reproduce it is to refresh the spring-context > bundle inside servicemix 4.4 (running on felix). > If I switch to equinox I don't have that issue. That doesn't say much, but I > mention it to exclude other possibilities. > From my logs I see that Felix tries to refresh the bundles in the populated > graph with a different order each time (I don't know if this helps > identifying the issue). > Usually, the error looks like this: > ERROR: Bundle org.springframework.osgi.extender [83] Error stopping bundle. > (java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration) > java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration > at > org.springframework.osgi.util.OsgiServiceUtils.unregisterService(OsgiServiceUtils.java:41) > at > org.springframework.osgi.extender.internal.support.NamespaceManager.unregisterResolverService(NamespaceManager.java:195) > at > org.springframework.osgi.extender.internal.support.NamespaceManager.destroy(NamespaceManager.java:223) > at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.shutdown(ContextLoaderListener.java:547) > at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.stop(ContextLoaderListener.java:431) > at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651) > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2216) > at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4489) > at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3581) > at > org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:363) > at java.lang.Thread.run(Thread.java:680) > Caused by: java.lang.ClassNotFoundException: > org.osgi.framework.ServiceRegistration not found by > org.springframework.osgi.core [80] > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787) > at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > ... 11 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3153) refreshPackages on certain bundles can create a mess
[
https://issues.apache.org/jira/browse/FELIX-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124431#comment-13124431
]
Richard S. Hall commented on FELIX-3153:
Ok, I hacked up ServiceMix to run with framework 4.0.0...the difficult part is
that they provide their own OSGi API classes instead of using the ones coming
from the framework...this is probably not a smart thing since frameworks are
free to make implementation-specific adaptations to the OSGi API
implementations, so you cannot be sure that a given framework will work
properly with the original OSGi JARs. At any rate...
I was able to reproduce similar issues. In the end, I believe I understand at
least some aspect of what is going wrong. When refreshing bundles, the Felix
framework is stopping and refreshing bundles one at a time, when in fact it
should be stopping them all first, then refreshing them all in a separate pass,
and finally restarting them again in a third pass. So, I will commit a patch to
do just that and change the subject of this bug to more accurately reflect the
issue.
Unfortunately, it doesn't appear to make the refresh of the spring context
bundle work correctly, but at least the error is more consistent and
controlled. I regularly see this:
ERROR: Bundle org.apache.servicemix.jbi.osgi [123] EventDispatcher: Error
during dispatch. (org.apache.servicemix.nmr.api.ServiceMixException: Unable to
register service servicemix-wsn2005 with properties {NAME=servicemix-wsn2005,
objectClass=[Ljava.lang.String;@2cf9f1b5, service.id=725, TYPE=service-engine}.
Reason: javax.jbi.JBIException: Error calling init)
org.apache.servicemix.nmr.api.ServiceMixException: Unable to register service
servicemix-wsn2005 with properties {NAME=servicemix-wsn2005,
objectClass=[Ljava.lang.String;@2cf9f1b5, service.id=725, TYPE=service-engine}.
Reason: javax.jbi.JBIException: Error calling init
at
org.apache.servicemix.nmr.core.ServiceRegistryImpl.register(ServiceRegistryImpl.java:52)
at
org.apache.servicemix.nmr.osgi.OsgiServiceRegistryTracker.addingService(OsgiServiceRegistryTracker.java:78)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:980)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:906)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:262)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:234)
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:941)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4250)
at org.apache.felix.framework.Felix.registerService(Felix.java:3275)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
at
org.apache.servicemix.jbi.deployer.impl.Deployer.registerService(Deployer.java:762)
at
org.apache.servicemix.jbi.deployer.impl.Deployer.registerComponent(Deployer.java:418)
at
org.apache.servicemix.jbi.deployer.impl.ComponentInstaller.initComponent(ComponentInstaller.java:424)
at
org.apache.servicemix.jbi.deployer.impl.ComponentInstaller.install(ComponentInstaller.java:150)
at
org.apache.servicemix.jbi.deployer.impl.Deployer.registerDeployedComponent(Deployer.java:657)
at
org.apache.servicemix.jbi.deployer.impl.Deployer$1.addingService(Deployer.java:222)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:980)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:906)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:262)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:234)
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:941)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4250)
at org.apache.felix.framework.Felix.registerService(Felix.java:3275)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.reg
[jira] [Commented] (FELIX-3153) refreshPackages on certain bundles can create a mess
[ https://issues.apache.org/jira/browse/FELIX-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124324#comment-13124324 ] Richard S. Hall commented on FELIX-3153: Yes, the "current" release is 4.0.0. :-) Can you just replace the old Felix framework JAR file with the new one in Karaf as a quick and dirty fix? I don't think it should look much different from a client's perspective. > refreshPackages on certain bundles can create a mess > > > Key: FELIX-3153 > URL: https://issues.apache.org/jira/browse/FELIX-3153 > Project: Felix > Issue Type: Bug >Affects Versions: framework-3.0.9, framework-3.2.2 >Reporter: Ioannis Canellos > > When using refreshPackages on a bundle that is used by a lot of other > bundles, it results in error. > There is no deterministic behavior and the error is not always the same, even > if I repeat the exact same test twice. > A typical example on how I reproduce it is to refresh the spring-context > bundle inside servicemix 4.4 (running on felix). > If I switch to equinox I don't have that issue. That doesn't say much, but I > mention it to exclude other possibilities. > From my logs I see that Felix tries to refresh the bundles in the populated > graph with a different order each time (I don't know if this helps > identifying the issue). > Usually, the error looks like this: > ERROR: Bundle org.springframework.osgi.extender [83] Error stopping bundle. > (java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration) > java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration > at > org.springframework.osgi.util.OsgiServiceUtils.unregisterService(OsgiServiceUtils.java:41) > at > org.springframework.osgi.extender.internal.support.NamespaceManager.unregisterResolverService(NamespaceManager.java:195) > at > org.springframework.osgi.extender.internal.support.NamespaceManager.destroy(NamespaceManager.java:223) > at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.shutdown(ContextLoaderListener.java:547) > at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.stop(ContextLoaderListener.java:431) > at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651) > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2216) > at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4489) > at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3581) > at > org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:363) > at java.lang.Thread.run(Thread.java:680) > Caused by: java.lang.ClassNotFoundException: > org.osgi.framework.ServiceRegistration not found by > org.springframework.osgi.core [80] > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787) > at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > ... 11 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3154) "felix.systembundle.activators" list : there is a change in config map form felix v3 to felix v4
[ https://issues.apache.org/jira/browse/FELIX-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124320#comment-13124320 ] Richard S. Hall commented on FELIX-3154: Use the Felix framework constructor. If you are using that property, you are already tied to the Felix framework impl, so there is little reason to use FrameworkFactory since an instance of Equinox, for example, wouldn't do what you want. > "felix.systembundle.activators" list : there is a change in config map form > felix v3 to felix v4 > > > Key: FELIX-3154 > URL: https://issues.apache.org/jira/browse/FELIX-3154 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Andrei Pozolotin > > there is a change in config map form felix v3 to felix v4 > Map > http://www.osgi.org/javadoc/r4v42/org/osgi/framework/launch/FrameworkFactory.html > Map > http://www.osgi.org/javadoc/r4v43/org/osgi/framework/launch/FrameworkFactory.html > short of raw type hack in; what is the correct way to provide > "felix.systembundle.activators" list ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3153) refreshPackages on certain bundles can create a mess
[ https://issues.apache.org/jira/browse/FELIX-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124241#comment-13124241 ] Richard S. Hall commented on FELIX-3153: Try to recreate on the current framework release. Let me know what happens. > refreshPackages on certain bundles can create a mess > > > Key: FELIX-3153 > URL: https://issues.apache.org/jira/browse/FELIX-3153 > Project: Felix > Issue Type: Bug >Affects Versions: framework-3.0.9 >Reporter: Ioannis Canellos > > When using refreshPackages on a bundle that is used by a lot of other > bundles, it results in error. > There is no deterministic behavior and the error is not always the same, even > if I repeat the exact same test twice. > A typical example on how I reproduce it is to refresh the spring-context > bundle inside servicemix 4.4 (running on felix). > If I switch to equinox I don't have that issue. That doesn't say much, but I > mention it to exclude other possibilities. > From my logs I see that Felix tries to refresh the bundles in the populated > graph with a different order each time (I don't know if this helps > identifying the issue). > Usually, the error looks like this: > ERROR: Bundle org.springframework.osgi.extender [83] Error stopping bundle. > (java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration) > java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration > at > org.springframework.osgi.util.OsgiServiceUtils.unregisterService(OsgiServiceUtils.java:41) > at > org.springframework.osgi.extender.internal.support.NamespaceManager.unregisterResolverService(NamespaceManager.java:195) > at > org.springframework.osgi.extender.internal.support.NamespaceManager.destroy(NamespaceManager.java:223) > at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.shutdown(ContextLoaderListener.java:547) > at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.stop(ContextLoaderListener.java:431) > at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651) > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2216) > at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4489) > at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3581) > at > org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:363) > at java.lang.Thread.run(Thread.java:680) > Caused by: java.lang.ClassNotFoundException: > org.osgi.framework.ServiceRegistration not found by > org.springframework.osgi.core [80] > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787) > at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > ... 11 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3004) felix.security does not work with exploded jars
[ https://issues.apache.org/jira/browse/FELIX-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124243#comment-13124243 ] Richard S. Hall commented on FELIX-3004: It would look like it, since 2.0.0 is listed as the fix version on this issue. > felix.security does not work with exploded jars > > > Key: FELIX-3004 > URL: https://issues.apache.org/jira/browse/FELIX-3004 > Project: Felix > Issue Type: Bug > Components: Framework Security >Affects Versions: framework.security-1.4.1 >Reporter: Andrei Pozolotin >Assignee: Karl Pauls >Priority: Minor > Fix For: framework.security-2.0.0 > > > original thread: > https://issues.apache.org/jira/browse/FELIX-2993?focusedCommentId=13050774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050774 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3151) Activating bundles in seperate thread
[ https://issues.apache.org/jira/browse/FELIX-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124175#comment-13124175 ] Richard S. Hall commented on FELIX-3151: There is no particular reason. It could be done, but it would potentially complicate concurrency issues even more since we'd have to block the calling thread, call into the bundle with another thread, who could then in turn call back into the framework on another thread, which means we'd have to be extra careful with locking. This is really complicated by things like "refresh" that have to hold locks and operate on multiple bundles. Further, the implied solution here is to have a timeout and try to kill the activator thread if it is taking too long, but we already know that killing threads in Java is unreliable and not recommended. Further still, this is just one failure mode associated with bundles and there are tons of other failure modes that we can't do anything about, since Java doesn't provide any way to isolate or limit resource consumption. So, in the end, if a bundle is not well behaved, it is probably better to learn about it quicker and stop using it. > Activating bundles in seperate thread > - > > Key: FELIX-3151 > URL: https://issues.apache.org/jira/browse/FELIX-3151 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Andie Similon >Priority: Minor > > I was wondering about the following thing and I'd like one of the developers > opinion about it. Is there a reason why bundles are not started in a seperate > thread. I was wondering this because if a bundle developer creates a bundle > that ends up in an infinite loop or something in the bundle start method, it > will block the entire system. Is there a reason why the bundles aren't > started in a seperate thread? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3084) Submission of source code for review of software grant for lightweight HTTP service implementation.
[ https://issues.apache.org/jira/browse/FELIX-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123815#comment-13123815 ] Richard S. Hall commented on FELIX-3084: No, nothing to do. It is done and I'll wrap it up this coming week. I was at JavaOne last week, so I didn't really have much time to do other things. > Submission of source code for review of software grant for lightweight HTTP > service implementation. > --- > > Key: FELIX-3084 > URL: https://issues.apache.org/jira/browse/FELIX-3084 > Project: Felix > Issue Type: Task > Components: HTTP Service >Reporter: Ken Gilmer > Labels: software > Attachments: GRANT.pdf, org.apache.felix.http.lightweight-src.tar.gz > > > This issue is created as part of the process outlined in the "Contributing > Source Code" Felix page as suggested by Richard Hall in issue FELIX-538[1]. > The source code attached[6] to this issue is an implementation of the OSGi > HTTP Service specification version 1.2. The code is based on Richard's > original server which is also referenced in FELIX-538, and the remaining code > was developed by me, with the exception of a few classes which were adapted > from existing Felix sources[2]. > Design constraints for this project were backwards compatibility, simplicity, > and size. The code base consists of 23 Java files in 3 packages. The source > is divided into "osgi", "server", and "servlet" packages according to the > primary purpose of the class, and interfaces are utilized to keep the three > domains fairly isolated[3]. The minimal compiled jar which does not include > the servlet API or OSGi API currently is 41Kb, and the dependency-free jar > with all necessary APIs is 125Kb. An Ant script is provided that will build > the jars and a CI server is also available for binary builds[4] and > javadocs[5]. > In terms of features the server doesn't offer: > -HTTPS > -Authentication > -Cookie support > -Session support > In addition several aspects of the Servlet implementation have not been > tested including: > -Multipart POST > -DELETE > -PUT > -Non-default character encodings > And as of the submission several Servlet API methods are unimplemented in > (all unimplemented methods throw > org.apache.felix.http.lightweight.servlet.UnimplementedAPIException): > -HttpServletRequest(Impl) > -HttpServletResponse(Impl) > However the core functionality has been implemented and tested and the Felix > Web Admin application can be hosted with this HTTP Service implementation. > I plan in continuing to use the service in personal and professional projects > and would be happy to continue to add unimplemented features and maintain the > code base as a Felix committer. > Thanks! > Ken Gilmer > 1: https://issues.apache.org/jira/browse/FELIX-538 > 2: > /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/DefaultContextImpl.java, > > /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/Logger.java > 3: > /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationHandler.java, > > /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationResolver.java > 4: https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/ > 5: > https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/javadoc/ > 6: MD5SUM 47580996a8c364890518222494d4d26b > org.apache.felix.http.lightweight-src.tar.gz > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3147) Check whether bundle jar is signed
[ https://issues.apache.org/jira/browse/FELIX-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120591#comment-13120591 ] Richard S. Hall commented on FELIX-3147: Do you have the security provider bundle installed and security enabled? > Check whether bundle jar is signed > -- > > Key: FELIX-3147 > URL: https://issues.apache.org/jira/browse/FELIX-3147 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-3.0.9 >Reporter: Andie Similon >Priority: Minor > > I am not sure but it seems to be that when loading a bundle it will not > verify the signature of the bundle. I can self sign a bundle and then change > its contents and the framework will not throw a SecurityException. Is this > intended? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3084) Submission of source code for review of software grant for lightweight HTTP service implementation.
[ https://issues.apache.org/jira/browse/FELIX-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118190#comment-13118190 ] Richard S. Hall commented on FELIX-3084: The IP clearance form is visible now: http://incubator.apache.org/ip-clearance/felix-lightweight-httpservice.html I've sent a message to request review. After three days, we should be ready to go. > Submission of source code for review of software grant for lightweight HTTP > service implementation. > --- > > Key: FELIX-3084 > URL: https://issues.apache.org/jira/browse/FELIX-3084 > Project: Felix > Issue Type: Task > Components: HTTP Service >Reporter: Ken Gilmer > Labels: software > Attachments: GRANT.pdf, org.apache.felix.http.lightweight-src.tar.gz > > > This issue is created as part of the process outlined in the "Contributing > Source Code" Felix page as suggested by Richard Hall in issue FELIX-538[1]. > The source code attached[6] to this issue is an implementation of the OSGi > HTTP Service specification version 1.2. The code is based on Richard's > original server which is also referenced in FELIX-538, and the remaining code > was developed by me, with the exception of a few classes which were adapted > from existing Felix sources[2]. > Design constraints for this project were backwards compatibility, simplicity, > and size. The code base consists of 23 Java files in 3 packages. The source > is divided into "osgi", "server", and "servlet" packages according to the > primary purpose of the class, and interfaces are utilized to keep the three > domains fairly isolated[3]. The minimal compiled jar which does not include > the servlet API or OSGi API currently is 41Kb, and the dependency-free jar > with all necessary APIs is 125Kb. An Ant script is provided that will build > the jars and a CI server is also available for binary builds[4] and > javadocs[5]. > In terms of features the server doesn't offer: > -HTTPS > -Authentication > -Cookie support > -Session support > In addition several aspects of the Servlet implementation have not been > tested including: > -Multipart POST > -DELETE > -PUT > -Non-default character encodings > And as of the submission several Servlet API methods are unimplemented in > (all unimplemented methods throw > org.apache.felix.http.lightweight.servlet.UnimplementedAPIException): > -HttpServletRequest(Impl) > -HttpServletResponse(Impl) > However the core functionality has been implemented and tested and the Felix > Web Admin application can be hosted with this HTTP Service implementation. > I plan in continuing to use the service in personal and professional projects > and would be happy to continue to add unimplemented features and maintain the > code base as a Felix committer. > Thanks! > Ken Gilmer > 1: https://issues.apache.org/jira/browse/FELIX-538 > 2: > /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/DefaultContextImpl.java, > > /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/Logger.java > 3: > /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationHandler.java, > > /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationResolver.java > 4: https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/ > 5: > https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/javadoc/ > 6: MD5SUM 47580996a8c364890518222494d4d26b > org.apache.felix.http.lightweight-src.tar.gz > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
