[jira] [Commented] (FELIX-3711) Make more REST Urls available in UI (component id/name and service pid is often not clickable)
[ https://issues.apache.org/jira/browse/FELIX-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476047#comment-13476047 ] Felix Meschberger commented on FELIX-3711: -- I understand your request, but I think the solution is not appropriate: * Checking for a plugin's existince from another plugin (or the core by that matter) introduces a nasty back-coupling which is error-prone should the plugin be refactored. * Linking to other plugins is problematic (and we only very reluctantly did it until now). I think the BundleInfo approach sketched by FELIX-3140 is supperior (and should be generalized/extended to also cover other areas like: * bundles linking to services and components * components linking to their configuration * components linking to services * services linking to components Finally, while I agree, that it would be helpful to have links to self other than by bundle ID, I think such links are a presentation task better done in the respective JavaScript file (e.g. bundles.js for the bundles list) and not the JSON generation. I'd prefer to have the JSONs HTML-free and just provide the raw data. Make more REST Urls available in UI (component id/name and service pid is often not clickable) -- Key: FELIX-3711 URL: https://issues.apache.org/jira/browse/FELIX-3711 Project: Felix Issue Type: New Feature Components: Web Console Affects Versions: webconsole-4.0.0 Reporter: Georg Henzler Attachments: org.apache.felix.webconsole.patch-for-FELIX-3711-v2.patch Many REST urls already work if created manually, but are not yet available as links in the UI: http://localhost:8080/system/console/bundles/org.apache.felix.webconsole http://localhost:8080/system/console/bundles/org.apache.felix.webconsole:4.0.1.SNAPSHOT http://localhost:8080/system/console/configMgr/org.apache.felix.webconsole.plugins.event.internal.PluginServlet http://localhost:8080/system/console/components/com.test.scr.ClassB It would be easy to put the appropriate link behind the property values in bundles/configuration/services detail views. I use the REST Urls a lot as they are really valuable in email/instant messenger/JIRA/WIKI to bring people with one click to the desired location, therefore it would be nice to not have to construct them manually. -- 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-3700) DS Factory Components don't support configuration-policy = require
[
https://issues.apache.org/jira/browse/FELIX-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476070#comment-13476070
]
Pierre De Rop commented on FELIX-3700:
--
Thanks David for reacting;
Ok, I do agree: in section 112.7, the specification forbids to use a factory
configuration pid in order to configure a DS component factory.
But this issue is not about using a factory configuration pid: it is about
using a single configuration pid for configuring a DS component factory. By
single configuration pid, I'm talking about configurations created with the
org.osgi.service.cm.ConfigurationAdmin.getConfiguration(java.lang.String pid,
java.lang.String location) method.
That beeing said, one week has passed since I posted this issue and many
commits have been made ...
So I have to recheck with the current trunk, and will get back as soon as
possible.
DS Factory Components don't support configuration-policy = require
--
Key: FELIX-3700
URL: https://issues.apache.org/jira/browse/FELIX-3700
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Environment: linux, jdk1.6
Reporter: Pierre De Rop
Attachments: ComponentFactoryTest.java, FELIX-3700.patch
With scr 1.6.0 and also with scr from trunk, there is the following problem:
When a factory component (declared with a factory attribute in the Component
element), and when the Component is also defined with configuration-policy =
require, then the org.osgi.service.component.ComponentFactory associated to
the factory component is registered in the OSGi registry even if the
configuration for the component is not yet available.
This is a problem because when the
org.osgi.service.component.ComponentFactory is registered in the registry,
then another component using the ComponentFactory may call the newInstance
method and then instantiate the component without the required configuration.
For example, in the following code, Main is injected with the A
ComponentFactory and creates immediately one A instance: but at this point,
the Configuration for A has not yet been created (see in the Main.start
method, where a thread is started in order to create the A configuration
after 1 second ...).
I expect A ComponentFactory to be registered only after the A Configuration
is available from config admin, because the A configuration-policy has been
set to the require value.
Am I correct or does the spec forbid factory components to use the
configuration-policy = require ?
-
@Component(name=A, factory = A, configurationPolicy =
ConfigurationPolicy.require)
public class A {
@Activate
void start(Map?, ? config) {
System.out.println(A.start: + config.get(foo);
}
}
@Component
public class Main {
private ConfigurationAdmin _cm;
@Reference(type = '*', target = (component.factory=A))
void bindCF(ComponentFactory cf) { // should only be called once A config
admin configuration is avail
System.out.println(Main.bindCF);
cf.newInstance(null);
}
@Reference
void bindCM(ConfigurationAdmin cm) {
_cm = cm;
}
@Activate
void start() {
System.out.println(Main.start);
new Thread(new Runnable() {
public void run() {
try {
Thread.sleep(1000);
System.out.println(Configuring A);
Configuration config = _cm.getConfiguration(A, null);
config.update(new Hashtable() {
{
put(foo, bar);
}
});
} catch (Exception ioe) {
ioe.printStackTrace();
}
}
}).start();
}
}
--
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-3711) Make more REST Urls available in UI (component id/name and service pid is often not clickable)
[
https://issues.apache.org/jira/browse/FELIX-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476089#comment-13476089
]
Georg Henzler commented on FELIX-3711:
--
= RE presentation task better done in the respective JavaScript
Not polluting the JSON with Html is a good point - so I agree a frontend js
solution could be the better approach. Let's have a look at the JSON how it's
currently delivered:
{ key: Bundle-SymbolicName, value: com.day.cq.wcm.cq-wcm-foundation }
{ key: Service ID a href='/system/console/services/797'797/a,
value: [
Types: javax.servlet.Servlet, javax.servlet.ServletConfig,
java.io.Serializable,
Service PID: com.day.cq.wcm.foundation.ParagraphServlet,
Component Name: com.day.cq.wcm.foundation.ParagraphServlet,
Component ID: 563,
Vendor: Day Management AG
] }
We have some html in the JSON already (Service ID-Link)... to get rid of it
(and to support the new feature of this issue) we could refactor it as follows:
{ key: Bundle-SymbolicName, label: Symbolic Name, value:
com.day.cq.wcm.cq-wcm-foundation, link: http:// can be optional }
{ key: service.id, label: Service ID, link:
/system/console/services/797
value: [
...
{ key: component.name, Label: Component Name
com.day.cq.wcm.foundation.ParagraphServlet, link: http:// can be
optional }
...
]}
But obviously this would mean a bit of refactoring on both JS and Java sides.
= RE: BundleInfo approach superior
IMHO, this not the case - the BundleInfo mechanism would get a lot more
complicated to be able to hook into the basic display of the bundle... I
believe the links should be a first level citizen in the UI and not be
provided by some sort of plugin mechanism.
Make more REST Urls available in UI (component id/name and service pid is
often not clickable)
--
Key: FELIX-3711
URL: https://issues.apache.org/jira/browse/FELIX-3711
Project: Felix
Issue Type: New Feature
Components: Web Console
Affects Versions: webconsole-4.0.0
Reporter: Georg Henzler
Attachments: org.apache.felix.webconsole.patch-for-FELIX-3711-v2.patch
Many REST urls already work if created manually, but are not yet available as
links in the UI:
http://localhost:8080/system/console/bundles/org.apache.felix.webconsole
http://localhost:8080/system/console/bundles/org.apache.felix.webconsole:4.0.1.SNAPSHOT
http://localhost:8080/system/console/configMgr/org.apache.felix.webconsole.plugins.event.internal.PluginServlet
http://localhost:8080/system/console/components/com.test.scr.ClassB
It would be easy to put the appropriate link behind the property values in
bundles/configuration/services detail views.
I use the REST Urls a lot as they are really valuable in email/instant
messenger/JIRA/WIKI to bring people with one click to the desired location,
therefore it would be nice to not have to construct them manually.
--
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-3711) Make more REST Urls available in UI (component id/name and service pid is often not clickable)
[ https://issues.apache.org/jira/browse/FELIX-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476090#comment-13476090 ] Georg Henzler commented on FELIX-3711: -- Maybe another question before we dive too deep into the discussion about the solution: Do you general agree, that it's worthwhile to have those REST URLs available in the web console? Make more REST Urls available in UI (component id/name and service pid is often not clickable) -- Key: FELIX-3711 URL: https://issues.apache.org/jira/browse/FELIX-3711 Project: Felix Issue Type: New Feature Components: Web Console Affects Versions: webconsole-4.0.0 Reporter: Georg Henzler Attachments: org.apache.felix.webconsole.patch-for-FELIX-3711-v2.patch Many REST urls already work if created manually, but are not yet available as links in the UI: http://localhost:8080/system/console/bundles/org.apache.felix.webconsole http://localhost:8080/system/console/bundles/org.apache.felix.webconsole:4.0.1.SNAPSHOT http://localhost:8080/system/console/configMgr/org.apache.felix.webconsole.plugins.event.internal.PluginServlet http://localhost:8080/system/console/components/com.test.scr.ClassB It would be easy to put the appropriate link behind the property values in bundles/configuration/services detail views. I use the REST Urls a lot as they are really valuable in email/instant messenger/JIRA/WIKI to bring people with one click to the desired location, therefore it would be nice to not have to construct them manually. -- 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-3700) DS Factory Components don't support configuration-policy = require
[
https://issues.apache.org/jira/browse/FELIX-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476164#comment-13476164
]
Pierre De Rop commented on FELIX-3700:
--
ok, I have aligned the patch with the current trunk.
so, regarding your questions:
1) I haven't tried your patch but I don't really understand why you need the
new variable. What happens if you leave it out?
-
the m_componentMetadata variable is used because the
ComponentFactoryImpl.hasConfiguration() should return false if the config
policy is required and if the configuration is not yet available. This variable
is set to true when the configurationUpdated method is called (when config
admin gives us the configuration).
Now, I do agree that we could avoid using this extra variable... I will manage
to rework the patch without using this extra variable.
2) It also looks to me as if ComponentFactoryImpl.getProperties is wrong in
the presence of a configuration that overrides some target properties from the
metadata. Is this the additional problem you saw?
I did not find this problem but looking at the code, I do agree with you, we
probably have this problem too.
Now the new problem I found is another one: Since the commit of
AbstractComponentManager.java, from revision 1397887:
http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java?r1=1397886r2=1397887
then any component factory defined with configuration-policy = require, and
also with some required (and available) service dependencies remains
unsatisfied.
I mean: the ComponentFactory is never registered into the registry even if the
required References are available and if the configuration is also available.
I have to make an integration test for this problem ...
If we remove the if ( !m_componentMetadata.isConfigurationRequired() ) test
from the AbstractComponentManager.enableDependencyManagers method,
then we don't have the problem:
private void enableDependencyManagers() throws InvalidSyntaxException
{
//if ( !m_componentMetadata.isConfigurationRequired() )
//{
Iterator it = getDependencyManagers();
while ( it.hasNext() )
{
DependencyManager dm = (DependencyManager) it.next();
dm.enable();
}
//}
}
I wonder why the dependency managers are not enabled if the configuration is
required ?
DS Factory Components don't support configuration-policy = require
--
Key: FELIX-3700
URL: https://issues.apache.org/jira/browse/FELIX-3700
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Environment: linux, jdk1.6
Reporter: Pierre De Rop
Attachments: ComponentFactoryTest.java, FELIX-3700.patch
With scr 1.6.0 and also with scr from trunk, there is the following problem:
When a factory component (declared with a factory attribute in the Component
element), and when the Component is also defined with configuration-policy =
require, then the org.osgi.service.component.ComponentFactory associated to
the factory component is registered in the OSGi registry even if the
configuration for the component is not yet available.
This is a problem because when the
org.osgi.service.component.ComponentFactory is registered in the registry,
then another component using the ComponentFactory may call the newInstance
method and then instantiate the component without the required configuration.
For example, in the following code, Main is injected with the A
ComponentFactory and creates immediately one A instance: but at this point,
the Configuration for A has not yet been created (see in the Main.start
method, where a thread is started in order to create the A configuration
after 1 second ...).
I expect A ComponentFactory to be registered only after the A Configuration
is available from config admin, because the A configuration-policy has been
set to the require value.
Am I correct or does the spec forbid factory components to use the
configuration-policy = require ?
-
@Component(name=A, factory = A, configurationPolicy =
ConfigurationPolicy.require)
public class A {
@Activate
void start(Map?, ? config) {
System.out.println(A.start: + config.get(foo);
}
}
@Component
public class Main {
private ConfigurationAdmin _cm;
@Reference(type = '*', target = (component.factory=A))
void bindCF(ComponentFactory cf) { // should only be called once A config
admin configuration is avail
System.out.println(Main.bindCF);
cf.newInstance(null);
}
@Reference
void bindCM(ConfigurationAdmin cm) {
_cm = cm;
}
@Activate
void start() {
[jira] [Updated] (FELIX-3700) DS Factory Components don't support configuration-policy = require
[
https://issues.apache.org/jira/browse/FELIX-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-3700:
-
Attachment: FELIX-37000.patch2
Attached a cleaned version of the initial patch (I'm still using an extra
m_isConfigured class attribute).
The patch also includes a modification made in the integration
ComponentFactoryTest.
Also implemented deactivation of the ComponentFactory when configuration is
lost (and when configuration policy was required).
I wonder if all created component instances (with ComponentFactory.newInstance)
should also be deactivated when configuration is lost ? (I prefer to think
about this a bit before committing anything. what do you think ?
DS Factory Components don't support configuration-policy = require
--
Key: FELIX-3700
URL: https://issues.apache.org/jira/browse/FELIX-3700
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Environment: linux, jdk1.6
Reporter: Pierre De Rop
Attachments: ComponentFactoryTest.java, FELIX-37000.patch2,
FELIX-3700.patch
With scr 1.6.0 and also with scr from trunk, there is the following problem:
When a factory component (declared with a factory attribute in the Component
element), and when the Component is also defined with configuration-policy =
require, then the org.osgi.service.component.ComponentFactory associated to
the factory component is registered in the OSGi registry even if the
configuration for the component is not yet available.
This is a problem because when the
org.osgi.service.component.ComponentFactory is registered in the registry,
then another component using the ComponentFactory may call the newInstance
method and then instantiate the component without the required configuration.
For example, in the following code, Main is injected with the A
ComponentFactory and creates immediately one A instance: but at this point,
the Configuration for A has not yet been created (see in the Main.start
method, where a thread is started in order to create the A configuration
after 1 second ...).
I expect A ComponentFactory to be registered only after the A Configuration
is available from config admin, because the A configuration-policy has been
set to the require value.
Am I correct or does the spec forbid factory components to use the
configuration-policy = require ?
-
@Component(name=A, factory = A, configurationPolicy =
ConfigurationPolicy.require)
public class A {
@Activate
void start(Map?, ? config) {
System.out.println(A.start: + config.get(foo);
}
}
@Component
public class Main {
private ConfigurationAdmin _cm;
@Reference(type = '*', target = (component.factory=A))
void bindCF(ComponentFactory cf) { // should only be called once A config
admin configuration is avail
System.out.println(Main.bindCF);
cf.newInstance(null);
}
@Reference
void bindCM(ConfigurationAdmin cm) {
_cm = cm;
}
@Activate
void start() {
System.out.println(Main.start);
new Thread(new Runnable() {
public void run() {
try {
Thread.sleep(1000);
System.out.println(Configuring A);
Configuration config = _cm.getConfiguration(A, null);
config.update(new Hashtable() {
{
put(foo, bar);
}
});
} catch (Exception ioe) {
ioe.printStackTrace();
}
}
}).start();
}
}
--
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] [Updated] (FELIX-3707) Uses constraints not properly checked with require bundle
[ https://issues.apache.org/jira/browse/FELIX-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson updated FELIX-3707: - Attachment: org.apache.felix.resolver.patch There was a bug in my 'performance' fix from the last patch. The resultCache must not be cleared out each time a ResolutionException is thrown. Instead a new HashMap resultCache should only get created each time a new permutation is attempted. This updated patch simply removes line of code that clears the resultCache map. The patch already creates a new resultCache map each time a new permutation is checked. Uses constraints not properly checked with require bundle - Key: FELIX-3707 URL: https://issues.apache.org/jira/browse/FELIX-3707 Project: Felix Issue Type: Bug Components: Resolver Environment: All Reporter: Thomas Watson Labels: patch Attachments: org.apache.felix.resolver.patch Original Estimate: 2h Remaining Estimate: 2h The following set of manifests should result in require.b1 being unresolvable due to an inconsistent class space for package p1: Bundle-ManifestVersion: 2 Bundle-SymbolicName: require.b1 Bundle-Version: 1.0.0 Require-Bundle: require.b2, require.b3 Bundle-ManifestVersion: 2 Bundle-SymbolicName: require.b2 Bundle-Version: 1.0.0 Export-Package: p1 Bundle-ManifestVersion: 2 Bundle-SymbolicName: require.b3 Bundle-Version: 1.0.0 Export-Package: p2; uses:=p1 Require-Bundle: require.b4 Bundle-ManifestVersion: 2 Bundle-SymbolicName: require.b4 Bundle-Version: 1.0.0 Export-Package: p1 I will attach a possible fix and testcase -- 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] [Updated] (FELIX-3707) Uses constraints not properly checked with require bundle
[ https://issues.apache.org/jira/browse/FELIX-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson updated FELIX-3707: - Attachment: (was: org.apache.felix.resolver.patch) Uses constraints not properly checked with require bundle - Key: FELIX-3707 URL: https://issues.apache.org/jira/browse/FELIX-3707 Project: Felix Issue Type: Bug Components: Resolver Environment: All Reporter: Thomas Watson Labels: patch Attachments: org.apache.felix.resolver.patch Original Estimate: 2h Remaining Estimate: 2h The following set of manifests should result in require.b1 being unresolvable due to an inconsistent class space for package p1: Bundle-ManifestVersion: 2 Bundle-SymbolicName: require.b1 Bundle-Version: 1.0.0 Require-Bundle: require.b2, require.b3 Bundle-ManifestVersion: 2 Bundle-SymbolicName: require.b2 Bundle-Version: 1.0.0 Export-Package: p1 Bundle-ManifestVersion: 2 Bundle-SymbolicName: require.b3 Bundle-Version: 1.0.0 Export-Package: p2; uses:=p1 Require-Bundle: require.b4 Bundle-ManifestVersion: 2 Bundle-SymbolicName: require.b4 Bundle-Version: 1.0.0 Export-Package: p1 I will attach a possible fix and testcase -- 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
