[jira] [Commented] (FELIX-3171) felix src annotations : the future?
[ https://issues.apache.org/jira/browse/FELIX-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509290#comment-13509290 ] Toni Menzel commented on FELIX-3171: I also just stumbled over this. Whats the status about making org.osgi.service.component.annotations.* annotations recognized in felix scr plugin ? felix src annotations : the future? --- Key: FELIX-3171 URL: https://issues.apache.org/jira/browse/FELIX-3171 Project: Felix Issue Type: Bug Reporter: Andrei Pozolotin can someone in the know please comment on the future of : 1) felix src annotations: http://felix.apache.org/site/scr-annotations.html 2) felix src annotations plugin: http://felix.apache.org/site/apache-felix-maven-scr-plugin.html in the context of RFC 0172 http://www.osgi.org/download/osgi-early-draft-2011-09.pdf ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991390#comment-12991390 ] Toni Menzel commented on FELIX-2826: Though this is nothing about OSGi at all. Its just Eclipse trying to follow the entire call stack of a library you are using. So this is a generic thing to remember (and to know). Just out of curiosity, which maven eclipse integration do you use ? Would believe M2Eclipse takes care of this transitive dependency. LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-1728) Karaf itest fail on IBM JDK due to Pax Exam annotations not found
[ https://issues.apache.org/jira/browse/FELIX-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763967#action_12763967 ] Toni Menzel commented on FELIX-1728: We just added this http://paxexam.ops4j.org/space/FAQ cause it's a bug in IBM JDK. Karaf itest fail on IBM JDK due to Pax Exam annotations not found - Key: FELIX-1728 URL: https://issues.apache.org/jira/browse/FELIX-1728 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.2 Due to a difference in the way the IBM JDK handles annotations (it fails on annotations not on the classpath instead of ignoring them), the following tests fail: org.apache.felix.karaf.shell.itests.FeaturesTest.testFeatures [equinox] org.apache.felix.karaf.shell.itests.CoreTest.testHelp [equinox] org.apache.felix.karaf.shell.itests.CoreTest.testInstallCommand [equinox] Cfr. http://lists.ops4j.org/pipermail/general/2009q4/003296.html for background information the error looks like this: java.lang.TypeNotPresentException: Type org.ops4j.pax.exam.junit.Configuration not present at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38) at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50) at com.ibm.oti.reflect.Method.getDeclaredAnnotations(Method.java:31) at java.lang.reflect.Method.getDeclaredAnnotations(Method.java:722) at java.lang.reflect.AccessibleObject.getAnnotations(AccessibleObject.java:191) at com.ibm.oti.reflect.Method.getAnnotation(Method.java:20) at java.lang.reflect.Method.getAnnotation(Method.java:711) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.getAnnotatedMethods(CallableTestMethodImpl.java:295) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.runBefores(CallableTestMethodImpl.java:162) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:124) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:279) at sun.rmi.transport.Transport.serviceCall(Transport.java:164) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912) at java.lang.Thread.run(Thread.java:810) Caused by: java.lang.ClassNotFoundException: org.ops4j.pax.exam.junit.Configuration at java.lang.Class.forName(Class.java:163) at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33) ... 27 more The test launches okay, but the pax Configuration annotation class cannot be found. Adding the jar that contains the class, pax-exam-junit as a bundle in the test when we detect that we are using the ibm jdk allows the test to pass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1305) DPs with Bundles having parametrized SymbolicNames throw Exception
[ https://issues.apache.org/jira/browse/FELIX-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762955#action_12762955 ] Toni Menzel commented on FELIX-1305: Yep, works. Sorry for being so late. Somehow the comment/patched applied hasn't received my mailbox.. or so ;) DPs with Bundles having parametrized SymbolicNames throw Exception -- Key: FELIX-1305 URL: https://issues.apache.org/jira/browse/FELIX-1305 Project: Felix Issue Type: Bug Components: Deployment Admin Reporter: Toni Menzel Assignee: Marcel Offermans Attachments: felix-deploymentadmin-symbolicname.patch For example: Bundle-SymbolicName=foo;singleton=true never matches installed bundle headers unless parameters are stripped. (Patch) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1305) DPs with Bundles having parametrized SymbolicNames throw Exception
DPs with Bundles having parametrized SymbolicNames throw Exception -- Key: FELIX-1305 URL: https://issues.apache.org/jira/browse/FELIX-1305 Project: Felix Issue Type: Bug Components: Deployment Admin Reporter: Toni Menzel For example: Bundle-SymbolicName=foo;singleton=true never matches installed bundle headers unless parameters are stripped. (Patch) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1305) DPs with Bundles having parametrized SymbolicNames throw Exception
[ https://issues.apache.org/jira/browse/FELIX-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-1305: --- Attachment: felix-deploymentadmin-symbolicname.patch DPs with Bundles having parametrized SymbolicNames throw Exception -- Key: FELIX-1305 URL: https://issues.apache.org/jira/browse/FELIX-1305 Project: Felix Issue Type: Bug Components: Deployment Admin Reporter: Toni Menzel Attachments: felix-deploymentadmin-symbolicname.patch For example: Bundle-SymbolicName=foo;singleton=true never matches installed bundle headers unless parameters are stripped. (Patch) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1306) getDataFile handling in DeploymentSessionImpl sometimes does not work
getDataFile handling in DeploymentSessionImpl sometimes does not work - Key: FELIX-1306 URL: https://issues.apache.org/jira/browse/FELIX-1306 Project: Felix Issue Type: Improvement Components: Deployment Admin Reporter: Toni Menzel Attachments: felix-deploymentadmim-deploymentsession-datafile.patch This is not really a bug but can be improved. Getting BundleContext from Bundle instance via reflection currently does not catch all bundle implementations. To be safe, a second lookup with getMethods(..) is done. Also this component (amongst others) can really need some documentation. Some (for class under patch) has been added (like reference to corresponding specs because osgi-API is not really dead clear at that point). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1306) getDataFile handling in DeploymentSessionImpl sometimes does not work
[ https://issues.apache.org/jira/browse/FELIX-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-1306: --- Attachment: felix-deploymentadmim-deploymentsession-datafile.patch includes an extended hunt for getBundleContext methods via reflection and some more docs. getDataFile handling in DeploymentSessionImpl sometimes does not work - Key: FELIX-1306 URL: https://issues.apache.org/jira/browse/FELIX-1306 Project: Felix Issue Type: Improvement Components: Deployment Admin Reporter: Toni Menzel Attachments: felix-deploymentadmim-deploymentsession-datafile.patch This is not really a bug but can be improved. Getting BundleContext from Bundle instance via reflection currently does not catch all bundle implementations. To be safe, a second lookup with getMethods(..) is done. Also this component (amongst others) can really need some documentation. Some (for class under patch) has been added (like reference to corresponding specs because osgi-API is not really dead clear at that point). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1307) Log situation in DeploymentAdmin impl very unclear
Log situation in DeploymentAdmin impl very unclear -- Key: FELIX-1307 URL: https://issues.apache.org/jira/browse/FELIX-1307 Project: Felix Issue Type: Improvement Components: Deployment Admin Reporter: Toni Menzel Priority: Trivial e.g. StartBundleCommand.java : has this: // TODO: m_log.log(LogService.LOG_DEBUG, won't wait for Packages refreshed event, event is already received); all over the place. And not just this one. Question: what is the intend of commenting this out ? What is the plan here ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-528) Support nested folders in fileinstall
[ https://issues.apache.org/jira/browse/FELIX-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601132#action_12601132 ] Toni Menzel commented on FELIX-528: --- Does ANYONE care about this NEW (for felix) component anymore ? I mean, there are some rather trivial patches flying arround Jira in this component now since nearly two months. Since nobody commits or rejects those patches, i don't see chances for bigger enhancements to be added as well. So, it would be nice if somebody could clarify the future of this component in felix ? Otherwise i would suggest other place for this component with lower barriers of entry to make things happen. (?) Toni Support nested folders in fileinstall - Key: FELIX-528 URL: https://issues.apache.org/jira/browse/FELIX-528 Project: Felix Issue Type: New Feature Components: File Install Reporter: Toni Menzel Priority: Minor Attachments: FELIX-528.patch Currently FileInstall just supports flat jar-Files as bundles in its load folder. How about supporting (nested) folders? This way, you could: 1. just drop an arbitrary folder structure and fileinstall would install all bundles inside. 2. you could enable/disable entire bundle-sets with: 2a. in/move it out of the folder 2b. rename the folder with prefix that means unrecognized folder Just a thought.. Toni -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-534) Allow filtering by status in ps command (shell)
[ https://issues.apache.org/jira/browse/FELIX-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-534: -- Attachment: FELIX-534_2.patch well, you are right. I implemented a unix style piping mechanism on top of the current Command implementation. Now this is possible: # ps | grep 'compendium' # headers | grep 'Export-Package' | grep 'org.osgi.framework' and alike. The new GrepCommandImpl uses an extended Command Interface that supports InputStreams. I integrated those type of commands into ShellServiceImpl. Keep in mind that i fought a bit with the Piping stuff but ..well i'll try to fix things if they show up. Anyway, wdyt about the general approach? Toni Allow filtering by status in ps command (shell) --- Key: FELIX-534 URL: https://issues.apache.org/jira/browse/FELIX-534 Project: Felix Issue Type: New Feature Reporter: Toni Menzel Priority: Minor Attachments: FELIX-534.patch, FELIX-534_2.patch If you have many bundles it would be nice if you could filter certain status when executing the ps command like so: ps active resolved -- shows active and resolved bundles ps -- shows all bundles (just like its currently) Simple solution is attached. btw.: there is no shell component in Felix Jira.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-534) Allow filtering by status in ps command (shell)
[ https://issues.apache.org/jira/browse/FELIX-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-534: -- Attachment: (was: FELIX-534.patch) Allow filtering by status in ps command (shell) --- Key: FELIX-534 URL: https://issues.apache.org/jira/browse/FELIX-534 Project: Felix Issue Type: New Feature Reporter: Toni Menzel Priority: Minor Attachments: FELIX-534_2.patch If you have many bundles it would be nice if you could filter certain status when executing the ps command like so: ps active resolved -- shows active and resolved bundles ps -- shows all bundles (just like its currently) Simple solution is attached. btw.: there is no shell component in Felix Jira.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-534) Allow filtering by status in ps command (shell)
[ https://issues.apache.org/jira/browse/FELIX-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-534: -- Attachment: FELIX-534_3.patch FELIX-534_3.patch is a revised patch without extra formatting. The grep command now accepts a -e flag to submit raw regular expressions. Allow filtering by status in ps command (shell) --- Key: FELIX-534 URL: https://issues.apache.org/jira/browse/FELIX-534 Project: Felix Issue Type: New Feature Reporter: Toni Menzel Priority: Minor Attachments: FELIX-534_2.patch, FELIX-534_3.patch If you have many bundles it would be nice if you could filter certain status when executing the ps command like so: ps active resolved -- shows active and resolved bundles ps -- shows all bundles (just like its currently) Simple solution is attached. btw.: there is no shell component in Felix Jira.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-529) improve logging in FileInstall
[ https://issues.apache.org/jira/browse/FELIX-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-529: -- Attachment: FELIX-529.patch LogService Support, Minore integration improvements for FileInstall - use LogService as primary log target. Fallback to sysout/err - tighten visibility of member vars to private instead of packagelevel. - contains feature FELIX-524 and FELIX-528 - replaced static references with explicit parameters - cancelation flag should be (at least) volatile to ensure visibility - renamed non obvious field names (like jarfile) improve logging in FileInstall -- Key: FELIX-529 URL: https://issues.apache.org/jira/browse/FELIX-529 Project: Felix Issue Type: Bug Components: File Install Reporter: Toni Menzel Priority: Trivial Attachments: FELIX-529.patch Logging currently goes to System.err Stream and prints common null arguments - like Exception. This leads to common messages like Installed pax-url-mvn-0.3.1-SNAPSHOT.jar: null on the error console. Fix: - Remove exception if null. - write messages to System.out (like they usually do in felix) (i think there is no patchfile required, is it?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-534) Allow filtering by status in ps command (shell)
[ https://issues.apache.org/jira/browse/FELIX-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588437#action_12588437 ] Toni Menzel commented on FELIX-534: --- Not sure about the word simple: Is the java.util.regex implementation too slow/memory intense itself to be used or is it the probability of complex stuff someone _could_ enter? I don't think an ldap filter would give better usability for 85% of usages compared to a simple substring matching. In this case i'd just use a substring matching. Though it reduces much of the capabilities - not sure about maybe providing a different set of powerful commands for powerful machines? And the whole piping thing makes a lot more stuff possible but won't run/be useful on small devices. Allow filtering by status in ps command (shell) --- Key: FELIX-534 URL: https://issues.apache.org/jira/browse/FELIX-534 Project: Felix Issue Type: New Feature Reporter: Toni Menzel Priority: Minor Attachments: FELIX-534_2.patch, FELIX-534_3.patch If you have many bundles it would be nice if you could filter certain status when executing the ps command like so: ps active resolved -- shows active and resolved bundles ps -- shows all bundles (just like its currently) Simple solution is attached. btw.: there is no shell component in Felix Jira.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-528) Support nested folders in fileinstall
[ https://issues.apache.org/jira/browse/FELIX-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588440#action_12588440 ] Toni Menzel commented on FELIX-528: --- FELIX-529 contains this one as well as some other (small) so to say improvements. Support nested folders in fileinstall - Key: FELIX-528 URL: https://issues.apache.org/jira/browse/FELIX-528 Project: Felix Issue Type: New Feature Components: File Install Reporter: Toni Menzel Priority: Minor Attachments: FELIX-528.patch Currently FileInstall just supports flat jar-Files as bundles in its load folder. How about supporting (nested) folders? This way, you could: 1. just drop an arbitrary folder structure and fileinstall would install all bundles inside. 2. you could enable/disable entire bundle-sets with: 2a. in/move it out of the folder 2b. rename the folder with prefix that means unrecognized folder Just a thought.. Toni -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-524) Support Environment variables for getting the load directory for FileInstall
[ https://issues.apache.org/jira/browse/FELIX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588439#action_12588439 ] Toni Menzel commented on FELIX-524: --- FELIX-529 contains this one as well as some other (small) so to say improvements. Support Environment variables for getting the load directory for FileInstall Key: FELIX-524 URL: https://issues.apache.org/jira/browse/FELIX-524 Project: Felix Issue Type: New Feature Components: File Install Reporter: Peter Kriens Attachments: FELIX-524.patch Currently, File Install only looks in the System properties for the name of the the load directory. I want to use it inside Eclipse (getting tired of update manager) but then it would be nice if file install could be get the load directory from an environment variable. This way, when I install a new Eclipse I only have to install file install and load my extra bundles from one location. If it was a property, I would have to edit configuration files. I added this in my local aQute copy, if nobody takes up the maintenance of this unit then I can do it if I get commit access -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-534) Allow filtering by status in ps command (shell)
Allow filtering by status in ps command (shell) --- Key: FELIX-534 URL: https://issues.apache.org/jira/browse/FELIX-534 Project: Felix Issue Type: New Feature Reporter: Toni Menzel Priority: Minor If you have many bundles it would be nice if you could filter certain status when executing the ps command like so: ps active resolved -- shows active and resolved bundles ps -- shows all bundles (just like its currently) Simple solution is attached. btw.: there is no shell component in Felix Jira.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-528) Support nested folders in fileinstall
[ https://issues.apache.org/jira/browse/FELIX-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-528: -- Attachment: FELIX-528.patch If you like this feature, patch is attached. Toni Support nested folders in fileinstall - Key: FELIX-528 URL: https://issues.apache.org/jira/browse/FELIX-528 Project: Felix Issue Type: New Feature Components: File Install Reporter: Toni Menzel Priority: Minor Attachments: FELIX-528.patch Currently FileInstall just supports flat jar-Files as bundles in its load folder. How about supporting (nested) folders? This way, you could: 1. just drop an arbitrary folder structure and fileinstall would install all bundles inside. 2. you could enable/disable entire bundle-sets with: 2a. in/move it out of the folder 2b. rename the folder with prefix that means unrecognized folder Just a thought.. Toni -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-530) Separate DirectoryWatch function from action
Separate DirectoryWatch function from action Key: FELIX-530 URL: https://issues.apache.org/jira/browse/FELIX-530 Project: Felix Issue Type: New Feature Components: File Install Reporter: Toni Menzel I would like to pull the actions out of the DirectoryWatcher class. Instead, this class just detect/tracks changes like it currently does and calls an appropriate action contributed via extender pattern. This way, other bundles can 1. contribute functionality like handling other stuff than final bundles and .cfg files. 2. replace the current behavior 3. DirectoryWatcher gets slicker / easier to maintain The current two behaviors (install/update/remove on .jar Bundles and .cfg) could be installed in the activator by default (just like felix.shell does with its commands) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-528) Support nested folders in fileinstall
Support nested folders in fileinstall - Key: FELIX-528 URL: https://issues.apache.org/jira/browse/FELIX-528 Project: Felix Issue Type: New Feature Components: File Install Reporter: Toni Menzel Priority: Minor Currently FileInstall just supports flat jar-Files as bundles in its load folder. How about supporting (nested) folders? This way, you could: 1. just drop an arbitrary folder structure and fileinstall would install all bundles inside. 2. you could enable/disable entire bundle-sets with: 2a. in/move it out of the folder 2b. rename the folder with prefix that means unrecognized folder Just a thought.. Toni -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-512) Sort files before installing
[ https://issues.apache.org/jira/browse/FELIX-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586151#action_12586151 ] Toni Menzel commented on FELIX-512: --- So, what's the case here now? This item can be closed with won't fix because of peter's explanation? Personally i'd agree him. Sort files before installing Key: FELIX-512 URL: https://issues.apache.org/jira/browse/FELIX-512 Project: Felix Issue Type: Improvement Components: File Install Reporter: Rodrigo Madera Priority: Minor Make the component sort the files it reads before it installs them, that way we can use names as in Linux's rc directories: 100_bundle_one 110_bundle_two 120_bundle_three etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-524) Support Environment variables for getting the load directory for FileInstall
[ https://issues.apache.org/jira/browse/FELIX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-524: -- Attachment: FELIX-524.patch I needed this one (with Environment variables you mean data retrieved by System.getenv , correct?) lately. I've added my changes to this item. Support Environment variables for getting the load directory for FileInstall Key: FELIX-524 URL: https://issues.apache.org/jira/browse/FELIX-524 Project: Felix Issue Type: New Feature Components: File Install Reporter: Peter Kriens Attachments: FELIX-524.patch Currently, File Install only looks in the System properties for the name of the the load directory. I want to use it inside Eclipse (getting tired of update manager) but then it would be nice if file install could be get the load directory from an environment variable. This way, when I install a new Eclipse I only have to install file install and load my extra bundles from one location. If it was a property, I would have to edit configuration files. I added this in my local aQute copy, if nobody takes up the maintenance of this unit then I can do it if I get commit access -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-529) improve logging in FileInstall
improve logging in FileInstall -- Key: FELIX-529 URL: https://issues.apache.org/jira/browse/FELIX-529 Project: Felix Issue Type: Bug Components: File Install Reporter: Toni Menzel Priority: Trivial Logging currently goes to System.err Stream and prints common null arguments - like Exception. This leads to common messages like Installed pax-url-mvn-0.3.1-SNAPSHOT.jar: null on the error console. Fix: - Remove exception if null. - write messages to System.out (like they usually do in felix) (i think there is no patchfile required, is it?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-329) Calling Felix.stopAndWait() from Runtime.shutdownHook() freezes thread
[ https://issues.apache.org/jira/browse/FELIX-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toni Menzel updated FELIX-329: -- Summary: Calling Felix.stopAndWait() from Runtime.shutdownHook() freezes thread (was: Calling Felix.stopAndWait() from Runtime.shutdownHook() freezed thread) Calling Felix.stopAndWait() from Runtime.shutdownHook() freezes thread -- Key: FELIX-329 URL: https://issues.apache.org/jira/browse/FELIX-329 Project: Felix Issue Type: Bug Components: Framework Environment: tested on trunk (r555374) Reporter: Toni Menzel Fix For: 1.0.0 if a shutdownHook invokes Felix.stopAndWait() the monitor never gets notified and stays wait() forever. Until now i haven't found a direct way to fix this behaviour normally but if we could use the timeout version wait(int) instead of wait() this behaviour is not tied to the monitor.notifyAll() functionality. (so perhaps its the better solution anyway and not just a workaround?) Toni -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
