[jira] [Commented] (FELIX-3337) DependencyManager/Updated configuration dependency does not propagate to provided service properties
[
https://issues.apache.org/jira/browse/FELIX-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199773#comment-13199773
]
Pierre De Rop commented on FELIX-3337:
--
I committed a new test which seems to reproduce the issue:
src/test/java/org/apache/felix/dm/test/FELIX3337_UpdatedConfigurationDependencyWithPropagationTest.java
> DependencyManager/Updated configuration dependency does not propagate to
> provided service properties
>
>
> Key: FELIX-3337
> URL: https://issues.apache.org/jira/browse/FELIX-3337
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Priority: Minor
>
> This issue is related to the following post:
> http://www.mail-archive.com/users@felix.apache.org/msg11711.html
> The problem is the following; it seems that when a service S1 depends on a
> ConfigurationDependency with propagate = true, then the configuration is
> propagated to the service properties provided by S1, but when the
> configuration is changed (by ConfigAdmin), then the S1 service properties are
> not updated.
> For example, here is the service S1 which depends on a Configuratin pid
> "test":
> Component s1 = m.createComponent()
> .setImplementation(new S1()))
> .setInterface(S1.class.getName(), null)
> .add(m.createConfigurationDependency()
> .setPid("test")
> .setPropagate(true));
> We assume that the configuration pid "test" contains "testkey=testvalue"
> Now, we have S2, which depends on S1 like this:
> Component s2 = m.createComponent()
> .setImplementation(new S2())
> .add(m.createServiceDependency()
> .setService(S1.class, ("(testkey=testvalue)"))
> .setRequired(true)
> .setCallbacks("add", "change", null));
> So, at initialization, S2 is properly injected with S1 (in its "add" method).
> But when the configuration is updated, S2 is not called back in its "change"
> method (I think that it should be, because the ConfigurationDependency
> declared in S1 is using propagate=true flag.
> I will manage to commit a testcase which reproduce this issue.
> /pierre
--
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] [Issue Comment Edited] (FELIX-3336) Exceptions related to the pipe used in deployment admin
[ https://issues.apache.org/jira/browse/FELIX-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199767#comment-13199767 ] J.W. Janssen edited comment on FELIX-3336 at 2/3/12 3:26 PM: - After some debugging, it appears that a ZipInputStream does *not* read all bytes from the underlying input stream, but stops after the last ZIP-entry (after this the central directory of the ZIP file is stored, which is not used by the implementation). Hence, the ExplodingOutputtingInputStream thinks it has read all underlying bytes, but in fact this is not the case. So, it terminates, while the other end still is processing the last couple of bytes (= central directory of ZIP-file). This explains why the above error occurs. A solution would be to read the last couple of bytes in the input stream after the ZipInputStream is finished... PS: one of the reasons why this might spuriously occur in real life is that the buffer size of PipedInputStream is large enough to read those last couple of bytes of the ZIP file... was (Author: jajans): After some debugging, it appears that a ZipInputStream does *not* read all bytes from the underlying input stream, but stops after the last ZIP-entry (after this the central directory of the ZIP file is stored, which is not used by the implementation). Hence, the ExplodingOutputtingInputStream thinks it has read all underlying bytes, but in fact this is not the case. So, it terminates, while the other end still is processing the last couple of bytes (= central directory of ZIP-file). This explains why the above error occurs. A solution would be to read the last couple of bytes in the input stream after the ZipInputStream is finished... > Exceptions related to the pipe used in deployment admin > --- > > Key: FELIX-3336 > URL: https://issues.apache.org/jira/browse/FELIX-3336 > Project: Felix > Issue Type: Bug > Components: Deployment Admin >Reporter: Marcel Offermans > > Sporadically getting "Pipe closed" exceptions. Not reproducible yet, but > seemingly related to a line containing "input.close()" in the > ExplodingOutputtingInputStream. Needs investigation. -- 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-3337) DependencyManager/Updated configuration dependency does not propagate to provided service properties
DependencyManager/Updated configuration dependency does not propagate to
provided service properties
Key: FELIX-3337
URL: https://issues.apache.org/jira/browse/FELIX-3337
Project: Felix
Issue Type: Bug
Components: Dependency Manager
Affects Versions: dependencymanager-3.0.0
Reporter: Pierre De Rop
Priority: Minor
This issue is related to the following post:
http://www.mail-archive.com/users@felix.apache.org/msg11711.html
The problem is the following; it seems that when a service S1 depends on a
ConfigurationDependency with propagate = true, then the configuration is
propagated to the service properties provided by S1, but when the configuration
is changed (by ConfigAdmin), then the S1 service properties are not updated.
For example, here is the service S1 which depends on a Configuratin pid "test":
Component s1 = m.createComponent()
.setImplementation(new S1()))
.setInterface(S1.class.getName(), null)
.add(m.createConfigurationDependency()
.setPid("test")
.setPropagate(true));
We assume that the configuration pid "test" contains "testkey=testvalue"
Now, we have S2, which depends on S1 like this:
Component s2 = m.createComponent()
.setImplementation(new S2())
.add(m.createServiceDependency()
.setService(S1.class, ("(testkey=testvalue)"))
.setRequired(true)
.setCallbacks("add", "change", null));
So, at initialization, S2 is properly injected with S1 (in its "add" method).
But when the configuration is updated, S2 is not called back in its "change"
method (I think that it should be, because the ConfigurationDependency
declared in S1 is using propagate=true flag.
I will manage to commit a testcase which reproduce this issue.
/pierre
--
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-3336) Exceptions related to the pipe used in deployment admin
[ https://issues.apache.org/jira/browse/FELIX-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199767#comment-13199767 ] J.W. Janssen commented on FELIX-3336: - After some debugging, it appears that a ZipInputStream does *not* read all bytes from the underlying input stream, but stops after the last ZIP-entry (after this the central directory of the ZIP file is stored, which is not used by the implementation). Hence, the ExplodingOutputtingInputStream thinks it has read all underlying bytes, but in fact this is not the case. So, it terminates, while the other end still is processing the last couple of bytes (= central directory of ZIP-file). This explains why the above error occurs. A solution would be to read the last couple of bytes in the input stream after the ZipInputStream is finished... > Exceptions related to the pipe used in deployment admin > --- > > Key: FELIX-3336 > URL: https://issues.apache.org/jira/browse/FELIX-3336 > Project: Felix > Issue Type: Bug > Components: Deployment Admin >Reporter: Marcel Offermans > > Sporadically getting "Pipe closed" exceptions. Not reproducible yet, but > seemingly related to a line containing "input.close()" in the > ExplodingOutputtingInputStream. Needs investigation. -- 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: [RESULT][VOTE] Release Service Diagnostics Plugin version 0.1.1
Thanks for looking into this Stuart. Indeed the release.xml is now updated. My local maven repository contains quite a few versions of the maven-bundle-plugin (from 1.4.0 to 2.3.6) and of bundlerepository (from 1.0.3 to 1.6.6) including some snapshots for each.. My parent pom points to maven-bundle-plugin version 2.3.5 which in turn points to bundlerepository version 1.6.6.. but you're right, it doesn't match the code so I'm not sure what version is used. So now I just need the write permissions for confluence and I think I'll be through with my first release :) thanks, arjun On 02/03/2012 03:06 PM, Stuart McCulloch wrote: On 3 Feb 2012, at 09:44, Arjun Panday wrote: Two more things: I didn't have account on confluence so I simply signed up, but that doesn't give write permissions to update the news and download sections. Can someone please unlock this for me? (Marcel?) Also there seem to be an issue with the OBR update. The maven command exited with "Build success" just after dumping a NullPointerException, so I checked the file people.apache.org:/www/felix.apache.org/obr/releases.xml and it doesn't seem to contain any reference to my plugin and it is still dated Jul 10 2011. I tried the same command locally after checking out the https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.servicediagnostics.plugin-0.1.1 tag and didn't see the NPE The other odd thing is that the line DataModelHelperImpl.java:875 doesn't appear to match any public release of the bundlerepository For info: [WARNING] Exception while updating remote OBR: null java.lang.NullPointerException at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.getSymbolicName(DataModelHelperImpl.java:875) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.populate(DataModelHelperImpl.java:521) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.createResource(DataModelHelperImpl.java:515) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.createResource(DataModelHelperImpl.java:406) at org.apache.felix.obrplugin.ObrUpdate.updateRepository(ObrUpdate.java:170) at org.apache.felix.obrplugin.ObrDeploy.updateRemoteBundleMetadata(ObrDeploy.java:352) at org.apache.felix.obrplugin.ObrDeploy.execute(ObrDeploy.java:254) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 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) [INFO] UNLOCK scp://people.apache.org/www/felix.apache.org/obr/releases.xml [INFO] [INFO] BUILD SUCCESS [INFO] thanks, Arjun On 02/03/2012 09:48 AM, Arjun Panday wrote: Hi, I'm not sure if I've done something stupid now! The doc reads: "login to https://repository.apache.org with your Apache SVN credentials. Click on Staging. Find your closed staging repository, right click on it and choose Promote. Select the Releases repository from the drop-down list and click Promote." But the Promote button was not available on my closed staging repo; only the release button was... so I tried that one :) "next click on Repositories, select the Releases repository and validate that your artifacts are all there" Yes, they are.. What about the p
Re: [RESULT][VOTE] Release Service Diagnostics Plugin version 0.1.1
On 3 Feb 2012, at 09:44, Arjun Panday wrote: > Two more things: > > I didn't have account on confluence so I simply signed up, but that doesn't > give write permissions to update the news and download sections. Can someone > please unlock this for me? (Marcel?) > > Also there seem to be an issue with the OBR update. The maven command exited > with "Build success" just after dumping a NullPointerException, so I checked > the file people.apache.org:/www/felix.apache.org/obr/releases.xml and it > doesn't seem to contain any reference to my plugin and it is still dated Jul > 10 2011. I tried the same command locally after checking out the https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.servicediagnostics.plugin-0.1.1 tag and didn't see the NPE The other odd thing is that the line DataModelHelperImpl.java:875 doesn't appear to match any public release of the bundlerepository > For info: > [WARNING] Exception while updating remote OBR: null > java.lang.NullPointerException >at > org.apache.felix.bundlerepository.impl.DataModelHelperImpl.getSymbolicName(DataModelHelperImpl.java:875) >at > org.apache.felix.bundlerepository.impl.DataModelHelperImpl.populate(DataModelHelperImpl.java:521) >at > org.apache.felix.bundlerepository.impl.DataModelHelperImpl.createResource(DataModelHelperImpl.java:515) >at > org.apache.felix.bundlerepository.impl.DataModelHelperImpl.createResource(DataModelHelperImpl.java:406) >at > org.apache.felix.obrplugin.ObrUpdate.updateRepository(ObrUpdate.java:170) >at > org.apache.felix.obrplugin.ObrDeploy.updateRemoteBundleMetadata(ObrDeploy.java:352) >at org.apache.felix.obrplugin.ObrDeploy.execute(ObrDeploy.java:254) >at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) >at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) >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) > [INFO] UNLOCK scp://people.apache.org/www/felix.apache.org/obr/releases.xml > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > > > thanks, > Arjun > > > > On 02/03/2012 09:48 AM, Arjun Panday wrote: >> Hi, >> >> I'm not sure if I've done something stupid now! >> >> The doc reads: >> "login to https://repository.apache.org with your Apache SVN >> credentials. Click on Staging. Find your closed staging repository, >> right click on it and choose Promote. Select the Releases repository >> from the drop-down list and click Promote." >> >> But the Promote button was not available on my closed staging repo; only >> the release button was... so I tried that one :) >> >> "next click on Repositories, select the Releases repository and validate >> that your artifacts are all there" >> >> Yes, they are.. >> What about the promote button? >> Did I miss something here? >> >> thanks, >> Arjun >> >> >> On 02/01/2012 02:17 PM, Arjun Panday wrote: >>> Hi, >>> >>> I'm closing the vote. >>> >>> The vote has passed with: >>> +1 (binding) from Carsten Ziegeler, Stuart McCulloch and Richard Hall >>> +1 (non binding) from Pierre De Rop and Ken Gilmer >>> >>> I'll proceed to promote the release. >>> >>> Thanks a lot everyone. >>> >>> Arjun >>> >>> >>> >>> On 02/01/2012 11:42 AM, Stuar
Re: [RESULT][VOTE] Release Service Diagnostics Plugin version 0.1.1
On 3 Feb 2012, at 08:48, Arjun Panday wrote: > Hi, > > I'm not sure if I've done something stupid now! > > The doc reads: > "login to https://repository.apache.org with your Apache SVN credentials. > Click on Staging. Find your closed staging repository, right click on it and > choose Promote. Select the Releases repository from the drop-down list and > click Promote." > > But the Promote button was not available on my closed staging repo; only the > release button was... so I tried that one :) > > "next click on Repositories, select the Releases repository and validate that > your artifacts are all there" > > Yes, they are.. > What about the promote button? > Did I miss something here? No, the UI changed and I forgot to update the docs - the release button is the one to use. I'll update the wiki. > thanks, > Arjun > > > On 02/01/2012 02:17 PM, Arjun Panday wrote: >> Hi, >> >> I'm closing the vote. >> >> The vote has passed with: >> +1 (binding) from Carsten Ziegeler, Stuart McCulloch and Richard Hall >> +1 (non binding) from Pierre De Rop and Ken Gilmer >> >> I'll proceed to promote the release. >> >> Thanks a lot everyone. >> >> Arjun >> >> >> >> On 02/01/2012 11:42 AM, Stuart McCulloch wrote: >>> On 1 Feb 2012, at 10:24, Arjun Panday >>> wrote: >>> On 01/31/2012 11:26 PM, Stuart McCulloch wrote: > On 31 Jan 2012, at 22:06, Richard S. Hall wrote: > >> +1 >> >> The NOTICE file is a little messed up in the plugin, it seems to repeat >> itself. The copyright year should be updated to 2012 in both NOTICE and >> DEPENDENCIES. >> >> ->richard >> >> p.s. That's a really big bundle...8.5MB... :-) > To be fair ~8mb of that is the Scala runtime... maybe that should be > separated into its own bundle in case others want to re-use it? Exactly, plus a bit of javascript libraries.. the plugin itself is quite small. Unfortunately the scala runtime doesn't come readily packaged as an OSGi bundle. The original project didn't embed the scala runtime; it came with a readme file to explain how to wrap the scala library using bnd. But for the release, in order to have something readily useable, I decided to embed the scala library. It's a packaging issue. I wouldn't mind creating a new module just for the scala library, outside the service diagnostics sub-project, so that other sub-projects can use scala. I think I'll go ahead with this release for now and maybe I can issue a new JIRA for the scala library packaging? >>> Sounds good to me, definitely go ahead with this release - it was just a >>> thought for future development. >>> thanks, -arjun >> On 1/20/12 03:59 , Arjun Panday wrote: >>> Hi everyone, >>> >>> Second attempt at releasing the Service Diagnostics WebConsole Plugin. >>> I've simply refactored the POMs by moving the parent role out of the >>> reactor POM. The directory structure seems cleaner. Let me know. >>> >>> Here's the staging repository: >>> https://repository.apache.org/content/repositories/orgapachefelix-110/ >>> >>> >>> 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 010 /tmp/felix-staging >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Veto the release (please provide specific comments) >>> >>> This vote will be open for 72 hours. >>> >>> Thanks, >>> -arjun >>> >>> >>> >>> >>> >
[jira] [Commented] (FELIX-3336) Exceptions related to the pipe used in deployment admin
[
https://issues.apache.org/jira/browse/FELIX-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199665#comment-13199665
]
Marcel Offermans commented on FELIX-3336:
-
A solution has been committed, but I'm not quite sure why it works. If you do a
checkout, and run "mvn clean install" the test succeeds. If you apply this
patch:
{code}
Index:
src/main/java/org/apache/felix/deploymentadmin/ExplodingOutputtingInputStream.java
===
---
src/main/java/org/apache/felix/deploymentadmin/ExplodingOutputtingInputStream.java
(revision 1240137)
+++
src/main/java/org/apache/felix/deploymentadmin/ExplodingOutputtingInputStream.java
(working copy)
@@ -73,7 +73,7 @@
super(inputStream, output);
m_contentDir = root;
m_indexFile = index;
-m_input = new PipedInputStream(output /*, 8 FELIX-3336: if you provide
such a small buffer, the error is reproducible (see below) */);
+m_input = new PipedInputStream(output , 8 /* FELIX-3336: if you
provide such a small buffer, the error is reproducible (see below) */);
m_task = new Thread(this, "Apache Felix DeploymentAdmin -
ExplodingOutputtingInputStream");
m_task.start();
}
@@ -129,16 +129,16 @@
}
}
// FELIX-3336: if you include this code, the issue is gone
-try {
-byte[] bb = new byte[512];
-int c = m_input.read(bb);
-while (c != -1) {
-c = m_input.read(bb);
-}
-}
-catch (IOException e) {
-e.printStackTrace();
-}
+//try {
+//byte[] bb = new byte[512];
+//int c = m_input.read(bb);
+//while (c != -1) {
+//c = m_input.read(bb);
+//}
+//}
+//catch (IOException e) {
+//e.printStackTrace();
+//}
}
{code}
And then run the test again, you get:
{code}
$ cat
target/surefire-reports/org.apache.felix.deploymentadmin.ExplodingOutputtingInputStreamTest.txt
---
Test set: org.apache.felix.deploymentadmin.ExplodingOutputtingInputStreamTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.071 sec <<<
FAILURE!
testStream(org.apache.felix.deploymentadmin.ExplodingOutputtingInputStreamTest)
Time elapsed: 1.057 sec <<< ERROR!
java.io.IOException: Read end dead
at
java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:246)
at java.io.PipedInputStream.awaitSpace(PipedInputStream.java:252)
at java.io.PipedInputStream.receive(PipedInputStream.java:215)
at java.io.PipedOutputStream.write(PipedOutputStream.java:132)
at
org.apache.felix.deploymentadmin.OutputtingInputStream.read(OutputtingInputStream.java:58)
at
org.apache.felix.deploymentadmin.ExplodingOutputtingInputStreamTest.testStream(ExplodingOutputtingInputStreamTest.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[...]
{code}
For some weird reason the read blocks and finally generates an exception
because the pipe has been closed. I have no clue why the read blocks though,
and why reading extra bytes from an underlying stream (m_input) that should
have already been read completely (this ZipInputStream reads everything it
should) unblocks the read. Admittedly, this is not the easiest piece of code to
read, but I can't find a fundamental flaw in the approach. Maybe someone else
can. :)
> Exceptions related to the pipe used in deployment admin
> ---
>
> Key: FELIX-3336
> URL: https://issues.apache.org/jira/browse/FELIX-3336
> Project: Felix
> Issue Type: Bug
> Components: Deployment Admin
>Reporter: Marcel Offermans
>
> Sporadically getting "Pipe closed" exceptions. Not reproducible yet, but
> seemingly related to a line containing "input.close()" in the
> ExplodingOutputtingInputStream. Needs investigation.
--
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: [RESULT][VOTE] Release Service Diagnostics Plugin version 0.1.1
Two more things: I didn't have account on confluence so I simply signed up, but that doesn't give write permissions to update the news and download sections. Can someone please unlock this for me? (Marcel?) Also there seem to be an issue with the OBR update. The maven command exited with "Build success" just after dumping a NullPointerException, so I checked the file people.apache.org:/www/felix.apache.org/obr/releases.xml and it doesn't seem to contain any reference to my plugin and it is still dated Jul 10 2011. For info: [WARNING] Exception while updating remote OBR: null java.lang.NullPointerException at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.getSymbolicName(DataModelHelperImpl.java:875) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.populate(DataModelHelperImpl.java:521) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.createResource(DataModelHelperImpl.java:515) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.createResource(DataModelHelperImpl.java:406) at org.apache.felix.obrplugin.ObrUpdate.updateRepository(ObrUpdate.java:170) at org.apache.felix.obrplugin.ObrDeploy.updateRemoteBundleMetadata(ObrDeploy.java:352) at org.apache.felix.obrplugin.ObrDeploy.execute(ObrDeploy.java:254) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 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) [INFO] UNLOCK scp://people.apache.org/www/felix.apache.org/obr/releases.xml [INFO] [INFO] BUILD SUCCESS [INFO] thanks, Arjun On 02/03/2012 09:48 AM, Arjun Panday wrote: Hi, I'm not sure if I've done something stupid now! The doc reads: "login to https://repository.apache.org with your Apache SVN credentials. Click on Staging. Find your closed staging repository, right click on it and choose Promote. Select the Releases repository from the drop-down list and click Promote." But the Promote button was not available on my closed staging repo; only the release button was... so I tried that one :) "next click on Repositories, select the Releases repository and validate that your artifacts are all there" Yes, they are.. What about the promote button? Did I miss something here? thanks, Arjun On 02/01/2012 02:17 PM, Arjun Panday wrote: Hi, I'm closing the vote. The vote has passed with: +1 (binding) from Carsten Ziegeler, Stuart McCulloch and Richard Hall +1 (non binding) from Pierre De Rop and Ken Gilmer I'll proceed to promote the release. Thanks a lot everyone. Arjun On 02/01/2012 11:42 AM, Stuart McCulloch wrote: On 1 Feb 2012, at 10:24, Arjun Pandaywrote: On 01/31/2012 11:26 PM, Stuart McCulloch wrote: On 31 Jan 2012, at 22:06, Richard S. Hall wrote: +1 The NOTICE file is a little messed up in the plugin, it seems to repeat itself. The copyright year should be updated to 2012 in both NOTICE and DEPENDENCIES. -> richard p.s. That's a really big bundle...8.5MB... :-) To be fair ~8mb of that is the Scala runtime... maybe that should be separated into its own bundle in case others want to re-use it? Exactly, plus a bit of javascript libraries.. the plugin itself is quite small. Unfor
[jira] [Created] (FELIX-3336) Exceptions related to the pipe used in deployment admin
Exceptions related to the pipe used in deployment admin --- Key: FELIX-3336 URL: https://issues.apache.org/jira/browse/FELIX-3336 Project: Felix Issue Type: Bug Components: Deployment Admin Reporter: Marcel Offermans Sporadically getting "Pipe closed" exceptions. Not reproducible yet, but seemingly related to a line containing "input.close()" in the ExplodingOutputtingInputStream. Needs investigation. -- 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: [RESULT][VOTE] Release Service Diagnostics Plugin version 0.1.1
Hi, I'm not sure if I've done something stupid now! The doc reads: "login to https://repository.apache.org with your Apache SVN credentials. Click on Staging. Find your closed staging repository, right click on it and choose Promote. Select the Releases repository from the drop-down list and click Promote." But the Promote button was not available on my closed staging repo; only the release button was... so I tried that one :) "next click on Repositories, select the Releases repository and validate that your artifacts are all there" Yes, they are.. What about the promote button? Did I miss something here? thanks, Arjun On 02/01/2012 02:17 PM, Arjun Panday wrote: Hi, I'm closing the vote. The vote has passed with: +1 (binding) from Carsten Ziegeler, Stuart McCulloch and Richard Hall +1 (non binding) from Pierre De Rop and Ken Gilmer I'll proceed to promote the release. Thanks a lot everyone. Arjun On 02/01/2012 11:42 AM, Stuart McCulloch wrote: On 1 Feb 2012, at 10:24, Arjun Panday wrote: On 01/31/2012 11:26 PM, Stuart McCulloch wrote: On 31 Jan 2012, at 22:06, Richard S. Hall wrote: +1 The NOTICE file is a little messed up in the plugin, it seems to repeat itself. The copyright year should be updated to 2012 in both NOTICE and DEPENDENCIES. ->richard p.s. That's a really big bundle...8.5MB... :-) To be fair ~8mb of that is the Scala runtime... maybe that should be separated into its own bundle in case others want to re-use it? Exactly, plus a bit of javascript libraries.. the plugin itself is quite small. Unfortunately the scala runtime doesn't come readily packaged as an OSGi bundle. The original project didn't embed the scala runtime; it came with a readme file to explain how to wrap the scala library using bnd. But for the release, in order to have something readily useable, I decided to embed the scala library. It's a packaging issue. I wouldn't mind creating a new module just for the scala library, outside the service diagnostics sub-project, so that other sub-projects can use scala. I think I'll go ahead with this release for now and maybe I can issue a new JIRA for the scala library packaging? Sounds good to me, definitely go ahead with this release - it was just a thought for future development. thanks, -arjun On 1/20/12 03:59 , Arjun Panday wrote: Hi everyone, Second attempt at releasing the Service Diagnostics WebConsole Plugin. I've simply refactored the POMs by moving the parent role out of the reactor POM. The directory structure seems cleaner. Let me know. Here's the staging repository: https://repository.apache.org/content/repositories/orgapachefelix-110/ 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 010 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Thanks, -arjun
