[jira] Commented: (FELIX-738) First access to Bundles web console tab takes a long time if the server has no internet access
[ https://issues.apache.org/jira/browse/FELIX-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634767#action_12634767 ] Felix Meschberger commented on FELIX-738: - we would have the same problem, as the box has no internet access. If the box is behind a firewill, the firewall admin should actually have set up the firewall to send back an error in case of trying to connect to the internet. So a timeout should not happen. Make it possible to disable the lookup and/or the entire bundle repository bundle by some config value. We could define a framework property and or a Config Admin property, which would disable the OBR lookup for the bundle list. Of course, I would think to enable OBR by default ;-) Is it really necessary for the bundle repository bundle to access The bundle list page provides the Update buttons. These are enabled if the OBR might have a more recent version of the respective bundle. To be able to check the OBR, the URL must of course be accessed. If you can go by without OBR updates from within the bundles list, then OBR access may be switched off (see above). So I propose to define a property -- say org.apache.felix.webconsole.bundle.obr.disable -- which is false by default (if missing or wrong value). It is checked as a framework propery and as a ConfigurationAdmin configuration property, where the ConfigurationAdmin setting overruels the framework property. WDYT ? First access to Bundles web console tab takes a long time if the server has no internet access - Key: FELIX-738 URL: https://issues.apache.org/jira/browse/FELIX-738 Project: Felix Issue Type: Bug Components: Web Console Environment: Linux box without internet access (firewalled intranet) Reporter: Mike Pfaff Priority: Minor Log entries: [...] RepositoryAdminImpl: Exception creating repository - java.net.ConnectException: Operation timed out RepositoryAdminImpl: Ignoring repository http://oscar-osgi.sourceforge.net/obr2/repository.xml [...] I know that the repo URL is outdated, but even with the new URL http://felix.apache.org/obr/releases.xml we would have the same problem, as the box has no internet access. Possible solutions and ideas: - Make it possible to disable the lookup and/or the entire bundle repository bundle by some config value. - Set the timeout to a lower value (maybe 5 or 10 seconds) - Is it really necessary for the bundle repository bundle to access the repo URL when you go to the Bundle web console tab? (It makes sense for the OSGi Repository web console tab). - Stopping/Uninstalling the bundle repository bundle poses some kind of chicken/egg problem, as one would have to use the Bundle web console tab - which is where the problem occurs - for that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-734) Remote shell bundle can prevent felix shutdown
[ https://issues.apache.org/jira/browse/FELIX-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634773#action_12634773 ] Felix Meschberger commented on FELIX-734: - Thanks for the supplied patch. I will look into applying it shortly. Can you please tell me the Java runtime version and vendor as well as possibly the OS platform you used, where you encountered the issue. Thanks. Remote shell bundle can prevent felix shutdown -- Key: FELIX-734 URL: https://issues.apache.org/jira/browse/FELIX-734 Project: Felix Issue Type: Bug Components: Remote Shell Affects Versions: shell.remote-1.0.2 Environment: felix 1.2.1, shell-remote 1.0.2 Reporter: Patrick Forhan Attachments: RemoteShellListenerPatch.txt On one of our PCs, issuing a shutdown command to felix remote shell would hang indefinitely. We could go to the console window and still type in commands to the local shell, and a 'ps' showed that bundle 0 and the remote-shell bundle were in stopping states. The problem was in remote.shell's Listener.java. The deactivate method seemed to be expecting the m_ServerSocket.close() call on line 70 to cause an exception in the waiting thread at line 104, the m_ServerSocket.accept() call. For most of our machines, this seems to work as expected. But the one that did waited forever for the thread join to happen, and could never shutdown. To address this, we set the serverSocket's SOTimeout field, so that it it will timeout, go through the do/while loop, and reevaluate the m_stop variable. The timeout is configurable via the bundle context property osgi.shell.telnet.SocketTimeout and defaults to 0, the current behavior. Patch will be attached shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-729) Shell-TUI causes 100% CPU load when using javaw launcher
[ https://issues.apache.org/jira/browse/FELIX-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634784#action_12634784 ] Stuart McCulloch commented on FELIX-729: FYI, checking for an IOException from System.in.available() is what we ended up using in Pax-Runner for a similar problem (and it did fix it) Shell-TUI causes 100% CPU load when using javaw launcher Key: FELIX-729 URL: https://issues.apache.org/jira/browse/FELIX-729 Project: Felix Issue Type: Bug Components: Shell Affects Versions: felix-1.0.4, felix-1.2.0 Environment: Windows 2000 SP4, Windows Vista Enterprise, JDK 1.6 Reporter: Barend Garvelink Assignee: Richard S. Hall I ran into this issue at work with Felix 1.0.4 on Win2k SP4 and reproduced it at home with Felix 1.2.1 on Vista Enterprise, both on JDK 1.6. I only discovered it by accident, as I normally use the console during development. I suspect the people reading this do, too :-). When using the javaw.exe launcher rather than the java.exe launcher, Felix-shell-TUI permanently draws 100% CPU (divide by the number of cores, home PC reports 50%). After removing shell-TUI from the autostart list, Felix can be run with the javaw launcher without issue, demonstrating that the problem originates from that bundle. Steps to reproduce: 1) unzip a fresh copy of Felix-1.2.1.zip 2) in the install dir, create two batch files: felix-console.bat and felix-noconsole.bat, one executes `java -Dfelix.cache.profile=consoletest -jar bin\felix.jar`, the other executes `javaw -Dfelix.cache.profile=consoletest -jar bin\felix.jar` 3) double-click either from Windows Explorer, note that when you run the javaw one, CPU shoots to 100% and stays there. Running them from within Windows Explorer isn't strictly necessary to reproduce the issue, the problem will also show when you start the batch file from the command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-728) Garbage Collection Corner Cases in PackageAdminImpl and StartLevelImpl
[ https://issues.apache.org/jira/browse/FELIX-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-728: Fix Version/s: felix-1.2.2 I assume this will go into the felix-1.2.2 release. Thanks. Garbage Collection Corner Cases in PackageAdminImpl and StartLevelImpl -- Key: FELIX-728 URL: https://issues.apache.org/jira/browse/FELIX-728 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: felix-1.0.4, felix-1.2.0 Reporter: Felix Meschberger Assignee: Richard S. Hall Fix For: felix-1.2.2 Attachments: FELIX-728.patch While tracking down memory issues in our OSGi based application, I stumbled upon two corner case issues in the StartLevelImpl and PackageAdminImpl classes, which both implement the Thread.run() method to execute their operations asynchronously. Each of these run methods have a local variable which is not reset after executing the operation: StartLevelImpl.run() has an Object request. This is set to the start level request. For example to set the start level of a bundle, the request object is an array of two elements containing the bundle whose start level is to be set and the actual startlevel. After setting the start level the StartLevelImpl.run method keeps a string reference to the request object, most notably the Bundle. If now a bundle is installed, its startlevel is set and then the bundle is uninstalled, the actual bundle as well as its class loader and classes will only be unloaded when a new request is sent to the StartLevelImpl class. To fix this situation, I propose to move the definition of the request variable inside the loop. This way, the variable is dropped together with any string references. Similarly the PackageAdminImpl.run() method has a Bundle[] bundles variable, which is also not reset. The fix is the same as for the StartLevelImpl.run() method, in that the variable declaration is moved inside the loop. While I did not stumble upon the PackageAdminImpl issue, I encountered the StartLevelImpl one. Will attach a patch for review. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: web console multi file upload and install
Hi Roger, Roger Martin schrieb: Felix? Do you prefer less of a flash approach? Will look to build patches for you to try... To be honest, I don't really care ;-) I know that file uploads is problematic and flash seems to fix pretty many problems (and creating others ...) So, looking forwards to the patches. Thanks. Regards Felix On 9/17/08, Rob Walker [EMAIL PROTECTED] wrote: Roger Have attached what the modified multi file uploader class we used - looking at the comment it seems I used an original from Jgraphpad source, although I seem to recall I largely rewrote it. I might have a change history if it's of interest i.e. in terms of licensing or re-use.. The source code shows what I think is a fairly generic way to to multi file uploads. Regards -- Rob Roger Martin wrote: Hi Felix, It is solely in the client side javascript and using flash. The FancyUpload builds a hidden queue in the DOM and then sends them one by one back to the server as if the user did it. I was hoping to hear more from Rob. Planning on creating a patch. There were a couple of JavaScript variable collisions I need to work out and also test on more than Firefox... On Wed, Sep 10, 2008 at 2:50 PM, Felix Meschberger [EMAIL PROTECTED]wrote: Hi Roger, Roger Martin schrieb: Hi Felix developers, In my local Felix development I've been testing different ways to change the web console to allow multiple files to be dragged from an OS folder and upload them via the Apache Felix Web Management Console. After searching, testing and running into many obsolete documentations in this murky territory I found the FancyUpload by http://digitarald.de/project/fancyupload/1-0/ works using a flash method. My first case, Firefox is working and I got all the other noted browsers queued up for testing. FancyUpload has an MIT license (http://www.opensource.org/licenses/mit-license.php). If this feature is of interest, is the license ok? I would be interested in seeing a patch, yes, of course ;-) I assume beside the client side, you also had to modify the server side to accept multiple files, right ? Is there another preferred technology I should test? I have no preference of course. Regards Felix Also I know that Glassfish is possibly remodeling to fit the Felix console in with the Glassfish Admin Console; perhaps this may fit there? Although I know that there are many profiles I as a Felix user like to set up independent of glassfish for testing. Each of these profiles are very much like a unit test for scenarios involving a subset of the composite apps I'm working on. So a way to quickly set them up via multi file upload and install works for me. Perhaps for others as well. -- Ascert - Taking systems to the Edge [EMAIL PROTECTED] +44 (0)20 7488 3470 www.ascert.com
[jira] Resolved: (FELIX-729) Shell-TUI causes 100% CPU load when using javaw launcher
[ https://issues.apache.org/jira/browse/FELIX-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barend Garvelink resolved FELIX-729. Resolution: Fixed That last change fixed the problem. Thank you for your time, Richard. Shell-TUI causes 100% CPU load when using javaw launcher Key: FELIX-729 URL: https://issues.apache.org/jira/browse/FELIX-729 Project: Felix Issue Type: Bug Components: Shell Affects Versions: felix-1.0.4, felix-1.2.0 Environment: Windows 2000 SP4, Windows Vista Enterprise, JDK 1.6 Reporter: Barend Garvelink Assignee: Richard S. Hall I ran into this issue at work with Felix 1.0.4 on Win2k SP4 and reproduced it at home with Felix 1.2.1 on Vista Enterprise, both on JDK 1.6. I only discovered it by accident, as I normally use the console during development. I suspect the people reading this do, too :-). When using the javaw.exe launcher rather than the java.exe launcher, Felix-shell-TUI permanently draws 100% CPU (divide by the number of cores, home PC reports 50%). After removing shell-TUI from the autostart list, Felix can be run with the javaw launcher without issue, demonstrating that the problem originates from that bundle. Steps to reproduce: 1) unzip a fresh copy of Felix-1.2.1.zip 2) in the install dir, create two batch files: felix-console.bat and felix-noconsole.bat, one executes `java -Dfelix.cache.profile=consoletest -jar bin\felix.jar`, the other executes `javaw -Dfelix.cache.profile=consoletest -jar bin\felix.jar` 3) double-click either from Windows Explorer, note that when you run the javaw one, CPU shoots to 100% and stays there. Running them from within Windows Explorer isn't strictly necessary to reproduce the issue, the problem will also show when you start the batch file from the command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-740) ConfigurationManager throws NPE when bundle that registered service is uninstalled
ConfigurationManager throws NPE when bundle that registered service is
uninstalled
--
Key: FELIX-740
URL: https://issues.apache.org/jira/browse/FELIX-740
Project: Felix
Issue Type: Bug
Components: Configuration Admin
Affects Versions: configadmin-1.0.4
Reporter: Peter Doornbosch
Priority: Minor
Sometimes, a NullPointerException is thrown in the ConfigAdmin's update thread,
that is originating from the following piece of code (ConfigurationManager):
private class ManagedServiceFactoryUpdate implements Runnable
(...)
public void run()
{
Factory factory;
try
{
factory = getFactory( factoryPid );
}
catch ( IOException ioe )
{
log( LogService.LOG_ERROR, Cannot get factory mapping for
factory PID + factoryPid, ioe );
return;
}
String bundleLocation = sr.getBundle().getLocation();
The NPE occurs in the last line. From the context it is clear that sr is not
null, hence, sr.getBundle() returns null.
Probably, this is caused by a bundle that is stopped concurrently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-713) Add support for Bundle.start(int)
[ https://issues.apache.org/jira/browse/FELIX-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reassigned FELIX-713: - Assignee: Richard S. Hall Add support for Bundle.start(int) - Key: FELIX-713 URL: https://issues.apache.org/jira/browse/FELIX-713 Project: Felix Issue Type: New Feature Components: Framework Affects Versions: felix-1.2.1 Environment: NA Reporter: Sahoo Assignee: Richard S. Hall Fix For: felix-1.2.2 Attachments: Felix-713.zip I would like Felix to support for Bundle.start(int), which is introduced in OSGi R4, version 4.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-741) Modify shell start/stop commands to support transient starting/stopping of bundles
Modify shell start/stop commands to support transient starting/stopping of bundles -- Key: FELIX-741 URL: https://issues.apache.org/jira/browse/FELIX-741 Project: Felix Issue Type: New Feature Components: Shell Reporter: Richard S. Hall Assignee: Richard S. Hall Priority: Minor Fix For: felix-1.2.2 Once we modify Felix to support transient starting/stopping of bundles, we should modify the shell's start/stop commands to support it (e.g., perhaps accept a -t option). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-713) Add support for Bundle.start(int)
[ https://issues.apache.org/jira/browse/FELIX-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-713: -- Attachment: FELIX-713.patch Add support for Bundle.start(int) - Key: FELIX-713 URL: https://issues.apache.org/jira/browse/FELIX-713 Project: Felix Issue Type: New Feature Components: Framework Affects Versions: felix-1.2.1 Environment: NA Reporter: Sahoo Assignee: Richard S. Hall Fix For: felix-1.2.2 Attachments: FELIX-713.patch, Felix-713.zip I would like Felix to support for Bundle.start(int), which is introduced in OSGi R4, version 4.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-713) Add support for Bundle.start(int)
[ https://issues.apache.org/jira/browse/FELIX-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635081#action_12635081 ] Richard S. Hall commented on FELIX-713: --- Sahoo, I have attached a modified version of your patch, but the overall approach is the same. I have tested it locally and it appears to work for me. Take a look and let me know what you think. If it looks good, I will apply it. BTW, I also committed changes and deployed a snapshot of shell that has commands for starting/stopping transiently. Add support for Bundle.start(int) - Key: FELIX-713 URL: https://issues.apache.org/jira/browse/FELIX-713 Project: Felix Issue Type: New Feature Components: Framework Affects Versions: felix-1.2.1 Environment: NA Reporter: Sahoo Assignee: Richard S. Hall Fix For: felix-1.2.2 Attachments: FELIX-713.patch, Felix-713.zip I would like Felix to support for Bundle.start(int), which is introduced in OSGi R4, version 4.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
