Re: New committer - Filippo Diotalevi
Congrats and welcome aboard ! On Tue, Jun 30, 2009 at 15:19, Richard S. Hall wrote: > Hello, > > I wanted to let everyone know that Filippo Diotalevi has been accepted as a > new committer for his continued contributions around File Install, web site > documentation, and more. > > Keep up the good work, Filippo, and thanks for your contribution. > > -> richard > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: New committer - Filippo Diotalevi
Welcome on board ! Clement On 30.06.2009, at 15:19, Richard S. Hall wrote: Hello, I wanted to let everyone know that Filippo Diotalevi has been accepted as a new committer for his continued contributions around File Install, web site documentation, and more. Keep up the good work, Filippo, and thanks for your contribution. -> richard
[jira] Updated: (FELIX-1123) System bundle does still not correctly handle (export) package attributes
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-1123: --- Summary: System bundle does still not correctly handle (export) package attributes (was: [CLONED] System bundle does not correctly handle (export) package attributes) > System bundle does still not correctly handle (export) package attributes > - > > Key: FELIX-1123 > URL: https://issues.apache.org/jira/browse/FELIX-1123 > Project: Felix > Issue Type: Bug > Components: Framework, Specification compliance >Affects Versions: felix-1.6.0 > Environment: java version "1.6.0_07" > Java(TM) SE Runtime Environment (build 1.6.0_07-b06) > Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode) > SunOS castor 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-V890 >Reporter: Alexander Berger >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > This issue is related to the follwing mailing list thread: > http://www.mail-archive.com/us...@felix.apache.org/msg03403.html > Section 3.5.5 of the OSGi core specification (4.1) states: > The Framework will automatically associate each package export definition > with the following attributes: > • bundle-symbolic-name - The bundle symbolic name of the exporting > bundle. In the case of a Fragment bundle, this is the host bundle's > symbolic > name. > • bundle-version - The bundle version of the exporting bundle. In the case > of a Fragment bundle, this is the host bundle's version. > > And section 3.6.5 specifies how these attributes must be applied when > resolving > packages. > Using Apache Felix Version 1.4.1 I have encountered the following behaviour > when using different approaches to import packages exported by the system > bundle > (org.apache.felix.framework respectively system.bundle) when using attribute > matching: > For the following test cases the bundle manifest of the system bundle looks > like > this: > Bundle-Version = 1.4.1 > Bundle-Name = System Bundle > Bundle-SymbolicName = org.apache.felix.framework > Export-Package = my.package; provider="xxx", ... > Test Case 1: >Import-Package: my.package;bundle-symbolic-name="system.bundle" > Result: Package my.package could not be resolved! > > > Test Case 2: >Import-Package: > my.package;bundle-symbolic-name="org.apache.felix.framework" > Result: Package my.package could not be resolved! > > > Test Case 3: >Import-Package: my.package;provider="xxx" > Result: Package my.package was resolved successfully. > > > Test Case 4: >DynamicImport-Package: *;bundle-symbolic-name="system.bundle" > Result: Package my.package could not be resolved (class not found at > runtime)! > > > Test Case 2: >DynamicImport-Package: *;bundle-symbolic-name="org.apache.felix.framework" > Result: Package my.package could not be resolved (class not found at > runtime)! > > > Test Case 3: >DynamicImport-Package: my.package;provider="xxx" > Result: Package my.package was resolved successfully (at runtime). > The same behaviour is also true for packages that are added to the list of > exported packages of the system bundle by extension bundles (fragment bundles > with extension:=framework). For such packages another problem arises as the > matching attributes as defined in the Export-Package header of the extension > bundle are not taken over by the system bundle. So for example if the > extension > bundle has the following export: >Export-Package my.package;provider="xxx";version="1.0.0" > Then the system bundle seems to discard the attribute "provider" but respects > the > version attribute: >Export-Package my.package;version="1.0.0" > So it looks as if the framework should be fixed to always add the automatic > attributes to > exported packages (as defined in 3.5.5). Furthermore it should also make sure > that all > other (non automatic) attributes are respected especially for exorts that are > added by > extension bundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1193) Implement org.osgi.framework.bundle.parent from RFC 132
[ https://issues.apache.org/jira/browse/FELIX-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1193. -- Resolution: Fixed Committed a patch for this. > Implement org.osgi.framework.bundle.parent from RFC 132 > --- > > Key: FELIX-1193 > URL: https://issues.apache.org/jira/browse/FELIX-1193 > Project: Felix > Issue Type: New Feature > Components: Framework, Specification compliance >Affects Versions: felix-1.8.0 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > The new standard framework launching and embedding API introduced a property > (org.osgi.framework.bundle.parent) to configure the class loader used for > boot delegation. We should modify Felix to support this property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1289) Support for FrameworkUtil.getBundle()
[ https://issues.apache.org/jira/browse/FELIX-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-1289: --- Fix Version/s: felix-2.0.0 > Support for FrameworkUtil.getBundle() > - > > Key: FELIX-1289 > URL: https://issues.apache.org/jira/browse/FELIX-1289 > Project: Felix > Issue Type: New Feature > Components: Framework, Specification compliance >Affects Versions: felix-1.8.1 >Reporter: Erin Schnabel > Fix For: felix-2.0.0 > > > java.lang.NoSuchMethodError: > org/osgi/framework/FrameworkUtil.getBundle(Ljava/lang/Class;)Lorg/osgi/framework/Bundle; > The new FrameworkUtil.getBundle method from the OSGi 4.2 core spec is not yet > supported in Felix ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UPnP base driver 0.8.0 version in JIRA
closed, btw next time first of all I'll change the priority to the right level ;-) regards, francesco Richard S. Hall ha scritto: On 6/30/09 5:12 PM, Francesco Furfari wrote: Hi Richard, you are right, it's my fault. I started to discuss the issue and I expected a feedback on the provided solution to close it. I simply forgot to properly manage it . The base driver has many other open issues we should check. I' m not in Italy now , let me come back and I'll review all the Jira stuff. Sorry again for the "impact" on all excellent work done in Felix. No problem. Just reminding everyone. :-) -> richard regards, francesco Richard S. Hall ha scritto: Hey guys, I just wanted to point out that the UPnP base driver version in JIRA has been released, but it still shows up in the open issues page because it has unresolved issues on it. If these issues are actually resolved, they should be updated. If they are not resolved, they should be moved off of this version, so it will stop showing up on the open issues page. If we are going to start to use JIRA to help us generate our release notes, we have to manage these versions better. I had noticed an older release of the framework accidentally listed an unresolved issue in its release notes. Oops. We want to avoid such things. Thanks. -> richard
Re: New committer - Filippo Diotalevi
Excellent. Success! On Tue, Jun 30, 2009 at 4:19 PM, Richard S. Hall wrote: > Hello, > > I wanted to let everyone know that Filippo Diotalevi has been accepted as a > new committer for his continued contributions around File Install, web site > documentation, and more. > > Keep up the good work, Filippo, and thanks for your contribution. > > -> richard > -- Alin Dreghiciu Software Developer - Looking for new projects! My profile: http://www.linkedin.com/in/alindreghiciu My blog: http://adreghiciu.blogspot.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development.
[jira] Closed: (FELIX-642) upnp event delivery to OSGi event listeners fails on random devices after a certain period of time
[ https://issues.apache.org/jira/browse/FELIX-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Furfari closed FELIX-642. --- Resolution: Fixed The issue has been solved by adding a synchronize block in the subscribe method in the base driver (see commit #68 - 13 Aug 2008). A better solution would imply the redisign of the renewer mechanism in the CyberDomo library. > upnp event delivery to OSGi event listeners fails on random devices after a > certain period of time > -- > > Key: FELIX-642 > URL: https://issues.apache.org/jira/browse/FELIX-642 > Project: Felix > Issue Type: Bug > Components: UPnP Subproject >Affects Versions: upnp-basedriver-0.8.0 >Reporter: Daniel Felsing >Priority: Blocker > Fix For: upnp-basedriver-0.8.0 > > > Ok...overall problem is as follows: > upnp event delivery to OSGi event listeners fails on random devices after a > certain period of time > Overall Environment Setup > - > - i have two hosts A and B => A is a Bridge exporting about 20 devices at the > moment (will get more - it's a X10 like system), B acts as a central server > for the devices (Smart Home implementation) > - A is a SensorBridge...and B a central controlpoint importing all those > devices > - both ends use upnpbasedriver 0.8 and extra bundle from felix project > - the two hosts are connected through a Gigabit Switch (NO WIRELESS USED!) > - all the devices on the server (so the central smart home controller) that > get imported get refined. They subscribe to the upnp device it refines to get > notified on event change. > - on the central server (Host B) i subscribe to UPnP Devices exported by Host > A using UPnPSubscriber Helper class of the extra bundle > Issues > -- > - "SOMETIMES" on INITIAL subscription not all devices get notified about the > initial status (devices get found properly though) > ( see also http://www.mail-archive.com/us...@felix.apache.org/msg01781.html > for that) > - after some time of operation random devices begin to fail - that > means..they do not get notified about event changes anymore, but devices are > still present (so they are still there as UPnPDevice instances in the central > server)... > => i had debug enabledand as i see i still receive the event-change > notifies on my Host B (=central server)if i "resubscribe" to the event > listener of the failed device everything works again (i dont need to restart > the whole basedriver or osgi framework to let it work again - just my > refining driver must be restarted which does the subscription to the devices > using UPnPSubscriber class) ... > SO this STILL GETS DELIVERED, but listeners do not get notified about the > change: > REQUEST= > NOTIFY /evetSub HTTP/1.0 > Content-Type: text/xml; charset="utf-8" > HOST: 192.168.0.5 > NT: upnp:event > NTS: upnp:propchange > SID: uuid:956d-a11b-fe88-e08e > SEQ: 0 > Content-Length: 165 > Connection: close > > > > off > > > > Tests: > - > - yes - every device exported by the upnpsensorbridge (=Host A) gets found by > the central server (=Host B) > - upnp tester of felix project experiences same issues > - the REFINED devices on the SERVER themselves are using the felix helper > class to subscribe to the events: > // create upnp listener - if evented is true > subscriber = new UPnPSubscriber(bundleContext, this); > subscriber.subscribeAllServicesOf(super.getUPnPDeviceUDN()); > - i also tried: EventListener test = new EventListener(); > servReg = > context.registerService(UPnPEventListener.class.getName(), test, null); > (so not using UPnPSubscriber) => same problem...so UPnPSubscriber may not be > the root of the problem > - the upnp device implementation on the host exporting the upnp devices ( > =Host A, sensorbridge) are using the following line to expose event notifier > // setup event notifier > notify_switch = new UPnPEventNotifier(context, this, > switchdevswitchservice, switchDev); > > Is it possible that my issue is connected to this one mentioned in the > cyberlink forum? > Stefano answered to it in the cyberlink forum!! > http://sourceforge.net/forum/forum.php?thread_id=1952657&forum_id=258158 > > if you need something else please contact me! :) -- This message is automatically generated by JIRA. - You can reply
Re: UPnP base driver 0.8.0 version in JIRA
On 6/30/09 5:12 PM, Francesco Furfari wrote: Hi Richard, you are right, it's my fault. I started to discuss the issue and I expected a feedback on the provided solution to close it. I simply forgot to properly manage it . The base driver has many other open issues we should check. I' m not in Italy now , let me come back and I'll review all the Jira stuff. Sorry again for the "impact" on all excellent work done in Felix. No problem. Just reminding everyone. :-) -> richard regards, francesco Richard S. Hall ha scritto: Hey guys, I just wanted to point out that the UPnP base driver version in JIRA has been released, but it still shows up in the open issues page because it has unresolved issues on it. If these issues are actually resolved, they should be updated. If they are not resolved, they should be moved off of this version, so it will stop showing up on the open issues page. If we are going to start to use JIRA to help us generate our release notes, we have to manage these versions better. I had noticed an older release of the framework accidentally listed an unresolved issue in its release notes. Oops. We want to avoid such things. Thanks. -> richard
Re: UPnP base driver 0.8.0 version in JIRA
Hi Richard, you are right, it's my fault. I started to discuss the issue and I expected a feedback on the provided solution to close it. I simply forgot to properly manage it . The base driver has many other open issues we should check. I' m not in Italy now , let me come back and I'll review all the Jira stuff. Sorry again for the "impact" on all excellent work done in Felix. regards, francesco Richard S. Hall ha scritto: Hey guys, I just wanted to point out that the UPnP base driver version in JIRA has been released, but it still shows up in the open issues page because it has unresolved issues on it. If these issues are actually resolved, they should be updated. If they are not resolved, they should be moved off of this version, so it will stop showing up on the open issues page. If we are going to start to use JIRA to help us generate our release notes, we have to manage these versions better. I had noticed an older release of the framework accidentally listed an unresolved issue in its release notes. Oops. We want to avoid such things. Thanks. -> richard
[jira] Resolved: (FELIX-1266) [gogo] Provide a maven build for gogo
[ https://issues.apache.org/jira/browse/FELIX-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1266. Resolution: Fixed I've tried to put gogo in a usable state with maven. The structure is kinda the same as for the shell subproject, though we might want to add a new module for the telnet stuff. And thx for the patch, Filippo ! URL: http://svn.apache.org/viewvc?rev=789948&view=rev > [gogo] Provide a maven build for gogo > - > > Key: FELIX-1266 > URL: https://issues.apache.org/jira/browse/FELIX-1266 > Project: Felix > Issue Type: Task > Components: Gogo >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Attachments: build.xml, FELIX-1266.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1289) Support for FrameworkUtil.getBundle()
Support for FrameworkUtil.getBundle() - Key: FELIX-1289 URL: https://issues.apache.org/jira/browse/FELIX-1289 Project: Felix Issue Type: New Feature Components: Framework, Specification compliance Affects Versions: felix-1.8.1 Reporter: Erin Schnabel java.lang.NoSuchMethodError: org/osgi/framework/FrameworkUtil.getBundle(Ljava/lang/Class;)Lorg/osgi/framework/Bundle; The new FrameworkUtil.getBundle method from the OSGi 4.2 core spec is not yet supported in Felix ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-33) Implement system bundle update
[ https://issues.apache.org/jira/browse/FELIX-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-33. Resolution: Fixed Fix Version/s: felix-2.0.0 Assignee: Richard S. Hall Committed an initial pass at this. > Implement system bundle update > -- > > Key: FELIX-33 > URL: https://issues.apache.org/jira/browse/FELIX-33 > Project: Felix > Issue Type: New Feature > Components: Framework, Specification compliance >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > This issue is described in section 4.5 of the OSGi R4 specification. When the > system bundle is updated, the framework is supposed to shutdown and restart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1286) Module class loader should use secure action instead of a privileged block
[ https://issues.apache.org/jira/browse/FELIX-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1286. -- Resolution: Fixed Committed a fix. > Module class loader should use secure action instead of a privileged block > -- > > Key: FELIX-1286 > URL: https://issues.apache.org/jira/browse/FELIX-1286 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.8.1 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > Due to some refactoring, the module class loader was no longer being created > in a privileged block, which was causing difficulties when running Felix with > the security manager enabled. The refactoring made our existing SecureAction > approach for performing secure actions in feasible (because the class loader > became an instance inner class and cannot be created externally anymore). For > Felix 1.8.1, we just simply wrapped it in a doPrivileged() block, but we > should change this to use SecureAction operations like getting the > constructor and invoking it. This may require we add some operations to > SecureAction or reorganize the existing ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1288) System bundle context should be null after stopping the framework
[ https://issues.apache.org/jira/browse/FELIX-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1288. -- Resolution: Fixed Committed a fix. > System bundle context should be null after stopping the framework > - > > Key: FELIX-1288 > URL: https://issues.apache.org/jira/browse/FELIX-1288 > Project: Felix > Issue Type: Bug > Components: Framework, Specification compliance >Affects Versions: felix-1.8.1 >Reporter: Richard S. Hall >Assignee: Richard S. Hall >Priority: Minor > Fix For: felix-2.0.0 > > > We need to invalidate and null the system bundle's context as part of > framework shutdown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1288) System bundle context should be null after stopping the framework
System bundle context should be null after stopping the framework - Key: FELIX-1288 URL: https://issues.apache.org/jira/browse/FELIX-1288 Project: Felix Issue Type: Bug Components: Framework, Specification compliance Affects Versions: felix-1.8.1 Reporter: Richard S. Hall Assignee: Richard S. Hall Priority: Minor Fix For: felix-2.0.0 We need to invalidate and null the system bundle's context as part of framework shutdown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1285) SecureAction captures the calling context incorrectly
[ https://issues.apache.org/jira/browse/FELIX-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1285. -- Resolution: Fixed I committed a fix for this. > SecureAction captures the calling context incorrectly > - > > Key: FELIX-1285 > URL: https://issues.apache.org/jira/browse/FELIX-1285 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.8.1 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > In SecureAction we capture the calling context for optimization purposes, but > the context captures the current stack no matter who is on the stack. Since > the whole point of SecureAction is to allow the framework to perform > sensitive operations without worrying about who is on the call stack, this > seems to be a bug since there could be someone with lower privileges on the > stack. I think we need to capture the calling context inside a privileged > block. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1285) SecureAction captures the calling context incorrectly
[ https://issues.apache.org/jira/browse/FELIX-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reassigned FELIX-1285: -- Assignee: Richard S. Hall (was: Karl Pauls) > SecureAction captures the calling context incorrectly > - > > Key: FELIX-1285 > URL: https://issues.apache.org/jira/browse/FELIX-1285 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.8.1 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > In SecureAction we capture the calling context for optimization purposes, but > the context captures the current stack no matter who is on the stack. Since > the whole point of SecureAction is to allow the framework to perform > sensitive operations without worrying about who is on the call stack, this > seems to be a bug since there could be someone with lower privileges on the > stack. I think we need to capture the calling context inside a privileged > block. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1287) System bundle operations from RFC-132 (e.g., init(), start(), stop(), waitForStop()) are using wrong lock object
[ https://issues.apache.org/jira/browse/FELIX-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1287. -- Resolution: Fixed I committed a fix for this. > System bundle operations from RFC-132 (e.g., init(), start(), stop(), > waitForStop()) are using wrong lock object > > > Key: FELIX-1287 > URL: https://issues.apache.org/jira/browse/FELIX-1287 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.8.1 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > The system bundle uses "this" as the lock object for performing operations on > its state. For normal bundles, we acquire bundle locks, so we should probably > do the same for the system bundle for consistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
UPnP base driver 0.8.0 version in JIRA
Hey guys, I just wanted to point out that the UPnP base driver version in JIRA has been released, but it still shows up in the open issues page because it has unresolved issues on it. If these issues are actually resolved, they should be updated. If they are not resolved, they should be moved off of this version, so it will stop showing up on the open issues page. If we are going to start to use JIRA to help us generate our release notes, we have to manage these versions better. I had noticed an older release of the framework accidentally listed an unresolved issue in its release notes. Oops. We want to avoid such things. Thanks. -> richard
[jira] Created: (FELIX-1287) System bundle operations from RFC-132 (e.g., init(), start(), stop(), waitForStop()) are using wrong lock object
System bundle operations from RFC-132 (e.g., init(), start(), stop(), waitForStop()) are using wrong lock object Key: FELIX-1287 URL: https://issues.apache.org/jira/browse/FELIX-1287 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.8.1 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: felix-2.0.0 The system bundle uses "this" as the lock object for performing operations on its state. For normal bundles, we acquire bundle locks, so we should probably do the same for the system bundle for consistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1193) Implement org.osgi.framework.bundle.parent from RFC 132
[ https://issues.apache.org/jira/browse/FELIX-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reassigned FELIX-1193: -- Assignee: Richard S. Hall > Implement org.osgi.framework.bundle.parent from RFC 132 > --- > > Key: FELIX-1193 > URL: https://issues.apache.org/jira/browse/FELIX-1193 > Project: Felix > Issue Type: New Feature > Components: Framework, Specification compliance >Affects Versions: felix-1.8.0 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > The new standard framework launching and embedding API introduced a property > (org.osgi.framework.bundle.parent) to configure the class loader used for > boot delegation. We should modify Felix to support this property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1286) Module class loader should use secure action instead of a privileged block
[ https://issues.apache.org/jira/browse/FELIX-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-1286: --- Description: Due to some refactoring, the module class loader was no longer being created in a privileged block, which was causing difficulties when running Felix with the security manager enabled. The refactoring made our existing SecureAction approach for performing secure actions in feasible (because the class loader became an instance inner class and cannot be created externally anymore). For Felix 1.8.1, we just simply wrapped it in a doPrivileged() block, but we should change this to use SecureAction operations like getting the constructor and invoking it. This may require we add some operations to SecureAction or reorganize the existing ones. (was: Due to some refactoring, the module class loader is no longer being created in a privileged block. Since creating a secure class loader is a protected operation, this is causing difficulties when running Felix with the security manager enabled. The refactoring made our existing SecureAction approach for performing secure actions in feasible (because the class loader became an instance inner class and cannot be created externally anymore). We need to think of a new way to do this, but at a minimum we should just put a doPriv() block right in the ModuleImpl class.) Affects Version/s: (was: felix-1.6.1) (was: felix-1.8.0) (was: felix-1.6.0) felix-1.8.1 Fix Version/s: (was: felix-1.8.1) felix-2.0.0 > Module class loader should use secure action instead of a privileged block > -- > > Key: FELIX-1286 > URL: https://issues.apache.org/jira/browse/FELIX-1286 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.8.1 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > Due to some refactoring, the module class loader was no longer being created > in a privileged block, which was causing difficulties when running Felix with > the security manager enabled. The refactoring made our existing SecureAction > approach for performing secure actions in feasible (because the class loader > became an instance inner class and cannot be created externally anymore). For > Felix 1.8.1, we just simply wrapped it in a doPrivileged() block, but we > should change this to use SecureAction operations like getting the > constructor and invoking it. This may require we add some operations to > SecureAction or reorganize the existing ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1286) Module class loader should use secure action instead of a privileged block
Module class loader should use secure action instead of a privileged block -- Key: FELIX-1286 URL: https://issues.apache.org/jira/browse/FELIX-1286 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.6.0, felix-1.6.1, felix-1.8.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: felix-1.8.1 Due to some refactoring, the module class loader is no longer being created in a privileged block. Since creating a secure class loader is a protected operation, this is causing difficulties when running Felix with the security manager enabled. The refactoring made our existing SecureAction approach for performing secure actions in feasible (because the class loader became an instance inner class and cannot be created externally anymore). We need to think of a new way to do this, but at a minimum we should just put a doPriv() block right in the ModuleImpl class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1124) ResourceNotFoundException too verbose
[
https://issues.apache.org/jira/browse/FELIX-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725650#action_12725650
]
Richard S. Hall edited comment on FELIX-1124 at 6/30/09 7:42 AM:
-
Thomas, I created the following bundle activator:
public class Activator implements BundleActivator
{
public void start(final BundleContext context) throws Exception
{
getClass().getClassLoader().getResourceAsStream("does/not/exist.txt");
}
public void stop(BundleContext context)
{
}
}
When I run this in Felix I get:
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [0] System Bundle (1.9.0.SNAPSHOT)
[ 1] [Active ] [1] Apache Felix Shell Service (1.3.0.SNAPSHOT)
[ 2] [Active ] [1] Apache Felix Shell TUI (1.3.0.SNAPSHOT)
[ 3] [Active ] [1] Apache Felix Bundle Repository (1.5.0.SNAPSHOT)
[ 5] [Installed ] [1] test.logger
-> start 5
DEBUG: WIRE: 5.0 -> org.osgi.framework -> 0
DEBUG: does/not/exist.txt
(org.apache.felix.moduleloader.ResourceNotFoundException: does/not/exist.txt)
->
I do not get a stack trace, which is what I would expect from the code for
Logger. Are you passing in a Logger instance to Felix when you construct it or
are you just using Felix' launcher? If the former, I would have to assume that
the passed in logger is printing the stack trace.
Let me know if I am missing something.
was (Author: rickhall):
Thomas, I created the following bundle activator:
public class Activator implements BundleActivator
{
public void start(final BundleContext context) throws Exception
{
getClass().getClassLoader().getResourceAsStream("does/not/exist.txt");
}
public void stop(BundleContext context)
{
}
}
When I run this in Felix I get:
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [0] System Bundle (1.9.0.SNAPSHOT)
[ 1] [Active ] [1] Apache Felix Shell Service (1.3.0.SNAPSHOT)
[ 2] [Active ] [1] Apache Felix Shell TUI (1.3.0.SNAPSHOT)
[ 3] [Active ] [1] Apache Felix Bundle Repository (1.5.0.SNAPSHOT)
[ 5] [Installed ] [1] test.logger
-> start 5
DEBUG: WIRE: 5.0 -> org.osgi.framework -> 0
DEBUG: does/not/exist.txt
(org.apache.felix.moduleloader.ResourceNotFoundException: does/not/exist.txt)
->
I do not get a stack trace, which is what I would expect from the code for
Logger. Are you passing in a Logger instance to Felix when you construct it or
are you just using Felix' launcher? If the former, I would have to assume that
the passed in launcher is printing the stack trace.
Let me know if I am missing something.
> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0, felix-1.8.1
>Reporter: Thomas Diesler
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often
> resources are optional or may be located at different locations.
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client
> to be more verbose when appropriate.
> To log no message at all and simply return null would also be consistent with
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1124) ResourceNotFoundException too verbose
[
https://issues.apache.org/jira/browse/FELIX-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725650#action_12725650
]
Richard S. Hall commented on FELIX-1124:
Thomas, I created the following bundle activator:
public class Activator implements BundleActivator
{
public void start(final BundleContext context) throws Exception
{
getClass().getClassLoader().getResourceAsStream("does/not/exist.txt");
}
public void stop(BundleContext context)
{
}
}
When I run this in Felix I get:
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [0] System Bundle (1.9.0.SNAPSHOT)
[ 1] [Active ] [1] Apache Felix Shell Service (1.3.0.SNAPSHOT)
[ 2] [Active ] [1] Apache Felix Shell TUI (1.3.0.SNAPSHOT)
[ 3] [Active ] [1] Apache Felix Bundle Repository (1.5.0.SNAPSHOT)
[ 5] [Installed ] [1] test.logger
-> start 5
DEBUG: WIRE: 5.0 -> org.osgi.framework -> 0
DEBUG: does/not/exist.txt
(org.apache.felix.moduleloader.ResourceNotFoundException: does/not/exist.txt)
->
I do not get a stack trace, which is what I would expect from the code for
Logger. Are you passing in a Logger instance to Felix when you construct it or
are you just using Felix' launcher? If the former, I would have to assume that
the passed in launcher is printing the stack trace.
Let me know if I am missing something.
> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0, felix-1.8.1
>Reporter: Thomas Diesler
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often
> resources are optional or may be located at different locations.
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client
> to be more verbose when appropriate.
> To log no message at all and simply return null would also be consistent with
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: New committer - Filippo Diotalevi
Filippo, Many congratulations. Sahoo Toni Menzel wrote: Congrats, man ! On Tue, Jun 30, 2009 at 3:55 PM, Felix Meschberger wrote: Welcome to the team, Filippo ! Regards Felix Richard S. Hall schrieb: Hello, I wanted to let everyone know that Filippo Diotalevi has been accepted as a new committer for his continued contributions around File Install, web site documentation, and more. Keep up the good work, Filippo, and thanks for your contribution. -> richard
Re: New committer - Filippo Diotalevi
Congrats, man ! On Tue, Jun 30, 2009 at 3:55 PM, Felix Meschberger wrote: > Welcome to the team, Filippo ! > > Regards > Felix > > Richard S. Hall schrieb: >> Hello, >> >> I wanted to let everyone know that Filippo Diotalevi has been accepted >> as a new committer for his continued contributions around File Install, >> web site documentation, and more. >> >> Keep up the good work, Filippo, and thanks for your contribution. >> >> -> richard >> > -- Toni Menzel Independent Software Developer Professional Profile: http://okidokiteam.com t...@okidokiteam.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
Re: New committer - Filippo Diotalevi
Welcome to the team, Filippo ! Regards Felix Richard S. Hall schrieb: > Hello, > > I wanted to let everyone know that Filippo Diotalevi has been accepted > as a new committer for his continued contributions around File Install, > web site documentation, and more. > > Keep up the good work, Filippo, and thanks for your contribution. > > -> richard >
Re: New committer - Filippo Diotalevi
Many congrats Filippo ! --Jools 2009/6/30 Richard S. Hall > Hello, > > I wanted to let everyone know that Filippo Diotalevi has been accepted as a > new committer for his continued contributions around File Install, web site > documentation, and more. > > Keep up the good work, Filippo, and thanks for your contribution. > > -> richard >
New committer - Filippo Diotalevi
Hello, I wanted to let everyone know that Filippo Diotalevi has been accepted as a new committer for his continued contributions around File Install, web site documentation, and more. Keep up the good work, Filippo, and thanks for your contribution. -> richard
Re: Felix Wiki
This had corrected itself, but now it is doing it again. Does anyone have any idea what is going on? -> richard On 6/12/09 11:44 AM, Richard S. Hall wrote: Strange situation. When I go to the index page: http://cwiki.apache.org/confluence/display/FELIX/Index It used to show me the child pages at the bottom. I could then get to the documentation page, etc. Now it doesn't display them, so I have no way to get there from here. Does anyone have any idea what changed? -> richard
Re: Apache Karaf & Spring DM : consider taking a snapshot and then shutdown the VM in case the thread still hangs
I tought that there was a specific option in apache karaf ;-) Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com On Tue, Jun 30, 2009 at 2:33 PM, Guillaume Nodet wrote: > Try googling for "java thread dump" and you'll find the answer. > > On Tue, Jun 30, 2009 at 13:50, Charles Moulliard > wrote: > > How can I achieve this ? > > > > Charles Moulliard > > Senior Enterprise Architect > > Apache Camel Committer > > > > * > > blog : http://cmoulliard.blogspot.com > > > > > > On Tue, Jun 30, 2009 at 1:42 PM, Guillaume Nodet > wrote: > > > >> Could you grab a thread dump of the vm when the shutdown is waiting ? > >> There must be a deadlock somewhere but without any thread dump, it's > >> kinda impossible to see what happen. > >> > >> On Tue, Jun 30, 2009 at 13:25, Charles Moulliard > >> wrote: > >> > Hi, > >> > > >> > When Camel tries to stop one of its context, the following message is > >> > displayed in the log: > >> > > >> > 13:10:59,213 | INFO | Timer-2 | DefaultCamelContext > >> | > >> > e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT > >> > (CamelContext:InToOut) is stopping > >> > 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext > >> | > >> > e.camel.impl.DefaultCamelContext 975 | Apache Camel 2.0-SNAPSHOT > >> > (CamelContext:InToOut) stopped > >> > 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext > >> | > >> > e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT > >> > (CamelContext:OutToIn) is stopping > >> > *13:11:09,181 | ERROR | Thread-47| RunnableTimedExecution > >> > | oncurrent.RunnableTimedExecution 109 | Closing runnable for context > >> > OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-core, > >> > config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; > >> > consider taking a snapshot and then shutdown the VM in case the thread > >> still > >> > hangs > >> > 13:11:19,181 | ERROR | Thread-47| RunnableTimedExecution > >> | > >> > oncurrent.RunnableTimedExecution 109 | Closing runnable for context > >> > OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-service, > >> > config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; > >> > consider taking a snapshot and then shutdown the VM in case the thread > >> still > >> > hangs* > >> > > >> > It seems to be related to the following Spring DM error : > >> > http://jira.springframework.org/browse/OSGI-611 but I use Spring OSGI > >> 1.2 > >> > and the error is still there > >> > > >> > Does anybody knows how to solve this ? > >> > > >> > Regards, > >> > > >> > Charles Moulliard > >> > Senior Enterprise Architect > >> > Apache Camel Committer > >> > > >> > * > >> > blog : http://cmoulliard.blogspot.com > >> > > >> > >> > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> > >> Blog: http://gnodet.blogspot.com/ > >> > >> Open Source SOA > >> http://fusesource.com > >> > > > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com >
Re: Apache Karaf & Spring DM : consider taking a snapshot and then shutdown the VM in case the thread still hangs
Try googling for "java thread dump" and you'll find the answer. On Tue, Jun 30, 2009 at 13:50, Charles Moulliard wrote: > How can I achieve this ? > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > * > blog : http://cmoulliard.blogspot.com > > > On Tue, Jun 30, 2009 at 1:42 PM, Guillaume Nodet wrote: > >> Could you grab a thread dump of the vm when the shutdown is waiting ? >> There must be a deadlock somewhere but without any thread dump, it's >> kinda impossible to see what happen. >> >> On Tue, Jun 30, 2009 at 13:25, Charles Moulliard >> wrote: >> > Hi, >> > >> > When Camel tries to stop one of its context, the following message is >> > displayed in the log: >> > >> > 13:10:59,213 | INFO | Timer-2 | DefaultCamelContext >> | >> > e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT >> > (CamelContext:InToOut) is stopping >> > 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext >> | >> > e.camel.impl.DefaultCamelContext 975 | Apache Camel 2.0-SNAPSHOT >> > (CamelContext:InToOut) stopped >> > 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext >> | >> > e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT >> > (CamelContext:OutToIn) is stopping >> > *13:11:09,181 | ERROR | Thread-47 | RunnableTimedExecution >> > | oncurrent.RunnableTimedExecution 109 | Closing runnable for context >> > OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-core, >> > config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; >> > consider taking a snapshot and then shutdown the VM in case the thread >> still >> > hangs >> > 13:11:19,181 | ERROR | Thread-47 | RunnableTimedExecution >> | >> > oncurrent.RunnableTimedExecution 109 | Closing runnable for context >> > OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-service, >> > config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; >> > consider taking a snapshot and then shutdown the VM in case the thread >> still >> > hangs* >> > >> > It seems to be related to the following Spring DM error : >> > http://jira.springframework.org/browse/OSGI-611 but I use Spring OSGI >> 1.2 >> > and the error is still there >> > >> > Does anybody knows how to solve this ? >> > >> > Regards, >> > >> > Charles Moulliard >> > Senior Enterprise Architect >> > Apache Camel Committer >> > >> > * >> > blog : http://cmoulliard.blogspot.com >> > >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Apache Karaf & Spring DM : consider taking a snapshot and then shutdown the VM in case the thread still hangs
How can I achieve this ? Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com On Tue, Jun 30, 2009 at 1:42 PM, Guillaume Nodet wrote: > Could you grab a thread dump of the vm when the shutdown is waiting ? > There must be a deadlock somewhere but without any thread dump, it's > kinda impossible to see what happen. > > On Tue, Jun 30, 2009 at 13:25, Charles Moulliard > wrote: > > Hi, > > > > When Camel tries to stop one of its context, the following message is > > displayed in the log: > > > > 13:10:59,213 | INFO | Timer-2 | DefaultCamelContext > | > > e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT > > (CamelContext:InToOut) is stopping > > 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext > | > > e.camel.impl.DefaultCamelContext 975 | Apache Camel 2.0-SNAPSHOT > > (CamelContext:InToOut) stopped > > 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext > | > > e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT > > (CamelContext:OutToIn) is stopping > > *13:11:09,181 | ERROR | Thread-47| RunnableTimedExecution > > | oncurrent.RunnableTimedExecution 109 | Closing runnable for context > > OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-core, > > config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; > > consider taking a snapshot and then shutdown the VM in case the thread > still > > hangs > > 13:11:19,181 | ERROR | Thread-47| RunnableTimedExecution > | > > oncurrent.RunnableTimedExecution 109 | Closing runnable for context > > OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-service, > > config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; > > consider taking a snapshot and then shutdown the VM in case the thread > still > > hangs* > > > > It seems to be related to the following Spring DM error : > > http://jira.springframework.org/browse/OSGI-611 but I use Spring OSGI > 1.2 > > and the error is still there > > > > Does anybody knows how to solve this ? > > > > Regards, > > > > Charles Moulliard > > Senior Enterprise Architect > > Apache Camel Committer > > > > * > > blog : http://cmoulliard.blogspot.com > > > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com >
Re: Apache Karaf & Spring DM : consider taking a snapshot and then shutdown the VM in case the thread still hangs
Could you grab a thread dump of the vm when the shutdown is waiting ? There must be a deadlock somewhere but without any thread dump, it's kinda impossible to see what happen. On Tue, Jun 30, 2009 at 13:25, Charles Moulliard wrote: > Hi, > > When Camel tries to stop one of its context, the following message is > displayed in the log: > > 13:10:59,213 | INFO | Timer-2 | DefaultCamelContext | > e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT > (CamelContext:InToOut) is stopping > 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext | > e.camel.impl.DefaultCamelContext 975 | Apache Camel 2.0-SNAPSHOT > (CamelContext:InToOut) stopped > 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext | > e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT > (CamelContext:OutToIn) is stopping > *13:11:09,181 | ERROR | Thread-47 | RunnableTimedExecution > | oncurrent.RunnableTimedExecution 109 | Closing runnable for context > OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-core, > config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; > consider taking a snapshot and then shutdown the VM in case the thread still > hangs > 13:11:19,181 | ERROR | Thread-47 | RunnableTimedExecution | > oncurrent.RunnableTimedExecution 109 | Closing runnable for context > OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-service, > config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; > consider taking a snapshot and then shutdown the VM in case the thread still > hangs* > > It seems to be related to the following Spring DM error : > http://jira.springframework.org/browse/OSGI-611 but I use Spring OSGI 1.2 > and the error is still there > > Does anybody knows how to solve this ? > > Regards, > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > * > blog : http://cmoulliard.blogspot.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Apache Karaf & Spring DM : consider taking a snapshot and then shutdown the VM in case the thread still hangs
Hi, When Camel tries to stop one of its context, the following message is displayed in the log: 13:10:59,213 | INFO | Timer-2 | DefaultCamelContext | e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT (CamelContext:InToOut) is stopping 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext | e.camel.impl.DefaultCamelContext 975 | Apache Camel 2.0-SNAPSHOT (CamelContext:InToOut) stopped 13:11:00,244 | INFO | Timer-2 | DefaultCamelContext | e.camel.impl.DefaultCamelContext 965 | Apache Camel 2.0-SNAPSHOT (CamelContext:OutToIn) is stopping *13:11:09,181 | ERROR | Thread-47| RunnableTimedExecution | oncurrent.RunnableTimedExecution 109 | Closing runnable for context OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-core, config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; consider taking a snapshot and then shutdown the VM in case the thread still hangs 13:11:19,181 | ERROR | Thread-47| RunnableTimedExecution | oncurrent.RunnableTimedExecution 109 | Closing runnable for context OsgiBundleXmlApplicationContext(bundle=com.xpectis.x3s.x3s-service, config=osgibundle:/META-INF/spring/*.xml) did not finish in 1ms; consider taking a snapshot and then shutdown the VM in case the thread still hangs* It seems to be related to the following Spring DM error : http://jira.springframework.org/browse/OSGI-611 but I use Spring OSGI 1.2 and the error is still there Does anybody knows how to solve this ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com
[jira] Issue Comment Edited: (FELIX-1124) ResourceNotFoundException too verbose
[
https://issues.apache.org/jira/browse/FELIX-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725540#action_12725540
]
Thomas Diesler edited comment on FELIX-1124 at 6/30/09 2:29 AM:
Also affects 1.8.1
was (Author: tdiesler):
Also effects 1.8.1
> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0, felix-1.8.1
>Reporter: Thomas Diesler
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often
> resources are optional or may be located at different locations.
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client
> to be more verbose when appropriate.
> To log no message at all and simply return null would also be consistent with
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1124) ResourceNotFoundException too verbose
[
https://issues.apache.org/jira/browse/FELIX-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Diesler updated FELIX-1124:
--
Affects Version/s: felix-1.8.1
Also effects 1.8.1
> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0, felix-1.8.1
>Reporter: Thomas Diesler
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often
> resources are optional or may be located at different locations.
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client
> to be more verbose when appropriate.
> To log no message at all and simply return null would also be consistent with
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
