You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Valentin Valchev (JIRA)" <ji...@apache.org> on 2010/02/22 10:16:27 UTC
[jira] Created: (FELIX-2117) Use DynamicImport instead of Optional
Packages
Use DynamicImport instead of Optional Packages
----------------------------------------------
Key: FELIX-2117
URL: https://issues.apache.org/jira/browse/FELIX-2117
Project: Felix
Issue Type: Improvement
Components: Web Console
Reporter: Valentin Valchev
Currently the web console uses optional packages for some plugins.
Unfortunately an 'optional' import is wired when the bundle is resolved.
DynamicImport however is wired when the package is accessed.
This means, that currently, you
- install webconsole
- install scr
= scr plugin is not available
- resolve webconsole (again)
= scr plugin is available after 1 additional step
However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2117) Use DynamicImport instead of
Optional Packages
Posted by "Sahoo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848688#action_12848688 ]
Sahoo commented on FELIX-2117:
------------------------------
How does Dynamic-ImportPackage work when it comes to ServiceTracker? We will probably have to track for services not reachable by webconsole bundle and deal with the ClassCastException. Comments?
> Use DynamicImport instead of Optional Packages
> ----------------------------------------------
>
> Key: FELIX-2117
> URL: https://issues.apache.org/jira/browse/FELIX-2117
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Reporter: Valentin Valchev
>
> Currently the web console uses optional packages for some plugins.
> Unfortunately an 'optional' import is wired when the bundle is resolved.
> DynamicImport however is wired when the package is accessed.
> This means, that currently, you
> - install webconsole
> - install scr
> = scr plugin is not available
> - resolve webconsole (again)
> = scr plugin is available after 1 additional step
> However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2117) Use DynamicImport instead of
Optional Packages
Posted by "Valentin Valchev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849105#action_12849105 ]
Valentin Valchev commented on FELIX-2117:
-----------------------------------------
Felix, I vote to separate it for this release. No delay. For both of these plugins.
However, it is for this release, I guess you better post a new issue for each plugin. Feel free to assign any task to me ;)
> Use DynamicImport instead of Optional Packages
> ----------------------------------------------
>
> Key: FELIX-2117
> URL: https://issues.apache.org/jira/browse/FELIX-2117
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Reporter: Valentin Valchev
>
> Currently the web console uses optional packages for some plugins.
> Unfortunately an 'optional' import is wired when the bundle is resolved.
> DynamicImport however is wired when the package is accessed.
> This means, that currently, you
> - install webconsole
> - install scr
> = scr plugin is not available
> - resolve webconsole (again)
> = scr plugin is available after 1 additional step
> However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (FELIX-2117) Use DynamicImport instead of Optional
Packages
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Hmm, difficult question...
How about this: We leave it in for the 3.0 release and make upgrade from
previous releases as seemless as possible.
For the next release we scan all contained plugins and decide on which
plugins to keep in the core web console (I would assume the OSGi Core
Spec as well as the platform related plugins) and which plugins (the
compendium related plugins like configuration, scr, Deployment Admin,
...) to separate out into their own plugin bundles.
This makes it possible to easily mix and match the required/used plugins
and also allows use to independently evolve the different plugins.
WDYT ?
Regards
Felix
On 24.03.2010 13:22, Valentin Valchev wrote:
> For me - let's remove it, I don't need it, ProSyst too.... So don't
> count my voice.
>
> But, as not ProSyst employee, my opinion is that if removed, it makes no
> sense to delay the plugin, but to release it together with webconsole
> 3.0.0. This way, people that need OBR will be able to install it. Later,
> we can improve it and create a new OBR Plugin release.
>
> Regards,
> Valentin
>
> On 24.3.2010 г. 12:15, Felix Meschberger wrote:
>> Hi,
>>
>> On 23.03.2010 15:05, Valentin Valchev (JIRA) wrote:
>>
>>> BTW. Isn't it better to make OBR & SCR a separate plugins.
>>>
>>> OBR is not into OSGi core spec, and SCR is IMHO rarely used. The benefits of that step will be:
>>> 1. This will solve the resolve problem we have now
>>> 2. OBR activator might track OBR service and register the plugin only when it is available
>>> 3. SCR might be available only if at least one component is installed
>>>
>>> A similar approach is used by UPnP Plugin. It will not be visible in console, unless at least one UPnP Device is available.
>>>
>>> This prevents the user from being confused by opening as example "Components" page, that says "No components".
>>>
>> I am not against this proposal at all, in fact it makes some sense (and
>> the console bundle itself a bit smaller ;-) and lives by the OSGi ideas).
>>
>> My question is: Do we want to do this for the Web Console 3.0 release
>> already ?
>>
>> One advantage would be to be able to delay the OBR plugin release until
>> the bundlerepository and utils projects have settled. The disadvantage
>> of this is, that people upgrading from previous versions of the Web
>> Console would end without (released) support for OBR.
>>
>> WDYT ?
>>
>> Regards
>> Felix
>>
>>
>>
>
>
Re: [jira] Commented: (FELIX-2117) Use DynamicImport instead of Optional
Packages
Posted by Valentin Valchev <v_...@prosyst.bg>.
For me - let's remove it, I don't need it, ProSyst too.... So don't
count my voice.
But, as not ProSyst employee, my opinion is that if removed, it makes no
sense to delay the plugin, but to release it together with webconsole
3.0.0. This way, people that need OBR will be able to install it. Later,
we can improve it and create a new OBR Plugin release.
Regards,
Valentin
On 24.3.2010 г. 12:15, Felix Meschberger wrote:
> Hi,
>
> On 23.03.2010 15:05, Valentin Valchev (JIRA) wrote:
>
>> BTW. Isn't it better to make OBR & SCR a separate plugins.
>>
>> OBR is not into OSGi core spec, and SCR is IMHO rarely used. The benefits of that step will be:
>> 1. This will solve the resolve problem we have now
>> 2. OBR activator might track OBR service and register the plugin only when it is available
>> 3. SCR might be available only if at least one component is installed
>>
>> A similar approach is used by UPnP Plugin. It will not be visible in console, unless at least one UPnP Device is available.
>>
>> This prevents the user from being confused by opening as example "Components" page, that says "No components".
>>
> I am not against this proposal at all, in fact it makes some sense (and
> the console bundle itself a bit smaller ;-) and lives by the OSGi ideas).
>
> My question is: Do we want to do this for the Web Console 3.0 release
> already ?
>
> One advantage would be to be able to delay the OBR plugin release until
> the bundlerepository and utils projects have settled. The disadvantage
> of this is, that people upgrading from previous versions of the Web
> Console would end without (released) support for OBR.
>
> WDYT ?
>
> Regards
> Felix
>
>
>
--
-------------------------------------------------
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valchev@prosyst.bg
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Re: [jira] Commented: (FELIX-2117) Use DynamicImport instead of
Optional Packages
Posted by Sahoo <Sa...@Sun.COM>.
Felix Meschberger wrote:
> Hi,
>
> On 23.03.2010 15:05, Valentin Valchev (JIRA) wrote:
>
>> BTW. Isn't it better to make OBR & SCR a separate plugins.
>>
>> OBR is not into OSGi core spec, and SCR is IMHO rarely used. The benefits of that step will be:
>> 1. This will solve the resolve problem we have now
>> 2. OBR activator might track OBR service and register the plugin only when it is available
>> 3. SCR might be available only if at least one component is installed
>>
>> A similar approach is used by UPnP Plugin. It will not be visible in console, unless at least one UPnP Device is available.
>>
>> This prevents the user from being confused by opening as example "Components" page, that says "No components".
>>
>
> I am not against this proposal at all, in fact it makes some sense (and
> the console bundle itself a bit smaller ;-) and lives by the OSGi ideas).
>
> My question is: Do we want to do this for the Web Console 3.0 release
> already ?
>
> One advantage would be to be able to delay the OBR plugin release until
> the bundlerepository and utils projects have settled. The disadvantage
> of this is, that people upgrading from previous versions of the Web
> Console would end without (released) support for OBR.
>
> WDYT ?
>
IT depends on how much longer people have to wait before an OBR plugin
is available for Web Console 3.0. If it's a matter of weeks, then this
makes sense. If not, then go with earlier plan.
Thanks,
Sahoo
> Regards
> Felix
>
Re: [jira] Commented: (FELIX-2117) Use DynamicImport instead of Optional
Packages
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 23.03.2010 15:05, Valentin Valchev (JIRA) wrote:
> BTW. Isn't it better to make OBR & SCR a separate plugins.
>
> OBR is not into OSGi core spec, and SCR is IMHO rarely used. The benefits of that step will be:
> 1. This will solve the resolve problem we have now
> 2. OBR activator might track OBR service and register the plugin only when it is available
> 3. SCR might be available only if at least one component is installed
>
> A similar approach is used by UPnP Plugin. It will not be visible in console, unless at least one UPnP Device is available.
>
> This prevents the user from being confused by opening as example "Components" page, that says "No components".
I am not against this proposal at all, in fact it makes some sense (and
the console bundle itself a bit smaller ;-) and lives by the OSGi ideas).
My question is: Do we want to do this for the Web Console 3.0 release
already ?
One advantage would be to be able to delay the OBR plugin release until
the bundlerepository and utils projects have settled. The disadvantage
of this is, that people upgrading from previous versions of the Web
Console would end without (released) support for OBR.
WDYT ?
Regards
Felix
[jira] Commented: (FELIX-2117) Use DynamicImport instead of
Optional Packages
Posted by "Valentin Valchev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848717#action_12848717 ]
Valentin Valchev commented on FELIX-2117:
-----------------------------------------
BTW. Isn't it better to make OBR & SCR a separate plugins.
OBR is not into OSGi core spec, and SCR is IMHO rarely used. The benefits of that step will be:
1. This will solve the resolve problem we have now
2. OBR activator might track OBR service and register the plugin only when it is available
3. SCR might be available only if at least one component is installed
A similar approach is used by UPnP Plugin. It will not be visible in console, unless at least one UPnP Device is available.
This prevents the user from being confused by opening as example "Components" page, that says "No components".
> Use DynamicImport instead of Optional Packages
> ----------------------------------------------
>
> Key: FELIX-2117
> URL: https://issues.apache.org/jira/browse/FELIX-2117
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Reporter: Valentin Valchev
>
> Currently the web console uses optional packages for some plugins.
> Unfortunately an 'optional' import is wired when the bundle is resolved.
> DynamicImport however is wired when the package is accessed.
> This means, that currently, you
> - install webconsole
> - install scr
> = scr plugin is not available
> - resolve webconsole (again)
> = scr plugin is available after 1 additional step
> However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2117) Use DynamicImport instead of
Optional Packages
Posted by "Valentin Valchev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848701#action_12848701 ]
Valentin Valchev commented on FELIX-2117:
-----------------------------------------
No ClassCasts. If you have the service, then you will have the required API.
The difference compared to optional import, is that optional imports are resolved once. If package imported optional becomes available, the bundle that imports it optionally must be resolved again, in order to get access to that package.
The DynamicImport-Package dependency is resolved run-time, when class-loading occurs. So if you try to access functionality that requires some API, it will either fail with NoClassDefFound, or will work correctly.
> Use DynamicImport instead of Optional Packages
> ----------------------------------------------
>
> Key: FELIX-2117
> URL: https://issues.apache.org/jira/browse/FELIX-2117
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Reporter: Valentin Valchev
>
> Currently the web console uses optional packages for some plugins.
> Unfortunately an 'optional' import is wired when the bundle is resolved.
> DynamicImport however is wired when the package is accessed.
> This means, that currently, you
> - install webconsole
> - install scr
> = scr plugin is not available
> - resolve webconsole (again)
> = scr plugin is available after 1 additional step
> However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2117) Use DynamicImport instead of
Optional Packages
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846320#action_12846320 ]
Felix Meschberger commented on FELIX-2117:
------------------------------------------
This might make perfect sense. But it would probably require rewriting of some plugins which currently do not load if the dependency is satisified.
When switching to dynamic imports, the plugins must load and operate without the API being present and start doing useful things when the API is present.
> Use DynamicImport instead of Optional Packages
> ----------------------------------------------
>
> Key: FELIX-2117
> URL: https://issues.apache.org/jira/browse/FELIX-2117
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Reporter: Valentin Valchev
>
> Currently the web console uses optional packages for some plugins.
> Unfortunately an 'optional' import is wired when the bundle is resolved.
> DynamicImport however is wired when the package is accessed.
> This means, that currently, you
> - install webconsole
> - install scr
> = scr plugin is not available
> - resolve webconsole (again)
> = scr plugin is available after 1 additional step
> However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2117) Use DynamicImport instead of
Optional Packages
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849090#action_12849090 ]
Felix Meschberger commented on FELIX-2117:
------------------------------------------
@Sahoo: I have tested this setup (for the OBR bundle) and it works nicely. Point is, that the service consumer (ServiceTracker's ServiceListener) registers with a service name (not a service class). Once a service of that name is registered the service registry checks whether the consumer of the service is checked, whether it has access to the service class. Only at this time will the DynamicImport-Package be resolved and the API package wired and thus the service properly delivered to the consumer.
@Valentin: Agreed. But: Do we want to separate these plugins out for the 3.0 release already ? Or should we delay for a next release ?
> Use DynamicImport instead of Optional Packages
> ----------------------------------------------
>
> Key: FELIX-2117
> URL: https://issues.apache.org/jira/browse/FELIX-2117
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Reporter: Valentin Valchev
>
> Currently the web console uses optional packages for some plugins.
> Unfortunately an 'optional' import is wired when the bundle is resolved.
> DynamicImport however is wired when the package is accessed.
> This means, that currently, you
> - install webconsole
> - install scr
> = scr plugin is not available
> - resolve webconsole (again)
> = scr plugin is available after 1 additional step
> However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2117) Use DynamicImport instead of
Optional Packages
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840366#action_12840366 ]
Guillaume Nodet commented on FELIX-2117:
----------------------------------------
I think using both makes sense. The optional imports will make sure the package will be wired if it's available when the bundle is resolved instead of delaying it until it's used.
> Use DynamicImport instead of Optional Packages
> ----------------------------------------------
>
> Key: FELIX-2117
> URL: https://issues.apache.org/jira/browse/FELIX-2117
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
> Reporter: Valentin Valchev
>
> Currently the web console uses optional packages for some plugins.
> Unfortunately an 'optional' import is wired when the bundle is resolved.
> DynamicImport however is wired when the package is accessed.
> This means, that currently, you
> - install webconsole
> - install scr
> = scr plugin is not available
> - resolve webconsole (again)
> = scr plugin is available after 1 additional step
> However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.