[jira] [Created] (FELIX-2976) InvocationUtil cache is not used properly for determining that methods do not exist in a class
InvocationUtil cache is not used properly for determining that methods do not exist in a class -- Key: FELIX-2976 URL: https://issues.apache.org/jira/browse/FELIX-2976 Project: Felix Issue Type: Bug Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Reporter: Marcel Offermans Assignee: Marcel Offermans There is a bug in the InvocationUtil cache that prevents it from properly remembering that certain methods did not exist in a class. InvocationUtil.getDeclaredMethod(...) checks the cache and only returns something when the cache does not return null. But, null is actually a valid result, so we need to add a check to see if they key was in the map but with a null value. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2976) InvocationUtil cache is not used properly for determining that methods do not exist in a class
[ https://issues.apache.org/jira/browse/FELIX-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-2976. - Resolution: Fixed InvocationUtil cache is not used properly for determining that methods do not exist in a class -- Key: FELIX-2976 URL: https://issues.apache.org/jira/browse/FELIX-2976 Project: Felix Issue Type: Bug Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Reporter: Marcel Offermans Assignee: Marcel Offermans There is a bug in the InvocationUtil cache that prevents it from properly remembering that certain methods did not exist in a class. InvocationUtil.getDeclaredMethod(...) checks the cache and only returns something when the cache does not return null. But, null is actually a valid result, so we need to add a check to see if they key was in the map but with a null value. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2962) SCR doesn't detect invalid XML
[ https://issues.apache.org/jira/browse/FELIX-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041083#comment-13041083 ] Felix Meschberger commented on FELIX-2962: -- Excellent. Thanks, this helps. SCR doesn't detect invalid XML -- Key: FELIX-2962 URL: https://issues.apache.org/jira/browse/FELIX-2962 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Andrew Pimlott Labels: xml The XML parser (kxml2) used by SCR doesn't detect many forms of incorrect XML, even basic errors like mismatched start and end tags. This makes diagnosing component load errors very frustrating. Please use a real XML parser. It will save developers a lot of pain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: NPE with felix framework 3.0.8
Hi,
Sure.
Regards
Felix
Am Dienstag, den 24.05.2011, 15:28 +0100 schrieb Richard S. Hall:
Keep me posted...thanks.
- richard
On 5/24/11 3:28, Felix Meschberger wrote:
Hi,
Am Montag, den 23.05.2011, 14:59 +0100 schrieb Richard S. Hall:
If I recall, I don't think that should be null.
That would be my interpretation, too. But unfortunately it can happen.
It would be awesome if
there was some way to reproduce it.
I try to get hold to a system which exhibits this problem and try to
find out how to reproduce ...
At the moment it looks like this:
* start framework
* after startup install and start a bunch of bundles
* use the system
-- NPE occurs
* stop framework
* start the framework again
-- all bundles already installed and starting properly
* use the system
-- works flawlessly without NPE
So it sounds like an issue related to resolution bundles installed after
startup.
Regards
Felix
- richard
On 5/23/11 6:05, Felix Meschberger wrote:
Hi,
A user of ours just reported this stack trace with 3.0.7:
org.apache.felix.framework.resolver.ResolverImpl.permutateIfNeeded(ResolverImpl.java:1140)
org.apache.felix.framework.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1066)
org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:176)
org.apache.felix.framework.FelixFelixResolver.resolve(Felix.java:4066)
org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1412)
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)
Looking at the code in question:
SortedSetCapability candidates = allCandidates.getCandidates(req);
if (candidates.size() 1)
{
it seems like there is no candidates set for the requirement which
causes the candidates.size() method to throw .. This is still the same
code in 3.2.2.
The user in fact reports that after a restart everything works fine.
Regards
Felix
Am Mittwoch, den 02.02.2011, 22:37 + schrieb Richard S. Hall:
I don't think anything changed in that area for 3.0.8, but you could try
it on 3.0.7 to see.
If it is reproducible, then open a bug and tell me how and I'll look
into it.
- richard
On 2/2/11 16:30, Guillaume Nodet wrote:
I just had this exception while testing with the latest 3.0.8
java.lang.NullPointerException
at
org.apache.felix.framework.resolver.ResolverImpl.permutateIfNeeded(ResolverImpl.java:1140)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1066)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:176)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4100)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1412)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)[org.apache.felix.framework-3.0.8.jar:]
at
java.lang.ClassLoader.loadClass(ClassLoader.java:248)[:1.6.0_22]
at
org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1612)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904)[org.apache.felix.framework-3.0.8.jar:]
at
org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.findCompatibleNamespaceHandler(NamespaceHandlerRegistryImpl.java:369)[10:org.apache.aries.blueprint:0.3.0]
at
org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.registerHandler(NamespaceHandlerRegistryImpl.java:325)[10:org.apache.aries.blueprint:0.3.0]
at
org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.registerHandler(NamespaceHandlerRegistryImpl.java:135)[10:org.apache.aries.blueprint:0.3.0]
at
org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:97)[10:org.apache.aries.blueprint:0.3.0]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)[karaf.jar:]
at
[jira] [Commented] (FELIX-2961) SCR ConfigurationAdmin : service.pid resolution
[
https://issues.apache.org/jira/browse/FELIX-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041085#comment-13041085
]
Felix Meschberger commented on FELIX-2961:
--
What exactly do you have in mind for option 2 ? As it stands, it is a
compile-time constant (actually ending in the constant pool section of the
class).
But then you should anyway be able to do this:
@Component(name=TheClass.SOME_NAME_FIELD)
class TheClass {
private static final String SOME_NAME_FIELD=some constant;
}
Right ?
SCR ConfigurationAdmin : service.pid resolution
-
Key: FELIX-2961
URL: https://issues.apache.org/jira/browse/FELIX-2961
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Affects Versions: scr-1.6.0
Reporter: Andrei Pozolotin
hello!
when I use config admin to control instaniation of scr component services, I
use this pattern:
// 1) in config source bundle:
Configuration config =
configAdmin.getConfiguration(ZZZ, null);
DictionaryString, String props =
config.getProperties();
config.update(props);
// 2) in config target bundle:
@Service
@Component(name = AAA, policy = ConfigurationPolicy.REQUIRE, immediate =
true)
public class BucketPlugin implements PluginSpaceService {
@Property(name = service.pid)
protected static final String PID = ZZZ;
// 3) despite the fact service.pid looks good in xml for the tagret
compenent:
scr:component enabled=true immediate=true name=AAA
configuration-policy=require
implementation class=com.ddfplus.core.space.BucketPlugin/
service servicefactory=false
provide interface=com.ddfplus.api.plugin.PluginSpaceService/
/service
property name=service.pid type=String value=ZZZ/
// 4) the scr fails to initialize the component; intitialzation works only
when
(scr.component.name == config.service.pid) and NOT when (config.service.pid
== scr.component.property.pid)
// 5) if I look on the the config target in console (when I do manage to
inititialize it),
it shows that again, actual service.pid comes from scr.component.name and not
from scr.component.property.service.pid
thank you.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-2971) Configuration changes cannot be made via Felix Web Console in IE7
[ https://issues.apache.org/jira/browse/FELIX-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-2971: Assignee: Felix Meschberger Configuration changes cannot be made via Felix Web Console in IE7 - Key: FELIX-2971 URL: https://issues.apache.org/jira/browse/FELIX-2971 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.8 Environment: IE7 Reporter: Christanto Assignee: Felix Meschberger Attachments: support.patch Configuration changes cannot be made via Felix Web Console in IE7. Step to replicate: 1. Log inside http://localhost/system/console/configMgr 2. Click one of the config to open the edit window 3. Modify a value 4. Save 5. Reopen the edit window, note that the value is still the same as before This is due to the fact IE7 is not allowing name to be set. See [1]. Attached is the patch. [1] http://bugs.jquery.com/ticket/4691 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2971) Configuration changes cannot be made via Felix Web Console in IE7
[ https://issues.apache.org/jira/browse/FELIX-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041086#comment-13041086 ] Felix Meschberger commented on FELIX-2971: -- Thanks for providing the patch. Applied it in Rev. 1129126 Configuration changes cannot be made via Felix Web Console in IE7 - Key: FELIX-2971 URL: https://issues.apache.org/jira/browse/FELIX-2971 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.8 Environment: IE7 Reporter: Christanto Assignee: Felix Meschberger Fix For: webconsole-3.1.10 Attachments: support.patch Configuration changes cannot be made via Felix Web Console in IE7. Step to replicate: 1. Log inside http://localhost/system/console/configMgr 2. Click one of the config to open the edit window 3. Modify a value 4. Save 5. Reopen the edit window, note that the value is still the same as before This is due to the fact IE7 is not allowing name to be set. See [1]. Attached is the patch. [1] http://bugs.jquery.com/ticket/4691 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2971) Configuration changes cannot be made via Felix Web Console in IE7
[ https://issues.apache.org/jira/browse/FELIX-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2971. -- Resolution: Fixed Fix Version/s: webconsole-3.1.10 Fixed. Configuration changes cannot be made via Felix Web Console in IE7 - Key: FELIX-2971 URL: https://issues.apache.org/jira/browse/FELIX-2971 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.8 Environment: IE7 Reporter: Christanto Assignee: Felix Meschberger Fix For: webconsole-3.1.10 Attachments: support.patch Configuration changes cannot be made via Felix Web Console in IE7. Step to replicate: 1. Log inside http://localhost/system/console/configMgr 2. Click one of the config to open the edit window 3. Modify a value 4. Save 5. Reopen the edit window, note that the value is still the same as before This is due to the fact IE7 is not allowing name to be set. See [1]. Attached is the patch. [1] http://bugs.jquery.com/ticket/4691 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: iPOJO vs SCR vs Blueprint
Hi, Just stating an incompletely informed opinion here .. If you want something simple, light-weight and easy to use, go for Declarative Services. If you want elaborate functionality or need something Declarative Services does not provide, consider iPojo (I understand it is an evolution of Declarative Services, right ?) If you have a Spring background go for blueprint. Regards Felix, whose loves and sticks with Declarative Services ;-) Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan: On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham n...@apache.org wrote: Alasdair Nottingham On 25 May 2011, at 22:16, Richard S. Hall he...@ungoverned.org wrote: On 5/25/11 16:26, Alasdair Nottingham wrote: Hi, This is good I might link to it, or pinch it for the aries webpage too if that is ok. When doing that thought I would put some changes into the blueprint column. The Aries blueprint implementation provides some value add that would change some of the No's into Yes's. Sure. One thing though in component lifecycle control you have a Partial down for blueprint I was wondering what you meant by this. I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-) Of course if you were an expert you would know how much better it is than anything else ;) let the religious flame war begin, or not. In fact, casual users wish for an almighty expert who knows all solutions in-depth and exposes them to all. If there's no such expert, the second best method is, experts of different solutions advertise themself and compare with each other. Maybe that can be called religious flame war, but it's valuable. What we really need in open community is simple and perfect product in technology, but not many repeat manufacturing wheels like some outside companies. Regards, drhades - richard Thanks Alasdair On 25 May 2011 15:29, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 9:19, Richard S. Hall wrote: We actually have a table in our book (OSGi in Action) that tries to compare the features...perhaps I could re-create that table on a web page... Ok, I added the table to the iPOJO FAQ on wiki: https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F It's not perfect, but it is better than nothing. It should eventually propagate to our static pages. Clement, please double check the iPOJO features, since you've added features since the book has been published. - richard On 5/25/11 5:26, jie yan wrote: +1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.org wrote: On 05/24/2011 09:46 PM, jie yan wrote: I wonder what is the difference between these three component runtime. They all manage service dependencies. Blueprint and iPOJO provide more sophisticated features than DS. Each has a different focus or goal. I guess everyone like myself is seeing this question occur regularly on this mailing list. It's a valid question that perhaps we can dedicate a wiki/web page to with the pros and cons. I myself have many questions and can't really tell which is best for our needs at directory but I do know that I have to sit down and do the research. However our situation is much more unique since we back configuration information needed to wire the server inside a LDIF/LDAP based backing store. Lots to think about for us. Excuse the digression on our specific issues but regarding having a page dedicated to the pros and cons of each option at felix could benefit many of our users. Best, Alex
[jira] [Commented] (FELIX-2968) Bind method of optional references can be called before bind methods of mandatory references
[ https://issues.apache.org/jira/browse/FELIX-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041091#comment-13041091 ] Felix Meschberger commented on FELIX-2968: -- The order is specified exactly in Section 112.5.7, Binding Services: When binding services, the references are processed in the order in which they are specified in the component description. That is, target services from the first specified reference are bound before services from the next speci- fied reference. So, just order the references correctly in your descriptor and you should be done. Bind method of optional references can be called before bind methods of mandatory references Key: FELIX-2968 URL: https://issues.apache.org/jira/browse/FELIX-2968 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Guest Labels: felix, scr Original Estimate: 1h Remaining Estimate: 1h Hi, i got the following problem. I've some references to services, some of them are mandatory and some are optional. Well now osgi/scr waits to call the bind methods till all mandatory services are available. However when it starts to call the bind methods it seems that it doesn't care if those are mandatory or optional. This can result in a not expected behavior where optional dependencies are satisfied before the mandatory are. Consider you have a optional dynamic multiple service binding which you want to use with a mandatory service. There's as far as it looks to me no way to ensure that the mandatory binds are called before optional are allowed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Split Web Console
Hi, Am Donnerstag, den 19.05.2011, 16:02 +0100 schrieb Valentin Valchev: Hello Felix, I personally welcome your suggestion. Let's take benefit of the modularity that OSGi provides and split the plugins. This would also make them easier to maintain. Still too many bundles might be a little bit frustrating. So maybe API + Web Console Impl + Core Support should stay in one bundle - this way installing one bundle you get all core API including the possibility to extend the framework by installing new bundles. Makes sense. This is also exactly the reasoning for the current all-in-one bundle with respect to 3rd party dependencies (commons-fileupload, etc). The other plugins could be individually packaged in bundles. As for the Licenses plugin, I'm not quite sure it is part of the OSGi specification, so IMHO it should be also a separate bundle. The plugin makes use of two sources: One is the Bundle-License header specified in R4.2 and the other is well-known files and locations in Apache libraries. As for the second source moving out would make sense; as for the first source it would not ;-) But you are right. Maybe moving this thing out is the better option. Regards Felix Regards, Valentin Valchev On 19.5.2011 г. 17:37 ч., Felix Meschberger wrote: Hi all, The current Web Console bundle currently contains a lot of stuff with some dependencies to the outside: * Web Console API (optionally used by plugins) * Core Support - Bundles - Services - System Status - Configuration Status (pluggable in itself) - Licenses * OSGi Compendium Support - Felix DS Admin - Configuration Admin - Shell - Log Service - Event Admin - Deployment Admin * Actual Web Console implementation Now, if a framework instance does not have the Compendium Services installed, the respective pages are either empty or erroneous or cause exceptions in the log (see FELIX-2727 for example). I am thinking about splitting the Web Console Bundle up like this: * A Web Console API bundle just exporting the API * A Web Console Core bundle importing the Web Console API, exporting nothing and just providing the Core Support pages as listed above. * One additional bundle for Compendium support allowing for more flexible and dynamic adaption. WDYT ? Regards Felix
[jira] [Commented] (FELIX-2962) SCR doesn't detect invalid XML
[ https://issues.apache.org/jira/browse/FELIX-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041116#comment-13041116 ] Felix Meschberger commented on FELIX-2962: -- Added some checking code to ensure certain situations cause an Exception being thrown in Rev. 1129144: a -- new: throws a ParseException now, used to be silently ignored /a -- already threw an exception ab/a/b -- already threw an exception the new check mechanism particularly should prevent cases like scr:component scr:component Does this work for you ? SCR doesn't detect invalid XML -- Key: FELIX-2962 URL: https://issues.apache.org/jira/browse/FELIX-2962 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Andrew Pimlott Labels: xml The XML parser (kxml2) used by SCR doesn't detect many forms of incorrect XML, even basic errors like mismatched start and end tags. This makes diagnosing component load errors very frustrating. Please use a real XML parser. It will save developers a lot of pain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2977) org.apache.felix.gogo.command: depends on org.osgi.* in scope compile should be provided ?
org.apache.felix.gogo.command: depends on org.osgi.* in scope compile should be provided ? -- Key: FELIX-2977 URL: https://issues.apache.org/jira/browse/FELIX-2977 Project: Felix Issue Type: Bug Components: Gogo Command Reporter: Andrei Pozolotin org.apache.felix.gogo.command: depends on org.osgi.* in scope compile should be provided ? http://search.maven.org/#artifactdetails|org.apache.felix|org.apache.felix.gogo.command|0.8.0|bundle dependencies dependency groupIdorg.osgi/groupId artifactIdorg.osgi.core/artifactId version4.2.0/version /dependency dependency groupIdorg.osgi/groupId artifactIdorg.osgi.compendium/artifactId version4.0.0/version /dependency dependency groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.gogo.runtime/artifactId version0.8.0/version /dependency dependency groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.bundlerepository/artifactId version1.6.0/version /dependency /dependencies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2978) Lookup reference policy does not work for inherited components
Lookup reference policy does not work for inherited components -- Key: FELIX-2978 URL: https://issues.apache.org/jira/browse/FELIX-2978 Project: Felix Issue Type: Bug Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.7.0 Reporter: Vlad Arkhipov org.apache.felix.scrplugin.xml.ComponentDescriptorIO.generateXML(final String namespace,Reference reference, ContentHandler contentHandler, boolean isScrPrivateFile) does not save strategy property of a reference, however org.apache.felix.scrplugin.SCRDescriptorGenerator.execute() uses Reference.isLookupStrategy() to determine the reference's strategy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2978) Lookup reference policy does not work for inherited components
[ https://issues.apache.org/jira/browse/FELIX-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Arkhipov updated FELIX-2978: - Description: org.apache.felix.scrplugin.xml.ComponentDescriptorIO.generateXML(final String namespace,Reference reference, ContentHandler contentHandler, boolean isScrPrivateFile) does not save strategy property of a reference. org.apache.felix.scrplugin.xml.ComponentDescriptorIO.XmlHandler.startElement(String uri, String localName, String name, Attributes attributes) does not load strategy property of a reference. However org.apache.felix.scrplugin.SCRDescriptorGenerator.execute() uses Reference.isLookupStrategy() to determine the reference's strategy. was: org.apache.felix.scrplugin.xml.ComponentDescriptorIO.generateXML(final String namespace,Reference reference, ContentHandler contentHandler, boolean isScrPrivateFile) does not save strategy property of a reference, however org.apache.felix.scrplugin.SCRDescriptorGenerator.execute() uses Reference.isLookupStrategy() to determine the reference's strategy. Lookup reference policy does not work for inherited components -- Key: FELIX-2978 URL: https://issues.apache.org/jira/browse/FELIX-2978 Project: Felix Issue Type: Bug Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.7.0 Reporter: Vlad Arkhipov Original Estimate: 5m Remaining Estimate: 5m org.apache.felix.scrplugin.xml.ComponentDescriptorIO.generateXML(final String namespace,Reference reference, ContentHandler contentHandler, boolean isScrPrivateFile) does not save strategy property of a reference. org.apache.felix.scrplugin.xml.ComponentDescriptorIO.XmlHandler.startElement(String uri, String localName, String name, Attributes attributes) does not load strategy property of a reference. However org.apache.felix.scrplugin.SCRDescriptorGenerator.execute() uses Reference.isLookupStrategy() to determine the reference's strategy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
