[jira] Commented: (FELIX-2246) Lazy initialization of plugins
[ https://issues.apache.org/jira/browse/FELIX-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853775#action_12853775 ] Valentin Valchev commented on FELIX-2246: - Yes, it is possible to have the service, without actually resolving the bundle. We actually do this in ProSyst Framework and it is described here: http://dz.prosyst.com/pdoc/mBS_PE/um/framework/concepts/lazy_init.html This gives better performance compared to the OSGi Lazy bundles. And it is even better because the both lazy models works perfectly together. > Lazy initialization of plugins > -- > > Key: FELIX-2246 > URL: https://issues.apache.org/jira/browse/FELIX-2246 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-3.0.0 >Reporter: Valentin Valchev > Attachments: lazy-webconsole-plugins.jude, lazy-webconsole-plugins.png > > > Here at ProSyst we use a small trick to delay initialization of our services: > When the service is quite big, and loads many resources (incl. too many > classes), we register not a service, but a ServiceFactory instead. With that > factory we delay the instantiation of the service, when it is actually needed > and obtained by other bundle. > Yes, this makes the code a little bit more complex, but it greatly improves > the start-up time and the overall memory usage. > This can be applied to webconsole plugins too. My idea is that Web Console > should only track Service Reference without actually obtaining the service > itself [not getService()]. > When the user makes request the WebConsole calls the factory to create > instance. Instance is created and returned to the Web Console, which uses it > to generate content for the request. > This way a plugin is actually not initialized until it is really used. Only > small portion of classes, from the bundle are initialized. > Unfortunately the ServiceTracker, when notified for added service obtains the > real service object. So it might be better to use directly ServiceListener > for the plugins. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-2248) fileinstall does not restart bundles when the underlying file is modified
[ https://issues.apache.org/jira/browse/FELIX-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned FELIX-2248: -- Assignee: Guillaume Nodet > fileinstall does not restart bundles when the underlying file is modified > - > > Key: FELIX-2248 > URL: https://issues.apache.org/jira/browse/FELIX-2248 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-2.0.8 > Environment: Linux >Reporter: Sahoo >Assignee: Guillaume Nodet >Priority: Critical > Attachments: FELIX-2248.patch.txt > > > As I reported earlier in the forum, I found some strange behavior with > fileinstall-2.0.8. If I modify a jar in watched directory, fileinstall stops > the corresponding bundle and does not restart it until the framework is > restarted. > To reproduce this: > Copy a new bundle to watched directory. > Wait for fileinstall to install and start it. > Now modify the bundle jar in watched dir. > You shall see the bundle is either in RESOLVED state or INSTALLED state now > depending on whether this bundle participates in class loading or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (FELIX-2248) fileinstall does not restart bundles when the underlying file is modified
Has anyone got a chance to look into it? Thanks, Sahoo Sahoo (JIRA) wrote: [ https://issues.apache.org/jira/browse/FELIX-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sahoo updated FELIX-2248: - Attachment: FELIX-2248.patch.txt Patch to address the bug. The start level comparison seems wrong. fileinstall does not restart bundles when the underlying file is modified - Key: FELIX-2248 URL: https://issues.apache.org/jira/browse/FELIX-2248 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-2.0.8 Environment: Linux Reporter: Sahoo Priority: Critical Attachments: FELIX-2248.patch.txt As I reported earlier in the forum, I found some strange behavior with fileinstall-2.0.8. If I modify a jar in watched directory, fileinstall stops the corresponding bundle and does not restart it until the framework is restarted. To reproduce this: Copy a new bundle to watched directory. Wait for fileinstall to install and start it. Now modify the bundle jar in watched dir. You shall see the bundle is either in RESOLVED state or INSTALLED state now depending on whether this bundle participates in class loading or not.
[jira] Commented: (FELIX-2069) FileInstall creates ./load by default
[ https://issues.apache.org/jira/browse/FELIX-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853479#action_12853479 ] Richard S. Hall commented on FELIX-2069: +1 for not creating ./load > FileInstall creates ./load by default > - > > Key: FELIX-2069 > URL: https://issues.apache.org/jira/browse/FELIX-2069 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-2.0.8 >Reporter: Sahoo > Attachments: FELIX-2069.patch.txt > > > If not configured, file install bundle creates ./load when it starts. Either > it should not create any directory and wait for user to configure it or it > should create a directory in tmp folder. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Karaf snapshots
Hi, Does anyone know what's going on with Karaf snapshots? It looks like the jar, pom files are not getting updated since March 17th. For example, take a look at https://repository.apache.org/snapshots/org/apache/felix/karaf/jaas/org.apache.felix.karaf.jaas.boot/1.5.0-SNAPSHOT/. Thanks, Jarek
[jira] Updated: (FELIX-2201) [FileInstall] Make Scanner process artifacts in "oldest-file-modification-time first" order
[ https://issues.apache.org/jira/browse/FELIX-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Gardfjäll updated FELIX-2201: --- Attachment: processing_order_patch.diff Attached a patch that implements the requested feature. > [FileInstall] Make Scanner process artifacts in > "oldest-file-modification-time first" order > --- > > Key: FELIX-2201 > URL: https://issues.apache.org/jira/browse/FELIX-2201 > Project: Felix > Issue Type: Improvement > Components: File Install >Affects Versions: fileinstall-2.0.4 >Reporter: Peter Gardfjäll > Attachments: processing_order_patch.diff > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Currently FileInstall does not process new files in the load directory in any > particular order. > It would be beneficial to have these artifacts processed in a > First-Come-First-Served order. > That is, in order of increasing file modification time. > Refer to the following email thread for details > http://www.mail-archive.com/us...@felix.apache.org/msg06949.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
