Re: [VOTE] Felix 1.6.1 framework and main subproject releases
+1 Thanks for preparing. Regards Felix Karl Pauls schrieb: I would like to call a vote on the framework and main 1.6.1 subproject releases. The source and binary release archives, signature files, SHA and MD5 message digests for each are available as zip and tar.gz here: http://people.apache.org/~pauls/1.6.1 Additionally, a binary release is included (called felix-1.6.1). Please vote to approve these release archives: [ ] +1 Approve the releases [ ] -1 Veto the releases (please provide specific comments)
Re: [VOTE] Felix 1.6.1 framework and main subproject releases
+1 - richard On 4/26/09 5:48 PM, Karl Pauls wrote: I would like to call a vote on the framework and main 1.6.1 subproject releases. The source and binary release archives, signature files, SHA and MD5 message digests for each are available as zip and tar.gz here: http://people.apache.org/~pauls/1.6.1 Additionally, a binary release is included (called felix-1.6.1). Please vote to approve these release archives: [ ] +1 Approve the releases [ ] -1 Veto the releases (please provide specific comments)
[jira] Created: (FELIX-1060) URLHandlers doesn't support URLStreamHandler.openConnection(proxy,url) method
URLHandlers doesn't support URLStreamHandler.openConnection(proxy,url) method - Key: FELIX-1060 URL: https://issues.apache.org/jira/browse/FELIX-1060 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: felix-1.6.1 Reporter: Richard S. Hall Assignee: Karl Pauls Fix For: felix-1.8.0 JDK 1.5 introduced a URLStreamHandler.openConnection(proxy, url) method. Currently, our URL Handlers implementation does not support this at all. We need to figure out how to support it without creating a dependency on 1.5. The spec talks about this issue in 11.3.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1000) Updating an bundle which was installed via OBR fails
[ https://issues.apache.org/jira/browse/FELIX-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-1000: --- Affects Version/s: bundlerepository-1.2.1 Fix Version/s: bundlerepository-1.4.0 Assignee: Richard S. Hall Updating an bundle which was installed via OBR fails Key: FELIX-1000 URL: https://issues.apache.org/jira/browse/FELIX-1000 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.2.1 Reporter: Kristian Koehler Assignee: Richard S. Hall Fix For: bundlerepository-1.4.0 Attachments: FELIX-1000-21_04_2009.patch.txt, FELIX-1000-23_04_2009.patch.txt, FELIX-1000-27_04_2009.patch.txt Updating an bundle which was installed via the obr functionality results in an exception (update was triggered via the shell): --- 8 --- java.net.MalformedURLException: Unknown protocol: obr at java.net.URL.init(URL.java:601) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:149) at org.apache.felix.framework.cache.JarRevision.init(JarRevision.java:78) at org.apache.felix.framework.cache.JarRevision.init(JarRevision.java:56) at org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:986) at org.apache.felix.framework.cache.BundleArchive.revise(BundleArchive.java:614) at org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:916) at org.apache.felix.framework.Felix.updateBundle(Felix.java:1592) at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:792) at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:779) at org.apache.felix.shell.impl.UpdateCommandImpl.execute(UpdateCommandImpl.java:96) at org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276) at org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:167) at java.lang.Thread.run(Thread.java:619) --- 8 --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1061) [PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName header
[ https://issues.apache.org/jira/browse/FELIX-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated FELIX-1061: --- Attachment: FELIX-1061.patch [PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName header Key: FELIX-1061 URL: https://issues.apache.org/jira/browse/FELIX-1061 Project: Felix Issue Type: Bug Components: Web Console Reporter: Bertrand Delacretaz Priority: Minor Attachments: FELIX-1061.patch Trying to install a bundle which has no Bundle-SymbolicName header silently fails with the current console, there no error report in the log or in the web browser. Other exceptions during bundle installation are also invisible from the console web interface, they are only logged. With the attached patch, exceptions during bundle installation cause a 500 HTTP status and exception report in the web browser, and the InstallAction throws an IOException if a bundle has no Bundle-SymbolicName. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1061) [PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName header
[ https://issues.apache.org/jira/browse/FELIX-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-1061: Remaining Estimate: 0h Original Estimate: 0h Hi Bertrand, I've applied your patch in revision: 769372. Please cross check and close this bug. Thanks! [PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName header Key: FELIX-1061 URL: https://issues.apache.org/jira/browse/FELIX-1061 Project: Felix Issue Type: Bug Components: Web Console Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Attachments: FELIX-1061.patch Original Estimate: 0h Remaining Estimate: 0h Trying to install a bundle which has no Bundle-SymbolicName header silently fails with the current console, there no error report in the log or in the web browser. Other exceptions during bundle installation are also invisible from the console web interface, they are only logged. With the attached patch, exceptions during bundle installation cause a 500 HTTP status and exception report in the web browser, and the InstallAction throws an IOException if a bundle has no Bundle-SymbolicName. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1061) [PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName header
[PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName header Key: FELIX-1061 URL: https://issues.apache.org/jira/browse/FELIX-1061 Project: Felix Issue Type: Bug Components: Web Console Reporter: Bertrand Delacretaz Priority: Minor Trying to install a bundle which has no Bundle-SymbolicName header silently fails with the current console, there no error report in the log or in the web browser. Other exceptions during bundle installation are also invisible from the console web interface, they are only logged. With the attached patch, exceptions during bundle installation cause a 500 HTTP status and exception report in the web browser, and the InstallAction throws an IOException if a bundle has no Bundle-SymbolicName. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Karaf] Moving Karaf svn into Felix
Great ! Seems the discussion is over, so we should now think about executing this plan. Any volunteer ? On Mon, Apr 27, 2009 at 13:36, Guillaume Nodet gno...@gmail.com wrote: Ok, I'm not really convinced, but since it seems there is a lot of reluctance I think we should aim for: * packages in org.apache.felix.karaf * use existing FELIX infrastructure (mailing list, jira tracker, confluence space) I think we should start with the above and reconsider later if there is a need. Is everyone satisfied with the above ? On Mon, Apr 27, 2009 at 12:17, Karl Pauls karlpa...@gmail.com wrote: I think we should start with the FELIX infra and then see whether we need to create a new one when the need is there. About the package renaming, I'm in favour of going with org.apache.felix.karaf just because it emphasizes that felix is not about the framework. If we make an exception then this sends a strange message IMO. regards, Karl On Mon, Apr 27, 2009 at 12:11 PM, Richard S. Hall he...@ungoverned.org wrote: On 4/27/09 6:07 AM, Guillaume Nodet wrote: Yes, they do. The definition of a subproject is imho just something controlled by a given TLP. The way its infrastructure is set up has nothing to do with that. A lot of TLP uses multiple JIRA and confluence spaces for different reasons. My point was, this subproject is apparently not going to be treated like any other Felix subproject. - richard On Mon, Apr 27, 2009 at 12:03, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 5:57 AM, Guillaume Nodet wrote: It seems the consensus for the code is to move it to https://svn.apache.org/repos/asf/felix/trunk/karaf So i'll go ahead and move the servicemix kernel trunk there asap. We still need to settle the problems of: * package name: org.apache.karaf vs org.apache.felix.karaf * jira issue tracker: use FELIX or create a new KARAF one * web site: use FELIX or create a new KARAF one The package renaming to org.apache.karaf has raised a number of concerns, mostly (correct me if i'm wrong) about the fact whether this would be frowned upong by the ASF or not. Given the number of subprojects that do that since a long time, I think the answer is no. Now we need to decide if we want to do this or not. For the issue tracker and web site, I think this is somewhat related to the package renaming issue above, though the problem is a bit different. I'm really opened here, but if we choose to rename the packages to org.apache.karaf, it think it would make more sense to have dedicated JIRA and confluence spaces. And is this how other projects do it too? It seems this is a subproject in name only. - richard On Fri, Apr 24, 2009 at 09:26, Guillaume Nodetgno...@gmail.com wrote: I'd like to start moving the ServiceMix Kernel code into Felix now. Given the size of the code base, I think it would be better to just move the tree into its own top level svn structure. I'd like to run the following command: svn cp https://svn.apache.org/repos/asf/servicemix/smx4/kernel https://svn.apache.org/repos/asf/felix/karaf Any objections in doing that ? Next steps will include creating a JIRA project and moving all the issues into it (with a KARAF id), then the confluence space. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Karl Pauls karlpa...@gmail.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: [Karaf] Switching to blueprint ...
Well, if you are going to switch, now seems like the time. - richard On 4/28/09 9:45 AM, Guillaume Nodet wrote: The past days, I've been working on the blueprint implementation inside Geronimo [1]. The spec is still being written so the implementation is not really stable and is still missing a lot of features. However, it's already somewhat usable and as I've hacked Karaf to start using blueprint instead of spring-dm in a branch [2]. Tests do not even compile, but I've been able to start the console, so I thought I would talk about it a bit. This raises the question whether we want to switch to blueprint instead of spring-dm. I think we should, and even have to, given that Spring-DM will switch to support Blueprint at some point in the future too. Also the blueprint spec is way better than spring-dm wrt to namespace handlers (that are considered dependencies, so we would not have problems with namespace handlers not being available when a bundle is started) and classloading (i think classes loaded for namespace handlers will be loaded from the namespace handler bundle, thus freeing the bundle to import all the namespace handlers packages), though those areas are in flux. If so, we might even want to do that before renaming the packages, as the patch is quite big and would be quite broken after the rename imho ... As for tests, we'd have to switch to something else, which could be junit4osgi from iPojo or pax-exam for example. Feedback welcome. [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint [2] https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/
Re: [Karaf] Moving Karaf svn into Felix
I've only copy the smx kernel trunk into felix so far and was waiting for the discussion to settle. We need to address the following tasks: * package renaming (see discussion about blueprint, it might be appropriate to wait a bit or use the branch instead) * move jira issues (i'm not an admin on FELIX jira instance, but if I could be granted that, i could create a component and start moving the issues). I'm experimenting a bit with the CSV import to see if that could help. I guess the other solution is to recreate the existing issues. * move web site. I think this should be easy to move the pages into FELIX using confluence, the next step is then to replace all references from ServiceMix Kernel to Karaf On Tue, Apr 28, 2009 at 15:59, Richard S. Hall he...@ungoverned.org wrote: On 4/28/09 9:52 AM, Guillaume Nodet wrote: Great ! Seems the discussion is over, so we should now think about executing this plan. Any volunteer ? I thought you were already doing it! :-) - richard On Mon, Apr 27, 2009 at 13:36, Guillaume Nodetgno...@gmail.com wrote: Ok, I'm not really convinced, but since it seems there is a lot of reluctance I think we should aim for: * packages in org.apache.felix.karaf * use existing FELIX infrastructure (mailing list, jira tracker, confluence space) I think we should start with the above and reconsider later if there is a need. Is everyone satisfied with the above ? On Mon, Apr 27, 2009 at 12:17, Karl Paulskarlpa...@gmail.com wrote: I think we should start with the FELIX infra and then see whether we need to create a new one when the need is there. About the package renaming, I'm in favour of going with org.apache.felix.karaf just because it emphasizes that felix is not about the framework. If we make an exception then this sends a strange message IMO. regards, Karl On Mon, Apr 27, 2009 at 12:11 PM, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 6:07 AM, Guillaume Nodet wrote: Yes, they do. The definition of a subproject is imho just something controlled by a given TLP. The way its infrastructure is set up has nothing to do with that. A lot of TLP uses multiple JIRA and confluence spaces for different reasons. My point was, this subproject is apparently not going to be treated like any other Felix subproject. - richard On Mon, Apr 27, 2009 at 12:03, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 5:57 AM, Guillaume Nodet wrote: It seems the consensus for the code is to move it to https://svn.apache.org/repos/asf/felix/trunk/karaf So i'll go ahead and move the servicemix kernel trunk there asap. We still need to settle the problems of: * package name: org.apache.karaf vs org.apache.felix.karaf * jira issue tracker: use FELIX or create a new KARAF one * web site: use FELIX or create a new KARAF one The package renaming to org.apache.karaf has raised a number of concerns, mostly (correct me if i'm wrong) about the fact whether this would be frowned upong by the ASF or not. Given the number of subprojects that do that since a long time, I think the answer is no. Now we need to decide if we want to do this or not. For the issue tracker and web site, I think this is somewhat related to the package renaming issue above, though the problem is a bit different. I'm really opened here, but if we choose to rename the packages to org.apache.karaf, it think it would make more sense to have dedicated JIRA and confluence spaces. And is this how other projects do it too? It seems this is a subproject in name only. - richard On Fri, Apr 24, 2009 at 09:26, Guillaume Nodetgno...@gmail.com wrote: I'd like to start moving the ServiceMix Kernel code into Felix now. Given the size of the code base, I think it would be better to just move the tree into its own top level svn structure. I'd like to run the following command: svn cp https://svn.apache.org/repos/asf/servicemix/smx4/kernel https://svn.apache.org/repos/asf/felix/karaf Any objections in doing that ? Next steps will include creating a JIRA project and moving all the issues into it (with a KARAF id), then the confluence space. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Karl Pauls karlpa...@gmail.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: [Karaf] Moving Karaf svn into Felix
On 4/28/09 10:14 AM, Guillaume Nodet wrote: I've only copy the smx kernel trunk into felix so far and was waiting for the discussion to settle. We need to address the following tasks: * package renaming (see discussion about blueprint, it might be appropriate to wait a bit or use the branch instead) * move jira issues (i'm not an admin on FELIX jira instance, but if I could be granted that, i could create a component and start moving the issues). I'm experimenting a bit with the CSV import to see if that could help. I guess the other solution is to recreate the existing issues. Done. - richard * move web site. I think this should be easy to move the pages into FELIX using confluence, the next step is then to replace all references from ServiceMix Kernel to Karaf On Tue, Apr 28, 2009 at 15:59, Richard S. Hallhe...@ungoverned.org wrote: On 4/28/09 9:52 AM, Guillaume Nodet wrote: Great ! Seems the discussion is over, so we should now think about executing this plan. Any volunteer ? I thought you were already doing it! :-) - richard On Mon, Apr 27, 2009 at 13:36, Guillaume Nodetgno...@gmail.comwrote: Ok, I'm not really convinced, but since it seems there is a lot of reluctance I think we should aim for: * packages in org.apache.felix.karaf * use existing FELIX infrastructure (mailing list, jira tracker, confluence space) I think we should start with the above and reconsider later if there is a need. Is everyone satisfied with the above ? On Mon, Apr 27, 2009 at 12:17, Karl Paulskarlpa...@gmail.comwrote: I think we should start with the FELIX infra and then see whether we need to create a new one when the need is there. About the package renaming, I'm in favour of going with org.apache.felix.karaf just because it emphasizes that felix is not about the framework. If we make an exception then this sends a strange message IMO. regards, Karl On Mon, Apr 27, 2009 at 12:11 PM, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 6:07 AM, Guillaume Nodet wrote: Yes, they do. The definition of a subproject is imho just something controlled by a given TLP. The way its infrastructure is set up has nothing to do with that. A lot of TLP uses multiple JIRA and confluence spaces for different reasons. My point was, this subproject is apparently not going to be treated like any other Felix subproject. -richard On Mon, Apr 27, 2009 at 12:03, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 5:57 AM, Guillaume Nodet wrote: It seems the consensus for the code is to move it to https://svn.apache.org/repos/asf/felix/trunk/karaf So i'll go ahead and move the servicemix kernel trunk there asap. We still need to settle the problems of: * package name: org.apache.karaf vs org.apache.felix.karaf * jira issue tracker: use FELIX or create a new KARAF one * web site: use FELIX or create a new KARAF one The package renaming to org.apache.karaf has raised a number of concerns, mostly (correct me if i'm wrong) about the fact whether this would be frowned upong by the ASF or not. Given the number of subprojects that do that since a long time, I think the answer is no. Now we need to decide if we want to do this or not. For the issue tracker and web site, I think this is somewhat related to the package renaming issue above, though the problem is a bit different. I'm really opened here, but if we choose to rename the packages to org.apache.karaf, it think it would make more sense to have dedicated JIRA and confluence spaces. And is this how other projects do it too? It seems this is a subproject in name only. - richard On Fri, Apr 24, 2009 at 09:26, Guillaume Nodetgno...@gmail.com wrote: I'd like to start moving the ServiceMix Kernel code into Felix now. Given the size of the code base, I think it would be better to just move the tree into its own top level svn structure. I'd like to run the following command: svn cp https://svn.apache.org/repos/asf/servicemix/smx4/kernel https://svn.apache.org/repos/asf/felix/karaf Any objections in doing that ? Next steps will include creating a JIRA project and moving all the issues into it (with a KARAF id), then the confluence space. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Karl Pauls karlpa...@gmail.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (FELIX-1062) Upgrade to latest Felix Runtime
Upgrade to latest Felix Runtime --- Key: FELIX-1062 URL: https://issues.apache.org/jira/browse/FELIX-1062 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Fix For: karaf-1.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1063) Upgrade to latest Felix Bundle Repository
Upgrade to latest Felix Bundle Repository - Key: FELIX-1063 URL: https://issues.apache.org/jira/browse/FELIX-1063 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1064) New goal for the features-maven-plugin: validate a features xml file
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 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] Created: (FELIX-1068) Arrow keys for browsing command does not work on Win XP
Arrow keys for browsing command does not work on Win XP --- Key: FELIX-1068 URL: https://issues.apache.org/jira/browse/FELIX-1068 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1067) Improve history support by using the !
[ https://issues.apache.org/jira/browse/FELIX-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-1067: --- Attachment: SMX4KNL-237.patch Improve history support by using the ! --- Key: FELIX-1067 URL: https://issues.apache.org/jira/browse/FELIX-1067 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Attachments: SMX4KNL-237.patch the history command is cool but it would be nice to be able to use things like: * !142 (run the command from the history with index 142) * !os (run last command starting with os) = See http://www.gnu.org/software/bash/manual/html_node/Event-Designators.html = with this patch, we can access history command list with ! indext ! commandPrefix for example, history we get 345 osgi/list then ! 345 or ! os we get osgi/list execute again seems we have to add a whitespace between ! and the index number or commandPrefix, so the syntax is not exactly same as bash (which no whitespace between ! and index number) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1069) Akuma integration for easier daemonization?
Akuma integration for easier daemonization? --- Key: FELIX-1069 URL: https://issues.apache.org/jira/browse/FELIX-1069 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Guillaume Nodet this library looks pretty neat as an alternative to the Java Service Wrapper... https://akuma.dev.java.net/ for making unix daemons Lars Heinemann added a comment - 31/Mar/09 11:30 AM - edited Cool stuff. Thanks for providing the link, James. I will have a look at this in the next couple of days hopefully But the lack of Windows Support is maybe a drawback. James Strachan added a comment - 31/Mar/09 12:58 PM Agreed - though the awesome unix support will be great for folks using linux/solaris/os x. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1070) Improve war deployer in order to provide the WebApp-context
Improve war deployer in order to provide the WebApp-context
---
Key: FELIX-1070
URL: https://issues.apache.org/jira/browse/FELIX-1070
Project: Felix
Issue Type: Improvement
Components: Karaf
Reporter: Guillaume Nodet
I have deployed a sample.war file top of SMX4 Kernel. The war is well deployed.
Unfortunately, I cannot reach the web site
http://localhost:8080/file__D__Dvlpt_Java_workspace-ganymede_esb_apache-servicemix-kernel-1.2.0-SNAPSHOT_deploy_sample.war/index.html
It seemed that the webapp-context generated by default by PAX
{code}
file__D__Dvlpt_Java_workspace-ganymede_esb_apache-servicemix-kernel-1.2.0-SNAPSHOT_deploy_sample.war
{code}
is the cause of this issue :
By the way, If I install manually the war using the following command :
{code}
install war:file:///d:/temp/sample.war?Webapp-Context=sample
{code}
the web site is reachable with the following address :
http://localhost:8080/sample/index.html
Suggestion : Allow the user to provide the webapp context in order to avoid
weird name
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1071) Exception in thread SpringOsgiExtenderThread-22 java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before ac cessing beans v
Exception in thread SpringOsgiExtenderThread-22
java.lang.IllegalStateException: BeanFactory not initialized or already closed
- call 'refresh' before ac cessing beans via the ApplicationContext Click to
flag this post
Key: FELIX-1071
URL: https://issues.apache.org/jira/browse/FELIX-1071
Project: Felix
Issue Type: Bug
Components: Karaf
Reporter: Guillaume Nodet
The following error is generated by SMX Kernel / Spring DM during bundle start
after an update :
{code}
s...@root:osgi Exception in thread SpringOsgiExtenderThread-22
java.lang.IllegalStateException: BeanFactory not initialized or already closed
- call 'refresh' before ac
cessing beans via the ApplicationContext
at
org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:153)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.close(DependencyWaiterApplicationContextExecutor.jav
a:345)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.fail(DependencyWaiterApplicationContextExecutor.java
:401)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.
java:287)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.j
ava:175)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
at
org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:716)
at java.lang.Thread.run(Thread.java:619)
{code}
This is very difficult to reproduce it but it seems that the error is generated
when there is a syntactical error in the camel spring DSL file.
e.g.
setHeader name=origin
simplefile/simple
/setHeader
simple can't be use but constant
The syntactical error is not the cause of the error message but I presume that
during the camel context and spring beans instantiation, there are interaction
responsible of the error returned.
Here is the my camel-context :
{code}
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:camel=http://camel.apache.org/schema/spring;
xmlns:osgi=http://www.springframework.org/schema/osgi;
xmlns:cxf=http://camel.apache.org/schema/cxf;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/osgi
http://www.springframework.org/schema/osgi/spring-osgi.xsd
http://camel.apache.org/schema/osgi
http://camel.apache.org/schema/osgi/camel-osgi.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://camel.apache.org/schema/cxf
http://camel.apache.org/schema/cxf/camel-cxf.xsd;
import resource=classpath:META-INF/cxf/cxf.xml/
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml/
import resource=classpath:META-INF/cxf/cxf-extension-http-jetty.xml/
bean id=bindyDataformat
class=org.apache.camel.dataformat.bindy.csv.BindyCsvDataFormat
constructor-arg type=java.lang.String
value=org.apache.camel.example.reportincident.model /
/bean
bean id=incidentSaver
class=org.apache.camel.example.reportincident.beans.IncidentSaver
property name=incidentService
osgi:reference
interface=org.apache.camel.example.reportincident.service.IncidentService/
/property
/bean
bean id=webservice
class=org.apache.camel.example.reportincident.beans.WebService /
bean id=feedback
class=org.apache.camel.example.reportincident.beans.Feedback /
!-- webservice endpoint --
cxf:cxfEndpoint id=reportIncident
address=http://localhost:8080/camel-example/incident;
serviceClass=org.apache.camel.example.reportincident.ReportIncidentEndpoint
xmlns:s=http://reportincident.example.camel.apache.org;
/cxf:cxfEndpoint
osgi:reference id=queuingservice
[jira] Created: (FELIX-1072) Add ordering and filtering functionalities to the OSGI command 'List'
Add ordering and filtering functionalities to the OSGI command 'List' - Key: FELIX-1072 URL: https://issues.apache.org/jira/browse/FELIX-1072 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Guillaume Nodet I suggest to add ordering and filtering functionality to the OSGI command 'List' to allow by example to do the following : list filter=apache* : to filter the list of osgi bundles using the name 'apache*' list order=name : to order the list of bundle using the name as the key (and not the osgi n°) list order=state: idem but using the state of the bundle (10, 20, 30, ...) list order=spring : idem but using the process 'stated, ...' = We already have the grep command which can be used to filter easily. For sorting, i'm kinda tempted to add a sort command like the unix one. Though this may not be sufficient to sort on a given column. = FWIW, I've seen a JIRA issue about a 'find' method related to that -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Karaf] Moving Karaf svn into Felix
I'll do the wiki move in Confluence if I can get admin permissions in the Felix space. I could also do some of the pom.xml refactoring (artifact and groupid, descriptions, etc) as long as it won't affect your blueprint service patch. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Tue, Apr 28, 2009 at 8:14 AM, Guillaume Nodet gno...@gmail.com wrote: I've only copy the smx kernel trunk into felix so far and was waiting for the discussion to settle. We need to address the following tasks: * package renaming (see discussion about blueprint, it might be appropriate to wait a bit or use the branch instead) * move jira issues (i'm not an admin on FELIX jira instance, but if I could be granted that, i could create a component and start moving the issues). I'm experimenting a bit with the CSV import to see if that could help. I guess the other solution is to recreate the existing issues. * move web site. I think this should be easy to move the pages into FELIX using confluence, the next step is then to replace all references from ServiceMix Kernel to Karaf On Tue, Apr 28, 2009 at 15:59, Richard S. Hall he...@ungoverned.org wrote: On 4/28/09 9:52 AM, Guillaume Nodet wrote: Great ! Seems the discussion is over, so we should now think about executing this plan. Any volunteer ? I thought you were already doing it! :-) - richard On Mon, Apr 27, 2009 at 13:36, Guillaume Nodetgno...@gmail.com wrote: Ok, I'm not really convinced, but since it seems there is a lot of reluctance I think we should aim for: * packages in org.apache.felix.karaf * use existing FELIX infrastructure (mailing list, jira tracker, confluence space) I think we should start with the above and reconsider later if there is a need. Is everyone satisfied with the above ? On Mon, Apr 27, 2009 at 12:17, Karl Paulskarlpa...@gmail.com wrote: I think we should start with the FELIX infra and then see whether we need to create a new one when the need is there. About the package renaming, I'm in favour of going with org.apache.felix.karaf just because it emphasizes that felix is not about the framework. If we make an exception then this sends a strange message IMO. regards, Karl On Mon, Apr 27, 2009 at 12:11 PM, Richard S. Hall he...@ungoverned.org wrote: On 4/27/09 6:07 AM, Guillaume Nodet wrote: Yes, they do. The definition of a subproject is imho just something controlled by a given TLP. The way its infrastructure is set up has nothing to do with that. A lot of TLP uses multiple JIRA and confluence spaces for different reasons. My point was, this subproject is apparently not going to be treated like any other Felix subproject. - richard On Mon, Apr 27, 2009 at 12:03, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 5:57 AM, Guillaume Nodet wrote: It seems the consensus for the code is to move it to https://svn.apache.org/repos/asf/felix/trunk/karaf So i'll go ahead and move the servicemix kernel trunk there asap. We still need to settle the problems of: * package name: org.apache.karaf vs org.apache.felix.karaf * jira issue tracker: use FELIX or create a new KARAF one * web site: use FELIX or create a new KARAF one The package renaming to org.apache.karaf has raised a number of concerns, mostly (correct me if i'm wrong) about the fact whether this would be frowned upong by the ASF or not. Given the number of subprojects that do that since a long time, I think the answer is no. Now we need to decide if we want to do this or not. For the issue tracker and web site, I think this is somewhat related to the package renaming issue above, though the problem is a bit different. I'm really opened here, but if we choose to rename the packages to org.apache.karaf, it think it would make more sense to have dedicated JIRA and confluence spaces. And is this how other projects do it too? It seems this is a subproject in name only. -richard On Fri, Apr 24, 2009 at 09:26, Guillaume Nodetgno...@gmail.com wrote: I'd like to start moving the ServiceMix Kernel code into Felix now. Given the size of the code base, I think it would be better to just move the tree into its own top level svn structure. I'd like to run the following command: svn cp https://svn.apache.org/repos/asf/servicemix/smx4/kernel https://svn.apache.org/repos/asf/felix/karaf Any objections in doing that ? Next steps will include creating a JIRA project and moving all the issues into it (with a KARAF id), then the confluence space. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [Karaf] Moving Karaf svn into Felix
L.S., If the blueprint stuff is going to settle down pretty soon, we might as well start with Guillaume's branch and target a first release of Karaf with that. From the other post, it seems like a really nice feature to have... That way, we can get started renaming things now -- I guess the effort will only become bigger if we wait longer. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/28 Chris Custine ccust...@apache.org: I'll do the wiki move in Confluence if I can get admin permissions in the Felix space. I could also do some of the pom.xml refactoring (artifact and groupid, descriptions, etc) as long as it won't affect your blueprint service patch. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Tue, Apr 28, 2009 at 8:14 AM, Guillaume Nodet gno...@gmail.com wrote: I've only copy the smx kernel trunk into felix so far and was waiting for the discussion to settle. We need to address the following tasks: * package renaming (see discussion about blueprint, it might be appropriate to wait a bit or use the branch instead) * move jira issues (i'm not an admin on FELIX jira instance, but if I could be granted that, i could create a component and start moving the issues). I'm experimenting a bit with the CSV import to see if that could help. I guess the other solution is to recreate the existing issues. * move web site. I think this should be easy to move the pages into FELIX using confluence, the next step is then to replace all references from ServiceMix Kernel to Karaf On Tue, Apr 28, 2009 at 15:59, Richard S. Hall he...@ungoverned.org wrote: On 4/28/09 9:52 AM, Guillaume Nodet wrote: Great ! Seems the discussion is over, so we should now think about executing this plan. Any volunteer ? I thought you were already doing it! :-) - richard On Mon, Apr 27, 2009 at 13:36, Guillaume Nodetgno...@gmail.com wrote: Ok, I'm not really convinced, but since it seems there is a lot of reluctance I think we should aim for: * packages in org.apache.felix.karaf * use existing FELIX infrastructure (mailing list, jira tracker, confluence space) I think we should start with the above and reconsider later if there is a need. Is everyone satisfied with the above ? On Mon, Apr 27, 2009 at 12:17, Karl Paulskarlpa...@gmail.com wrote: I think we should start with the FELIX infra and then see whether we need to create a new one when the need is there. About the package renaming, I'm in favour of going with org.apache.felix.karaf just because it emphasizes that felix is not about the framework. If we make an exception then this sends a strange message IMO. regards, Karl On Mon, Apr 27, 2009 at 12:11 PM, Richard S. Hall he...@ungoverned.org wrote: On 4/27/09 6:07 AM, Guillaume Nodet wrote: Yes, they do. The definition of a subproject is imho just something controlled by a given TLP. The way its infrastructure is set up has nothing to do with that. A lot of TLP uses multiple JIRA and confluence spaces for different reasons. My point was, this subproject is apparently not going to be treated like any other Felix subproject. - richard On Mon, Apr 27, 2009 at 12:03, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 5:57 AM, Guillaume Nodet wrote: It seems the consensus for the code is to move it to https://svn.apache.org/repos/asf/felix/trunk/karaf So i'll go ahead and move the servicemix kernel trunk there asap. We still need to settle the problems of: * package name: org.apache.karaf vs org.apache.felix.karaf * jira issue tracker: use FELIX or create a new KARAF one * web site: use FELIX or create a new KARAF one The package renaming to org.apache.karaf has raised a number of concerns, mostly (correct me if i'm wrong) about the fact whether this would be frowned upong by the ASF or not. Given the number of subprojects that do that since a long time, I think the answer is no. Now we need to decide if we want to do this or not. For the issue tracker and web site, I think this is somewhat related to the package renaming issue above, though the problem is a bit different. I'm really opened here, but if we choose to rename the packages to org.apache.karaf, it think it would make more sense to have dedicated JIRA and confluence spaces. And is this how other projects do it too? It seems this is a subproject in name only. - richard On Fri, Apr 24, 2009 at 09:26, Guillaume Nodetgno...@gmail.com wrote: I'd like to start moving the ServiceMix Kernel code into Felix now. Given the size of the
[jira] Created: (FELIX-1074) When installing features, we need to osgi/refresh some bundles to allow optional imports to be resolved
When installing features, we need to osgi/refresh some bundles to allow optional imports to be resolved --- Key: FELIX-1074 URL: https://issues.apache.org/jira/browse/FELIX-1074 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet Attachments: SMX4KNL-249.patch For example, before the fix for SMX4-222, the jsp bundle was installed after the core web service, thus making jsp not working. When installing the jsp bundle, we should refresh the core web server, or maybe adding the core web service bundle to the web feature in addition to the web-core, and make the refresh when an already installed bundle is required by a feature (i think it would make more sense and be easier). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1074) When installing features, we need to osgi/refresh some bundles to allow optional imports to be resolved
[ https://issues.apache.org/jira/browse/FELIX-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-1074: --- Attachment: SMX4KNL-249.patch Attaching a patch here. This patch actually refreshes the bundles, but for some reason, it leads to gshell-core bundle being refreshed too and this breaks everything afterwards. This may also be releated to the fact that gshell commands bundles can not be refreshed properly. [ Show » ] Guillaume Nodet added a comment - 23/Mar/09 03:55 AM Attaching a patch here. This patch actually refreshes the bundles, but for some reason, it leads to gshell-core bundle being refreshed too and this breaks everything afterwards. This may also be releated to the fact that gshell commands bundles can not be refreshed properly. When installing features, we need to osgi/refresh some bundles to allow optional imports to be resolved --- Key: FELIX-1074 URL: https://issues.apache.org/jira/browse/FELIX-1074 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet Attachments: SMX4KNL-249.patch For example, before the fix for SMX4-222, the jsp bundle was installed after the core web service, thus making jsp not working. When installing the jsp bundle, we should refresh the core web server, or maybe adding the core web service bundle to the web feature in addition to the web-core, and make the refresh when an already installed bundle is required by a feature (i think it would make more sense and be easier). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1074) When installing features, we need to osgi/refresh some bundles to allow optional imports to be resolved
[ https://issues.apache.org/jira/browse/FELIX-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703694#action_12703694 ] Guillaume Nodet commented on FELIX-1074: Calling refresh on all bundles for the feature installed and all its dependencies may be a bit too much. We need to at least call refreshPackages(null), but this won't resolve optional imported packages that are available. Unfortunately, there's no easy way around that: a possible one would be to examine all bundles and if they have optional imports that are not resolved, try to refresh those. When installing features, we need to osgi/refresh some bundles to allow optional imports to be resolved --- Key: FELIX-1074 URL: https://issues.apache.org/jira/browse/FELIX-1074 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet Attachments: SMX4KNL-249.patch For example, before the fix for SMX4-222, the jsp bundle was installed after the core web service, thus making jsp not working. When installing the jsp bundle, we should refresh the core web server, or maybe adding the core web service bundle to the web feature in addition to the web-core, and make the refresh when an already installed bundle is required by a feature (i think it would make more sense and be easier). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1075) Error loading FeaturesService state java.lang.NumberFormatException: For input string:
Error loading FeaturesService state java.lang.NumberFormatException: For input
string:
-
Key: FELIX-1075
URL: https://issues.apache.org/jira/browse/FELIX-1075
Project: Felix
Issue Type: Bug
Components: Karaf
Reporter: Guillaume Nodet
{code}
13:30:18,788 | INFO | FelixStartLevel | FileMonitor |
x.kernel.filemonitor.FileMonitor 155 | Starting to monitor the deploy
directory:
D:\Dvlpt\Java\workspace-ganymede\esb\apache-servicemix-kernel-1.2.0-SNAPSHOT\deploy
every 500 millis
13:30:18,804 | INFO | FelixStartLevel | FileMonitor |
x.kernel.filemonitor.FileMonitor 158 | Config directory is at:
D:\Dvlpt\Java\workspace-ganymede\esb\apache-servicemix-kernel-1.2.0-SNAPSHOT\etc
13:30:18,804 | INFO | FelixStartLevel | FileMonitor |
x.kernel.filemonitor.FileMonitor 160 | Will generate bundles from expanded
source directories to:
D:\Dvlpt\Java\workspace-ganymede\esb\apache-servicemix-kernel-1.2.0-SNAPSHOT\data\generated-bundles
13:30:18,820 | WARN | pool-1-thread-1 | FileMonitor |
x.kernel.filemonitor.FileMonitor 272 | Unsupported deployment:
D:\Dvlpt\Java\workspace-ganymede\esb\apache-servicemix-kernel-1.2.0-SNAPSHOT\etc\system.properties
13:30:19,898 | INFO | FelixStartLevel | ContextLoaderListener|
.activator.ContextLoaderListener 356 | Starting
[org.springframework.osgi.extender] bundle v.[1.2.0.rc1]
13:30:20,070 | INFO | FelixStartLevel | ExtenderConfiguration|
al.support.ExtenderConfiguration 150 | No custom extender configuration
detected; using defaults...
13:30:20,085 | INFO | FelixStartLevel | TimerTaskExecutor|
heduling.timer.TimerTaskExecutor 90 | Initializing Timer
13:30:20,210 | INFO | FelixStartLevel | ultOsgiApplicationContextCreator |
ultOsgiApplicationContextCreator 67 | Discovered configurations
{osgibundle:/META-INF/spring/*.xml} in bundle [Apache ServiceMix Kernel ::
GShell Features (org.apache.servicemix.kernel.gshell.features)]
13:30:20,366 | INFO | FelixStartLevel | OsgiBundleXmlApplicationContext |
pport.AbstractApplicationContext 411 | Refreshing
org.springframework.osgi.context.support.osgibundlexmlapplicationcont...@1ea0105:
display name
[OsgiBundleXmlApplicationContext(bundle=org.apache.servicemix.kernel.gshell.features,
config=osgibundle:/META-INF/spring/*.xml)]; startup date [Fri Mar 20 13:30:20
CET 2009]; root of context hierarchy
13:30:20,366 | INFO | FelixStartLevel | OsgiBundleXmlApplicationContext |
ractOsgiBundleApplicationContext 359 | Unpublishing application context OSGi
service for bundle Apache ServiceMix Kernel :: GShell Features
(org.apache.servicemix.kernel.gshell.features)
13:30:20,460 | INFO | FelixStartLevel | XmlBeanDefinitionReader |
tory.xml.XmlBeanDefinitionReader 323 | Loading XML bean definitions from URL
[bundle://13.0:0/META-INF/spring/gshell-features.xml]
13:30:21,663 | INFO | FelixStartLevel | XmlBeanDefinitionReader |
tory.xml.XmlBeanDefinitionReader 323 | Loading XML bean definitions from OSGi
resource[classpath:org/apache/servicemix/kernel/gshell/core/commands.xml|bnd.id=13|bnd.sym=org.apache.servicemix.kernel.gshell.features]
13:30:21,866 | INFO | FelixStartLevel | OsgiBundleXmlApplicationContext |
pport.AbstractApplicationContext 426 | Bean factory for application context
[org.springframework.osgi.context.support.osgibundlexmlapplicationcont...@1ea0105]:
org.springframework.beans.factory.support.defaultlistablebeanfact...@109dc35
13:30:22,070 | INFO | FelixStartLevel | WaiterApplicationContextExecutor |
WaiterApplicationContextExecutor 252 | No outstanding OSGi service
dependencies, completing initialization for
OsgiBundleXmlApplicationContext(bundle=org.apache.servicemix.kernel.gshell.features,
config=osgibundle:/META-INF/spring/*.xml)
13:30:22,163 | INFO | FelixStartLevel | DefaultListableBeanFactory |
pport.DefaultListableBeanFactory 414 | Pre-instantiating singletons in
org.springframework.beans.factory.support.defaultlistablebeanfact...@109dc35:
defining beans
[jira] Created: (FELIX-1076) Full support for fragments
Full support for fragments -- Key: FELIX-1076 URL: https://issues.apache.org/jira/browse/FELIX-1076 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Felix has minimal support for fragment bundles in that currently you can only load resources form the fragment classpath. Fragments do not attach their imports/exports to the host bundle as stated in the spec. This prevents a few popular bundles form working, such as the Hibernate bundles from the Spring EBR. This issue is for ServiceMix users to track the progress and status of fragment support. The Felix issue relating to this is: https://issues.apache.org/jira/browse/FELIX-29 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1078) The config/list command fails if a configuration has been deleted
The config/list command fails if a configuration has been deleted
-
Key: FELIX-1078
URL: https://issues.apache.org/jira/browse/FELIX-1078
Project: Felix
Issue Type: Bug
Components: Karaf
Reporter: Guillaume Nodet
{code}
org.apache.geronimo.gshell.commandline.CommandLineExecutionFailed:
org.apache.geronimo.gshell.command.CommandException:
java.lang.IllegalStateException: Configuration org.ops4j.pax.logging deleted
at
org.apache.geronimo.gshell.parser.visitor.ExecutingVisitor.executePiped(ExecutingVisitor.java:246)
at
org.apache.geronimo.gshell.parser.visitor.ExecutingVisitor.visit(ExecutingVisitor.java:107)
at
org.apache.geronimo.gshell.parser.ASTExpression.jjtAccept(ASTExpression.java:17)
at
org.apache.geronimo.gshell.parser.SimpleNode.childrenAccept(SimpleNode.java:61)
at
org.apache.geronimo.gshell.parser.visitor.ExecutingVisitor.visit(ExecutingVisitor.java:90)
at
org.apache.geronimo.gshell.parser.ASTCommandLine.jjtAccept(ASTCommandLine.java:17)
at
org.apache.geronimo.gshell.wisdom.shell.CommandLineBuilderImpl$1.execute(CommandLineBuilderImpl.java:96)
at
org.apache.geronimo.gshell.wisdom.shell.CommandLineExecutorImpl.execute(CommandLineExecutorImpl.java:71)
at
org.apache.geronimo.gshell.commands.ssh.ShellFactoryImpl$ShellImpl.execute(ShellFactoryImpl.java:183)
at
org.apache.geronimo.gshell.commands.ssh.ShellFactoryImpl$ShellImpl$1.execute(ShellFactoryImpl.java:214)
at org.apache.geronimo.gshell.console.Console.work(Console.java:187)
at org.apache.geronimo.gshell.console.Console.run(Console.java:128)
at
org.apache.geronimo.gshell.commands.ssh.ShellFactoryImpl$ShellImpl.run(ShellFactoryImpl.java:236)
at
org.apache.geronimo.gshell.commands.ssh.ShellFactoryImpl$ShellImpl.run(ShellFactoryImpl.java:256)
at java.lang.Thread.run(Thread.java:613)
Caused by: org.apache.geronimo.gshell.command.CommandException:
java.lang.IllegalStateException: Configuration org.ops4j.pax.logging deleted
at
org.apache.geronimo.gshell.wisdom.shell.CommandLineExecutorImpl.doExecute(CommandLineExecutorImpl.java:148)
at
org.apache.geronimo.gshell.wisdom.shell.CommandLineExecutorImpl.execute(CommandLineExecutorImpl.java:106)
at
org.apache.geronimo.gshell.parser.visitor.ExecutingVisitor$1.run(ExecutingVisitor.java:208)
at
org.apache.geronimo.gshell.parser.visitor.ExecutingVisitor.executePiped(ExecutingVisitor.java:231)
... 14 more
Caused by: java.lang.IllegalStateException: Configuration org.ops4j.pax.logging
deleted
at
org.apache.felix.cm.impl.ConfigurationAdapter.checkDeleted(ConfigurationAdapter.java:170)
at
org.apache.felix.cm.impl.ConfigurationAdapter.getPid(ConfigurationAdapter.java:53)
at
org.apache.servicemix.kernel.gshell.config.ListCommand.doExecute(ListCommand.java:35)
at
org.apache.servicemix.kernel.gshell.config.ConfigCommandSupport.doExecute(ConfigCommandSupport.java:50)
at
org.apache.servicemix.kernel.gshell.core.OsgiCommandSupport.execute(OsgiCommandSupport.java:48)
at
org.apache.geronimo.gshell.wisdom.command.CommandSupport.executeAction(CommandSupport.java:303)
at
org.apache.geronimo.gshell.wisdom.command.StatefulCommand.executeAction(StatefulCommand.java:94)
at
org.apache.geronimo.gshell.wisdom.command.CommandSupport.execute(CommandSupport.java:194)
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.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:64)
at
org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:78)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at
org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invokeUnprivileged(ServiceTCCLInterceptor.java:57)
at
org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:40)
at
[jira] Created: (FELIX-1077) switch to using Commons Daemon rather than Java Service Wrapper to avoid GPL code (as its changed)
switch to using Commons Daemon rather than Java Service Wrapper to avoid GPL code (as its changed) -- Key: FELIX-1077 URL: https://issues.apache.org/jira/browse/FELIX-1077 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Tomcat do the same... http://commons.apache.org/daemon/ The latest versions of JSW are GPL. See http://wrapper.tanukisoftware.org/doc/english/licenseOverview.html There is a commercial license we can't really use. Older versions (including the one we use) were ASL, but we can't really upgrade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1079) Shell completion works only in the root shell
Shell completion works only in the root shell - Key: FELIX-1079 URL: https://issues.apache.org/jira/browse/FELIX-1079 Project: Felix Issue Type: Bug Reporter: Guillaume Nodet Related to https://issues.apache.org/jira/browse/GSHELL-161 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1080) Enhance features maven plugin to support deployment / undeployment of features, html generation and create a few archetypes
Enhance features maven plugin to support deployment / undeployment of features, html generation and create a few archetypes --- Key: FELIX-1080 URL: https://issues.apache.org/jira/browse/FELIX-1080 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Guillaume Nodet Enhance the features maven plugin (http://svn.apache.org/repos/asf/servicemix/maven-plugins/features-maven-plugin) to support : 1) Deployment / undeployment of features, 2) Generate html page about features : see http://fusesource.com/forums/message.jspa?messageID=2005#2005 for the suggestion 3) Creation a few archetypes: * one for creating a custom smx kernel distribution + a set of features (like what we do for our distributions). * one for creating a feature descriptor automatically generated using the maven plugin we already have + upload in the maven repo. Ideally, the descriptor should be created from the user pom.xml profile file or (pom.xml files if the user has created a parent pom.xml with modules) * one for creating a manually written feature descriptor + upload in the maven repo The two last archetypes should reference our maven plugin so that they could be easily installed / uninstalled to a running (or not) smx4 kernel instance using maven. Remark : this ticket has been created following discussions exchanged in the forum of SMX : http://www.nabble.com/forum/ViewPost.jtp?post=22285345framed=y -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1080) Enhance features maven plugin to support deployment / undeployment of features, html generation and create a few archetypes
[ https://issues.apache.org/jira/browse/FELIX-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703702#action_12703702 ] Guillaume Nodet commented on FELIX-1080: Edell Nolan: I have been working on creating an archetype to generate a feature descriptor automatically if you add in dependencies into a pom.xml file - our maven features plugin does this already and I have the archetype working. But I have a question around having multiple pom.xml files in that you have a root pom and serveral modules. if you then attempt to run this from the root - I get the impression you are looking for a features.xml file that would have covered all the module poms.xml files. so that it will add the features for all dependencies in all the sub modules Is this the case ? or should it be that you just generate the features.xml for each module individually ? Charles Mouillard: Personally, I prefer to have one feature file generated when we have a parent pom with several slave pom (= modules). Guillaume Nodet: I'm not sure that this is a good idea to generate the features file from the parent pom in case you have modules that are not really part of the feature, like an assembly of something like that. Edell Nolan: I was thinking about this a little more and I think it should just be based on one feature.xml file per pom.xml with its dependencies. You can always have one directory that will list all your dependencies and use this to create your features.xml file. I will get this in today hopefully. Charles Mouillard: Most of the time, when you work on a OSGI project, you will create in eclipse several eclipse projects, one by bundle. So, it makes sense to create a parent pom pointing to the different modules / bundles and to have one global features file. Here is an example of what I do manually to deploy all my bundles : features feature name=reportincident version=1.0 featurecamel-core/feature featurecamel-spring/feature featurecamel-osgi/feature featurecamel-bindy/feature featureserver/feature bundlemvn:org.apache.camel.example/reportincident.domain/1.0-SNAPSHOT/bundle bundlemvn:org.apache.camel.example/reportincident.service/1.0-SNAPSHOT/bundle bundlemvn:org.apache.camel.example/reportincident.interfaces/1.0-SNAPSHOT/bundle /feature reportincident.domain = maven project = bundle = eclipse project === Edell Nolan: Ok The way this currently works is that you would have one pom that would list dependencies on camel-core, camel-spring etc so this will generate your features.xml file - Also if you wish - it will indicate what other bundles it requires for classes that you may have not depended on and you can supply this list in a properties file so it will include dependent bundles for you as well. I will do up an example: that we did for our distribution of camel in servicemix. === Edell Nolan: Attaching a patch - you will need the latest of the features maven plugin or change the version in the generated pom It depends on features.maven.plugin.version1.1-SNAPSHOT/features.maven.plugin.version servicemix.kernel.version1.1.0-SNAPSHOT/servicemix.kernel.version Example here : if you run Step1 : C:\edell-featuresmvn archetype:create -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeArtifactId=servicemix-features-descriptor -DgroupId=org.apache.servicemix.edell -DartifactId=org.apache.servicemix.testCamel.features -DarchetypeVersion=2008.01-SNAPSHOT -DremoteRepositories=REPO_LOCATION This will generate the following directory structure org.apache.servicemix.testCamel.features - pom.xml - src/main/resources/bundle.properties If you run mvn install = this will result in a features.xml file with nothing in it. ?xml version=1.0 encoding=UTF-8? features /features Step 2: Your next step is to add your dependencies into the pom.xml file so if I added dependencies dependency groupIdorg.apache.camel/groupId artifactIdcamel-core/artifactId version1.5.0/version /dependency /dependencies This will result in target/classes/feature.xml file ?xml version=1.0 encoding=UTF-8? features feature name='camel-core' bundlemvn:org.apache.camel/camel-core/1.5.0/bundle /feature /features But it will also hint in the output about dependant bundles eg. [WARNING] Unable to find suitable bundle for dependency javax.activation (0.0. 0) (required by camel-core) [WARNING] Unable to find suitable bundle for dependency javax.xml.bind (0.0.0) (required by camel-core) [WARNING] Unable to find suitable bundle for dependency javax.xml.bind.annotat ion (0.0.0) (required by camel-core) Step 3: You can add the dependant bundles to your bundle.properties file So you get a resulting feature.xml file ?xml version=1.0 encoding=UTF-8? features feature name='camel-core'
[jira] Created: (FELIX-1081) Enhance features maven plugin to support deployment / undeployment of features
Enhance features maven plugin to support deployment / undeployment of features -- Key: FELIX-1081 URL: https://issues.apache.org/jira/browse/FELIX-1081 Project: Felix Issue Type: Sub-task Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1081) Enhance features maven plugin to support deployment / undeployment of features
[ https://issues.apache.org/jira/browse/FELIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703704#action_12703704 ] Guillaume Nodet commented on FELIX-1081: Going to work initially on getting the deployement/undeployement of features working through JMX MBeans and then will hook up the features plugin using a goal to the mbeans. === From looking into the MBean setup for features. There is a few things I would like to change in order to get the install working for a full features descriptor. Currently - you can really only install/uninstall a feature. Installing a repository - will only add a repository and add the list of features in that repository to an available list but you would have to install all features individually. Some people may want this. but it doesn't actually install everything in a repository. Plus this is also not recursive so if you install a repository and it has repositories of its own - these will not be added. So my proposal is to change the intention of InstallRepository to actually going ahead and install everything in that repository and making it recursive. Add an operation AddRepository which will be recursive but will only add the Repositories and the features to the list of available features and our Repositories tag will change to Available Repositories and have a new entry of Installed Repositories Then add two new operations in Repository to install/uninstall a Repository (this will include installing/uninstalling all features in that repository and again it should be recursive if there are any sub repositories). Currently the connection of a feature to a repository is not there so that would be part of this solution. Does this seem reasonable to change ? Edell. === I have got a bit further with getting the install/uninstall to work. I have changed one of the api's addRepository though. So now For the FeaturesService - you can install/uninstall a Feature, addRepository, installRepository. Then depending on whether you have added or installed the repository it means different things. Added - means that you can add the Repository and a list of the available features will be added to the Available feature list so you can sort of pick and choose what you want to install or then go ahead and install the entire repository which will install all dependant repositories and features. and abviously installed means to install the entire repository and all its dependants. So basically adding just gives the user the option to see whats in it before they install it and if they are sure they can ignore adding and just install directly. I have one issue left to resolve on the recursion - it seems to have a problem with a feature depending on a feature. I end up with a org.osgi.framework.BundleException (no securityManager: RMI Classloader disabled. Enhance features maven plugin to support deployment / undeployment of features -- Key: FELIX-1081 URL: https://issues.apache.org/jira/browse/FELIX-1081 Project: Felix Issue Type: Sub-task Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Karaf] Moving Karaf svn into Felix
On 4/28/09 11:34 AM, Chris Custine wrote: I'll do the wiki move in Confluence if I can get admin permissions in the Felix space. Last I knew, I didn't have admin permissions on Confluence (nor do I want it, just extra work. I think Marcel is our Confluence admin go to guy, so maybe he can do the move or help you do it... - richard I could also do some of the pom.xml refactoring (artifact and groupid, descriptions, etc) as long as it won't affect your blueprint service patch. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Tue, Apr 28, 2009 at 8:14 AM, Guillaume Nodetgno...@gmail.com wrote: I've only copy the smx kernel trunk into felix so far and was waiting for the discussion to settle. We need to address the following tasks: * package renaming (see discussion about blueprint, it might be appropriate to wait a bit or use the branch instead) * move jira issues (i'm not an admin on FELIX jira instance, but if I could be granted that, i could create a component and start moving the issues). I'm experimenting a bit with the CSV import to see if that could help. I guess the other solution is to recreate the existing issues. * move web site. I think this should be easy to move the pages into FELIX using confluence, the next step is then to replace all references from ServiceMix Kernel to Karaf On Tue, Apr 28, 2009 at 15:59, Richard S. Hallhe...@ungoverned.org wrote: On 4/28/09 9:52 AM, Guillaume Nodet wrote: Great ! Seems the discussion is over, so we should now think about executing this plan. Any volunteer ? I thought you were already doing it! :-) - richard On Mon, Apr 27, 2009 at 13:36, Guillaume Nodetgno...@gmail.com wrote: Ok, I'm not really convinced, but since it seems there is a lot of reluctance I think we should aim for: * packages in org.apache.felix.karaf * use existing FELIX infrastructure (mailing list, jira tracker, confluence space) I think we should start with the above and reconsider later if there is a need. Is everyone satisfied with the above ? On Mon, Apr 27, 2009 at 12:17, Karl Paulskarlpa...@gmail.com wrote: I think we should start with the FELIX infra and then see whether we need to create a new one when the need is there. About the package renaming, I'm in favour of going with org.apache.felix.karaf just because it emphasizes that felix is not about the framework. If we make an exception then this sends a strange message IMO. regards, Karl On Mon, Apr 27, 2009 at 12:11 PM, Richard S. Hall he...@ungoverned.org wrote: On 4/27/09 6:07 AM, Guillaume Nodet wrote: Yes, they do. The definition of a subproject is imho just something controlled by a given TLP. The way its infrastructure is set up has nothing to do with that. A lot of TLP uses multiple JIRA and confluence spaces for different reasons. My point was, this subproject is apparently not going to be treated like any other Felix subproject. - richard On Mon, Apr 27, 2009 at 12:03, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 5:57 AM, Guillaume Nodet wrote: It seems the consensus for the code is to move it to https://svn.apache.org/repos/asf/felix/trunk/karaf So i'll go ahead and move the servicemix kernel trunk there asap. We still need to settle the problems of: * package name: org.apache.karaf vs org.apache.felix.karaf * jira issue tracker: use FELIX or create a new KARAF one * web site: use FELIX or create a new KARAF one The package renaming to org.apache.karaf has raised a number of concerns, mostly (correct me if i'm wrong) about the fact whether this would be frowned upong by the ASF or not. Given the number of subprojects that do that since a long time, I think the answer is no. Now we need to decide if we want to do this or not. For the issue tracker and web site, I think this is somewhat related to the package renaming issue above, though the problem is a bit different. I'm really opened here, but if we choose to rename the packages to org.apache.karaf, it think it would make more sense to have dedicated JIRA and confluence spaces. And is this how other projects do it too? It seems this is a subproject in name only. - richard On Fri, Apr 24, 2009 at 09:26, Guillaume Nodetgno...@gmail.com wrote: I'd like to start moving the ServiceMix Kernel code into Felix now. Given the size of the code base, I think it would be better to just move the tree into its own top
Re: [Karaf] Moving Karaf svn into Felix
2009/4/28 Chris Custine ccust...@apache.org: I'll do the wiki move in Confluence if I can get admin permissions in the Felix space. Done I could also do some of the pom.xml refactoring (artifact and groupid, descriptions, etc) as long as it won't affect your blueprint service patch. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Tue, Apr 28, 2009 at 8:14 AM, Guillaume Nodet gno...@gmail.com wrote: I've only copy the smx kernel trunk into felix so far and was waiting for the discussion to settle. We need to address the following tasks: * package renaming (see discussion about blueprint, it might be appropriate to wait a bit or use the branch instead) * move jira issues (i'm not an admin on FELIX jira instance, but if I could be granted that, i could create a component and start moving the issues). I'm experimenting a bit with the CSV import to see if that could help. I guess the other solution is to recreate the existing issues. * move web site. I think this should be easy to move the pages into FELIX using confluence, the next step is then to replace all references from ServiceMix Kernel to Karaf On Tue, Apr 28, 2009 at 15:59, Richard S. Hall he...@ungoverned.org wrote: On 4/28/09 9:52 AM, Guillaume Nodet wrote: Great ! Seems the discussion is over, so we should now think about executing this plan. Any volunteer ? I thought you were already doing it! :-) - richard On Mon, Apr 27, 2009 at 13:36, Guillaume Nodetgno...@gmail.com wrote: Ok, I'm not really convinced, but since it seems there is a lot of reluctance I think we should aim for: * packages in org.apache.felix.karaf * use existing FELIX infrastructure (mailing list, jira tracker, confluence space) I think we should start with the above and reconsider later if there is a need. Is everyone satisfied with the above ? On Mon, Apr 27, 2009 at 12:17, Karl Paulskarlpa...@gmail.com wrote: I think we should start with the FELIX infra and then see whether we need to create a new one when the need is there. About the package renaming, I'm in favour of going with org.apache.felix.karaf just because it emphasizes that felix is not about the framework. If we make an exception then this sends a strange message IMO. regards, Karl On Mon, Apr 27, 2009 at 12:11 PM, Richard S. Hall he...@ungoverned.org wrote: On 4/27/09 6:07 AM, Guillaume Nodet wrote: Yes, they do. The definition of a subproject is imho just something controlled by a given TLP. The way its infrastructure is set up has nothing to do with that. A lot of TLP uses multiple JIRA and confluence spaces for different reasons. My point was, this subproject is apparently not going to be treated like any other Felix subproject. - richard On Mon, Apr 27, 2009 at 12:03, Richard S. Hallhe...@ungoverned.org wrote: On 4/27/09 5:57 AM, Guillaume Nodet wrote: It seems the consensus for the code is to move it to https://svn.apache.org/repos/asf/felix/trunk/karaf So i'll go ahead and move the servicemix kernel trunk there asap. We still need to settle the problems of: * package name: org.apache.karaf vs org.apache.felix.karaf * jira issue tracker: use FELIX or create a new KARAF one * web site: use FELIX or create a new KARAF one The package renaming to org.apache.karaf has raised a number of concerns, mostly (correct me if i'm wrong) about the fact whether this would be frowned upong by the ASF or not. Given the number of subprojects that do that since a long time, I think the answer is no. Now we need to decide if we want to do this or not. For the issue tracker and web site, I think this is somewhat related to the package renaming issue above, though the problem is a bit different. I'm really opened here, but if we choose to rename the packages to org.apache.karaf, it think it would make more sense to have dedicated JIRA and confluence spaces. And is this how other projects do it too? It seems this is a subproject in name only. - richard On Fri, Apr 24, 2009 at 09:26, Guillaume Nodetgno...@gmail.com wrote: I'd like to start moving the ServiceMix Kernel code into Felix now. Given the size of the code base, I think it would be better to just move the tree into its own top level svn structure. I'd like to run the following command: svn cp https://svn.apache.org/repos/asf/servicemix/smx4/kernel https://svn.apache.org/repos/asf/felix/karaf Any objections in doing that ? Next steps will include creating a JIRA project and moving all the issues into it (with a KARAF id), then the confluence space. -- Cheers, Guillaume Nodet
[jira] Created: (FELIX-1082) Generate html page about features : see http://fusesource.com/forums/message.jspa?messageID=2005#2005 for the suggestion
Generate html page about features : see http://fusesource.com/forums/message.jspa?messageID=2005#2005 for the suggestion Key: FELIX-1082 URL: https://issues.apache.org/jira/browse/FELIX-1082 Project: Felix Issue Type: Sub-task Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1083) Create new archetype to automatically generate feature.xml file + upload to the maven repo using features-maven-plugin
Create new archetype to automatically generate feature.xml file + upload to the maven repo using features-maven-plugin -- Key: FELIX-1083 URL: https://issues.apache.org/jira/browse/FELIX-1083 Project: Felix Issue Type: Sub-task Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1083) Create new archetype to automatically generate feature.xml file + upload to the maven repo using features-maven-plugin
[ https://issues.apache.org/jira/browse/FELIX-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703753#action_12703753 ] Guillaume Nodet commented on FELIX-1083: Charles Moulliard - 02/Mar/09 02:41 AM add reference to the forum link from which the ideas come [ Show » ] Charles Moulliard - 02/Mar/09 02:41 AM add reference to the forum link from which the ideas come [ Permlink | Edit | Delete | « Hide ] Edell Nolan - 03/Mar/09 10:17 AM I have been working on creating an archetype to generate a feature descriptor automatically if you add in dependencies into a pom.xml file - our maven features plugin does this already and I have the archetype working. But I have a question around having multiple pom.xml files in that you have a root pom and serveral modules. if you then attempt to run this from the root - I get the impression you are looking for a features.xml file that would have covered all the module poms.xml files. so that it will add the features for all dependencies in all the sub modules Is this the case ? or should it be that you just generate the features.xml for each module individually ? [ Show » ] Edell Nolan - 03/Mar/09 10:17 AM I have been working on creating an archetype to generate a feature descriptor automatically if you add in dependencies into a pom.xml file - our maven features plugin does this already and I have the archetype working. But I have a question around having multiple pom.xml files in that you have a root pom and serveral modules. if you then attempt to run this from the root - I get the impression you are looking for a features.xml file that would have covered all the module poms.xml files. so that it will add the features for all dependencies in all the sub modules Is this the case ? or should it be that you just generate the features.xml for each module individually ? [ Permlink | Delete | « Hide ] Charles Moulliard - 04/Mar/09 12:33 AM Personally, I prefer to have one feature file generated when we have a parent pom with several slave pom (= modules). [ Show » ] Charles Moulliard - 04/Mar/09 12:33 AM Personally, I prefer to have one feature file generated when we have a parent pom with several slave pom (= modules). [ Permlink | Delete | « Hide ] Guillaume Nodet - 04/Mar/09 01:19 AM I'm not sure that this is a good idea to generate the features file from the parent pom in case you have modules that are not really part of the feature, like an assembly of something like that. [ Show » ] Guillaume Nodet - 04/Mar/09 01:19 AM I'm not sure that this is a good idea to generate the features file from the parent pom in case you have modules that are not really part of the feature, like an assembly of something like that. [ Permlink | Edit | Delete | « Hide ] Edell Nolan - 04/Mar/09 01:30 AM I was thinking about this a little more and I think it should just be based on one feature.xml file per pom.xml with its dependencies. You can always have one directory that will list all your dependencies and use this to create your features.xml file. I will get this in today hopefully. [ Show » ] Edell Nolan - 04/Mar/09 01:30 AM I was thinking about this a little more and I think it should just be based on one feature.xml file per pom.xml with its dependencies. You can always have one directory that will list all your dependencies and use this to create your features.xml file. I will get this in today hopefully. [ Permlink | Delete | « Hide ] Charles Moulliard - 04/Mar/09 01:31 AM Most of the time, when you work on a OSGI project, you will create in eclipse several eclipse projects, one by bundle. So, it makes sense to create a parent pom pointing to the different modules / bundles and to have one global features file. Here is an example of what I do manually to deploy all my bundles : features feature name=reportincident version=1.0 featurecamel-core/feature featurecamel-spring/feature featurecamel-osgi/feature featurecamel-bindy/feature featureserver/feature bundlemvn:org.apache.camel.example/reportincident.domain/1.0-SNAPSHOT/bundle bundlemvn:org.apache.camel.example/reportincident.service/1.0-SNAPSHOT/bundle bundlemvn:org.apache.camel.example/reportincident.interfaces/1.0-SNAPSHOT/bundle /feature reportincident.domain = maven project = bundle = eclipse project [ Show » ] Charles Moulliard - 04/Mar/09 01:31 AM Most of the time, when you work on a OSGI project, you will create in eclipse several eclipse projects, one by bundle. So, it makes sense to create a parent pom pointing to the different modules / bundles and to have one global features file. Here is an example of what I do manually to deploy all my bundles : features feature name=reportincident version=1.0 featurecamel-core/feature featurecamel-spring/feature featurecamel-osgi/feature featurecamel-bindy/feature featureserver/feature
[jira] Issue Comment Edited: (FELIX-1083) Create new archetype to automatically generate feature.xml file + upload to the maven repo using features-maven-plugin
[ https://issues.apache.org/jira/browse/FELIX-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703753#action_12703753 ] Guillaume Nodet edited comment on FELIX-1083 at 4/28/09 10:21 AM: -- Charles Moulliard - 02/Mar/09 02:41 AM add reference to the forum link from which the ideas come [ Show » ] Charles Moulliard - 02/Mar/09 02:41 AM add reference to the forum link from which the ideas come [ Permlink | Edit | Delete | « Hide ] Edell Nolan - 03/Mar/09 10:17 AM I have been working on creating an archetype to generate a feature descriptor automatically if you add in dependencies into a pom.xml file - our maven features plugin does this already and I have the archetype working. But I have a question around having multiple pom.xml files in that you have a root pom and serveral modules. if you then attempt to run this from the root - I get the impression you are looking for a features.xml file that would have covered all the module poms.xml files. so that it will add the features for all dependencies in all the sub modules Is this the case ? or should it be that you just generate the features.xml for each module individually ? [ Show » ] Edell Nolan - 03/Mar/09 10:17 AM I have been working on creating an archetype to generate a feature descriptor automatically if you add in dependencies into a pom.xml file - our maven features plugin does this already and I have the archetype working. But I have a question around having multiple pom.xml files in that you have a root pom and serveral modules. if you then attempt to run this from the root - I get the impression you are looking for a features.xml file that would have covered all the module poms.xml files. so that it will add the features for all dependencies in all the sub modules Is this the case ? or should it be that you just generate the features.xml for each module individually ? [ Permlink | Delete | « Hide ] Charles Moulliard - 04/Mar/09 12:33 AM Personally, I prefer to have one feature file generated when we have a parent pom with several slave pom (= modules). [ Show » ] Charles Moulliard - 04/Mar/09 12:33 AM Personally, I prefer to have one feature file generated when we have a parent pom with several slave pom (= modules). [ Permlink | Delete | « Hide ] Guillaume Nodet - 04/Mar/09 01:19 AM I'm not sure that this is a good idea to generate the features file from the parent pom in case you have modules that are not really part of the feature, like an assembly of something like that. [ Show » ] Guillaume Nodet - 04/Mar/09 01:19 AM I'm not sure that this is a good idea to generate the features file from the parent pom in case you have modules that are not really part of the feature, like an assembly of something like that. [ Permlink | Edit | Delete | « Hide ] Edell Nolan - 04/Mar/09 01:30 AM I was thinking about this a little more and I think it should just be based on one feature.xml file per pom.xml with its dependencies. You can always have one directory that will list all your dependencies and use this to create your features.xml file. I will get this in today hopefully. [ Show » ] Edell Nolan - 04/Mar/09 01:30 AM I was thinking about this a little more and I think it should just be based on one feature.xml file per pom.xml with its dependencies. You can always have one directory that will list all your dependencies and use this to create your features.xml file. I will get this in today hopefully. [ Permlink | Delete | « Hide ] Charles Moulliard - 04/Mar/09 01:31 AM Most of the time, when you work on a OSGI project, you will create in eclipse several eclipse projects, one by bundle. So, it makes sense to create a parent pom pointing to the different modules / bundles and to have one global features file. Here is an example of what I do manually to deploy all my bundles : features feature name=reportincident version=1.0 featurecamel-core/feature featurecamel-spring/feature featurecamel-osgi/feature featurecamel-bindy/feature featureserver/feature bundlemvn:org.apache.camel.example/reportincident.domain/1.0-SNAPSHOT/bundle bundlemvn:org.apache.camel.example/reportincident.service/1.0-SNAPSHOT/bundle bundlemvn:org.apache.camel.example/reportincident.interfaces/1.0-SNAPSHOT/bundle /feature reportincident.domain = maven project = bundle = eclipse project [ Show » ] Charles Moulliard - 04/Mar/09 01:31 AM Most of the time, when you work on a OSGI project, you will create in eclipse several eclipse projects, one by bundle. So, it makes sense to create a parent pom pointing to the different modules / bundles and to have one global features file. Here is an example of what I do manually to deploy all my bundles : features feature name=reportincident version=1.0 featurecamel-core/feature featurecamel-spring/feature featurecamel-osgi/feature featurecamel-bindy/feature featureserver/feature
[jira] Updated: (FELIX-1083) Create new archetype to automatically generate feature.xml file + upload to the maven repo using features-maven-plugin
[ https://issues.apache.org/jira/browse/FELIX-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-1083: --- Description: Archetype for creating a feature descriptor automatically generated using the maven plugin we already have + upload in the maven repo. Ideally, the descriptor should be created from the user pom.xml profile file or (pom.xml files if the user has created a parent pom.xml with modules) See comments in https://issues.apache.org/activemq/browse/SMX4KNL-217 Create new archetype to automatically generate feature.xml file + upload to the maven repo using features-maven-plugin -- Key: FELIX-1083 URL: https://issues.apache.org/jira/browse/FELIX-1083 Project: Felix Issue Type: Sub-task Reporter: Guillaume Nodet Archetype for creating a feature descriptor automatically generated using the maven plugin we already have + upload in the maven repo. Ideally, the descriptor should be created from the user pom.xml profile file or (pom.xml files if the user has created a parent pom.xml with modules) See comments in https://issues.apache.org/activemq/browse/SMX4KNL-217 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1085) Update wiki
Update wiki --- Key: FELIX-1085 URL: https://issues.apache.org/jira/browse/FELIX-1085 Project: Felix Issue Type: Sub-task Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1084) Create new archetype to manualy create a feature descriptor + upload in the maven repo using features-maven-plugin
[ https://issues.apache.org/jira/browse/FELIX-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-1084: --- Component/s: Karaf Description: one for creating a manually written feature descriptor + upload in the maven repo Create new archetype to manualy create a feature descriptor + upload in the maven repo using features-maven-plugin -- Key: FELIX-1084 URL: https://issues.apache.org/jira/browse/FELIX-1084 Project: Felix Issue Type: Sub-task Components: Karaf Reporter: Guillaume Nodet one for creating a manually written feature descriptor + upload in the maven repo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Jira Permissions
Could someone update the jira permissions for the new committers? Right now I can't even assign issues to myself. Thanks, Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org
[jira] Created: (FELIX-1086) Improve help screens for commands
Improve help screens for commands - Key: FELIX-1086 URL: https://issues.apache.org/jira/browse/FELIX-1086 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Chris Custine Priority: Minor The help screens for the standard commands are largely empty so it would be nice to make a pass through them and document the arguments and some examples similar to Unix man pages. It also looks like the ANSI codes are rendered properly for the help screens so that would be nice to exploit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Jira Permissions
I added you to the Felix Developers group, I think that should give you access. Let me know if it doesn't. - richard On 4/28/09 1:45 PM, Chris Custine wrote: Could someone update the jira permissions for the new committers? Right now I can't even assign issues to myself. Thanks, Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org
[jira] Created: (FELIX-1088) The config/edit command changes does not takes precedence over configuration files in the etc folder at restart
The config/edit command changes does not takes precedence over configuration files in the etc folder at restart --- Key: FELIX-1088 URL: https://issues.apache.org/jira/browse/FELIX-1088 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet If you do the following servicemix config edit org.ops4j.pax.logging servicemix config log4j.appender.out.file /tmp/servicemix.log servicemix config update It does create my servicemix.log file in the /tmp directory and will log stuff there but if I shut the instance down and restart it - it redirects back to the original location for the servicemix.log file in the data directory. = Guillaume Nodet: Actually, this is the currently designed behavior. Configuration updates do not take precedence over the configuration files. So each time the configuration file is changed or reloaded due to a server restart, the changes done via the console are lost. However, this may be improved by saving the changes to the properties file instead of saving the changes directly into the ConfigAdmin service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1087) Unable to log into ServiceMix Kernel using Windows putty SSH client
Unable to log into ServiceMix Kernel using Windows putty SSH client --- Key: FELIX-1087 URL: https://issues.apache.org/jira/browse/FELIX-1087 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet See https://issues.apache.org/jira/browse/SSHD-15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1089) Allow SMX4 kernel to create logfile for the bundles/features
Allow SMX4 kernel to create logfile for the bundles/features Key: FELIX-1089 URL: https://issues.apache.org/jira/browse/FELIX-1089 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Guillaume Nodet I would like to suggest to add a new feature in SMX4 in order to have logfile for bundle (or a feature). The feature xml file could be modified to provide a new attribute logFile=true or false -- feature name=myProject version=1.0 logFile=Yes ... /feature When SMX4 will scan the feature xml file, it will create a log file with the name of the feature + version -- myProject-1.0_log.txt and all the exported classes defined in the MANIFEST-FILE of the project bundle will be added to the file : org.ops4j.pax.logging.cfg in order to allow to set the level to INFO, DEBUG, ... for these packages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1090) Use overriden properties instead of configuring the maven bundle plugin in each module
Use overriden properties instead of configuring the maven bundle plugin in each module -- Key: FELIX-1090 URL: https://issues.apache.org/jira/browse/FELIX-1090 Project: Felix Issue Type: Task Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1091) Re-enable gshell integration tests on windows
Re-enable gshell integration tests on windows - Key: FELIX-1091 URL: https://issues.apache.org/jira/browse/FELIX-1091 Project: Felix Issue Type: Task Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1093) features/uninstall behaves different in version selection than features/install
features/uninstall behaves different in version selection than features/install --- Key: FELIX-1093 URL: https://issues.apache.org/jira/browse/FELIX-1093 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet When using features/install xxx without a version info, than it takes the latest available version. When using features/uninstall xxx without a version info, than it complains if the version isn't 0.0.0. Lars Heinemann added a comment - 11/Feb/09 02:16 AM - edited Uninstalling a feature which contains other features which contain bundles will end up in having the most top feature in state uninstalled but the sub-features and components are no touched. For example: Feature MyFeature | --- MySubFeature1 | | --- Bundle A | | --- Bundle B | --- MySubFeature2 | | --- Bundle C | | --- Bundle D When uninstalling the feature MyFeature the result is this: [uninstalled] MyFeature [ installed ] MySubFeature1 [ installed ] MySubFeature2 This is imho not the correct behaviour. [ Show » ] Lars Heinemann added a comment - 11/Feb/09 02:16 AM - edited Uninstalling a feature which contains other features which contain bundles will end up in having the most top feature in state uninstalled but the sub-features and components are no touched. For example: Feature MyFeature | --- MySubFeature1 | | --- Bundle A | | --- Bundle B | --- MySubFeature2 | | --- Bundle C | | --- Bundle D When uninstalling the feature MyFeature the result is this: [uninstalled] MyFeature [ installed ] MySubFeature1 [ installed ] MySubFeature2 This is imho not the correct behaviour. [ Permlink | Edit | Delete | « Hide ] Guillaume Nodet added a comment - 11/Feb/09 09:26 AM The features/uninstall xxx should automatically select the version of the installed features, else throw an error. [ Show » ] Guillaume Nodet added a comment - 11/Feb/09 09:26 AM The features/uninstall xxx should automatically select the version of the installed features, else throw an error. [ Permlink | Edit | Delete | « Hide ] Guillaume Nodet added a comment - 11/Feb/09 10:59 AM For the uninstall stuff, I'm not sure. Currently we do not keep track of features installed as dependencies. i guess we'd have to. If a feature is installed as a dependency, it should be removed if no longer used because the feature having a dependency on it has been uninstalled. [ Show » ] Guillaume Nodet added a comment - 11/Feb/09 10:59 AM For the uninstall stuff, I'm not sure. Currently we do not keep track of features installed as dependencies. i guess we'd have to. If a feature is installed as a dependency, it should be removed if no longer used because the feature having a dependency on it has been uninstalled. [ Permlink | Edit | Delete | « Hide ] Guillaume Nodet added a comment - 11/Feb/09 11:34 AM Raised a different issue for automaticaly selecting the right version when uninstalling. [ Show » ] Guillaume Nodet added a comment - 11/Feb/09 11:34 AM Raised a different issue for automaticaly selecting the right version when uninstalling. [ Permlink | Delete | « Hide ] Chris Custine added a comment - 11/Feb/09 12:51 PM I noticed the same uninstall issue (not removing dependency features). It seems like we will have to do a considerable amount of dependency tracking to get this to work properly and there are some really difficult conflict resolution issues to consider. I think there is definitely some room to improve the features functionality but I am thinking this should probably be pushed to a later release. [ Show » ] Chris Custine added a comment - 11/Feb/09 12:51 PM I noticed the same uninstall issue (not removing dependency features). It seems like we will have to do a considerable amount of dependency tracking to get this to work properly and there are some really difficult conflict resolution issues to consider. I think there is definitely some room to improve the features functionality but I am thinking this should probably be pushed to a later release. [ Permlink | Edit | Delete | « Hide ] Guillaume Nodet added a comment - 11/Feb/09 02:13 PM Yeah, I fully agree. Let's move that one for 1.2.0 and get 1.1.0 out asap. [ Show » ] Guillaume Nodet added a comment - 11/Feb/09 02:13 PM Yeah, I fully agree. Let's move that one for 1.2.0 and get 1.1.0 out asap. [ Permlink | Delete | « Hide ] Lars Heinemann added a comment - 11/Feb/09 09:29 PM moved to version 1.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1094) Allow live update of configuration by leveraging spring-dm config admin update support
Allow live update of configuration by leveraging spring-dm config admin update support -- Key: FELIX-1094 URL: https://issues.apache.org/jira/browse/FELIX-1094 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Guillaume Nodet This would / should allow dynamically changing the ports numbers for SSH and RMI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1095) Investigate the integration of Pax VFS, as VFS is already used in GShell
Investigate the integration of Pax VFS, as VFS is already used in GShell Key: FELIX-1095 URL: https://issues.apache.org/jira/browse/FELIX-1095 Project: Felix Issue Type: Task Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1096) Ability to create a master / slave configuration at the container level (pointing to the same data dir) using the admin shell
Ability to create a master / slave configuration at the container level (pointing to the same data dir) using the admin shell - Key: FELIX-1096 URL: https://issues.apache.org/jira/browse/FELIX-1096 Project: Felix Issue Type: New Feature Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1086) Improve help screens for commands
[ https://issues.apache.org/jira/browse/FELIX-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine reassigned FELIX-1086: Assignee: Chris Custine Improve help screens for commands - Key: FELIX-1086 URL: https://issues.apache.org/jira/browse/FELIX-1086 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Chris Custine Assignee: Chris Custine Priority: Minor The help screens for the standard commands are largely empty so it would be nice to make a pass through them and document the arguments and some examples similar to Unix man pages. It also looks like the ANSI codes are rendered properly for the help screens so that would be nice to exploit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Jira Permissions
Looks good now. Thanks! -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Tue, Apr 28, 2009 at 11:56 AM, Richard S. Hall he...@ungoverned.orgwrote: I added you to the Felix Developers group, I think that should give you access. Let me know if it doesn't. - richard On 4/28/09 1:45 PM, Chris Custine wrote: Could someone update the jira permissions for the new committers? Right now I can't even assign issues to myself. Thanks, Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org
[jira] Created: (FELIX-1097) ServiceMix - Karaf in base directory notices
ServiceMix - Karaf in base directory notices - Key: FELIX-1097 URL: https://issues.apache.org/jira/browse/FELIX-1097 Project: Felix Issue Type: Bug Components: Karaf Reporter: Robert Burrell Donkin Small documentation fixes related to transition from ServiceMix to Karaf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1097) ServiceMix - Karaf in base directory notices
[ https://issues.apache.org/jira/browse/FELIX-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Burrell Donkin updated FELIX-1097: - Attachment: servicemix-to-karaf.diff Patches NOTICE.txt, README.txt, BUILDING.txt to replace ServiceMix with Karaf ServiceMix - Karaf in base directory notices - Key: FELIX-1097 URL: https://issues.apache.org/jira/browse/FELIX-1097 Project: Felix Issue Type: Bug Components: Karaf Reporter: Robert Burrell Donkin Attachments: servicemix-to-karaf.diff Small documentation fixes related to transition from ServiceMix to Karaf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1010) add java annotation support to felix-scr-plugin
[
https://issues.apache.org/jira/browse/FELIX-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703796#action_12703796
]
Stefan Seifert commented on FELIX-1010:
---
i personally would prefer keeping a single @Property tag with multiple value,
intValue etc. arrays.
one reasing is the @Properties tag - this has one implicit value array of
@Property tag. if defining different @Property, @IntProperty etc. tags this is
getting really ugly like this:
@Properties( values={
@Property(name = prop1, value = value1)
},
intValues={
@IntProperty(name = prop2, value = 5)
})
instead of
@Properties({
@Property(name = prop1, value = value1),
@Property(name = prop2, intValue = 5)
})
add java annotation support to felix-scr-plugin
---
Key: FELIX-1010
URL: https://issues.apache.org/jira/browse/FELIX-1010
Project: Felix
Issue Type: New Feature
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.0.10
Reporter: Stefan Seifert
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin-1.0.11
Attachments: 090329_felix_scrplugin_annotationsupport.patch,
090406_component_patch.patch, 090423_property_sorted_map.patch,
FELIX-1010.patch, scrplugin_annot_090422.patch
goals of this proposal:
- allow definition of SCR components with java annotations instead of QDox
tags
- advantages: strong typing, auto-completion and jump to source documentation
in modern IDEs
- support built-in annotations with 1:1 matching the old scr.* tags, and
allow definition of custom annotations for other felix/scr-based projects to
minimalize syntax overhead
- the QDox tags are still supported, but cannot be mixed with annotations
whithing the same source file
attached to this ticket is a full implemented and tested patch, that supports
all feates supported by the scr.* QDox tags today. some of the more exotic
features are not tested in detail, only the generated descriptors where
compared.
i created a new project scrplugin-annotations, that contains only the
annotations for easy referencing without unwanted transitive dependencies.
i'm not sure if the package and artifact name are well chosen.
Example 1
-
QDox version:
/**
* Service class with QDox annotations.
*
* @scr.component
* @scr.property name=testProperty value=testValue
* @scr.service
*/
public class MinimalServiceQDox implements {
...
Annotation version:
/**
* Service class with java annotations.
*/
@Component
@Property(name = testProperty, value = testValue)
@Service
public class MinimalServiceAnnotations {
...
Example 2
-
QDox version:
/**
* Service class with QDox annotations.
*
* @scr.component name=QDoxName label=theLabel
description=theDescription
*immediate=false enabled=false factory=xx.yy.zz
* @scr.service interface=org.osgi.service.component.ComponentInstance
* servicefactory=true
* @scr.service interface=java.lang.Readable
* @scr.property name=stringProp value=theValue label=thePropLabel
* description=thePropDesc options 0=option0 1=option1
* 2=option2
* @scr.property name=intProp value=5 type=Integer
* @scr.property name=multiProp values.0=multiValue1
values.1=multiValue2
*/
public class ServiceQDox implements ComponentInstance, Readable {
/**
* @scr.reference cardinality=0..1, dynamic=true
*/
MinimalServiceQDox reference;
...
Annotation version:
/**
* Service class with java annotations.
*/
@Component(name = AnnotName, label = theLabel, description =
theDescription, immediate = false, enabled = false, factory = xx.yy.zz)
@Services( { @Service(value = ComponentInstance.class, serviceFactory =
true), @Service(Readable.class) })
@Properties( {
@Property(name = stringProp, value = theValue, label =
thePropLabel, description = thePropDesc, options = {
@PropertyOption(name = 0, value = option0),
@PropertyOption(name = 1, value = option1),
@PropertyOption(name = 2, value = option2) }),
@Property(name = intProp, value = 5, type = Integer.class),
@Property(name = multiProp, value = { multiValue1, multiValue2
}) })
public class ServiceAnnotations implements ComponentInstance, Readable {
@Reference(cardinality = ReferenceCardinality.ZERO_TO_ONE, policy =
ReferencePolicy.DYNAMIC)
MinimalServiceAnnotations reference;
...
Example 3 - using Custom Annotation from other project
--
QDox version:
/**
* Sample servlet with sling mappings.
*
* @scr.component immediate=true
* @scr.service interface=javax.servlet.Servlet
* @scr.property name=sling.servlet.methods value=GET
*
[jira] Created: (FELIX-1098) Switch from spring-dm to blueprint
Switch from spring-dm to blueprint -- Key: FELIX-1098 URL: https://issues.apache.org/jira/browse/FELIX-1098 Project: Felix Issue Type: Task Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1062) Upgrade to latest Felix Runtime
[ https://issues.apache.org/jira/browse/FELIX-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned FELIX-1062: -- Assignee: Guillaume Nodet Upgrade to latest Felix Runtime --- Key: FELIX-1062 URL: https://issues.apache.org/jira/browse/FELIX-1062 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: karaf-1.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1063) Upgrade to latest Felix Bundle Repository
[ https://issues.apache.org/jira/browse/FELIX-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1063. Resolution: Fixed Fix Version/s: karaf-1.0.0 Assignee: Guillaume Nodet Sendingkaraf/pom.xml Transmitting file data . Committed revision 769550. Upgrade to latest Felix Bundle Repository - Key: FELIX-1063 URL: https://issues.apache.org/jira/browse/FELIX-1063 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: karaf-1.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1099) Switch from spring-dm integration tests to pax-exam
Switch from spring-dm integration tests to pax-exam --- Key: FELIX-1099 URL: https://issues.apache.org/jira/browse/FELIX-1099 Project: Felix Issue Type: Task Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
