SCR concurrency issues (cf FELIX-3456)
We've run into one definite concurrency problem in SCR and I've been discussing offline with a colleague how to fix it and wanted to get the discussion out in the open. The original symptom was when 2 mandatory service refs were satisfied on different threads at once: the 2nd wasn't recognized so the component never got activated. This is easily solved by synchronizing but this introduces risk of deadlocks (my first attempt, https://issues.apache.org/jira/secure/attachment/12522537/FELIX-3456-1.diff) We tried some partly asynchronous approaches such as https://issues.apache.org/jira/secure/attachment/12523313/FELIX-3456-4.diff. Unless there's a timeout (presumably due to deadlock) this gets all service events processed before the thread exits from its first call into SCR. However this can result in service events getting processed later than one expects possibly on a different thread. On further thought we concluded that a service event must be processed fully before the service registration call returns. We therefore don't think any kind of asynchronous approach will work. We've discovered the anti-circular-dependency clause in the spec (112.3.5) but it appears to be overly biased towards SCR-only graphs of services. We are leaning towards thinking that SCR also needs to consider: - an activate method registers a service that satisfies an optional dependency of a component being activated by scr on the same thread. - the same, except the activate method starts a new thread to register the service and waits for it to complete. Another scenario to consider is components C1 and C2 registering as services, each with an optional dynamic dependency on the other. If one starts, and then the other, there is no problem, they both get references to the other. If they both start at the same time in separate threads (either because they are in different bundles or because they get activated due to mandatory references being satisfied) and register the services while the other is in the Activating state, a simple lock over the service event processing will result in deadlock. Furthermore, to get the correct result, at least one of the services has to be bound while the component to which is is binding is in the Activating state. It looks like the situation can be simplified a bit by considering, for service events, whether the dependency will result in a state change: if it's optional or mandatory but not the only satisfying service, it won't, but if it's mandatory and the first satisfying service, it will. We can calculate this before calling any bind methods or activate methods. After determining this, we know the final state of the component. We're considering whether some kind of 2-stage lock would work: one level can change the state and blocks all other threads the other level can't change the state and lets stuff like service events for non-state-changing service references be processed according to the final state of the component. (e.g. activating will let bind methods be called on the under-configuration object). This does not yet consider bundle event driven state changes or deactivation or delayed component creation or service factories. Comments and more scenarios to consider are more than welcome. thanks david jencks
Re: Web Console plugin releases (Re: [VOTE] Release Apache Felix Web Console 3.4.0)
Hi,
Am 19.04.2012 um 16:24 schrieb Valentin Valchev:
> On 19.4.2012 г. 17:09 ч., Felix Meschberger wrote:
>> Hi Valentin,
>>
>> I see we have two different approaches to the i18n problem.
>>
>> (1) You create another resources entry pointing to target
>> (2) I configure the bundle plugin to consider the target in addition to
>> source
>>
>> IMHO the bundle plugin config is preferred because this really comes from a
>> problem with the bundle plugin which copies the {maven-resources} from the
>> source instead of copying the processed target resources.
>>
>> Where shall we go ?
> I really don't care which of these variants is chosen. In both ways the
> plugins will be working correctly and that is what's important. So you
> choose.
>>
>> Other than that, I would be ready for plugin releases. I suppose we just
>> release all plugins with changes since the last release, right ?
> Right. Actually part of those plugins were removed from WebConsole and
> now are separate. For others - like UPnP and Event plugin there are
> numerous improvements and bug fixes.
I go ahead and do the stuff ASAP.
Regards
Felix
>
>
>>
>> Regards
>> Felix
>>
>> Am 19.04.2012 um 15:50 schrieb Valentin Valchev:
>>
>>> +1 (non binding)
>>>
>>> PS.: What about releasing the plugins too?
>>>
>>> On 19.4.2012 г. 13:08 ч., Felix Meschberger wrote:
Hi,
Here is the Apache Felix Web Console 3.4.0 release. Besides a number of
bug fixes and improvements this release drops the full build and makes the
bare build the only one available. To install the Web Console, three
additional dependencies must now also be installed: Commons IO,
FileUpload, and JSON (e.g. the Geronimo JSON bundle).
We have fixed 43 issues in this release:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12316160
Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-072/
You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
Usage:
sh check_staged_release.sh 072 /tmp/felix-staging
Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)
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.valc...@prosyst.bg
>>> -
>>> stay in touch with your product.
>>> -
>>>
>>>
>
>
> --
>
> -
> 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.valc...@prosyst.bg
> -
> stay in touch with your product.
> -
>
>
Re: Web Console plugin releases (Re: [VOTE] Release Apache Felix Web Console 3.4.0)
On 19.4.2012 г. 17:09 ч., Felix Meschberger wrote:
> Hi Valentin,
>
> I see we have two different approaches to the i18n problem.
>
> (1) You create another resources entry pointing to target
> (2) I configure the bundle plugin to consider the target in addition to
> source
>
> IMHO the bundle plugin config is preferred because this really comes from a
> problem with the bundle plugin which copies the {maven-resources} from the
> source instead of copying the processed target resources.
>
> Where shall we go ?
I really don't care which of these variants is chosen. In both ways the
plugins will be working correctly and that is what's important. So you
choose.
>
> Other than that, I would be ready for plugin releases. I suppose we just
> release all plugins with changes since the last release, right ?
Right. Actually part of those plugins were removed from WebConsole and
now are separate. For others - like UPnP and Event plugin there are
numerous improvements and bug fixes.
>
> Regards
> Felix
>
> Am 19.04.2012 um 15:50 schrieb Valentin Valchev:
>
>> +1 (non binding)
>>
>> PS.: What about releasing the plugins too?
>>
>> On 19.4.2012 г. 13:08 ч., Felix Meschberger wrote:
>>> Hi,
>>>
>>> Here is the Apache Felix Web Console 3.4.0 release. Besides a number of bug
>>> fixes and improvements this release drops the full build and makes the bare
>>> build the only one available. To install the Web Console, three additional
>>> dependencies must now also be installed: Commons IO, FileUpload, and JSON
>>> (e.g. the Geronimo JSON bundle).
>>>
>>> We have fixed 43 issues in this release:
>>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12316160
>>>
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachefelix-072/
>>>
>>> You can use this UNIX script to download the release and verify the
>>> signatures:
>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>>
>>> Usage:
>>> sh check_staged_release.sh 072 /tmp/felix-staging
>>>
>>> Please vote to approve this release:
>>>
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>>
>>> 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.valc...@prosyst.bg
>> -
>> stay in touch with your product.
>> -
>>
>>
--
-
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.valc...@prosyst.bg
-
stay in touch with your product.
-
<>
signature.asc
Description: OpenPGP digital signature
Web Console plugin releases (Re: [VOTE] Release Apache Felix Web Console 3.4.0)
Hi Valentin,
I see we have two different approaches to the i18n problem.
(1) You create another resources entry pointing to target
(2) I configure the bundle plugin to consider the target in addition to source
IMHO the bundle plugin config is preferred because this really comes from a
problem with the bundle plugin which copies the {maven-resources} from the
source instead of copying the processed target resources.
Where shall we go ?
Other than that, I would be ready for plugin releases. I suppose we just
release all plugins with changes since the last release, right ?
Regards
Felix
Am 19.04.2012 um 15:50 schrieb Valentin Valchev:
> +1 (non binding)
>
> PS.: What about releasing the plugins too?
>
> On 19.4.2012 г. 13:08 ч., Felix Meschberger wrote:
>> Hi,
>>
>> Here is the Apache Felix Web Console 3.4.0 release. Besides a number of bug
>> fixes and improvements this release drops the full build and makes the bare
>> build the only one available. To install the Web Console, three additional
>> dependencies must now also be installed: Commons IO, FileUpload, and JSON
>> (e.g. the Geronimo JSON bundle).
>>
>> We have fixed 43 issues in this release:
>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12316160
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-072/
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 072 /tmp/felix-staging
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> 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.valc...@prosyst.bg
> -
> stay in touch with your product.
> -
>
>
Re: [VOTE] Release Apache Felix Web Console 3.4.0
+1 (non binding) PS.: What about releasing the plugins too? On 19.4.2012 г. 13:08 ч., Felix Meschberger wrote: > Hi, > > Here is the Apache Felix Web Console 3.4.0 release. Besides a number of bug > fixes and improvements this release drops the full build and makes the bare > build the only one available. To install the Web Console, three additional > dependencies must now also be installed: Commons IO, FileUpload, and JSON > (e.g. the Geronimo JSON bundle). > > We have fixed 43 issues in this release: > https://issues.apache.org/jira/browse/FELIX/fixforversion/12316160 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-072/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 072 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > 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.valc...@prosyst.bg - stay in touch with your product. - <> signature.asc Description: OpenPGP digital signature
Re: Enhanced Apache Felix / JRebel integration
Hello Robert, On Apr 19, 2012, at 14:34 , Robert Munteanu wrote: >> -Original Message- >> From: Felix Meschberger [mailto:fmesc...@adobe.com] >> Bundle deployment is generally really fast -- unless your bundle is >> large and has a complex import/export list, which would make that >> bundle a bad bundle by definition ;-) > > Agreed, bundle deployment is usually fast. However, the whole deployment > process is not instant for me. My use case is based on Sling, not Felix > standalone. > > I typically have to switch to the console and run something like 'mvn package > sling:install' or hunt for the Maven build command in my IDE and click it. > And all in all the process can take 10-20 seconds. All of that contrasted > with saving a class and then refreshing a web page seems a lot. Did you ever look at BndTools? It is a lot quicker in this respect: as soon as you save a source file, directly after Eclipse compiled it, a bundle is generated and if you had a framework already running inside Eclipse, it is directly updated. No manual steps whatsoever, and usually done within a second or two. You cannot make it much faster unless you take shortcuts that at some point will break (ie. not deploying things "a bundle at a time"). Greetings, Marcel
[jira] [Commented] (FELIX-3471) Support Schema validation for MetaData XML documents
[ https://issues.apache.org/jira/browse/FELIX-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257475#comment-13257475 ] Felix Meschberger commented on FELIX-3471: -- That would be quite heavy to do relying on at least one 3rd party library. What would be the benefit ? > Support Schema validation for MetaData XML documents > > > Key: FELIX-3471 > URL: https://issues.apache.org/jira/browse/FELIX-3471 > Project: Felix > Issue Type: Bug > Components: Metatype Service >Affects Versions: metatype-1.0.4 >Reporter: Alexandre Castro Alves > > MetaData XML documents are not being W3C Schema-validated. > Provide option for doing so. > Thanks > Alex -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3471) Support Schema validation for MetaData XML documents
Support Schema validation for MetaData XML documents Key: FELIX-3471 URL: https://issues.apache.org/jira/browse/FELIX-3471 Project: Felix Issue Type: Bug Components: Metatype Service Affects Versions: metatype-1.0.4 Reporter: Alexandre Castro Alves MetaData XML documents are not being W3C Schema-validated. Provide option for doing so. Thanks Alex -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Enhanced Apache Felix / JRebel integration
> -Original Message- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: Tuesday, April 17, 2012 12:49 PM > To: dev@felix.apache.org > Subject: Re: Enhanced Apache Felix / JRebel integration > > > Perhaps I can explain better with an example rather than in abstract > terms, so here's what I want to achieve in terms of development > experience: > > > > 1. Start Apache Felix with SCR capabilities and with the JRebel agent > > 2. Deploy a bundle with a JRebel configuration attached > > 3. Start listening for changes to the declared SCR descriptors of the > bundle > > That's part of JRebel support ? Yes, and already available without any changes. > > > 4. When the SCR descriptors change on disk, call > PackageAdmin.refreshPackages() > > This is probably not adequate (or even required): What you would have > to do is just stop and start the bundles. refreshPackages would only be > required if you want the wires of the bundle refresh. Right, thanks. > > > > > I can safely do (4) the packages since JRebel already ensures that I > will get the most current version of the class without needing to > redeploy the bundle. I purposefully ignore how the changes will be made > for (3) since that's a different implementation topic. > > > > I am aware that this process does not make sense unless JRebel is > used, so that's why I'm trying to find out the best way of hooking into > the framework without the need to make invasive changes. > > The longer I think of it, the longer I think such a thing is really > futile ... > > Bundle deployment is generally really fast -- unless your bundle is > large and has a complex import/export list, which would make that > bundle a bad bundle by definition ;-) Agreed, bundle deployment is usually fast. However, the whole deployment process is not instant for me. My use case is based on Sling, not Felix standalone. I typically have to switch to the console and run something like 'mvn package sling:install' or hunt for the Maven build command in my IDE and click it. And all in all the process can take 10-20 seconds. All of that contrasted with saving a class and then refreshing a web page seems a lot. > I honestly fail to see the point of JRebel in an OSGi framework ... To rephrase what I've said above - it's not that fast, incremental developement is not supported by OSGi frameworks, it's that it's not fast enough for my goals. My tooling should be smart enough to 'refresh on save', without the need to ask it nicely to repackage and redeploy my bundle. There's also a blog post from one of the JRebel devs regarding how JRebel and OSGi fit together [1]. However, I can see why you're skeptical and when I'll have a proof-of-concept I hope to have some hard numbers to support to difference in speed. Robert [1] http://zeroturnaround.com/blog/jrebel-vs-osgi-use-the-right-tool-for-the-right-job/ > > Regards > Felix > > > > > Robert > > > >> > >> -> richard > >> > >>> > >>> Thanks, > >>> > >>> Robert > >>> > -> richard > > > I would like to validate that this is at all possible within > Apache > Felix and to ask which are the best places to start looking for > >> adding > the JRebel functionality. Any thoughts/pointers on how to best > start > developing this would be greatly appreciated. > > > If this is feasible, I intend to develop this as a separate > JRebel > plugin and contribute it to the Apache Felix project. > > Thanks, > > > > Robert > > > > [1]: http://zeroturnaround.com/jrebel/ > > [2]: http://zeroturnaround.com/jrebel/features/ > >
[VOTE] Release Apache Felix Web Console 3.4.0
Hi, Here is the Apache Felix Web Console 3.4.0 release. Besides a number of bug fixes and improvements this release drops the full build and makes the bare build the only one available. To install the Web Console, three additional dependencies must now also be installed: Commons IO, FileUpload, and JSON (e.g. the Geronimo JSON bundle). We have fixed 43 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12316160 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-072/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 072 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Regards Felix
[jira] [Updated] (FELIX-3470) execute mvn install
[ https://issues.apache.org/jira/browse/FELIX-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liuxin updated FELIX-3470: -- Attachment: maven.log > execute mvn install > --- > > Key: FELIX-3470 > URL: https://issues.apache.org/jira/browse/FELIX-3470 > Project: Felix > Issue Type: Test > Components: Felix Commons >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: liuxin > Labels: maven > Fix For: maven-bundle-plugin-2.3.7 > > Attachments: maven.log > > > import: Entry[import from realm > ClassRealm[project>com.spdb:com.spdb.bpp.binding.sop:1.0.0.20110630, parent: > ClassRealm[maven.api, parent: null]]] > - > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-install of goal org.apache.felix:maven-bundle-plugin:2.3.7:install > failed: A required class was missing while executing > org.apache.felix:maven-bundle-plugin:2.3.7:install: > org/osgi/framework/InvalidSyntaxException > - > realm =plugin>org.apache.felix:maven-bundle-plugin:2.3.7 > strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > urls[0] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/felix/maven-bundle-plugin/2.3.7/maven-bundle-plugin-2.3.7.jar > urls[1] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/biz/aQute/bndlib/1.50.0/bndlib-1.50.0.jar > urls[2] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/felix/org.apache.felix.bundlerepository/1.6.6/org.apache.felix.bundlerepository-1.6.6.jar > urls[3] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.7/maven-reporting-api-2.0.7.jar > urls[4] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar > urls[5] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > urls[6] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/commons-cli/commons-cli/1.0/commons-cli-1.0.jar > urls[7] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar > urls[8] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/maven/maven-archiver/2.4.1/maven-archiver-2.4.1.jar > urls[9] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0/plexus-archiver-1.0.jar > urls[10] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-io/1.0/plexus-io-1.0.jar > urls[11] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar > urls[12] = > file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/maven/shared/maven-dependency-tree/1.2/maven-dependency-tree-1.2.jar > urls[13] = > file:/C:/Document
[jira] [Created] (FELIX-3470) execute mvn install
execute mvn install --- Key: FELIX-3470 URL: https://issues.apache.org/jira/browse/FELIX-3470 Project: Felix Issue Type: Test Components: Felix Commons Affects Versions: maven-bundle-plugin-2.3.7 Reporter: liuxin Fix For: maven-bundle-plugin-2.3.7 import: Entry[import from realm ClassRealm[project>com.spdb:com.spdb.bpp.binding.sop:1.0.0.20110630, parent: ClassRealm[maven.api, parent: null]]] - at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-install of goal org.apache.felix:maven-bundle-plugin:2.3.7:install failed: A required class was missing while executing org.apache.felix:maven-bundle-plugin:2.3.7:install: org/osgi/framework/InvalidSyntaxException - realm =plugin>org.apache.felix:maven-bundle-plugin:2.3.7 strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy urls[0] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/felix/maven-bundle-plugin/2.3.7/maven-bundle-plugin-2.3.7.jar urls[1] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/biz/aQute/bndlib/1.50.0/bndlib-1.50.0.jar urls[2] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/felix/org.apache.felix.bundlerepository/1.6.6/org.apache.felix.bundlerepository-1.6.6.jar urls[3] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.7/maven-reporting-api-2.0.7.jar urls[4] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar urls[5] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar urls[6] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/commons-cli/commons-cli/1.0/commons-cli-1.0.jar urls[7] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar urls[8] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/maven/maven-archiver/2.4.1/maven-archiver-2.4.1.jar urls[9] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0/plexus-archiver-1.0.jar urls[10] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-io/1.0/plexus-io-1.0.jar urls[11] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar urls[12] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/apache/maven/shared/maven-dependency-tree/1.2/maven-dependency-tree-1.2.jar urls[13] = file:/C:/Documents%20and%20Settings/liux/.m2/repository/org/codehaus/plexus/plexus-utils/2.1/plexus-utils-2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[project>com.spdb:com.spdb.bpp.binding.sop:1.0.0.20110630, parent: ClassRealm[maven.api, parent: null]]] - at org.apache.maven.plugin.DefaultBuildPluginManager.exe
[jira] [Resolved] (FELIX-3469) Type mismatch JS error using the memoryusage plugin
[ https://issues.apache.org/jira/browse/FELIX-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-3469. -- Resolution: Fixed Fixed in Rev. 1327875 > Type mismatch JS error using the memoryusage plugin > --- > > Key: FELIX-3469 > URL: https://issues.apache.org/jira/browse/FELIX-3469 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-3.1.2 > Environment: Microsoft IE 8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-3.4.0 > > > When showing the Memory Usage page, IE8 reports a type mismatch error in the > support.js script. > For example when clicking the Heap Dump button: >Result: Type mismatch error in > http://localhost:4502/system/console/res/lib/support.js (line: 257, char: 4) >Expected: no error, GC and heap dump to execute > Also the detail information is not properly listed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3469) Type mismatch JS error using the memoryusage plugin
[
https://issues.apache.org/jira/browse/FELIX-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257381#comment-13257381
]
Felix Meschberger commented on FELIX-3469:
--
Apparently the problem occurs in this code at the end of the createElement
function:
for (var i=0; i < children.length; i++) {
element.appendChild( children[i] );
}
Looks like the children.length method reports a wrong size and thus at the end
an non-existing child should be added. The fix is to simply guard against
non-existing array entry.
> Type mismatch JS error using the memoryusage plugin
> ---
>
> Key: FELIX-3469
> URL: https://issues.apache.org/jira/browse/FELIX-3469
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-3.1.2
> Environment: Microsoft IE 8
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: webconsole-3.4.0
>
>
> When showing the Memory Usage page, IE8 reports a type mismatch error in the
> support.js script.
> For example when clicking the Heap Dump button:
>Result: Type mismatch error in
> http://localhost:4502/system/console/res/lib/support.js (line: 257, char: 4)
>Expected: no error, GC and heap dump to execute
> Also the detail information is not properly listed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3469) Type mismatch JS error using the memoryusage plugin
Type mismatch JS error using the memoryusage plugin --- Key: FELIX-3469 URL: https://issues.apache.org/jira/browse/FELIX-3469 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.2 Environment: Microsoft IE 8 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: webconsole-3.4.0 When showing the Memory Usage page, IE8 reports a type mismatch error in the support.js script. For example when clicking the Heap Dump button: Result: Type mismatch error in http://localhost:4502/system/console/res/lib/support.js (line: 257, char: 4) Expected: no error, GC and heap dump to execute Also the detail information is not properly listed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated FELIX-3456: Attachment: FELIX-3456-4.diff This uses the same idea as the previous patch but fully synchronizes the enable and disable methods and the service factory getService and ungetService methods. > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.diff, FELIX-3456-3.diff, FELIX-3456-4.diff > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a component was still activating if > another instance of the same service was registered on a different thread. > There are other fixes that could be done by synchronizing more around service > additions. > Is anyone willing to make this fix or does anyone have any thoughts about > this issue? > Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
