[jira] [Commented] (FELIX-3773) WebConsole uses library with ASL-incompatible licence
[ https://issues.apache.org/jira/browse/FELIX-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502290#comment-13502290 ] Gert Vanthienen commented on FELIX-3773: According to http://www.apache.org/legal/resolved.html#json, it looks like the use of this library has been approved by the legal@ team WebConsole uses library with ASL-incompatible licence - Key: FELIX-3773 URL: https://issues.apache.org/jira/browse/FELIX-3773 Project: Felix Issue Type: Bug Components: Web Console Reporter: Neil Bartlett Priority: Critical WebConsole uses the JSON library from json.org that contains the following term in its licence (http://www.json.org/license.html): The Software shall be used for Good, not Evil. I believe that this restriction is incompatible with the ASL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3752) Compilation failure in utils subproject on AIX
Gert Vanthienen created FELIX-3752: -- Summary: Compilation failure in utils subproject on AIX Key: FELIX-3752 URL: https://issues.apache.org/jira/browse/FELIX-3752 Project: Felix Issue Type: Bug Components: Utils Affects Versions: utils-1.2.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Minor Fix For: utils-1.2.2 When building the Felix Utils subproject on AIX, you bump into this compilation failure due to an unused com.sun import in PropertiesTest [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile (default-testCompile) on project org.apache.felix.utils: Compilation failure [ERROR] /home/hudson/workspace/felix-utils-7.1.x.fuse-stable-platform/jdk/jdk6/label/aix5/utils/src/test/java/org/apache/felix/utils/properties/PropertiesTest.java:[26,49] package com.sun.org.apache.xerces.internal.impl.dv does not exist [ERROR] - [Help 1] [ERROR] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3752) Compilation failure in utils subproject on AIX
[ https://issues.apache.org/jira/browse/FELIX-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-3752. Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1408700 Compilation failure in utils subproject on AIX -- Key: FELIX-3752 URL: https://issues.apache.org/jira/browse/FELIX-3752 Project: Felix Issue Type: Bug Components: Utils Affects Versions: utils-1.2.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Minor Fix For: utils-1.2.2 When building the Felix Utils subproject on AIX, you bump into this compilation failure due to an unused com.sun import in PropertiesTest [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile (default-testCompile) on project org.apache.felix.utils: Compilation failure [ERROR] /home/hudson/workspace/felix-utils-7.1.x.fuse-stable-platform/jdk/jdk6/label/aix5/utils/src/test/java/org/apache/felix/utils/properties/PropertiesTest.java:[26,49] package com.sun.org.apache.xerces.internal.impl.dv does not exist [ERROR] - [Help 1] [ERROR] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3006) Please create a logout button for the web console screen
[ https://issues.apache.org/jira/browse/FELIX-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102516#comment-13102516 ] Gert Vanthienen commented on FELIX-3006: The LogoutServlet plugin was added to avoid having to code addtional bits and pieces into the main OsgiManager class if we can have the logout code/ui/... done in a similar way as the other stuff. As Felix already pointed out, there's no use of sessions or cookies, so I just focused on getting the UI done and sending back the HTTP 401 authentication challenge so people have to provide their credentials again before they can continue working. That's the closest thing to 'logging out' that I could imagine, but I'm open to suggestions. Feel free to send along any suggestions/recommendations for improvement and I'll gladly alter the patch... Please create a logout button for the web console screen Key: FELIX-3006 URL: https://issues.apache.org/jira/browse/FELIX-3006 Project: Felix Issue Type: Improvement Components: Web Console Reporter: Susan Javurek Attachments: FELIX-3006.diff Please add a log out button on the web console to avoid sessions and cookies being retained. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3006) Please create a logout button for the web console screen
[ https://issues.apache.org/jira/browse/FELIX-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated FELIX-3006: --- Attachment: FELIX-3006.diff Attaching a first stab at a fix... Please create a logout button for the web console screen Key: FELIX-3006 URL: https://issues.apache.org/jira/browse/FELIX-3006 Project: Felix Issue Type: Improvement Components: Web Console Reporter: Susan Javurek Attachments: FELIX-3006.diff Please add a log out button on the web console to avoid sessions and cookies being retained. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Karaf 1.6.2 (5th try)
Cancelling the vote -- as Guillaume has pointed out, we should fix the JDK 1.5 issue first Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 26 June 2010 15:42, Guillaume Nodet gno...@gmail.com wrote: I'm changing my vote to -1 due to the problems Jamie found on JDK 1.5 I don't think we ship ship if it can't be used on 1.5 On Sun, Jun 20, 2010 at 10:26, Guillaume Nodet gno...@gmail.com wrote: +1 On Sat, Jun 19, 2010 at 23:41, Gert Vanthienen gert.vanthie...@gmail.com wrote: L.S., I would like to call a new vote on karaf 1.6.2. The only change since the 3th attempt is the fix for https://issues.apache.org/jira/browse/FELIX-2419 that showed up during the release vote at that time. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-005/ 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 005 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 There's a problem (please provide specific comments) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release Karaf 1.6.2 (4th try)
L.S., It looks like something went wrong with this release, so I've recut the release off the same codebase -- starting a new vote thread asap Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 19 June 2010 07:31, Gert Vanthienen gert.vanthie...@gmail.com wrote: L.S., The fix for that issue doesn't appear to be included in the release, but there's something odd about the release tag as well: - http://svn.apache.org/repos/asf/felix/releases/karaf-1.6.2/ looks like the previous release tag - http://svn.apache.org/repos/asf/felix/releases/karaf-1.6.2/karaf seems to be the new tag (notice the extra karaf folder at the end) I guess the maven-release-plugin picked up the first tag directory instead of the second -- the artifact I downloaded from the repository is still having the same problem. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 19 June 2010 00:05, Chris Custine chris.cust...@gmail.com wrote: Sorry, I pasted the wrong issue. The missing fix is: https://issues.apache.org/jira/browse/FELIX-2419 https://issues.apache.org/jira/browse/FELIX-2419Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Fri, Jun 18, 2010 at 15:19, Chris Custine chris.cust...@gmail.comwrote: Artifacts look good, but I'm not sure the fix for https://issues.apache.org/jira/browse/FELIX-2361 made it in to this build. I still get the error and the stack trace points to the old code location. The tag in svn shows the right version but the source in the staging repo has the old code. Not sure what could be happening. Anyone else seeing this or am I getting a stale copy from an http cache somewhere? Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Fri, Jun 18, 2010 at 07:17, Guillaume Nodet gno...@gmail.com wrote: I would like to call a new vote on karaf 1.6.2. The only change since the 3thd attempt is the fix for the bug Gert found in the features service. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-004/ 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 004 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 There's a problem (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (FELIX-2419) UnsupportedOperationException while installing features
UnsupportedOperationException while installing features
---
Key: FELIX-2419
URL: https://issues.apache.org/jira/browse/FELIX-2419
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.6.2
Reporter: Gert Vanthienen
Fix For: karaf 1.8.0
I was trying to install a few features on the Karaf 1.6.2 release candidate
build and encountered UnsupportedOperationException
Here are the commands I used
{noformat}
features:addUrl mvn:org.apache.camel.karaf/apache-camel/2.2.0/xml/features
features:install camel-scala
features:install camel
{noformat}
This is the resulting exception's stack trace
{noformat}
10:46:07,342 | INFO | l Console Thread | Console |
araf.shell.console.jline.Console 198 | Exception caught while executing command
java.lang.UnsupportedOperationException
at java.util.AbstractList.remove(AbstractList.java:144)[:1.6.0_20]
at java.util.AbstractList$Itr.remove(AbstractList.java:360)[:1.6.0_20]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.findBundlesWithOptionalPackagesToRefresh(FeaturesServiceImpl.java:445)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.findBundlesToRefresh(FeaturesServiceImpl.java:389)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:252)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:222)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:218)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[27:org.apache.felix.karaf.features.command:1.6.2]
at
org.apache.felix.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[27:org.apache.felix.karaf.features.command:1.6.2]
at
org.apache.felix.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:41)[22:org.apache.felix.karaf.shell.console:1.6.2]
at
org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[22:org.apache.felix.karaf.shell.console:1.6.2]
at
org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.karaf.shell.console.jline.Console.run(Console.java:180)[22:org.apache.felix.karaf.shell.console:1.6.2]
at java.lang.Thread.run(Thread.java:637)[:1.6.0_20]
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2419) UnsupportedOperationException while installing features
[
https://issues.apache.org/jira/browse/FELIX-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen updated FELIX-2419:
---
Attachment: FELIX-2419.diff
UnsupportedOperationException while installing features
---
Key: FELIX-2419
URL: https://issues.apache.org/jira/browse/FELIX-2419
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.6.2
Reporter: Gert Vanthienen
Assignee: Guillaume Nodet
Fix For: karaf-1.6.2
Attachments: FELIX-2419.diff
I was trying to install a few features on the Karaf 1.6.2 release candidate
build and encountered UnsupportedOperationException
Here are the commands I used
{noformat}
features:addUrl mvn:org.apache.camel.karaf/apache-camel/2.2.0/xml/features
features:install camel-scala
features:install camel
{noformat}
This is the resulting exception's stack trace
{noformat}
10:46:07,342 | INFO | l Console Thread | Console |
araf.shell.console.jline.Console 198 | Exception caught while executing
command
java.lang.UnsupportedOperationException
at java.util.AbstractList.remove(AbstractList.java:144)[:1.6.0_20]
at java.util.AbstractList$Itr.remove(AbstractList.java:360)[:1.6.0_20]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.findBundlesWithOptionalPackagesToRefresh(FeaturesServiceImpl.java:445)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.findBundlesToRefresh(FeaturesServiceImpl.java:389)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:252)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:222)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:218)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[27:org.apache.felix.karaf.features.command:1.6.2]
at
org.apache.felix.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[27:org.apache.felix.karaf.features.command:1.6.2]
at
org.apache.felix.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:41)[22:org.apache.felix.karaf.shell.console:1.6.2]
at
org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[22:org.apache.felix.karaf.shell.console:1.6.2]
at
org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.karaf.shell.console.jline.Console.run(Console.java:180)[22:org.apache.felix.karaf.shell.console:1.6.2]
at java.lang.Thread.run(Thread.java:637)[:1.6.0_20]
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2419) UnsupportedOperationException while installing features
[
https://issues.apache.org/jira/browse/FELIX-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved FELIX-2419.
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revisionrevision=955727
UnsupportedOperationException while installing features
---
Key: FELIX-2419
URL: https://issues.apache.org/jira/browse/FELIX-2419
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.6.2
Reporter: Gert Vanthienen
Assignee: Guillaume Nodet
Fix For: karaf-1.6.2
Attachments: FELIX-2419.diff
I was trying to install a few features on the Karaf 1.6.2 release candidate
build and encountered UnsupportedOperationException
Here are the commands I used
{noformat}
features:addUrl mvn:org.apache.camel.karaf/apache-camel/2.2.0/xml/features
features:install camel-scala
features:install camel
{noformat}
This is the resulting exception's stack trace
{noformat}
10:46:07,342 | INFO | l Console Thread | Console |
araf.shell.console.jline.Console 198 | Exception caught while executing
command
java.lang.UnsupportedOperationException
at java.util.AbstractList.remove(AbstractList.java:144)[:1.6.0_20]
at java.util.AbstractList$Itr.remove(AbstractList.java:360)[:1.6.0_20]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.findBundlesWithOptionalPackagesToRefresh(FeaturesServiceImpl.java:445)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.findBundlesToRefresh(FeaturesServiceImpl.java:389)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:252)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:222)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:218)[20:org.apache.felix.karaf.features.core:1.6.2]
at
org.apache.felix.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[27:org.apache.felix.karaf.features.command:1.6.2]
at
org.apache.felix.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[27:org.apache.felix.karaf.features.command:1.6.2]
at
org.apache.felix.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:41)[22:org.apache.felix.karaf.shell.console:1.6.2]
at
org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[22:org.apache.felix.karaf.shell.console:1.6.2]
at
org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[17:org.apache.felix.gogo.runtime:0.4.0]
at
org.apache.felix.karaf.shell.console.jline.Console.run(Console.java:180)[22:org.apache.felix.karaf.shell.console:1.6.2]
at java.lang.Thread.run(Thread.java:637)[:1.6.0_20]
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2361) Unable to connect to admin:create'd instances from within the Karaf shell
[ https://issues.apache.org/jira/browse/FELIX-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12877950#action_12877950 ] Gert Vanthienen commented on FELIX-2361: This was apparently only happening on Ubuntu Linux -- it no longer ships with support for the Cipher implementations required for the SSH connection. This issue can be fixed by adding Bouncycastle as a security provider as explained in http://felix.apache.org/site/65-deploying-security-providers.html (or downloading and installing the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6 from Sun) Unable to connect to admin:create'd instances from within the Karaf shell - Key: FELIX-2361 URL: https://issues.apache.org/jira/browse/FELIX-2361 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Gert Vanthienen Assignee: Guillaume Nodet Fix For: karaf-1.6.2 When a child instance has been created with admin:create command, connecting to it with the admin:connect afterwards fails. The child instance itself is working correctly though and connecting with a plain ssh connection works fine. ka...@root admin:list Port State Pid Name [ 8101] [Started ] [20896] root [ 8102] [Started ] [19939] test ka...@root admin:connect test Connecting to host localhost on port 8102 Connected Error executing command: Session is closed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-2360) Error message from bin/karaf script
[ https://issues.apache.org/jira/browse/FELIX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen reassigned FELIX-2360: -- Assignee: Gert Vanthienen Error message from bin/karaf script Key: FELIX-2360 URL: https://issues.apache.org/jira/browse/FELIX-2360 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Trivial Fix For: karaf 1.8.0 When starting Karaf 1.6.0, an unnecessary error message appears on the console: ge...@ubuntu:~/opt/apache-felix-karaf-1.6.0$ bin/karaf bin/karaf: 326: [[: not found -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Felix framework 3.0.0 and Gogo 0.6.0 subproject releases (take2)
+1 Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 8 June 2010 19:51, Rob Walker r...@ascert.com wrote: +1 -- Rob On Mon, Jun 7, 2010 at 10:42, Karl Pauls karlpa...@gmail.com wrote: I would like to call a new vote on the following subproject releases: gogo 0.6.0 gogo.runtime 0.6.0 gogo.shell 0.6.0 gogo.command 0.6.0 framework 3.0.0 framework.security 1.2.0 main 3.0.0 main.distribution 3.0.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-040/ 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 040 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
Re: [VOTE] Propose Karaf as a TLP
+1 On 3 June 2010 14:28, David Jencks david_jen...@yahoo.com wrote: +1 david jencks On Jun 2, 2010, at 11:24 PM, Guillaume Nodet wrote: I think it's time start a vote about moving Karaf as a TLP as we recently discussed. The vote is about submitting the following proposal to the next board meeting: [ ] +1 send this proposal to the board [ ] -1 do not The vote will be opened for 72 hours = WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to an OSGI based runtime for creating enterprise servers for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to an OSGI based runtime for creating enterprise servers; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * Chris Custine ccust...@apache.org * Freeman Fang ff...@apache.org * Jarek Gawor ga...@apache.org * Jamie Goodyear jgoody...@apache.org * David Jencks djen...@apache.org * Alex Karasulu akaras...@apache.org * Charles Moulliard cmoulli...@apache.org * Guillaume Nodet gno...@apache.org * Jean-Baptiste Onofré jbono...@apache.org * Gert Vanthienen ge...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Karaf Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. === -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSS] Move Karaf as a TLP
L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: I would like to be involved with this TLP as well. Thanks, Jarek On Friday, May 28, 2010, Guillaume Nodet gno...@gmail.com wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to XXX; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * xxx x...@apache.org * ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Mahout Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. On Fri, May 14, 2010 at 12:20, Guillaume Nodet gno...@gmail.com wrote: Karaf has been brought into the Felix TLP nearly one year ago. Things have not been too bad, but I still see the karaf community as being very disjoint from the other felix community, as it looks that none of the existing felix committers did really get involved in Karaf. I really don't blame anyone, i think it's just that the interest are not the same (not sure where they actually diverge though). I don't really see what
[jira] Created: (FELIX-2360) Error message from bin/karaf script
Error message from bin/karaf script Key: FELIX-2360 URL: https://issues.apache.org/jira/browse/FELIX-2360 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Gert Vanthienen Priority: Trivial Fix For: karaf 1.8.0 When starting Karaf 1.6.0, an unnecessary error message appears on the console: ge...@ubuntu:~/opt/apache-felix-karaf-1.6.0$ bin/karaf bin/karaf: 326: [[: not found -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2361) Unable to connect to admin:create'd instances from within the Karaf shell
Unable to connect to admin:create'd instances from within the Karaf shell - Key: FELIX-2361 URL: https://issues.apache.org/jira/browse/FELIX-2361 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Gert Vanthienen Fix For: karaf 1.8.0 When a child instance has been created with admin:create command, connecting to it with the admin:connect afterwards fails. The child instance itself is working correctly though and connecting with a plain ssh connection works fine. ka...@root admin:list Port State Pid Name [ 8101] [Started ] [20896] root [ 8102] [Started ] [19939] test ka...@root admin:connect test Connecting to host localhost on port 8102 Connected Error executing command: Session is closed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RESULT] [VOTE] Release Karaf 1.6.0 (2nd try)
L.S., I just discovered a few minor issues with this release (FELIX-2360 and FELIX-2361), I'll add those to a known issues section in the release notes page for this release. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 27 May 2010 09:38, Guillaume Nodet gno...@gmail.com wrote: Closing this vote with: +1: Guillaume Nodet, Freeman Fang, J-B Onofré, Jamie Goodyear, Chris Custine, Rob Walker, Charles Moulliard I will publish the release asap. On Thu, May 20, 2010 at 23:21, Guillaume Nodet gno...@gmail.com wrote: Second try. The karaf manual should be ok now and this release also includes FELIX-2280 (Too much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock). No other changes. We solved a bunch of issues for 1.6.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100styleName=Htmlversion=12314791 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-003/ 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 003 /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. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release fileinstall 2.0.10, gogo 0.4.0, bundlerepository 1.6.2, bundleplugin 2.1.0
+1 (non-binding) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 3 May 2010 17:52, Richard S. Hall he...@ungoverned.org wrote: +1 for OBR: * It's NOTICE file says it includes OSGi code, but it doesn't. * The changelog hasn't been updated since 1.4.3. +1 for bundleplugin: * It's NOTICE file also says it includes OSGi code, but it doesn't. * NOTICE file copyright year is still 2009. * The changelog hasn't been updated. +1 for Gogo: * Commands, console, and runtime should depend on the official OSGi JAR files, not the Felix ones. * Commands' NOTICE file also says it includes OSGi code, but it doesn't. * Commands, console, launcher, and runtime NOTICE file copyright year is still 2009. * Launcher JAR includes OSGi classes, but only says it uses them. Clearly, we have some NOTICE file issues and we still need to change the way we deal with NOTICE files. Did we ever come to a conclusion how to handle this? We also apparently need to update our release process to document the inclusion of changelogs and make this consistent across releases. - richard On 4/29/10 14:47, Guillaume Nodet wrote: I would like to call a vote on the following subproject releases: fileinstall 2.0.10 gogo 0.4.0 bundlerepository 1.6.2 bundleplugin 2.1.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-034/ 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 034 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] Release fileinstall 3.0.0 (2nd try)
+1 (non-binding) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 3 May 2010 16:11, Sahoo sa...@sun.com wrote: +1 Thanks, Sahoo Guillaume Nodet wrote: I would like to call a vote on the following subproject releases: fileinstall 3.0.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-039/ 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 039 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] Release Karaf 1.4.0 - Take 3
+1 (non-binding) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 5 March 2010 09:45, Rob Walker r...@ascert.com wrote: +1 On Wed, Mar 3, 2010 at 10:15, Chris Custine ccust...@apache.org wrote: The Karaf 1.4.0 artifacts have been staged for release. This release build includes some missing headers as pointed out by Karl in the previous vote, as well as some additional ones discovered after upgrading to a newer Rat version. There is one known Rat failure in manual/src/styles/print.css because rat does not recognize the MIT license text, but this file is now properly noted in the manual NOTICE file so the rat failure can be safely ignored. I have also fixed the duplicate .asc.asc signatures. As with the previous vote, I have noted that the vote will be open for *at least* 72 hours in order to allow time for proper review. Thanks for your patience. Release notes are here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100styleName=Htmlversion=12314410 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-003/ 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 003 /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 at least 72 hours. -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org -- Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
[jira] Created: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle
Improve dev:show-tree performance and avoid NPE for installed bundle Key: FELIX-2169 URL: https://issues.apache.org/jira/browse/FELIX-2169 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.4.0 As reported in https://issues.apache.org/activemq/browse/SMX4-489, the current implementation of the dev:show-tree command has two problems: * for bundles with an extensive set of dependencies, calculating the dependency tree can take a long time (several seconds) * for installed bundles with imports for which no suitable export is available, the command fails with a NullPointerException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle
[ https://issues.apache.org/jira/browse/FELIX-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated FELIX-2169: --- Affects Version/s: (was: karaf-1.2.0) karaf-1.4.0 Fix Version/s: (was: karaf-1.4.0) karaf 1.6.0 Improve dev:show-tree performance and avoid NPE for installed bundle Key: FELIX-2169 URL: https://issues.apache.org/jira/browse/FELIX-2169 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf 1.6.0 As reported in https://issues.apache.org/activemq/browse/SMX4-489, the current implementation of the dev:show-tree command has two problems: * for bundles with an extensive set of dependencies, calculating the dependency tree can take a long time (several seconds) * for installed bundles with imports for which no suitable export is available, the command fails with a NullPointerException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle
[ https://issues.apache.org/jira/browse/FELIX-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-2169. Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revisionrevision=918963 Will ask Charles Mouillard to confirm that this fixes the issue he has reported. Improve dev:show-tree performance and avoid NPE for installed bundle Key: FELIX-2169 URL: https://issues.apache.org/jira/browse/FELIX-2169 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf 1.6.0 As reported in https://issues.apache.org/activemq/browse/SMX4-489, the current implementation of the dev:show-tree command has two problems: * for bundles with an extensive set of dependencies, calculating the dependency tree can take a long time (several seconds) * for installed bundles with imports for which no suitable export is available, the command fails with a NullPointerException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Karaf 1.4.0
+1 (non-binding) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 26 February 2010 17:41, Chris Custine ccust...@apache.org wrote: +1 (non-binding) -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Wed, Feb 24, 2010 at 11:57 AM, Chris Custine ccust...@apache.org wrote: The Karaf 1.4.0 artifacts have been staged for release. These release artifacts contain updated copyright year in all NOTICE files and includes an updated RELEASE-NOTES file which was not updated in the previous release vote. As requested by Richard, I have noted that the vote will be open for *at least* 72 hours in order to allow time for proper review. Release notes are here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100styleName=Htmlversion=12314410 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-015/ 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 015 /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 at least 72 hours. -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org
[jira] Closed: (FELIX-2061) [karaf] use waitForFrameworkStartup pax-exam option in the integration tests
[ https://issues.apache.org/jira/browse/FELIX-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen closed FELIX-2061. -- Resolution: Fixed Assignee: Gert Vanthienen Fixed in http://svn.apache.org/viewvc?view=revisionrevision=908120 Thanks to Eoghan for providing the patch! [karaf] use waitForFrameworkStartup pax-exam option in the integration tests Key: FELIX-2061 URL: https://issues.apache.org/jira/browse/FELIX-2061 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Eoghan Glynn Assignee: Gert Vanthienen Fix For: karaf-1.4.0 Attachments: felix_2061.patch I've seen the odd timeout in the Karaf integration tests, and I noticed that waitForFrameworkStartup pax-exam option was not being used. Now I'm not sure whether there's even any relationship there, but it probably wouldn't do any harm to add in this option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2004) Update Configuring Failover Deployments doc to to include Oracle support
[ https://issues.apache.org/jira/browse/FELIX-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-2004. Resolution: Fixed Fix Version/s: (was: karaf-1.0.0) karaf-1.2.0 Updated http://cwiki.apache.org/confluence/display/FELIX/6.7.+Configuring+Failover+Deployments with the content provided in the test space. @David: Thanks a lot for providing this new content! Could you quickly verify that the new content is in the correct place and close this issue if it is OK? Update Configuring Failover Deployments doc to to include Oracle support Key: FELIX-2004 URL: https://issues.apache.org/jira/browse/FELIX-2004 Project: Felix Issue Type: Bug Components: Documentation Affects Versions: karaf-1.0.0 Reporter: David Porter Fix For: karaf-1.2.0 I have made a number of changes to the Configuring Failover Deployments topic in the Karaf user's guide (http://felix.apache.org/site/67-configuring-failover-deployments.html) I have restructured the topic and added detail on the Oracle support added in FELIX-1975. I don't have rights to update the wiki page, so I have added the revised topic to a test wiki space here: http://cwiki.apache.org/confluence/display/test/6.7.+Configuring+Failover+Deployments I need someone to copy the contents of that page and overwrite the current page, which is here: http://cwiki.apache.org/confluence/display/FELIX/6.7.+Configuring+Failover+Deployments -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1975) [Karaf] Add oracle database support to Karaf jdbc locking feature.
[ https://issues.apache.org/jira/browse/FELIX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804567#action_12804567 ] Gert Vanthienen commented on FELIX-1975: Patch has been applied in http://svn.apache.org/viewvc?view=revisionrevision=902839 Thanks to Jamie Goodyear for yet another fine Karaf patch! [Karaf] Add oracle database support to Karaf jdbc locking feature. -- Key: FELIX-1975 URL: https://issues.apache.org/jira/browse/FELIX-1975 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Jamie goodyear Assignee: Gert Vanthienen Attachments: felix-1975.patch Add oracle database support to Karaf jdbc locking feature. Current default JDBC class does not work well with Oracle databases, please add support for functionality with Oracle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1975) [Karaf] Add oracle database support to Karaf jdbc locking feature.
[ https://issues.apache.org/jira/browse/FELIX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-1975. Resolution: Fixed Fix Version/s: karaf-1.4.0 [Karaf] Add oracle database support to Karaf jdbc locking feature. -- Key: FELIX-1975 URL: https://issues.apache.org/jira/browse/FELIX-1975 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Jamie goodyear Assignee: Gert Vanthienen Fix For: karaf-1.4.0 Attachments: felix-1975.patch Add oracle database support to Karaf jdbc locking feature. Current default JDBC class does not work well with Oracle databases, please add support for functionality with Oracle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release fileinstall 2.0.8
L.S., Here's my +1 (non-binding) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/12/22 Chris Custine ccust...@apache.org: Hi All, Before checking the staged artifacts, please be sure to import my public key from either http://www.apache.org/dist/felix/KEYS or a public keyserver. Release Notes - Felix - Version fileinstall-2.0.8 ** Bug * [FELIX-1775] - fileinstall release archives contains an empty load folder which should be removed * [FELIX-1789] - FileInstall is too verbose * [FELIX-1851] - FileInstall watched bundles are restarted twice upon update * [FELIX-1861] - FileInstall created temp directories are never deleted * [FELIX-1862] - fileinstall thread name as printed in log messages need to be less verbose * [FELIX-1928] - File installer starts bundles too early on restart ** Task * [FELIX-1811] - fileinstall should depend on the official osgi artifacts Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-005/ 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 005 /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, Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org
[jira] Assigned: (FELIX-1843) Karaf shell doens't work properly under windows
[ https://issues.apache.org/jira/browse/FELIX-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen reassigned FELIX-1843: -- Assignee: Gert Vanthienen Karaf shell doens't work properly under windows --- Key: FELIX-1843 URL: https://issues.apache.org/jira/browse/FELIX-1843 Project: Felix Issue Type: Bug Components: Gogo, Karaf Affects Versions: karaf-1.2.0, gogo-0.2.0 Reporter: Stefan Weber Assignee: Gert Vanthienen When ever you try to complete a command the completion doesn't replace the prevoiusly typed characters but will be appended to them. Also backspace isn't working. Same behaviour if you use the up-key to get the last used command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1932) Possible NullPointerException when itest fails
Possible NullPointerException when itest fails
--
Key: FELIX-1932
URL: https://issues.apache.org/jira/browse/FELIX-1932
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.2.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: karaf-1.4.0
When a Karaf itest fails due to a missing service reference, the extra logging
that is being created can be interrupted by a NullPointException:
{noformat}
java.lang.NullPointerException
at
org.apache.felix.karaf.shell.itests.AbstractIntegrationTest.getOsgiService(AbstractIntegrationTest.java:76)
at
org.apache.felix.karaf.shell.itests.FeaturesTest.testFeatures(FeaturesTest.java:45)
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:585)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
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:585)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
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:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
{noformat}
The bundle headers logging is also not very useful
{noformat}
Test bundle headers: [Ljava.lang.Object;@7f8922
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1932) Possible NullPointerException when itest fails
[
https://issues.apache.org/jira/browse/FELIX-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen closed FELIX-1932.
--
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revisionrevision=888961
Possible NullPointerException when itest fails
--
Key: FELIX-1932
URL: https://issues.apache.org/jira/browse/FELIX-1932
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.2.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: karaf-1.4.0
When a Karaf itest fails due to a missing service reference, the extra
logging that is being created can be interrupted by a NullPointException:
{noformat}
java.lang.NullPointerException
at
org.apache.felix.karaf.shell.itests.AbstractIntegrationTest.getOsgiService(AbstractIntegrationTest.java:76)
at
org.apache.felix.karaf.shell.itests.FeaturesTest.testFeatures(FeaturesTest.java:45)
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:585)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
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:585)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
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:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
{noformat}
The bundle headers logging is also not very useful
{noformat}
Test bundle headers: [Ljava.lang.Object;@7f8922
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1914) Add a development subshell to ease troubleshooting classloading/resolution issues
[
https://issues.apache.org/jira/browse/FELIX-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12786674#action_12786674
]
Gert Vanthienen commented on FELIX-1914:
Add a *{{dev:dynamic-import}}* to enable/disable dynamic imports on a bundle in
http://svn.apache.org/viewvc?view=revisionrevision=887748
When disabling the bundle, the command will determine what packages have been
added.
Example:
{noformat}
ka...@root osgi:update 32
...
Caused by: java.lang.ClassNotFoundException: org.hsqldb.jdbcDriver
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:738)
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:60)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1650)
at java.lang.ClassLoader.loadClass(ClassLoader.java:254)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:399)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1130)
... 26 more
ka...@root dev:dynamic-import 35
Enabling dynamic imports on bundle org.apache.servicemix.bundles.commons-dbcp
[35]
ka...@root osgi:update 32
ka...@root dev:dynamic-import 35
Disabling dynamic imports on bundle org.apache.servicemix.bundles.commons-dbcp
[35]
Additional packages wired since dynamic import was enabled:
- org.hsqldb
{noformat}
Add a development subshell to ease troubleshooting classloading/resolution
issues
-
Key: FELIX-1914
URL: https://issues.apache.org/jira/browse/FELIX-1914
Project: Felix
Issue Type: Improvement
Components: Karaf
Affects Versions: karaf-1.2.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: karaf-1.4.0
At development time, people sometimes bump into classloading or bundle
resolution issues. Proposing to add a subshell with a few development tools
that can be used to troubleshoot these issues:
- To solve the unable to resolve due to constraint violation, we could
build a tool that discovers multiple bundles exporting the same package that
are needed to resolve the given bundle to give people a clue which
uses-constraints might be involved
- To solve a CNFE, we could build a tool that takes a snapshot of imports,
enabled dynamic imports and refreshes the bundle and then checks the imported
packages again to see which imports were added by the dynamic import
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1914) Add a development subshell to ease troubleshooting classloading/resolution issues
[ https://issues.apache.org/jira/browse/FELIX-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen closed FELIX-1914. -- Resolution: Fixed An initial set of 3 commands has been added to the dev: shell: - dev:show-tree id to show bundle wiring as dependency tree - dev:framework -(no)debug to enable/disable OSGi framework debug logging - dev:dynamic-import to enable/disable dynamic import on the fly Closing this issue - we can always create new issues if we think of new commands to add to the shell. Add a development subshell to ease troubleshooting classloading/resolution issues - Key: FELIX-1914 URL: https://issues.apache.org/jira/browse/FELIX-1914 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.4.0 At development time, people sometimes bump into classloading or bundle resolution issues. Proposing to add a subshell with a few development tools that can be used to troubleshoot these issues: - To solve the unable to resolve due to constraint violation, we could build a tool that discovers multiple bundles exporting the same package that are needed to resolve the given bundle to give people a clue which uses-constraints might be involved - To solve a CNFE, we could build a tool that takes a snapshot of imports, enabled dynamic imports and refreshes the bundle and then checks the imported packages again to see which imports were added by the dynamic import -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1914) Add a development subshell to ease troubleshooting classloading/resolution issues
[
https://issues.apache.org/jira/browse/FELIX-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12786473#action_12786473
]
Gert Vanthienen commented on FELIX-1914:
Added a *{{dev:framework}}* to enable/disable debug logging on the underlying
OSGi framework in http://svn.apache.org/viewvc?view=revisionrevision=887538.
* dev:framework -debug enables debug logging
* dev:framework -nodebug disables debug logging
Add a development subshell to ease troubleshooting classloading/resolution
issues
-
Key: FELIX-1914
URL: https://issues.apache.org/jira/browse/FELIX-1914
Project: Felix
Issue Type: Improvement
Components: Karaf
Affects Versions: karaf-1.2.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: karaf-1.4.0
At development time, people sometimes bump into classloading or bundle
resolution issues. Proposing to add a subshell with a few development tools
that can be used to troubleshoot these issues:
- To solve the unable to resolve due to constraint violation, we could
build a tool that discovers multiple bundles exporting the same package that
are needed to resolve the given bundle to give people a clue which
uses-constraints might be involved
- To solve a CNFE, we could build a tool that takes a snapshot of imports,
enabled dynamic imports and refreshes the bundle and then checks the imported
packages again to see which imports were added by the dynamic import
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1914) Add a development subshell to ease troubleshooting classloading/resolution issues
[
https://issues.apache.org/jira/browse/FELIX-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12785971#action_12785971
]
Gert Vanthienen commented on FELIX-1914:
Added a *{{dev:show-tree}}* in
http://svn.apache.org/viewvc?view=revisionrevision=887233
This can be used to represent bundle dependencies 'graphically' and it will
also warn users if multiple bundles in the dependency graph are exporting the
same packages.
{noformat}
ka...@root dev:show-tree 36
Bundle wip.foobar [36] is currently INSTALLED
- using wip.bar2 [34] to resolve import org.wip.bar;version=2.0.0
- using wip.foo [35] to resolve import org.wip.foo
wip.foobar [36]
+- wip.bar2 [34]
+- wip.foo [35]
+- wip.bar1 [33]
WARNING: multiple bundles are exporting package org.wip.bar
- wip.bar1 [33]
- wip.bar2 [34]
{noformat}
Add a development subshell to ease troubleshooting classloading/resolution
issues
-
Key: FELIX-1914
URL: https://issues.apache.org/jira/browse/FELIX-1914
Project: Felix
Issue Type: Improvement
Components: Karaf
Affects Versions: karaf-1.2.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: karaf-1.4.0
At development time, people sometimes bump into classloading or bundle
resolution issues. Proposing to add a subshell with a few development tools
that can be used to troubleshoot these issues:
- To solve the unable to resolve due to constraint violation, we could
build a tool that discovers multiple bundles exporting the same package that
are needed to resolve the given bundle to give people a clue which
uses-constraints might be involved
- To solve a CNFE, we could build a tool that takes a snapshot of imports,
enabled dynamic imports and refreshes the bundle and then checks the imported
packages again to see which imports were added by the dynamic import
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1914) Add a development subshell to ease troubleshooting classloading/resolution issues
Add a development subshell to ease troubleshooting classloading/resolution issues - Key: FELIX-1914 URL: https://issues.apache.org/jira/browse/FELIX-1914 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.4.0 At development time, people sometimes bump into classloading or bundle resolution issues. Proposing to add a subshell with a few development tools that can be used to troubleshoot these issues: - To solve the unable to resolve due to constraint violation, we could build a tool that discovers multiple bundles exporting the same package that are needed to resolve the given bundle to give people a clue which uses-constraints might be involved - To solve a CNFE, we could build a tool that takes a snapshot of imports, enabled dynamic imports and refreshes the bundle and then checks the imported packages again to see which imports were added by the dynamic import -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1899) Karaf itest (CoreTest) fails on slower CI machines
Karaf itest (CoreTest) fails on slower CI machines
---
Key: FELIX-1899
URL: https://issues.apache.org/jira/browse/FELIX-1899
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.0.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Priority: Minor
Fix For: karaf-1.2.0
When running the Karaf build on a slower (CI) build machine, the CoreTest in
the itests fails because the commands have not been set up when the assertions
are being executed:
{noformat}
org.apache.felix.karaf.shell.itests.CoreTest.testInstallCommand [equinox] View
test details
java.lang.IllegalArgumentException: Command not found: log:display
at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:208)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1899) Karaf itest (CoreTest) fails on slower CI machines
[
https://issues.apache.org/jira/browse/FELIX-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved FELIX-1899.
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revisionrevision=884537
Karaf itest (CoreTest) fails on slower CI machines
---
Key: FELIX-1899
URL: https://issues.apache.org/jira/browse/FELIX-1899
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.0.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Priority: Minor
Fix For: karaf-1.2.0
When running the Karaf build on a slower (CI) build machine, the CoreTest in
the itests fails because the commands have not been set up when the
assertions are being executed:
{noformat}
org.apache.felix.karaf.shell.itests.CoreTest.testInstallCommand [equinox]
View test details
java.lang.IllegalArgumentException: Command not found: log:display
at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:208)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1882) [karaf] karaf-client should have the option to retry connection establishment
[ https://issues.apache.org/jira/browse/FELIX-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen reassigned FELIX-1882: -- Assignee: Gert Vanthienen [karaf] karaf-client should have the option to retry connection establishment - Key: FELIX-1882 URL: https://issues.apache.org/jira/browse/FELIX-1882 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Assignee: Gert Vanthienen Fix For: karaf-1.0.2, karaf-1.2.0 Attachments: felix_1882.patch When using the karaf-client to run some automated set-up commands on a newly started karaf instances, there's a slight race condition between the ssh server being ready to accept incoming connections and the point at which the karaf-client is run. This is especially apparent if the karaf instance has a long boot features list. To avoid having to artificially delay the client start-up, the karaf-client should accept two new command-line options to enable connection-establishment retry logic: -r [attempts] retry connection establishment (up to attempts times) -d [delay]intra-retry delay (defaults to 2 seconds) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release fileinstall 2.0.4
+1 Regards, Gert Vanthienen 2009/10/22 Guillaume Nodet gno...@gmail.com: This release includes * fileinstall 2.0.4 Staging repository: https://repository.apache.org/content/repositories/felix-staging-009/ 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 9 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Closed: (FELIX-1799) Hot-deployment does not work on admin:create'd instances
[ https://issues.apache.org/jira/browse/FELIX-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen closed FELIX-1799. -- Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revisionrevision=829191 Hot-deployment does not work on admin:create'd instances Key: FELIX-1799 URL: https://issues.apache.org/jira/browse/FELIX-1799 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.2.0 When using admin:create to create a new container instance, bundles copied to the hot-deployment folder for that instance are being deployed. The reason is that the etc/org.apache.felix.fileinstall-deploy.cfg file is missing from the instance which is required to configure Felix FileInstall -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1799) Hot-deployment does not work on admin:create'd instances
Hot-deployment does not work on admin:create'd instances Key: FELIX-1799 URL: https://issues.apache.org/jira/browse/FELIX-1799 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.2.0 When using admin:create to create a new container instance, bundles copied to the hot-deployment folder for that instance are being deployed. The reason is that the etc/org.apache.felix.fileinstall-deploy.cfg file is missing from the instance which is required to configure Felix FileInstall -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1064) New goal for the features-maven-plugin: validate a features xml file
[ https://issues.apache.org/jira/browse/FELIX-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12767479#action_12767479 ] Gert Vanthienen commented on FELIX-1064: Improving the validate goal to deal with maven repositories specified in the bundle url cfr. http://svn.apache.org/viewvc?view=revisionrevision=826783 New goal for the features-maven-plugin: validate a features xml file Key: FELIX-1064 URL: https://issues.apache.org/jira/browse/FELIX-1064 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Assignee: Gert Vanthienen Fix For: karaf-1.0.2, karaf-1.2.0 We should add a goal to the features-maven-plugin to validate the features xml file: * do all the bundles exist? * are all the imports from the bundles resolved? Most of the code for reading manifest and looking up the bundles is already available in the features-maven-plugin' generate-features-xml Mojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1064) New goal for the features-maven-plugin: validate a features xml file
[ https://issues.apache.org/jira/browse/FELIX-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen reassigned FELIX-1064: -- Assignee: Gert Vanthienen New goal for the features-maven-plugin: validate a features xml file Key: FELIX-1064 URL: https://issues.apache.org/jira/browse/FELIX-1064 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Assignee: Gert Vanthienen We should add a goal to the features-maven-plugin to validate the features xml file: * do all the bundles exist? * are all the imports from the bundles resolved? Most of the code for reading manifest and looking up the bundles is already available in the features-maven-plugin' generate-features-xml Mojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1064) New goal for the features-maven-plugin: validate a features xml file
[
https://issues.apache.org/jira/browse/FELIX-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved FELIX-1064.
Resolution: Fixed
Fix Version/s: karaf-1.2.0
karaf-1.0.2
The new plugin goal has been added in
http://svn.apache.org/viewvc?view=revisionrevision=826062
The new goal can be used by adding this plugin configuration to the build
section:
{code:xml}
plugin
groupIdorg.apache.felix.karaf.tooling/groupId
artifactIdfeatures-maven-plugin/artifactId
version1.1.0-SNAPSHOT/version
executions
execution
idvalidate/id
phaseprocess-resources/phase
goals
goalvalidate/goal
/goals
/execution
/executions
/plugin
{code
New goal for the features-maven-plugin: validate a features xml file
Key: FELIX-1064
URL: https://issues.apache.org/jira/browse/FELIX-1064
Project: Felix
Issue Type: Improvement
Components: Karaf
Reporter: Guillaume Nodet
Assignee: Gert Vanthienen
Fix For: karaf-1.0.2, karaf-1.2.0
We should add a goal to the features-maven-plugin to validate the features
xml file:
* do all the bundles exist?
* are all the imports from the bundles resolved?
Most of the code for reading manifest and looking up the bundles is already
available in the features-maven-plugin' generate-features-xml Mojo.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1749) Improve log:set command - add auto-completion for log levels and support lower case level
[ https://issues.apache.org/jira/browse/FELIX-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated FELIX-1749: --- Fix Version/s: (was: felix-2.0.1) Improve log:set command - add auto-completion for log levels and support lower case level - Key: FELIX-1749 URL: https://issues.apache.org/jira/browse/FELIX-1749 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Minor Fix For: karaf-1.0.2, karaf-1.2.0 Improve usability on the log:set command by: - adding a completer for the log level - allowing people to specify log levels in lower case too -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1749) Improve log:set command - add auto-completion for log levels and support lower case level
[ https://issues.apache.org/jira/browse/FELIX-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen closed FELIX-1749. -- Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revrevision=824811 Improve log:set command - add auto-completion for log levels and support lower case level - Key: FELIX-1749 URL: https://issues.apache.org/jira/browse/FELIX-1749 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Minor Fix For: karaf-1.0.2, karaf-1.2.0 Improve usability on the log:set command by: - adding a completer for the log level - allowing people to specify log levels in lower case too -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1749) Improve log:set command - add auto-completion for log levels and support lower case level
Improve log:set command - add auto-completion for log levels and support lower case level - Key: FELIX-1749 URL: https://issues.apache.org/jira/browse/FELIX-1749 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Priority: Minor Fix For: felix-2.0.1, karaf-1.0.2, karaf-1.2.0 Improve usability on the log:set command by: - adding a completer for the log level - allowing people to specify log levels in lower case too -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1745) Unable to alter/unset a log level after it has been set from the console
Unable to alter/unset a log level after it has been set from the console Key: FELIX-1745 URL: https://issues.apache.org/jira/browse/FELIX-1745 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.2, karaf-1.2.0 Once a log level has been set from the console, it seems impossible to alter/unset it. Cfr. this example ka...@root:/ log:get all ROOT: INFO org.apache.geronimo.gshell.remote: WARN ka...@root:/ log:set DEBUG com.foo ka...@root:/ log:set WARN com.foo.example ka...@root:/ log:get all ROOT: INFO com.foo: DEBUG com.foo.example: WARN org.apache.geronimo.gshell.remote: WARN ka...@root:/ log:set INFO com.foo ka...@root:/ log:get all ROOT: INFO com.foo: DEBUG com.foo.example: WARN org.apache.geronimo.gshell.remote: WARN ka...@root:/ log:set INFO com.foo ka...@root:/ log:get all ROOT: INFO com.foo: DEBUG com.foo.example: WARN org.apache.geronimo.gshell.remote: WARN ka...@root:/ log:set - com.foo ERROR - is not a valid option ka...@root:/ log:set WARN com.foo ka...@root:/ log:set - com.foo ERROR - is not a valid option ka...@root:/ log:get all ROOT: INFO com.foo: DEBUG com.foo.example: WARN org.apache.geronimo.gshell.remote: WARN -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1745) Unable to alter/unset a log level after it has been set from the console
[ https://issues.apache.org/jira/browse/FELIX-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen closed FELIX-1745. -- Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revrevision=824488 Unable to alter/unset a log level after it has been set from the console Key: FELIX-1745 URL: https://issues.apache.org/jira/browse/FELIX-1745 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.2, karaf-1.2.0 Once a log level has been set from the console, it seems impossible to alter/unset it. Cfr. this example ka...@root:/ log:get all ROOT: INFO org.apache.geronimo.gshell.remote: WARN ka...@root:/ log:set DEBUG com.foo ka...@root:/ log:set WARN com.foo.example ka...@root:/ log:get all ROOT: INFO com.foo: DEBUG com.foo.example: WARN org.apache.geronimo.gshell.remote: WARN ka...@root:/ log:set INFO com.foo ka...@root:/ log:get all ROOT: INFO com.foo: DEBUG com.foo.example: WARN org.apache.geronimo.gshell.remote: WARN ka...@root:/ log:set INFO com.foo ka...@root:/ log:get all ROOT: INFO com.foo: DEBUG com.foo.example: WARN org.apache.geronimo.gshell.remote: WARN ka...@root:/ log:set - com.foo ERROR - is not a valid option ka...@root:/ log:set WARN com.foo ka...@root:/ log:set - com.foo ERROR - is not a valid option ka...@root:/ log:get all ROOT: INFO com.foo: DEBUG com.foo.example: WARN org.apache.geronimo.gshell.remote: WARN -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1728) Karaf itest fail on IBM JDK due to Pax Exam annotations not found
Karaf itest fail on IBM JDK due to Pax Exam annotations not found - Key: FELIX-1728 URL: https://issues.apache.org/jira/browse/FELIX-1728 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.2 Due to a difference in the way the IBM JDK handles annotations (it fails on annotations not on the classpath instead of ignoring them), the following tests fail: org.apache.felix.karaf.shell.itests.FeaturesTest.testFeatures [equinox] org.apache.felix.karaf.shell.itests.CoreTest.testHelp [equinox] org.apache.felix.karaf.shell.itests.CoreTest.testInstallCommand [equinox] Cfr. http://lists.ops4j.org/pipermail/general/2009q4/003296.html for background information the error looks like this: java.lang.TypeNotPresentException: Type org.ops4j.pax.exam.junit.Configuration not present at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38) at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50) at com.ibm.oti.reflect.Method.getDeclaredAnnotations(Method.java:31) at java.lang.reflect.Method.getDeclaredAnnotations(Method.java:722) at java.lang.reflect.AccessibleObject.getAnnotations(AccessibleObject.java:191) at com.ibm.oti.reflect.Method.getAnnotation(Method.java:20) at java.lang.reflect.Method.getAnnotation(Method.java:711) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.getAnnotatedMethods(CallableTestMethodImpl.java:295) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.runBefores(CallableTestMethodImpl.java:162) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:124) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:279) at sun.rmi.transport.Transport.serviceCall(Transport.java:164) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912) at java.lang.Thread.run(Thread.java:810) Caused by: java.lang.ClassNotFoundException: org.ops4j.pax.exam.junit.Configuration at java.lang.Class.forName(Class.java:163) at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33) ... 27 more The test launches okay, but the pax Configuration annotation class cannot be found. Adding the jar that contains the class, pax-exam-junit as a bundle in the test when we detect that we are using the ibm jdk allows the test to pass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1728) Karaf itest fail on IBM JDK due to Pax Exam annotations not found
[ https://issues.apache.org/jira/browse/FELIX-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-1728. Resolution: Fixed http://svn.apache.org/viewvc?view=revrevision=823510 adds the necessary jars to the classpath when running the tests on an IBM JDK Karaf itest fail on IBM JDK due to Pax Exam annotations not found - Key: FELIX-1728 URL: https://issues.apache.org/jira/browse/FELIX-1728 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.2 Due to a difference in the way the IBM JDK handles annotations (it fails on annotations not on the classpath instead of ignoring them), the following tests fail: org.apache.felix.karaf.shell.itests.FeaturesTest.testFeatures [equinox] org.apache.felix.karaf.shell.itests.CoreTest.testHelp [equinox] org.apache.felix.karaf.shell.itests.CoreTest.testInstallCommand [equinox] Cfr. http://lists.ops4j.org/pipermail/general/2009q4/003296.html for background information the error looks like this: java.lang.TypeNotPresentException: Type org.ops4j.pax.exam.junit.Configuration not present at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:38) at com.ibm.oti.reflect.AnnotationHelper.getDeclaredAnnotations(AnnotationHelper.java:50) at com.ibm.oti.reflect.Method.getDeclaredAnnotations(Method.java:31) at java.lang.reflect.Method.getDeclaredAnnotations(Method.java:722) at java.lang.reflect.AccessibleObject.getAnnotations(AccessibleObject.java:191) at com.ibm.oti.reflect.Method.getAnnotation(Method.java:20) at java.lang.reflect.Method.getAnnotation(Method.java:711) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.getAnnotatedMethods(CallableTestMethodImpl.java:295) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.runBefores(CallableTestMethodImpl.java:162) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:124) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:279) at sun.rmi.transport.Transport.serviceCall(Transport.java:164) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912) at java.lang.Thread.run(Thread.java:810) Caused by: java.lang.ClassNotFoundException: org.ops4j.pax.exam.junit.Configuration at java.lang.Class.forName(Class.java:163) at com.ibm.oti.reflect.AnnotationHelper.getAnnotation(AnnotationHelper.java:33) ... 27 more The test launches okay, but the pax Configuration annotation class cannot be found. Adding the jar that contains the class, pax-exam-junit as a bundle in the test when we detect that we are using the ibm jdk allows the test to pass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1641) Unable to connect to Karaf with ssh on Windows
Unable to connect to Karaf with ssh on Windows -- Key: FELIX-1641 URL: https://issues.apache.org/jira/browse/FELIX-1641 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 When running Karaf on Windows, you can not connect to it with ssh. The connection is established, but authentication fails even with the default username and password right after installation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1641) Unable to connect to Karaf with ssh on Windows
[ https://issues.apache.org/jira/browse/FELIX-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-1641. Resolution: Fixed The default blueprint converter for String - Properties uses the Properties.load() method which strips the \ from the Windows path names. Fixed in https://svn.apache.org/viewvc?view=revrevision=818650 by adding a custom converter to handle this particular use case. Unable to connect to Karaf with ssh on Windows -- Key: FELIX-1641 URL: https://issues.apache.org/jira/browse/FELIX-1641 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 When running Karaf on Windows, you can not connect to it with ssh. The connection is established, but authentication fails even with the default username and password right after installation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1635) Find a way to improve handling optional imports in Karaf
Find a way to improve handling optional imports in Karaf Key: FELIX-1635 URL: https://issues.apache.org/jira/browse/FELIX-1635 Project: Felix Issue Type: Improvement Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen When installing a bundle, optional imports that unavailable at that time are ignored. However, if those ignored packages become available afterwards, users have to manually refresh the bundle to get the optional imports wired correctly. When a user is unaware of this, she'll probably experience a problem that gets fixed when the container is restarted (because bundles are being wired again), We should try to come up with a mechanism to improve this experience. One possible solution would be to improve the features mechanism to support refreshing existing bundles, so we can indicate that a given bundle needs to refreshed when a feature is being installed. Another way to handle it would be by keeping tracking of unwired optional imports and when automatically refreshing bundles when more imports become available. Probably needs a bit more investigation though to find a solution that works... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1624) Add a convenience start/stop script to start/stop karaf running in server mode
Add a convenience start/stop script to start/stop karaf running in server mode -- Key: FELIX-1624 URL: https://issues.apache.org/jira/browse/FELIX-1624 Project: Felix Issue Type: Improvement Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 Add two convenience scripts for starting/stopping karaf in server mode (without a local console) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1624) Add a convenience start/stop script to start/stop karaf running in server mode
[ https://issues.apache.org/jira/browse/FELIX-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated FELIX-1624: --- Attachment: FELIX-1624.diff First take on the *nix scripts -- still need to add the matching Windows scripts to this Add a convenience start/stop script to start/stop karaf running in server mode -- Key: FELIX-1624 URL: https://issues.apache.org/jira/browse/FELIX-1624 Project: Felix Issue Type: Improvement Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 Attachments: FELIX-1624.diff Add two convenience scripts for starting/stopping karaf in server mode (without a local console) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1618) in spring-dm feature, optional imports in spring-context won't get resolved
[ https://issues.apache.org/jira/browse/FELIX-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen reassigned FELIX-1618: -- Assignee: Gert Vanthienen in spring-dm feature, optional imports in spring-context won't get resolved --- Key: FELIX-1618 URL: https://issues.apache.org/jira/browse/FELIX-1618 Project: Felix Issue Type: Bug Affects Versions: karaf-1.0.0 Reporter: Hans Couder Assignee: Gert Vanthienen Fix For: karaf-1.0.0 In the spring-dm feature, the spring-context bundle precedes spring-aop. This causes optional imports in the spring-context bundle won't get resolved resulting in: Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=org.apache.camel.camel-example-osgi, config=osgibundle:/META-INF/spring/*.xml)) java.lang.NoClassDefFoundError: org/springframework/aop/support/AopUtils at org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler.checkManagedBean(MetadataMBeanInfoAssembler.java:106) at org.springframework.jmx.export.assembler.AbstractMBeanInfoAssembler.getMBeanInfo(AbstractMBeanInfoAssembler.java:63) at org.apache.camel.management.DefaultManagementAgent.register(DefaultManagementAgent.java:202) at org.apache.camel.management.DefaultManagementAgent.register(DefaultManagementAgent.java:193) at org.apache.camel.management.ManagedManagementStrategy.manageNamedObject(ManagedManagementStrategy.java:68) at org.apache.camel.management.ManagedManagementStrategy.manageObject(ManagedManagementStrategy.java:61) at org.apache.camel.management.DefaultManagementLifecycleStrategy.onContextStart(DefaultManagementLifecycleStrategy.java:99) at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:918) at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:869) at org.apache.camel.spring.SpringCamelContext.maybeDoStart(SpringCamelContext.java:165) at org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:160) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:52) at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:832) at org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:99) at org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:119) at org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:516) at org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78) at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76) at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:274) at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:736) at org.springframework.osgi.context.support.AbstractOsgiBundleApplicationContext.finishRefresh(AbstractOsgiBundleApplicationContext.java:235) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:358) at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:136) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.ClassNotFoundException: *** Class 'org.springframework.aop.support.AopUtils' was not found because bundle 38 does not import 'org.springframework.aop.support' even though bundle 39 does export it. To resolve this issue, add an import for 'org.springframework.aop.support' to bundle 38. *** at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1645) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) ... 27 more Caused by: java.lang.ClassNotFoundException: org.springframework.aop.support.AopUtils at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation
[jira] Resolved: (FELIX-1618) in spring-dm feature, optional imports in spring-context won't get resolved
[ https://issues.apache.org/jira/browse/FELIX-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-1618. Resolution: Fixed Reordering the bundles in the features descriptor should fix this, cfr. http://svn.apache.org/viewvc?view=revrevision=816629 @Hans: Can you close this issue if this fixes your problem? in spring-dm feature, optional imports in spring-context won't get resolved --- Key: FELIX-1618 URL: https://issues.apache.org/jira/browse/FELIX-1618 Project: Felix Issue Type: Bug Affects Versions: karaf-1.0.0 Reporter: Hans Couder Assignee: Gert Vanthienen Fix For: karaf-1.0.0 In the spring-dm feature, the spring-context bundle precedes spring-aop. This causes optional imports in the spring-context bundle won't get resolved resulting in: Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=org.apache.camel.camel-example-osgi, config=osgibundle:/META-INF/spring/*.xml)) java.lang.NoClassDefFoundError: org/springframework/aop/support/AopUtils at org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler.checkManagedBean(MetadataMBeanInfoAssembler.java:106) at org.springframework.jmx.export.assembler.AbstractMBeanInfoAssembler.getMBeanInfo(AbstractMBeanInfoAssembler.java:63) at org.apache.camel.management.DefaultManagementAgent.register(DefaultManagementAgent.java:202) at org.apache.camel.management.DefaultManagementAgent.register(DefaultManagementAgent.java:193) at org.apache.camel.management.ManagedManagementStrategy.manageNamedObject(ManagedManagementStrategy.java:68) at org.apache.camel.management.ManagedManagementStrategy.manageObject(ManagedManagementStrategy.java:61) at org.apache.camel.management.DefaultManagementLifecycleStrategy.onContextStart(DefaultManagementLifecycleStrategy.java:99) at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:918) at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:869) at org.apache.camel.spring.SpringCamelContext.maybeDoStart(SpringCamelContext.java:165) at org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:160) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:52) at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:832) at org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:99) at org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:119) at org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:516) at org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78) at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76) at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:274) at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:736) at org.springframework.osgi.context.support.AbstractOsgiBundleApplicationContext.finishRefresh(AbstractOsgiBundleApplicationContext.java:235) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:358) at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:136) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.ClassNotFoundException: *** Class 'org.springframework.aop.support.AopUtils' was not found because bundle 38 does not import 'org.springframework.aop.support' even though bundle 39 does export it. To resolve this issue, add an import for 'org.springframework.aop.support' to bundle 38. *** at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1645) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) ... 27 more Caused
[jira] Created: (FELIX-1602) Unable to configure boot features on admin:create-d instance
Unable to configure boot features on admin:create-d instance Key: FELIX-1602 URL: https://issues.apache.org/jira/browse/FELIX-1602 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 When using admin:create to create a new Felix Karaf instance, you can not configure the boot features by just editing the etc/org.apache.felix.karaf.features.cfg file for that instance. To reproduce: - start karaf - from the console, create a new instance with admin:create myinstance - edit the karaf_home/instances/myinstance/etc/org.apache.felix.karaf.features.cfg file - start the instance from the console with admin:start myinstance You'll notice that the instance starts fine but the boot features have not been installed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1602) Unable to configure boot features on admin:create-d instance
[ https://issues.apache.org/jira/browse/FELIX-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-1602. Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revrevision=815332 Thanks to Guillaume for the pointer! Unable to configure boot features on admin:create-d instance Key: FELIX-1602 URL: https://issues.apache.org/jira/browse/FELIX-1602 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 When using admin:create to create a new Felix Karaf instance, you can not configure the boot features by just editing the etc/org.apache.felix.karaf.features.cfg file for that instance. To reproduce: - start karaf - from the console, create a new instance with admin:create myinstance - edit the karaf_home/instances/myinstance/etc/org.apache.felix.karaf.features.cfg file - start the instance from the console with admin:start myinstance You'll notice that the instance starts fine but the boot features have not been installed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1485) Admin commands support in Karaf webconsole
[ https://issues.apache.org/jira/browse/FELIX-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-1485. Resolution: Fixed Fix Version/s: karaf-1.0.0 Assignee: Gert Vanthienen Patch has been applied in http://svn.apache.org/viewvc?view=revrevision=804868! @Marcin: Thanks a lot for providing this patch! Could you double-check if everything works as you intended and then close the issue? Admin commands support in Karaf webconsole -- Key: FELIX-1485 URL: https://issues.apache.org/jira/browse/FELIX-1485 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Marcin Wilkos Assignee: Gert Vanthienen Fix For: karaf-1.0.0 Attachments: FELIX-1485.patch We need a new tab in the console for the admin commands (create/destroy/start/stop). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Deploy snapshots from Bamboo
L.S., In order to get this working from Bamboo, we need to have our deploy credentials added to a settings.xml file on the Bamboo server. I've been in touch with one of the system administrators, but they are a bit reluctant to add this kind of information/files to their servers. Therefore, I would like to propose we keep Bamboo as our CI server, but setting up additional nightly builds for deploying snapshots on Apache's infrastructure. Personally, I'm very happy with the way the Hudson/Nexus combo at Apache works, so if nobody objects I'll set up nightlies for Apache Felix Karaf and whatever other bits of Felix that people would like to get nightly builds out for. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/7/17 Stuart McCulloch mccu...@gmail.com: 2009/7/14 Stuart McCulloch mccu...@gmail.com 2009/7/14 Gert Vanthienen gert.vanthie...@gmail.com Stuart, My Bamboo user id is gertv, I'll gladly help out setting things up (now or for future Felix projects). OK you should now be able to setup Karaf builds I'm also sending you the credentials, as you probably know your way around in Bamboo already to get this thing working. not sure about that, but I'll give it a go ;) just to follow-up... I wasn't able to find out where to add these credentials (I'm also away for next 2 weeks) hopefully you now have the access rights to add them, once you find out where they go! Thanks, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/7/13 Stuart McCulloch mccu...@gmail.com: 2009/7/14 Gert Vanthienen gert.vanthie...@gmail.com L.S., Ok, so let me try to ask this question the other way around then... Is there a way I could get access to the Bamboo server so I could setup CI builds for Karaf and get the credentials for deploying snapshots in place? if you sign up at http://opensource.bamboo.atlassian.com then I can give you access, alternatively send me the relevant details and I can update the build plans accordingly Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/7/10 Gert Vanthienen gert.vanthie...@gmail.com: L.S., In order to be able to deploy snapshots from our Bamboo CI server, I opened a JIRA for INFRA a while ago to get repository.apache.org set up for that. The issue has now been resolved and I have received the credentials to be used. I'm not sure who's taking care of configuring the Bamboo build server, but if you let me know I'll forward that information to him/her. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ -- Cheers, Stuart
Re: [OSS Bamboo] Apache Felix - Default build 2081 has FAILED (0 tests failed). Change made by rickhall
Richard, Seems to work fine on my machine as well... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/7/23 Richard S. Hall he...@ungoverned.org: Can anyone verify whether they are having difficulty building trunk? It is working for me locally. - richard On 7/23/09 9:20 AM, Atlassian Open Source Bamboo wrote: FELIX-DEF-2081 http://opensource.bamboo.atlassian.com/browse/FELIX-DEF-2081/ failed. Code has been updated by rickhall http://opensource.bamboo.atlassian.com/browse/author/rickhall. No failed tests found, a possible compilation error. Code Changes http://opensource.bamboo.atlassian.com/browse/FELIX-DEF-2081/commit See full change details http://opensource.bamboo.atlassian.com/browse/FELIX-DEF-2081/commit rickhall http://opensource.bamboo.atlassian.com/browse/author/rickhall Use OSGi R4.2 implementations of AdminPermission, FrameworkUtil, and FilterImpl. (FELIX-1404) Error Summary http://opensource.bamboo.atlassian.com/browse/FELIX-DEF-2081/log See full build log http://opensource.bamboo.atlassian.com/browse/FELIX-DEF-2081/log [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[24,26] package org.osgi.framework does not exist /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[25,26] package org.osgi.framework does not exist /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[26,26] package org.osgi.framework does not exist /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[27,35] package org.osgi.service.startlevel does not exist /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[29,38] cannot find symbol symbol: class BundleActivator public class AutoActivator implements BundleActivator /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[53,22] cannot find symbol symbol : class BundleContext location: class org.apache.felix.main.AutoActivator /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[62,21] cannot find symbol symbol : class BundleContext location: class org.apache.felix.main.AutoActivator /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[73,39] cannot find symbol symbol : class BundleContext location: class org.apache.felix.main.AutoActivator /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/Main.java:[28,26] package org.osgi.framework does not exist /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/Main.java:[29,33] package org.osgi.framework.launch does not exist /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/Main.java:[65,19] cannot find symbol symbol : class Framework location: class org.apache.felix.main.Main /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[77,8] cannot find symbol symbol : class StartLevel location: class org.apache.felix.main.AutoActivator /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[77,25] cannot find symbol symbol : class StartLevel location: class org.apache.felix.main.AutoActivator /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[78,67] package org.osgi.service.startlevel does not exist /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[121,20] cannot find symbol symbol : class Bundle location: class org.apache.felix.main.AutoActivator /opt/j2ee/domains/bamboo.atlassian.com/opensource/home/xml-data/build-dir/FELIX-DEF/main/src/main/java/org/apache/felix/main/AutoActivator.java:[144,24] cannot
[jira] Created: (FELIX-1391) Unable to create new ConfigAdmin PID through karaf console
Unable to create new ConfigAdmin PID through karaf console -- Key: FELIX-1391 URL: https://issues.apache.org/jira/browse/FELIX-1391 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 When creating a new PID through the the Karaf console, you get No configuration is being edited. Run the edit command first when trying to set a property value. ka...@root config:edit my.new.pid ka...@root config:propset key value No configuration is being edited. Run the edit command first -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1391) Unable to create new ConfigAdmin PID through karaf console
[ https://issues.apache.org/jira/browse/FELIX-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-1391. Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revrevision=796348 Unable to create new ConfigAdmin PID through karaf console -- Key: FELIX-1391 URL: https://issues.apache.org/jira/browse/FELIX-1391 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 When creating a new PID through the the Karaf console, you get No configuration is being edited. Run the edit command first when trying to set a property value. ka...@root config:edit my.new.pid ka...@root config:propset key value No configuration is being edited. Run the edit command first -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Deploy snapshots from Bamboo
L.S., Ok, so let me try to ask this question the other way around then... Is there a way I could get access to the Bamboo server so I could setup CI builds for Karaf and get the credentials for deploying snapshots in place? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/7/10 Gert Vanthienen gert.vanthie...@gmail.com: L.S., In order to be able to deploy snapshots from our Bamboo CI server, I opened a JIRA for INFRA a while ago to get repository.apache.org set up for that. The issue has now been resolved and I have received the credentials to be used. I'm not sure who's taking care of configuring the Bamboo build server, but if you let me know I'll forward that information to him/her. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Deploy snapshots from Bamboo
L.S., In order to be able to deploy snapshots from our Bamboo CI server, I opened a JIRA for INFRA a while ago to get repository.apache.org set up for that. The issue has now been resolved and I have received the credentials to be used. I'm not sure who's taking care of configuring the Bamboo build server, but if you let me know I'll forward that information to him/her. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Deploy a webconsole snapshot?
Felix, Thanks for taking care of this! I already had the server configuration in my settings.xml for deploying ActiveMQ, Camel and ServiceMix snapshots, but I can't deploy Felix snapshots with my user. Do you need to be a PMC member to be able to do this or should I ping reposit...@a.o to get this fixed? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/7/3 Felix Meschberger fmesc...@gmail.com: Hi, I have just don it. Deploying to the ASF m2-snapshot-repository should not be done anymore, since we carry all our artifacts on repository.a.o. To deploy to repository.a.o you have to configure the snapshot server in your settings.xml file: server idapache.snapshots.https/id usernamesvn-user-name/username passwordsvn-password/password /server This should do the trick (I don't know whether password encryption in the settings.xml file is already supported or not, I help myself by making the file read-only to me only (as a workaround)). HTH Regards Felix Guillaume Nodet schrieb: I can't do that either. But I guess deploying to http://people.apache.org/repo/m2-snapshot-repository should be doable. Not sure what's wrong with repository.a.o though ... On Fri, Jul 3, 2009 at 16:20, Gert Vanthienengert.vanthie...@gmail.com wrote: L.S., Could someone publish a Felix webconsole snapshot on repository.apache.org? I can't seem to do that for Apache Felix snapshots with my own user... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
[jira] Resolved: (FELIX-1261) Install/Uninstall Karaf Features from Felix WebConsole
[ https://issues.apache.org/jira/browse/FELIX-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen resolved FELIX-1261. Resolution: Fixed Fix Version/s: karaf-1.0.0 Assignee: Gert Vanthienen Thanks to Tim and Marcin for providing the patches! I have applied Tim's patch in http://svn.apache.org/viewvc?view=revrevision=790920 using the Blueprint descriptor that was already there to glue things together. Could you give it a spin and close this issue afterwards? Install/Uninstall Karaf Features from Felix WebConsole -- Key: FELIX-1261 URL: https://issues.apache.org/jira/browse/FELIX-1261 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Marcin Wilkos Assignee: Gert Vanthienen Fix For: karaf-1.0.0 Attachments: FELIX-1261-ExtendedFeaturesPlugin.patch, webconsole.patch Currently we can't Install/Uninstall Karaf Features from Felix WebConsole. In my Google Summer of Code project I created an Extension Plugin for web console, which lists Karaf Features and gives admin ability to manage them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Deploy a webconsole snapshot?
L.S., Could someone publish a Felix webconsole snapshot on repository.apache.org? I can't seem to do that for Apache Felix snapshots with my own user... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
[jira] Commented: (FELIX-1200) Move features-maven-plugin into Karaf
[ https://issues.apache.org/jira/browse/FELIX-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12719957#action_12719957 ] Gert Vanthienen commented on FELIX-1200: Initial move in http://svn.apache.org/viewvc?view=revrevision=785091 Move features-maven-plugin into Karaf - Key: FELIX-1200 URL: https://issues.apache.org/jira/browse/FELIX-1200 Project: Felix Issue Type: Task Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 The ServiceMix Kernel features-maven-plugin should be moved to Karaf as well. cfr. http://www.nabble.com/-karaf--Maven-Features-Plugin-...--to23899256.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
felix-parent 1.2.0 or felix 1.0.4
L.S., Which of these two POMs are we supposed to be using as a parent POM for Karaf? - org.apache.felix/felix/1.0.4 - org.apache.felix/felix-parent/1.2.0 We currently have the first one, but that is giving us a bit of a problem with the EasyMock 1.2 dependency it introduces while Karaf uses EasyMock 2.4. Since some of the more active subprojects have moved to the felix-parent pom, I suspect we should be using that one instead. Is that correct? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Deploying snapshots
Guillaume, You should be able to do that if you specify your svn username/password in the Maven settings.xml file (cfr. http://maven.apache.org/developers/committer-settings.html). We had a discussion about using Hudson/Nexus for doing regular snapshot releases a while ago, but we decided to stick with our current Bamboo CI server. There's a pending INFRA issue (https://issues.apache.org/jira/browse/INFRA-2085) for getting that box set up for snapshot releases. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/16 Guillaume Nodet gno...@gmail.com: I'd like to deploy snapshots of framework / main onto the snapshot repository. What's the way to do this ? Atm, I end up with the following error: [INFO] Error deploying artifact: Failed to transfer file: https://repository.apache.org/content/repositories/snapshots/org/apache/felix/org.apache.felix.framework/1.9.0-SNAPSHOT/org.apache.felix.framework-1.9.0-20090616.082913-1.jar. Return code is: 401 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: felix-parent 1.2.0 or felix 1.0.4
Thanks Karl for confirming that! It also got rid of my EasyMock problem. Thanks, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/16 Karl Pauls karlpa...@gmail.com: On Tue, Jun 16, 2009 at 10:09 AM, Gert Vanthienengert.vanthie...@gmail.com wrote: L.S., Which of these two POMs are we supposed to be using as a parent POM for Karaf? - org.apache.felix/felix/1.0.4 - org.apache.felix/felix-parent/1.2.0 We currently have the first one, but that is giving us a bit of a problem with the EasyMock 1.2 dependency it introduces while Karaf uses EasyMock 2.4. Since some of the more active subprojects have moved to the felix-parent pom, I suspect we should be using that one instead. Is that correct? Yes. We now do our releases using nexus and for that you need 1.2.0 anyways. regards, Karl Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ -- Karl Pauls karlpa...@gmail.com
[jira] Closed: (FELIX-1200) Move features-maven-plugin into Karaf
[ https://issues.apache.org/jira/browse/FELIX-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen closed FELIX-1200. -- Resolution: Fixed Aligned it with the rest of Felix Karaf and removed some more references to servicemix kernel in http://svn.apache.org/viewvc?view=revrevision=785170 Move features-maven-plugin into Karaf - Key: FELIX-1200 URL: https://issues.apache.org/jira/browse/FELIX-1200 Project: Felix Issue Type: Task Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 The ServiceMix Kernel features-maven-plugin should be moved to Karaf as well. cfr. http://www.nabble.com/-karaf--Maven-Features-Plugin-...--to23899256.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Deploying snapshots
Richard, I don't think you can use a system variable or something like that to replace the settings password with Maven 2.0.x, but starting with Maven 2.1.x you can encrypt the passwords so they no longer have to be stored in plain text in your settings.xml file. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/16 Richard S. Hall he...@ungoverned.org: Yeah, I wanted to deploy snapshots of them and some others too, but it wasn't working for me as well. Is this the only way? I prefer to type in my password... - richard On 6/16/09 4:48 AM, Gert Vanthienen wrote: Guillaume, You should be able to do that if you specify your svn username/password in the Maven settings.xml file (cfr. http://maven.apache.org/developers/committer-settings.html). We had a discussion about using Hudson/Nexus for doing regular snapshot releases a while ago, but we decided to stick with our current Bamboo CI server. There's a pending INFRA issue (https://issues.apache.org/jira/browse/INFRA-2085) for getting that box set up for snapshot releases. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/16 Guillaume Nodetgno...@gmail.com: I'd like to deploy snapshots of framework / main onto the snapshot repository. What's the way to do this ? Atm, I end up with the following error: [INFO] Error deploying artifact: Failed to transfer file: https://repository.apache.org/content/repositories/snapshots/org/apache/felix/org.apache.felix.framework/1.9.0-SNAPSHOT/org.apache.felix.framework-1.9.0-20090616.082913-1.jar. Return code is: 401 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code
Felix, You're right about the dependencies obviously: the plugin bundle would need to depend on the JAXRS API but the web console itself would depend on the API and some implementation like Jersey. That would be the biggest disadvantage in my mind, because at this point in time the felix web console is a very lightweight solution that doesn't need any dependencies. On the other hand, this solution would give us some benefits as well. The JAXRS bean I mentioned is just a POJO with methods and annotations. This will map the methods to URIs, allowing us to easily provide multiple uris from a single plugin. So we can have methods there for serving the main page content but others could handle POSTs or serve JSON or XML. As for rendering the reponse, you can still do that using a plain PrintWriter as we do in the Servlets now if we want a lightweight plugin, but it would also become possible use another kind of view technology (e.g. JSP or Lift templates) if people prefer that or to serve other kinds of resources (images, css style sheets, ...) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Gert Vanthienen schrieb: L.S., How about adding support for using JAX-RS resource beans for extending the felix web console? So instead of registering a servlet, you can register a JAX-RS bean. One of the methods on the bean can be used to render the 'main' contents of the web console plugin page, but you can also add other methods and annotate them with GET/POST for providing JSON resources or handling form submits. This will also remove the dependency on the felix web console bundle for the extension bundle while making it easier to implement multiple uris/actions without having to override the doGet/doPost methods and allow us to use some other template engine/language (JSP, Lift, ...) in the extension bundle without the need for the felix web console to be aware of those. The only real drawback I see is the fact that the Felix Web Console bundle itself would get another dependency, it would need the JAX-RS API. Wdyt? What else would be required ? Wouldn't we need an implementation of the API to glue this all together? What do you mean by register a JAX-RS bean ? IMHO registering a javax.servlet.Service is very appropriate in the OSGi context. Regards Felix Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting
Re: Google Summer of Code
Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code
Felix, Like I said, I really do get your point about the dependencies. Not sure I follow with the argument that it would lock the console into a single presentation technology, because you can plugin different view technologies into jersey and at this point in time, the only view technology that's available for the web console plugins is using a plain Servlet. My suggestion would be to put the JAX-RS bean in the OSGi Service Registry, just like we to with the Servlet right now. However, I do like your suggestion for somehow building a bridge and hide the entire view technology behind the Servlet (which is what almost all view technologies eventually boil down to anyway). This would require us to get the brandability issue solved, so we no longer need to work with the AbstractConsolePlugin to draw the headers. So I guess it would make sense to make that the next task item on Marcin's list. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/10 Felix Meschberger fmesc...@gmail.com: Hi Gert Gert Vanthienen schrieb: Felix, You're right about the dependencies obviously: the plugin bundle would need to depend on the JAXRS API but the web console itself would depend on the API and some implementation like Jersey. That would be the biggest disadvantage in my mind, because at this point in time the felix web console is a very lightweight solution that doesn't need any dependencies. That is exactly one of my biggest issues ... In addition it would lock the console into a single presentation technology. There are others like JSF, Apache Sling, Wicket, etc. These would all be left out of the door. Honestly, I don't like the idea of adding Jersey to an OSGi framework just for the sake of the Web Console. This does not sound right. On the other hand, this solution would give us some benefits as well. The JAXRS bean I mentioned is just a POJO with methods and annotations. This will map the methods to URIs, allowing us to easily provide multiple uris from a single plugin. So we can have methods there for serving the main page content but others could handle POSTs or serve JSON or XML. I understand and agree. But you said *register* a JAX-RS bean. Where would that bean be registered ? As for rendering the reponse, you can still do that using a plain PrintWriter as we do in the Servlets now if we want a lightweight plugin, but it would also become possible use another kind of view technology (e.g. JSP or Lift templates) if people prefer that or to serve other kinds of resources (images, css style sheets, ...) Sure, I completely agree, that supporting other rendering technology (I, of course have a slight bias towards Apache Sling ;-) ) would be nice. But this should IMHO be possible without tying the Web Console to all these technologies. I opt for keeping the Web Console lightweight defining a simple API for extensions. To connect with other rendering technology, bridges could be defined. For example a Jersey bridge, which proxies JAX-RS beans into the Web Console registering proxy Servlets on behalf of the JAX-RS beans. Regards Felix Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Gert Vanthienen schrieb: L.S., How about adding support for using JAX-RS resource beans for extending the felix web console? So instead of registering a servlet, you can register a JAX-RS bean. One of the methods on the bean can be used to render the 'main' contents of the web console plugin page, but you can also add other methods and annotate them with GET/POST for providing JSON resources or handling form submits. This will also remove the dependency on the felix web console bundle for the extension bundle while making it easier to implement multiple uris/actions without having to override the doGet/doPost methods and allow us to use some other template engine/language (JSP, Lift, ...) in the extension bundle without the need for the felix web console to be aware of those. The only real drawback I see is the fact that the Felix Web Console bundle itself would get another dependency, it would need the JAX-RS API. Wdyt? What else would be required ? Wouldn't we need an implementation of the API to glue this all together? What do you mean by register a JAX-RS bean ? IMHO registering a javax.servlet.Service is very appropriate in the OSGi context. Regards Felix Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears
Re: Google Summer of Code
Juanjo, Yeah, sorry about that. Jersey was just an example but obviously CXF JAX-RS would be a great alternative to that ;) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/10 Juan José Vázquez Delgado juanjo.vazq...@gmail.com: You're right about the dependencies obviously: the plugin bundle would need to depend on the JAXRS API but the web console itself would depend on the API and some implementation like Jersey. Just a point, why Jersey? What about Apache CXF JAX-RS implementation [1]? [1] http://cwiki.apache.org/CXF20DOC/jax-rs.html Juanjo.
Re: Google Summer of Code
L.S., How about adding support for using JAX-RS resource beans for extending the felix web console? So instead of registering a servlet, you can register a JAX-RS bean. One of the methods on the bean can be used to render the 'main' contents of the web console plugin page, but you can also add other methods and annotate them with GET/POST for providing JSON resources or handling form submits. This will also remove the dependency on the felix web console bundle for the extension bundle while making it easier to implement multiple uris/actions without having to override the doGet/doPost methods and allow us to use some other template engine/language (JSP, Lift, ...) in the extension bundle without the need for the felix web console to be aware of those. The only real drawback I see is the fact that the Felix Web Console bundle itself would get another dependency, it would need the JAX-RS API. Wdyt? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSL the world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man. George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: [karaf] propappend ...?
Robert, Thanks for the suggestion! Yeah, that would be a useful addition, so we would definitely welcome a patch for that. Instead of config/propappend we could also add a parameter to propset, something like config/propset -a . Wdyt? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/7 Robert Burrell Donkin robertburrelldon...@gmail.com: some properties consist of a comma separated list of values (for example, 'org.ops4j.pax.url.mvn.repositories'). for these properties, it would be useful to be able to append to the current value (for example, ',http://example.org/repos/m2') without having to cut and paste using proplist and propset. does this already exist? if not, should i code up a patch? - robert
Re: [karaf] Maven Features Plugin ...?
Robert, That plugin does not have any ServiceMix-specific functions -- it was built to work with the ServiceMix Kernel features XML files so it would make a lot of sense to move that into Karaf. Given that we already have issues raised in Felix JIRA for this plugin, I think this has probably been the plan from the beginning, although this has not been explicitly communicated anywhere. Just created https://issues.apache.org/jira/browse/FELIX-1200 to track that task. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/6 Robert Burrell Donkin robertburrelldon...@gmail.com: the servicemix maven features plugin looks like it might be really useful for Karaf 1. is it possible to separate the servicemix specific functions? 2. are there any plans to move, fork or split the plugin into karaf? - robert
[jira] Created: (FELIX-1200) Move features-maven-plugin into Karaf
Move features-maven-plugin into Karaf - Key: FELIX-1200 URL: https://issues.apache.org/jira/browse/FELIX-1200 Project: Felix Issue Type: Task Reporter: Gert Vanthienen Assignee: Gert Vanthienen Fix For: karaf-1.0.0 The ServiceMix Kernel features-maven-plugin should be moved to Karaf as well. cfr. http://www.nabble.com/-karaf--Maven-Features-Plugin-...--to23899256.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1121) Add feature for installing Felix Web Console
[
https://issues.apache.org/jira/browse/FELIX-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved FELIX-1121.
Resolution: Fixed
Fix Version/s: karaf-1.0.0
Assignee: Gert Vanthienen
Thanks to Tim Moloney for providing the sample feature descriptor!
The new feature has been added to the main Karaf features file in
http://svn.apache.org/viewvc?view=revrevision=782239.
This will allow you to do a *{{features/install webconsole}}* to get the
console up and running.
Could you close this issue if this works for you, thanks?
Add feature for installing Felix Web Console
-
Key: FELIX-1121
URL: https://issues.apache.org/jira/browse/FELIX-1121
Project: Felix
Issue Type: Improvement
Components: Karaf
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
Fix For: karaf-1.0.0
Attachments: webconsole-feature.xml
The Felix Web Console can be installed on ServiceMix Kernel with these
commands:
- features/addUrl
mvn:org.apache.servicemix/apache-servicemix/4.0.0/xml/features
- features/install web
- osgi/install -s mvn:org.apache.felix/org.apache.felix.webconsole/1.2.8
We should make it easier for people to install it using a single command.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1196) Felix Web Console can't list Karaf features
[
https://issues.apache.org/jira/browse/FELIX-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved FELIX-1196.
Resolution: Fixed
Fix Version/s: karaf-1.0.0
Assignee: Gert Vanthienen
Thanks to Marcin Wilkos for this patch!
It has been integrated in Karaf in
http://svn.apache.org/viewvc?view=revrevision=782261. I have also added this
bundle to the *{{webconsole}}* feature, so it is installed automatically when
you do a *{{features/install webconsole}}*.
Could you check if this fixes the issue for you and close this issue if it's
OK? Thanks!
Felix Web Console can't list Karaf features
---
Key: FELIX-1196
URL: https://issues.apache.org/jira/browse/FELIX-1196
Project: Felix
Issue Type: Improvement
Components: Karaf
Reporter: Marcin Wilkos
Assignee: Gert Vanthienen
Fix For: karaf-1.0.0
Attachments: webconsole.patch
Original Estimate: 24h
Remaining Estimate: 24h
Web console should be extended by plugin, which will make possible listing
Karaf features.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Publishing Karaf snapshots
L.S., We would like to start using Karaf for building ServiceMix 4, but we need Karaf snapshots for this. In the ServiceMix project, we are using Apache's Hudson/Nexus combo to publish snapshots, but I don't see any Felix projects in there yet. There are some snapshot in the 'old' location http://people.apache.org/repo/m2-snapshot-repository. What is the normal Felix procedure we need to follow to get these snapshots out there or would it be OK for Apache Felix Karaf to keep on using Hudson/Nexus? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Publishing Karaf snapshots
L.S., No practical experience myself either, but I don't think a CI tool like Hudson is anyhow involved in the release process. For snapshot deployment, all the Apache CI servers have been setup with the correct credentials to allow you to do so. The last I heard about, there was a little bit of extra setup required for other servers. If we want to use Bamboo for building nightly snapshots as well, I'll raise an infra jira issue to get it set up. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/5 Marcel Offermans marcel.offerm...@luminis.nl: Same here, I have not done a release with it either. Perhaps someone else can share some experiences here. I would say, in theory, we should be able to deploy snapshots with just invoking some maven goal that could be run on any build server (or from the command line). On Jun 5, 2009, at 9:52 , Guillaume Nodet wrote: Right, I think I conflated two different things. I don't see why bamboo could not be used to deploy to nexus. I haven't done any release yet, so I'm quite unclear on the process, so the question is wether bamboo or hudson has some role in the release process or do we have to manually deploy to nexus ? If one of those helps in the release process, then maybe it could be worth investigating if we should use it, and if yes, it might make sense to use it to deploy nightly builds too. On Fri, Jun 5, 2009 at 18:39, Marcel Offermansmarcel.offerm...@luminis.nl wrote: Why would we want to switch build servers if you want to publish snapshots? Isn't there just a maven command to do that? On Jun 5, 2009, at 9:10 , Guillaume Nodet wrote: Don't we use nexus for releases now ? It would make sense to use it for snapshots too imho. On Fri, Jun 5, 2009 at 18:00, Marcel Offermansmarcel.offerm...@luminis.nl wrote: On Jun 5, 2009, at 3:04 , Gert Vanthienen wrote: We would like to start using Karaf for building ServiceMix 4, but we need Karaf snapshots for this. In the ServiceMix project, we are using Apache's Hudson/Nexus combo to publish snapshots, but I don't see any Felix projects in there yet. We are using the Bamboo build server for our builds. We don't automatically have it publish snapshots, but I'm sure that can be added. See: http://opensource.bamboo.atlassian.com/browse/FELIX-DEF Greetings, Marcel -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code: Marcin Wilkos
L.S., Using the optional import by default (for quick and easy branding) and documenting how to build a more 'safe' branding by unzipping the distro and hacking it to remove the optional imports sounds like a good compromise to me. Having something like goosh.org for our own console inside the web console sounds like a great idea too. For securing the web console, wouldn't it make sense to integrate that with Karaf's JAAS support, so we can plug in other providers afterwards (e.g. things like LDAP)? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/5/26 Guillaume Nodet gno...@gmail.com: On Tue, May 26, 2009 at 11:00, Carsten Ziegeler cziege...@apache.org wrote: Filippo Diotalevi wrote: On Tue, May 26, 2009 at 8:11 AM, Gert Vanthienen gert.vanthie...@gmail.com wrote: L.S., Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. That's very interesting. I think some starting points might be http://issues.apache.org/jira/browse/FELIX-1013 (umbrella issue for web console extensibility) http://issues.apache.org/jira/browse/FELIX-1051 (localization support) We had some discussions on this topic, but never really got to the point to implement it (just because of lack of time :) ). I've been thinking about this lately and I'm more and more thinking about not using an optional import. Rebranding something is usely meant that it stays rebranded, like if you want to bundle the web console with your own product. It is too easy to uninstall the optional bundle. You're right to some degree. I'd like the console to be branded with Karaf, while people using Karaf may want to rebrand it too. Rebranding Karaf also means rebranding the Karaf shell and both should be able to be done easily and I don't think unzipping karaf distribution and hacking more than one bundle is an easy way. So I think we need a safer way. We also had the discussion (and I think there is a jira issue for this as well), to configure which configuration tabs are available - you might not want to use the tab for the config admin which comes with the web console - or you want to disable the obr tab etc. Again this could be done with some configuration and/or optional importants but can be easily overriden which is not what you want. So to keep the long story short, I'm more in favour of customization at build time, you create your project, which depends on the web console and it just adds additional files, overwrites configs (whatever) and creates your web console bundle. Maybe there is a better way inbetween those two solutions? If we use an optional import, people wanting to safely rebrand the console without allowing people to modify it could still choose to repackage the web console bundle by putting customized resources directly into it and remove this optional import, right ? Btw, I also think that we should secure the web console and check the role of the current user for authorization purposes. Right. I think at some point we also want to add access to the shell through the web console and we also need to secure the shell commands. Hiram and I did some experiment some time ago, but it was based on a gwt web console, so it will need to be rewritten. Such a shell could provided access to other shell commands for admin confortable with command lines. Carsten -- Carsten Ziegeler cziege...@apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code: Marcin Wilkos
L.S., From now on, you can expect a weekly report on the mailing lists from Marcin about his progress (as well as probably a lot of other mails with questions/remarks/... ;)). You can also follow his work on http://twitter.com/mwilkos Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/5/26 Gert Vanthienen gert.vanthie...@gmail.com: L.S., Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. We would definitely consider building this on top the Felix Web Console. It already has some of the functionality we're looking for and it already is extensible -- there some information on the Felix website [2] and I know the Sling project has built some extensions to the console, so we can find a code example there. Is there any other information around for this? Are there any limitations we have to be aware of before starting the project? I guess we already know about one such limitation: Apache Felix Karaf has the ability to 'rebrand' the text console with another ASCII art logo and header, so we would want that for the web console as well. As far as I can see, this is not yet supported by the Felix Web Console. Are there any plans to support that? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ [1] http://www.nabble.com/%22Web-based-management-console-for-ServiceMix%22-proposal-for-Google--Summer-of-Code-2009-td22967846ef12049.html#a22967846 [2] http://felix.apache.org/site/apache-felix-web-console.html
Google Summer of Code: Marcin Wilkos
L.S., Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. We would definitely consider building this on top the Felix Web Console. It already has some of the functionality we're looking for and it already is extensible -- there some information on the Felix website [2] and I know the Sling project has built some extensions to the console, so we can find a code example there. Is there any other information around for this? Are there any limitations we have to be aware of before starting the project? I guess we already know about one such limitation: Apache Felix Karaf has the ability to 'rebrand' the text console with another ASCII art logo and header, so we would want that for the web console as well. As far as I can see, this is not yet supported by the Felix Web Console. Are there any plans to support that? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ [1] http://www.nabble.com/%22Web-based-management-console-for-ServiceMix%22-proposal-for-Google--Summer-of-Code-2009-td22967846ef12049.html#a22967846 [2] http://felix.apache.org/site/apache-felix-web-console.html
[jira] Resolved: (FELIX-1125) features/list -i returns ERROR CommandLineExecutionFailed: org.apache.geronimo.gshell.command.CommandException: java.lang.ArrayStoreException: org.apache.servicemix.ke
[
https://issues.apache.org/jira/browse/FELIX-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen resolved FELIX-1125.
Resolution: Fixed
Tim,
I think this bug was fixed just before ServiceMix Kernel became Apache Felix
Karaf (cfr. https://issues.apache.org/activemq/browse/SMX4KNL-266)
Regards,
Gert
features/list -i returns ERROR CommandLineExecutionFailed:
org.apache.geronimo.gshell.command.CommandException:
java.lang.ArrayStoreException:
org.apache.servicemix.kernel.gshell.features.internal.FeatureImpl
Key: FELIX-1125
URL: https://issues.apache.org/jira/browse/FELIX-1125
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.0.0
Environment: java version 1.6.0_13
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)
Reporter: Tim Moloney
The bug can be replicated as follows:
bash tar zxf apache-servicemix-kernel-1.1.0.tar.gz
bash cd apache-servicemix-kernel-1.1.0
bash cat webconsole-feature.xmlEOF
features
feature name=webconsole version=0.1.0-SNAPSHOT
bundlemvn:org.mortbay.jetty/jetty-util/6.1.11/jar/bundle
bundlemvn:org.mortbay.jetty/jetty-sslengine/6.1.11/jar/bundle
bundlemvn:org.mortbay.jetty/jetty/6.1.11/jar/bundle
bundlemvn:org.apache.felix/org.apache.felix.http.jetty/1.0.0/jar/bundle
config name=org.apache.felix.http
org.osgi.service.http.port=8080
/config
bundlemvn:org.apache.felix/org.apache.felix.webconsole/1.2.8/jar/bundle
config name=org.apache.felix.webconsole.internal.servlet.OsgiManager
username=tester
password=testing
/config
/feature
/features
EOF
bash bin/servicemix
_ __ __ _
/ ___| ___ _ _(_) ___ ___| \/ (_)_ __
\___ \ / _ \ '__\ \ / / |/ __/ _ \ |\/| | \ \/ /
___) | __/ | \ V /| | (_| __/ | | | |
|/ \___|_|\_/ |_|\___\___|_| |_|_/_/\_\
ServiceMix Kernel (1.1.0)
Type 'help' for more information.
---
s...@root:/ cp webconsole-feature.xml deploy
s...@root:/ features/list -i
ERROR CommandLineExecutionFailed:
org.apache.geronimo.gshell.command.CommandException:
java.lang.ArrayStoreException:
org.apache.servicemix.kernel.gshell.features.internal.FeatureImpl
s...@root:/ log/display-exception
s...@root:/ log/display
...
10:45:12,919 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 64 | Executing (String): features/list -i
10:45:12,920 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 104 | Executing (features/list): [-i]
10:46:19,302 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 64 | Executing (String):
log/display-exception
10:46:19,303 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 104 | Executing (log/display-exception): []
10:46:25,709 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 64 | Executing (String): log/display
10:46:25,711 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 104 | Executing (log/display): []
s...@root:/ osgi/shutdown
s...@root:/ bash
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1125) features/list -i returns ERROR CommandLineExecutionFailed: org.apache.geronimo.gshell.command.CommandException: java.lang.ArrayStoreException: org.apache.servicemix.ker
[
https://issues.apache.org/jira/browse/FELIX-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen updated FELIX-1125:
---
Fix Version/s: karaf-1.0.0
features/list -i returns ERROR CommandLineExecutionFailed:
org.apache.geronimo.gshell.command.CommandException:
java.lang.ArrayStoreException:
org.apache.servicemix.kernel.gshell.features.internal.FeatureImpl
Key: FELIX-1125
URL: https://issues.apache.org/jira/browse/FELIX-1125
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: karaf-1.0.0
Environment: java version 1.6.0_13
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)
Reporter: Tim Moloney
Fix For: karaf-1.0.0
The bug can be replicated as follows:
bash tar zxf apache-servicemix-kernel-1.1.0.tar.gz
bash cd apache-servicemix-kernel-1.1.0
bash cat webconsole-feature.xmlEOF
features
feature name=webconsole version=0.1.0-SNAPSHOT
bundlemvn:org.mortbay.jetty/jetty-util/6.1.11/jar/bundle
bundlemvn:org.mortbay.jetty/jetty-sslengine/6.1.11/jar/bundle
bundlemvn:org.mortbay.jetty/jetty/6.1.11/jar/bundle
bundlemvn:org.apache.felix/org.apache.felix.http.jetty/1.0.0/jar/bundle
config name=org.apache.felix.http
org.osgi.service.http.port=8080
/config
bundlemvn:org.apache.felix/org.apache.felix.webconsole/1.2.8/jar/bundle
config name=org.apache.felix.webconsole.internal.servlet.OsgiManager
username=tester
password=testing
/config
/feature
/features
EOF
bash bin/servicemix
_ __ __ _
/ ___| ___ _ _(_) ___ ___| \/ (_)_ __
\___ \ / _ \ '__\ \ / / |/ __/ _ \ |\/| | \ \/ /
___) | __/ | \ V /| | (_| __/ | | | |
|/ \___|_|\_/ |_|\___\___|_| |_|_/_/\_\
ServiceMix Kernel (1.1.0)
Type 'help' for more information.
---
s...@root:/ cp webconsole-feature.xml deploy
s...@root:/ features/list -i
ERROR CommandLineExecutionFailed:
org.apache.geronimo.gshell.command.CommandException:
java.lang.ArrayStoreException:
org.apache.servicemix.kernel.gshell.features.internal.FeatureImpl
s...@root:/ log/display-exception
s...@root:/ log/display
...
10:45:12,919 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 64 | Executing (String): features/list -i
10:45:12,920 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 104 | Executing (features/list): [-i]
10:46:19,302 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 64 | Executing (String):
log/display-exception
10:46:19,303 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 104 | Executing (log/display-exception): []
10:46:25,709 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 64 | Executing (String): log/display
10:46:25,711 | INFO | localShell | CommandLineExecutorImpl |
om.shell.CommandLineExecutorImpl 104 | Executing (log/display): []
s...@root:/ osgi/shutdown
s...@root:/ bash
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1121) Add feature for installing Felix Web Console
Add feature for installing Felix Web Console
-
Key: FELIX-1121
URL: https://issues.apache.org/jira/browse/FELIX-1121
Project: Felix
Issue Type: Improvement
Components: Karaf
Reporter: Gert Vanthienen
The Felix Web Console can be installed on ServiceMix Kernel with these commands:
{noformat}
- features/addUrl mvn:org.apache.servicemix/apache-servicemix/4.0.0/xml/features
- features/install web
- osgi/install -s mvn:org.apache.felix/org.apache.felix.webconsole/1.2.8
{noformat}
We should make it easier for people to install it using a single command.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1121) Add feature for installing Felix Web Console
[
https://issues.apache.org/jira/browse/FELIX-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen updated FELIX-1121:
---
Description:
The Felix Web Console can be installed on ServiceMix Kernel with these commands:
- features/addUrl mvn:org.apache.servicemix/apache-servicemix/4.0.0/xml/features
- features/install web
- osgi/install -s mvn:org.apache.felix/org.apache.felix.webconsole/1.2.8
We should make it easier for people to install it using a single command.
was:
The Felix Web Console can be installed on ServiceMix Kernel with these commands:
{noformat}
- features/addUrl mvn:org.apache.servicemix/apache-servicemix/4.0.0/xml/features
- features/install web
- osgi/install -s mvn:org.apache.felix/org.apache.felix.webconsole/1.2.8
{noformat}
We should make it easier for people to install it using a single command.
Add feature for installing Felix Web Console
-
Key: FELIX-1121
URL: https://issues.apache.org/jira/browse/FELIX-1121
Project: Felix
Issue Type: Improvement
Components: Karaf
Reporter: Gert Vanthienen
The Felix Web Console can be installed on ServiceMix Kernel with these
commands:
- features/addUrl
mvn:org.apache.servicemix/apache-servicemix/4.0.0/xml/features
- features/install web
- osgi/install -s mvn:org.apache.felix/org.apache.felix.webconsole/1.2.8
We should make it easier for people to install it using a single command.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1116) Rename to Apache Felix Karaf
Rename to Apache Felix Karaf Key: FELIX-1116 URL: https://issues.apache.org/jira/browse/FELIX-1116 Project: Felix Issue Type: Task Components: Karaf Reporter: Gert Vanthienen Fix For: karaf-1.0.0 Now that the ServiceMix Kernel sources have been copied to Felix, we need to start renaming things: - package names should become org.apache.felix.karaf.* - POM group and artifact IDs should be changed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1116) Rename to Apache Felix Karaf
[ https://issues.apache.org/jira/browse/FELIX-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705329#action_12705329 ] Gert Vanthienen commented on FELIX-1116: The bulk of the changes have been done in http://svn.apache.org/viewvc?limit_changes=0view=revrevision=770981. Some bits that remain are: - change the branding (the ascii art and the info that shows up when you start the product) - change the name of the commands in the bin folder Rename to Apache Felix Karaf Key: FELIX-1116 URL: https://issues.apache.org/jira/browse/FELIX-1116 Project: Felix Issue Type: Task Components: Karaf Reporter: Gert Vanthienen Fix For: karaf-1.0.0 Now that the ServiceMix Kernel sources have been copied to Felix, we need to start renaming things: - package names should become org.apache.felix.karaf.* - POM group and artifact IDs should be changed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
