Re: [DISCUSS] Move Karaf as a TLP
Yeah, sounds even better. On Tue, Jun 1, 2010 at 09:55, Alasdair Nottingham wrote: > Hi, > > How about "an OSGI based runtime for creating enterprise servers". To me the > word assembling implies that everything you need exists in Karaf and it is > just a case of pulling different bits from Karaf together. I don't think this > is what is intended. > > My 2 cents worth. > Alasdair > > Alasdair Nottingham > > On 1 Jun 2010, at 08:12, Guillaume Nodet wrote: > >> Why would we limit Karaf to the integration world ? >> Karaf may be used as the base platform for ActiveMQ, Directory, >> James, Geronimo, ServiceMix. All of those are not necesseraly geared >> toward integration imho, and even if they were, Karaf itself does not >> have anything specific to this area imho. >> >> I still think David's the best choice so far: >> >> "an OSGI based runtime for assembling enterprise servers" >> >> On Tue, Jun 1, 2010 at 09:06, Charles Moulliard wrote: >>> +1 >>> >>> Here is a new suggestion based on remarks : >>> >>> "an OSGI-based runtime for assembling enterprise server applications >>> integration oriented" >>> >>> Kind regards, >>> >>> Charles Moulliard >>> >>> Senior Enterprise Architect (J2EE, .NET, SOA) >>> Apache Camel/ServiceMix Committer >>> >>> *** >>> - Blog : http://cmoulliard.blogspot.com >>> - Twitter : http://twitter.com/cmoulliard >>> - Linkedlin : http://www.linkedin.com/in/charlesmoulliard >>> >>> >>> >>> On Tue, Jun 1, 2010 at 5:01 AM, Freeman Fang wrote: And here is my +1 for moving karaf to a TLP. Best Regards Freeman On 2010-5-31, at 下午5:14, Gert Vanthienen wrote: > L.S., > > Adding my (late) +1 for moving Karaf to a TLP > > Not sure if you're still looking for someone to take an initial stab > at the project goal or if that's being discussed on the Felix PMC at > the moment, but here's my proposal anyway: > "... for the creation and maintenance of > a small, extensible and enterprise-ready OSGi-based server runtime, > capable of being a base framework for building other enterprise > server applications, > as well as the necessary tools, add-ons and components to facilitate > building these applications" > > Regards, > > Gert Vanthienen > > > > On 30 May 2010 22:53, Lukasz Dywicki wrote: >> >> I would like to say 'yes' for TLP (even if my vote doesn't count). >> >> I try contribute Karaf from time to time and I wish continue doing that, >> when it will move to top level too. >> >> For me it does not make sense to try close all OSGi releated things in >> Felix >> project. At this moment we have Aries which is also very closer to OSGi >> but >> it's not a part of Felix. >> >> Best regards, >> Lukasz Dywicki >> >> >> Jarek Gawor-2 wrote: >>> >>> I would like to be involved with this TLP as well. >>> >>> Thanks, >>> Jarek >>> >>> On Friday, May 28, 2010, Guillaume Nodet wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Karaf Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creati
[jira] Created: (FELIX-2381) The default log exception renderer does not print inner exceptions anymore
The default log exception renderer does not print inner exceptions anymore -- Key: FELIX-2381 URL: https://issues.apache.org/jira/browse/FELIX-2381 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 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] Resolved: (FELIX-2380) [gogo] lock contention in piped writer when reader doesn't read all input
[ https://issues.apache.org/jira/browse/FELIX-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2380. --- Resolution: Fixed resolved by reflectively calling PipedInputStream.receivedLast(), which notifies the writer and stops it waiting. > [gogo] lock contention in piped writer when reader doesn't read all input > - > > Key: FELIX-2380 > URL: https://issues.apache.org/jira/browse/FELIX-2380 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > The following completes almost immediately: > g! cat conf/config.properties | grep Apache > # Licensed to the Apache Software Foundation (ASF) under one > # to you under the Apache License, Version 2.0 (the > true > but adding the --quiet flag to grep makes it take 1000mS longer: > g! cat conf/config.properties | grep --quiet Apache > true > This is because grep stops reading its input as soon as it has seen the first > match when --quiet is given. > The same delay also occurs if you pipe into a command that doesn't read its > input: > g! cat conf/config.properties | echo > The contention occurs because the writer (cat) is blocked on wait(1024) in > PipedInputStream when the 1024 byte buffer is full. It is only unblocked when > the reader (grep) reads more input. It is NOT unblocked when the reader > closes the piped input. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2380) [gogo] lock contention in piped writer when reader doesn't read all input
[ https://issues.apache.org/jira/browse/FELIX-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-2380: -- Fix Version/s: gogo-0.6.0 > [gogo] lock contention in piped writer when reader doesn't read all input > - > > Key: FELIX-2380 > URL: https://issues.apache.org/jira/browse/FELIX-2380 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > The following completes almost immediately: > g! cat conf/config.properties | grep Apache > # Licensed to the Apache Software Foundation (ASF) under one > # to you under the Apache License, Version 2.0 (the > true > but adding the --quiet flag to grep makes it take 1000mS longer: > g! cat conf/config.properties | grep --quiet Apache > true > This is because grep stops reading its input as soon as it has seen the first > match when --quiet is given. > The same delay also occurs if you pipe into a command that doesn't read its > input: > g! cat conf/config.properties | echo > The contention occurs because the writer (cat) is blocked on wait(1024) in > PipedInputStream when the 1024 byte buffer is full. It is only unblocked when > the reader (grep) reads more input. It is NOT unblocked when the reader > closes the piped input. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2375) [gogo] when supplied args can't be coerced, the error message prints the arg values, rather than their types
[ https://issues.apache.org/jira/browse/FELIX-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2375. --- Resolution: Fixed fixed as described, e.g. g! headers x gogo: IllegalArgumentException: Cannot coerce headers(String) to any of [(Bundle[])] > [gogo] when supplied args can't be coerced, the error message prints the arg > values, rather than their types > > > Key: FELIX-2375 > URL: https://issues.apache.org/jira/browse/FELIX-2375 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > e.g. > g! headers (bundles) > gogo: IllegalArgumentException: Cannot coerce > headers[[org.apache.felix.framework [0], org.apache.felix.bundlerepository > [1], org.apache.felix.gogo.command [2], org.apache.felix.gogo.runtime [3], > org.apache.felix.gogo.shell [4]]] to any of [(Bundle[])] > This message would be better as: > gogo: IllegalArgumentException: Cannot coerce headers(ArrayList) to any of > [(Bundle[])] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2375) [gogo] when supplied args can't be coerced, the error message prints the arg values, rather than their types
[ https://issues.apache.org/jira/browse/FELIX-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-2375: -- Assignee: Derek Baum Fix Version/s: gogo-0.6.0 > [gogo] when supplied args can't be coerced, the error message prints the arg > values, rather than their types > > > Key: FELIX-2375 > URL: https://issues.apache.org/jira/browse/FELIX-2375 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > e.g. > g! headers (bundles) > gogo: IllegalArgumentException: Cannot coerce > headers[[org.apache.felix.framework [0], org.apache.felix.bundlerepository > [1], org.apache.felix.gogo.command [2], org.apache.felix.gogo.runtime [3], > org.apache.felix.gogo.shell [4]]] to any of [(Bundle[])] > This message would be better as: > gogo: IllegalArgumentException: Cannot coerce headers(ArrayList) to any of > [(Bundle[])] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-2378) Deadlock in Felix Shell implementation
[ https://issues.apache.org/jira/browse/FELIX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Berger closed FELIX-2378. --- Ok. Works perfectly now, no deadlocks anymore :-) Thank you very much for the quick bugfix. > Deadlock in Felix Shell implementation > -- > > Key: FELIX-2378 > URL: https://issues.apache.org/jira/browse/FELIX-2378 > Project: Felix > Issue Type: Bug > Components: Shell >Affects Versions: shell-1.4.2 > Environment: Felix Framework Version 2.0.5 > SunOS castor 5.10 Generic_13-06 sun4u sparc SUNW,Sun-Fire-V890 > java version "1.6.0_12" > Java(TM) SE Runtime Environment (build 1.6.0_12-b04) > Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) >Reporter: Alexander Berger >Assignee: Richard S. Hall > Fix For: shell-1.6.0 > > Attachments: Activator.patch > > > The class org.apache.felix.shell.impl.Activator$ShellServiceImpl makes heavy > use of synchronized methods which synchronized on the ShellServiceImpl > itself. This causes a deadlock if a refresh/resolve (PackageAdmin) cycle is > initiated using the shell and some Commands are about to be removed from the > OSGi service registry (as a result of the refresh/resolve). > This happens because executeCommand locks the ShellServiceImpl instance and > later on when the PackageAdmin indirectly triggers the removal of some > registered Commands ShellServiceImpl.removeCommand(...) will try to lock the > same ShellServiceImpl instance which is still locked by the executeCommand. > I have created a patch for org.apache.felix.shell.impl.Activator (see > Attachment) for a possible solution of this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2378) Deadlock in Felix Shell implementation
[ https://issues.apache.org/jira/browse/FELIX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-2378. Resolution: Fixed Since I saw some other minor concurrency issues, I decided to convert shell to use the ServiceTracker which I believe will also address your deadlock issues. Please close this issue if you are satisfied with the result. Thanks. > Deadlock in Felix Shell implementation > -- > > Key: FELIX-2378 > URL: https://issues.apache.org/jira/browse/FELIX-2378 > Project: Felix > Issue Type: Bug > Components: Shell >Affects Versions: shell-1.4.2 > Environment: Felix Framework Version 2.0.5 > SunOS castor 5.10 Generic_13-06 sun4u sparc SUNW,Sun-Fire-V890 > java version "1.6.0_12" > Java(TM) SE Runtime Environment (build 1.6.0_12-b04) > Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) >Reporter: Alexander Berger >Assignee: Richard S. Hall > Fix For: shell-1.6.0 > > Attachments: Activator.patch > > > The class org.apache.felix.shell.impl.Activator$ShellServiceImpl makes heavy > use of synchronized methods which synchronized on the ShellServiceImpl > itself. This causes a deadlock if a refresh/resolve (PackageAdmin) cycle is > initiated using the shell and some Commands are about to be removed from the > OSGi service registry (as a result of the refresh/resolve). > This happens because executeCommand locks the ShellServiceImpl instance and > later on when the PackageAdmin indirectly triggers the removal of some > registered Commands ShellServiceImpl.removeCommand(...) will try to lock the > same ShellServiceImpl instance which is still locked by the executeCommand. > I have created a patch for org.apache.felix.shell.impl.Activator (see > Attachment) for a possible solution of this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-2379) Use service tracker in shell to track commands
[ https://issues.apache.org/jira/browse/FELIX-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-2379. -- Resolution: Fixed Committed patch. > Use service tracker in shell to track commands > -- > > Key: FELIX-2379 > URL: https://issues.apache.org/jira/browse/FELIX-2379 > Project: Felix > Issue Type: Improvement >Affects Versions: shell-1.4.2 >Reporter: Richard S. Hall >Assignee: Richard S. Hall > Fix For: shell-1.6.0 > > > The way shell is tracking command services isn't completely correct, we > should switch to ServiceTracker. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2380) [gogo] lock contention in piped writer when reader doesn't read all input
[gogo] lock contention in piped writer when reader doesn't read all input - Key: FELIX-2380 URL: https://issues.apache.org/jira/browse/FELIX-2380 Project: Felix Issue Type: Bug Components: Gogo Reporter: Derek Baum Assignee: Derek Baum Priority: Minor The following completes almost immediately: g! cat conf/config.properties | grep Apache # Licensed to the Apache Software Foundation (ASF) under one # to you under the Apache License, Version 2.0 (the true but adding the --quiet flag to grep makes it take 1000mS longer: g! cat conf/config.properties | grep --quiet Apache true This is because grep stops reading its input as soon as it has seen the first match when --quiet is given. The same delay also occurs if you pipe into a command that doesn't read its input: g! cat conf/config.properties | echo The contention occurs because the writer (cat) is blocked on wait(1024) in PipedInputStream when the 1024 byte buffer is full. It is only unblocked when the reader (grep) reads more input. It is NOT unblocked when the reader closes the piped input. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FELIX-2378) Deadlock in Felix Shell implementation
[ https://issues.apache.org/jira/browse/FELIX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reopened FELIX-2378: On second thought, I think I will address this a different way. > Deadlock in Felix Shell implementation > -- > > Key: FELIX-2378 > URL: https://issues.apache.org/jira/browse/FELIX-2378 > Project: Felix > Issue Type: Bug > Components: Shell >Affects Versions: shell-1.4.2 > Environment: Felix Framework Version 2.0.5 > SunOS castor 5.10 Generic_13-06 sun4u sparc SUNW,Sun-Fire-V890 > java version "1.6.0_12" > Java(TM) SE Runtime Environment (build 1.6.0_12-b04) > Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) >Reporter: Alexander Berger >Assignee: Richard S. Hall > Fix For: shell-1.6.0 > > Attachments: Activator.patch > > > The class org.apache.felix.shell.impl.Activator$ShellServiceImpl makes heavy > use of synchronized methods which synchronized on the ShellServiceImpl > itself. This causes a deadlock if a refresh/resolve (PackageAdmin) cycle is > initiated using the shell and some Commands are about to be removed from the > OSGi service registry (as a result of the refresh/resolve). > This happens because executeCommand locks the ShellServiceImpl instance and > later on when the PackageAdmin indirectly triggers the removal of some > registered Commands ShellServiceImpl.removeCommand(...) will try to lock the > same ShellServiceImpl instance which is still locked by the executeCommand. > I have created a patch for org.apache.felix.shell.impl.Activator (see > Attachment) for a possible solution of this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2379) Use service tracker in shell to track commands
Use service tracker in shell to track commands -- Key: FELIX-2379 URL: https://issues.apache.org/jira/browse/FELIX-2379 Project: Felix Issue Type: Improvement Affects Versions: shell-1.4.2 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: shell-1.6.0 The way shell is tracking command services isn't completely correct, we should switch to ServiceTracker. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2378) Deadlock in Felix Shell implementation
[ https://issues.apache.org/jira/browse/FELIX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-2378. Resolution: Fixed Applied patch with a few minor modifications. Please close if you are satisfied, thanks. > Deadlock in Felix Shell implementation > -- > > Key: FELIX-2378 > URL: https://issues.apache.org/jira/browse/FELIX-2378 > Project: Felix > Issue Type: Bug > Components: Shell >Affects Versions: shell-1.4.2 > Environment: Felix Framework Version 2.0.5 > SunOS castor 5.10 Generic_13-06 sun4u sparc SUNW,Sun-Fire-V890 > java version "1.6.0_12" > Java(TM) SE Runtime Environment (build 1.6.0_12-b04) > Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) >Reporter: Alexander Berger >Assignee: Richard S. Hall > Fix For: shell-1.6.0 > > Attachments: Activator.patch > > > The class org.apache.felix.shell.impl.Activator$ShellServiceImpl makes heavy > use of synchronized methods which synchronized on the ShellServiceImpl > itself. This causes a deadlock if a refresh/resolve (PackageAdmin) cycle is > initiated using the shell and some Commands are about to be removed from the > OSGi service registry (as a result of the refresh/resolve). > This happens because executeCommand locks the ShellServiceImpl instance and > later on when the PackageAdmin indirectly triggers the removal of some > registered Commands ShellServiceImpl.removeCommand(...) will try to lock the > same ShellServiceImpl instance which is still locked by the executeCommand. > I have created a patch for org.apache.felix.shell.impl.Activator (see > Attachment) for a possible solution of this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2378) Deadlock in Felix Shell implementation
[ https://issues.apache.org/jira/browse/FELIX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2378: --- Assignee: Richard S. Hall Fix Version/s: shell-1.6.0 > Deadlock in Felix Shell implementation > -- > > Key: FELIX-2378 > URL: https://issues.apache.org/jira/browse/FELIX-2378 > Project: Felix > Issue Type: Bug > Components: Shell >Affects Versions: shell-1.4.2 > Environment: Felix Framework Version 2.0.5 > SunOS castor 5.10 Generic_13-06 sun4u sparc SUNW,Sun-Fire-V890 > java version "1.6.0_12" > Java(TM) SE Runtime Environment (build 1.6.0_12-b04) > Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) >Reporter: Alexander Berger >Assignee: Richard S. Hall > Fix For: shell-1.6.0 > > Attachments: Activator.patch > > > The class org.apache.felix.shell.impl.Activator$ShellServiceImpl makes heavy > use of synchronized methods which synchronized on the ShellServiceImpl > itself. This causes a deadlock if a refresh/resolve (PackageAdmin) cycle is > initiated using the shell and some Commands are about to be removed from the > OSGi service registry (as a result of the refresh/resolve). > This happens because executeCommand locks the ShellServiceImpl instance and > later on when the PackageAdmin indirectly triggers the removal of some > registered Commands ShellServiceImpl.removeCommand(...) will try to lock the > same ShellServiceImpl instance which is still locked by the executeCommand. > I have created a patch for org.apache.felix.shell.impl.Activator (see > Attachment) for a possible solution of this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Error with UPnP Base driver
On 01/06/2010 1.58, charbel el_kaed wrote: > > Hi Stefano, > > Thanks for your reply. > > I can't actually touch those bundles. Is there another way to do so ? Have you checked if the hypothesis regarding the import/export headers of bundle 20 and 22 are correct? If they aren't then the source of the problem is somewhere else. If the hypothesis are correct then you can change the import-package header of the "UPnP Base Driver" in order to force the loading of the classes from the bundle 0 by means of the bundle-symbolic-name parameter of import-package header (see OSGi Service Platform Release 4 Version 4.2 page 52). > > Kind Regards, > Charbel. >
[jira] Updated: (FELIX-2378) Deadlock in Felix Shell implementation
[ https://issues.apache.org/jira/browse/FELIX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Berger updated FELIX-2378: Attachment: Activator.patch Patch for org.apache.felix.shell.impl.Activator which used more fine grained locking to avoid deadlock. > Deadlock in Felix Shell implementation > -- > > Key: FELIX-2378 > URL: https://issues.apache.org/jira/browse/FELIX-2378 > Project: Felix > Issue Type: Bug > Components: Shell >Affects Versions: shell-1.4.2 > Environment: Felix Framework Version 2.0.5 > SunOS castor 5.10 Generic_13-06 sun4u sparc SUNW,Sun-Fire-V890 > java version "1.6.0_12" > Java(TM) SE Runtime Environment (build 1.6.0_12-b04) > Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) >Reporter: Alexander Berger > Attachments: Activator.patch > > > The class org.apache.felix.shell.impl.Activator$ShellServiceImpl makes heavy > use of synchronized methods which synchronized on the ShellServiceImpl > itself. This causes a deadlock if a refresh/resolve (PackageAdmin) cycle is > initiated using the shell and some Commands are about to be removed from the > OSGi service registry (as a result of the refresh/resolve). > This happens because executeCommand locks the ShellServiceImpl instance and > later on when the PackageAdmin indirectly triggers the removal of some > registered Commands ShellServiceImpl.removeCommand(...) will try to lock the > same ShellServiceImpl instance which is still locked by the executeCommand. > I have created a patch for org.apache.felix.shell.impl.Activator (see > Attachment) for a possible solution of this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2378) Deadlock in Felix Shell implementation
Deadlock in Felix Shell implementation -- Key: FELIX-2378 URL: https://issues.apache.org/jira/browse/FELIX-2378 Project: Felix Issue Type: Bug Components: Shell Affects Versions: shell-1.4.2 Environment: Felix Framework Version 2.0.5 SunOS castor 5.10 Generic_13-06 sun4u sparc SUNW,Sun-Fire-V890 java version "1.6.0_12" Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) Reporter: Alexander Berger The class org.apache.felix.shell.impl.Activator$ShellServiceImpl makes heavy use of synchronized methods which synchronized on the ShellServiceImpl itself. This causes a deadlock if a refresh/resolve (PackageAdmin) cycle is initiated using the shell and some Commands are about to be removed from the OSGi service registry (as a result of the refresh/resolve). This happens because executeCommand locks the ShellServiceImpl instance and later on when the PackageAdmin indirectly triggers the removal of some registered Commands ShellServiceImpl.removeCommand(...) will try to lock the same ShellServiceImpl instance which is still locked by the executeCommand. I have created a patch for org.apache.felix.shell.impl.Activator (see Attachment) for a possible solution of this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2376) Installing camel-cxf feature fails with Woodstock complaining about J2SE 1.4 environment
[
https://issues.apache.org/jira/browse/FELIX-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873922#action_12873922
]
Claus Ibsen commented on FELIX-2376:
Okay I found a workaround / solution to it.
In the etc/config.properties you can comment out the following
# OSGi Execution Environment
###org.osgi.framework.executionenvironment=J2SE-1.5
This is the only change I have done. I have kept to use felix as osgi framework.
And then camel-cxf can be installed
[installed ] [2.5.6.SEC01] spring karaf-1.6.0
[installed ] [1.2.0 ] spring-dmkaraf-1.6.0
[uninstalled] [1.6.0 ] wrapper karaf-1.6.0
[uninstalled] [1.6.0 ] obr karaf-1.6.0
[uninstalled] [1.6.0 ] http karaf-1.6.0
[uninstalled] [1.6.0 ] war karaf-1.6.0
[uninstalled] [1.6.0 ] webconsole karaf-1.6.0
[installed ] [1.6.0 ] ssh karaf-1.6.0
[installed ] [1.6.0 ] management karaf-1.6.0
[installed ] [2.5.6.SEC01] spring repo-0
[installed ] [1.2.0 ] spring-dmrepo-0
[installed ] [2.3.0 ] http repo-0
[uninstalled] [2.3.0 ] camelrepo-0
[installed ] [2.3.0 ] camel-core repo-0
[installed ] [2.3.0 ] camel-spring-osgirepo-0
[uninstalled] [2.3.0 ] camel-test repo-0
[installed ] [2.3.0 ] camel-cxfrepo-0
> Installing camel-cxf feature fails with Woodstock complaining about J2SE 1.4
> environment
>
>
> Key: FELIX-2376
> URL: https://issues.apache.org/jira/browse/FELIX-2376
> Project: Felix
> Issue Type: Bug
>Affects Versions: karaf 1.6.0
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_17
> OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac"
>Reporter: Claus Ibsen
>
> 1. Download Apache Felix Karaf 1.6.0
> 2. bin/karaf
> 3. features:addUrl mvn:org.apache.camel.karaf/apache-camel/2.3.0/xml/features
> 4. features:list
> {code}
> ka...@root> features:list
> State Version Name Repository
> [uninstalled] [2.5.6.SEC01] spring karaf-1.6.0
> [uninstalled] [1.2.0 ] spring-dmkaraf-1.6.0
> [uninstalled] [1.6.0 ] wrapper karaf-1.6.0
> [uninstalled] [1.6.0 ] obr karaf-1.6.0
> [uninstalled] [1.6.0 ] http karaf-1.6.0
> [uninstalled] [1.6.0 ] war karaf-1.6.0
> [uninstalled] [1.6.0 ] webconsole karaf-1.6.0
> [installed ] [1.6.0 ] ssh karaf-1.6.0
> [installed ] [1.6.0 ] management karaf-1.6.0
> [uninstalled] [2.5.6.SEC01] spring repo-0
> [uninstalled] [1.2.0 ] spring-dmrepo-0
> [uninstalled] [2.3.0 ] http repo-0
> [uninstalled] [2.3.0 ] camelrepo-0
> [uninstalled] [2.3.0 ] camel-core repo-0
> [uninstalled] [2.3.0 ] camel-spring-osgirepo-0
> [uninstalled] [2.3.0 ] camel-test repo-0
> [uninstalled] [2.3.0 ] camel-cxfrepo-0
> [uninstalled] [2.3.0 ] camel-cache repo-0
> [uninstalled] [2.3.0 ] camel-castor repo-0
> [uninstalled] [2.3.0 ] camel-crypto repo-0
> [uninstalled] [2.3.0 ] camel-dozer repo-0
> [uninstalled] [2.3.0 ] camel-http repo-0
> [uninstalled] [2.3.0 ] camel-http4 repo-0
> [uninstalled] [2.3.0 ] camel-mina repo-0
> [uninstalled] [2.3.0 ] camel-jetty repo-0
> [uninstalled] [2.3.0 ] camel-servletrepo-0
> [uninstalled] [2.3.0 ] camel-jmsrepo-0
> [uninstalled] [2.3.0 ] camel-amqp repo-0
> [uninstalled] [2.3.0 ] camel-atom repo-0
> [uninstalled] [2.3.0 ] camel-bamrepo-0
> [uninstalled] [2.3.0 ] camel-bindy repo-0
> [uninstalled] [2.3.0 ] camel-cometd repo-0
> [uninstalled] [2.3.0 ] camel-csvrepo-0
> [uninstalled] [2.3.0 ] camel-flatpack repo-0
> [uninstalled] [2.3.0 ] camel-freemarker repo-0
> [uninstalled] [2.3.0 ] camel-ftprepo-0
> [uninstalled] [2.3.0 ] camel-guice repo-0
> [uninstalled] [2.3.0 ] camel-groovy repo-0
> [uninstalled] [2.3.0 ] camel-hl7repo-0
> [uninstalled] [2.3.0 ] camel-hawtdb repo-0
> [uninstalled] [2.3.0 ] came
[jira] Created: (FELIX-2377) info - Should output the exact JRE version used
info - Should output the exact JRE version used --- Key: FELIX-2377 URL: https://issues.apache.org/jira/browse/FELIX-2377 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Claus Ibsen When using info in the osgi shell you get some great details about the runtime. However the JVM does not output which exact JRE version is being in used. Or at least that build number is not easy to identify if its JDK 1.6.0_17 or 1.6.0_20 etc. ka...@root> info Karaf Karaf home /Users/davsclaus/Downloads/apache-felix-karaf-1.6.0 Karaf base /Users/davsclaus/Downloads/apache-felix-karaf-1.6.0 OSGi Framework org.apache.felix.framework - 2.0.5 JVM Java Virtual MachineJava HotSpot(TM) 64-Bit Server VM version 14.3-b01-101 Vendor Apple Inc. Uptime 3 minutes Total compile time 8.703 seconds Threads Live threads33 Daemon threads 26 Peak36 Total started 75 Memory Current heap size 67,221 kbytes Maximum heap size 466,048 kbytes Committed heap size 146,176 kbytes Pending objects 0 Garbage collector Name = 'PS Scavenge', Collections = 9, Time = 0.132 seconds Garbage collector Name = 'PS MarkSweep', Collections = 1, Time = 0.073 seconds Classes Current classes loaded 3,760 Total classes loaded3,761 Total classes unloaded 1 Operating system NameMac OS X version 10.6.3 Architecturex86_64 Processors 2 So if you under JVM have also listed Java version 1.6.0_17 Just as you see when using java -version from the cmd line -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2376) Installing camel-cxf feature fails with Woodstock complaining about J2SE 1.4 environment
Installing camel-cxf feature fails with Woodstock complaining about J2SE 1.4
environment
Key: FELIX-2376
URL: https://issues.apache.org/jira/browse/FELIX-2376
Project: Felix
Issue Type: Bug
Affects Versions: karaf 1.6.0
Environment: Maven version: 2.0.9
Java version: 1.6.0_17
OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac"
Reporter: Claus Ibsen
1. Download Apache Felix Karaf 1.6.0
2. bin/karaf
3. features:addUrl mvn:org.apache.camel.karaf/apache-camel/2.3.0/xml/features
4. features:list
{code}
ka...@root> features:list
State Version Name Repository
[uninstalled] [2.5.6.SEC01] spring karaf-1.6.0
[uninstalled] [1.2.0 ] spring-dmkaraf-1.6.0
[uninstalled] [1.6.0 ] wrapper karaf-1.6.0
[uninstalled] [1.6.0 ] obr karaf-1.6.0
[uninstalled] [1.6.0 ] http karaf-1.6.0
[uninstalled] [1.6.0 ] war karaf-1.6.0
[uninstalled] [1.6.0 ] webconsole karaf-1.6.0
[installed ] [1.6.0 ] ssh karaf-1.6.0
[installed ] [1.6.0 ] management karaf-1.6.0
[uninstalled] [2.5.6.SEC01] spring repo-0
[uninstalled] [1.2.0 ] spring-dmrepo-0
[uninstalled] [2.3.0 ] http repo-0
[uninstalled] [2.3.0 ] camelrepo-0
[uninstalled] [2.3.0 ] camel-core repo-0
[uninstalled] [2.3.0 ] camel-spring-osgirepo-0
[uninstalled] [2.3.0 ] camel-test repo-0
[uninstalled] [2.3.0 ] camel-cxfrepo-0
[uninstalled] [2.3.0 ] camel-cache repo-0
[uninstalled] [2.3.0 ] camel-castor repo-0
[uninstalled] [2.3.0 ] camel-crypto repo-0
[uninstalled] [2.3.0 ] camel-dozer repo-0
[uninstalled] [2.3.0 ] camel-http repo-0
[uninstalled] [2.3.0 ] camel-http4 repo-0
[uninstalled] [2.3.0 ] camel-mina repo-0
[uninstalled] [2.3.0 ] camel-jetty repo-0
[uninstalled] [2.3.0 ] camel-servletrepo-0
[uninstalled] [2.3.0 ] camel-jmsrepo-0
[uninstalled] [2.3.0 ] camel-amqp repo-0
[uninstalled] [2.3.0 ] camel-atom repo-0
[uninstalled] [2.3.0 ] camel-bamrepo-0
[uninstalled] [2.3.0 ] camel-bindy repo-0
[uninstalled] [2.3.0 ] camel-cometd repo-0
[uninstalled] [2.3.0 ] camel-csvrepo-0
[uninstalled] [2.3.0 ] camel-flatpack repo-0
[uninstalled] [2.3.0 ] camel-freemarker repo-0
[uninstalled] [2.3.0 ] camel-ftprepo-0
[uninstalled] [2.3.0 ] camel-guice repo-0
[uninstalled] [2.3.0 ] camel-groovy repo-0
[uninstalled] [2.3.0 ] camel-hl7repo-0
[uninstalled] [2.3.0 ] camel-hawtdb repo-0
[uninstalled] [2.3.0 ] camel-ibatis repo-0
[uninstalled] [2.3.0 ] camel-ircrepo-0
[uninstalled] [2.3.0 ] camel-jacksonrepo-0
[uninstalled] [2.3.0 ] camel-jaxb repo-0
[uninstalled] [2.3.0 ] camel-jcrrepo-0
[uninstalled] [2.3.0 ] camel-jing repo-0
[uninstalled] [2.3.0 ] camel-jdbc repo-0
[uninstalled] [2.3.0 ] camel-josql repo-0
[uninstalled] [2.3.0 ] camel-jparepo-0
[uninstalled] [2.3.0 ] camel-jxpath repo-0
[uninstalled] [2.3.0 ] camel-juel repo-0
[uninstalled] [2.3.0 ] camel-ldap repo-0
[uninstalled] [2.3.0 ] camel-lucene repo-0
[uninstalled] [2.3.0 ] camel-mail repo-0
[uninstalled] [2.3.0 ] camel-msvrepo-0
[uninstalled] [2.3.0 ] camel-mvel repo-0
[uninstalled] [2.3.0 ] camel-nagios repo-0
[uninstalled] [2.3.0 ] camel-netty repo-0
[uninstalled] [2.3.0 ] camel-ognl repo-0
[uninstalled] [2.3.0 ] camel-printerrepo-0
[uninstalled] [2.3.0 ] camel-protobuf repo-0
[uninstalled] [2.3.0 ] camel-quartz repo-0
[uninstalled] [2.3.0 ] camel-restletrepo-0
[uninstalled] [2.3.0 ] camel-rmirepo-0
[uninstalled] [2.3.0 ] camel-rssrepo-0
[uninstalled] [2.3.0 ] camel-saxon repo-0
[uninstalled] [2.3.0 ] camel-scala repo-0
[uninstalled] [2.3.0 ] camel-script repo-0
[uninstalled] [2.3.0 ] camel-smpp repo-0
[uninstalled] [2.3.0 ] cam
Re: [DISCUSS] Move Karaf as a TLP
Hi, How about "an OSGI based runtime for creating enterprise servers". To me the word assembling implies that everything you need exists in Karaf and it is just a case of pulling different bits from Karaf together. I don't think this is what is intended. My 2 cents worth. Alasdair Alasdair Nottingham On 1 Jun 2010, at 08:12, Guillaume Nodet wrote: > Why would we limit Karaf to the integration world ? > Karaf may be used as the base platform for ActiveMQ, Directory, > James, Geronimo, ServiceMix. All of those are not necesseraly geared > toward integration imho, and even if they were, Karaf itself does not > have anything specific to this area imho. > > I still think David's the best choice so far: > > "an OSGI based runtime for assembling enterprise servers" > > On Tue, Jun 1, 2010 at 09:06, Charles Moulliard wrote: >> +1 >> >> Here is a new suggestion based on remarks : >> >> "an OSGI-based runtime for assembling enterprise server applications >> integration oriented" >> >> Kind regards, >> >> Charles Moulliard >> >> Senior Enterprise Architect (J2EE, .NET, SOA) >> Apache Camel/ServiceMix Committer >> >> *** >> - Blog : http://cmoulliard.blogspot.com >> - Twitter : http://twitter.com/cmoulliard >> - Linkedlin : http://www.linkedin.com/in/charlesmoulliard >> >> >> >> On Tue, Jun 1, 2010 at 5:01 AM, Freeman Fang wrote: >>> And here is my +1 for moving karaf to a TLP. >>> >>> Best Regards >>> Freeman >>> On 2010-5-31, at 下午5:14, Gert Vanthienen wrote: >>> L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: "... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications" Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki wrote: > > I would like to say 'yes' for TLP (even if my vote doesn't count). > > I try contribute Karaf from time to time and I wish continue doing that, > when it will move to top level too. > > For me it does not make sense to try close all OSGi releated things in > Felix > project. At this moment we have Aries which is also very closer to OSGi > but > it's not a part of Felix. > > Best regards, > Lukasz Dywicki > > > Jarek Gawor-2 wrote: >> >> I would like to be involved with this TLP as well. >> >> Thanks, >> Jarek >> >> On Friday, May 28, 2010, Guillaume Nodet wrote: >>> >>> It seems there is a consensus to move Karaf as a TLP, at least amongst >>> people involved in Karaf (the other felix committers haven't really >>> expressed any opinion). >>> >>> I think the next steps would be to draft a proposed resolution to the >>> board, >>> which would include: >>> * the project goal >>> * the project PMC (including the chair) >>> >>> In order to create an open community from the start, I'd like to invite >>> anyone with an Apache account willing to contribute to Karaf to raise >>> hands >>> so that we can build this list. I don't think opening it wider for now >>> would be wise, but I do thing we should have a very low entry bar for >>> committership (but that can be discussed later). >>> >>> I'll try to come up with a proposal for Karaf's project goal asap, but >>> anyone is welcome to give it a try and propose some wording. >>> >>> FWIW, it would like the following, we just need to fill the : >>> >>> WHEREAS, the Board of Directors deems it to be in the best >>> interests of the Foundation and consistent with the >>> Foundation's purpose to establish a Project Management >>> Committee charged with the creation and maintenance of >>> open-source software related to a machine learning platform >>> for distribution at no charge to the public. >>> >>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management >>> Committee (PMC), to be known as the "Apache Karaf Project", >>> be and hereby is established pursuant to Bylaws of the >>> Foundation; and be it further >>> >>> RESOLVED, that the Apache Karaf Project be and hereby is >>> responsible for the creation and maintenance of software >>> related to XXX; and be it further >>> >>> RESOLVED, that the office of "Vice President, Apache Karaf" be >>> and here
Re: [DISCUSS] Move Karaf as a TLP
You are right : "integration" is too restrictive ;-) Kind regards, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel/ServiceMix Committer *** - Blog : http://cmoulliard.blogspot.com - Twitter : http://twitter.com/cmoulliard - Linkedlin : http://www.linkedin.com/in/charlesmoulliard On Tue, Jun 1, 2010 at 9:12 AM, Guillaume Nodet wrote: > Why would we limit Karaf to the integration world ? > Karaf may be used as the base platform for ActiveMQ, Directory, > James, Geronimo, ServiceMix. All of those are not necesseraly geared > toward integration imho, and even if they were, Karaf itself does not > have anything specific to this area imho. > > I still think David's the best choice so far: > > "an OSGI based runtime for assembling enterprise servers" > > On Tue, Jun 1, 2010 at 09:06, Charles Moulliard wrote: >> +1 >> >> Here is a new suggestion based on remarks : >> >> "an OSGI-based runtime for assembling enterprise server applications >> integration oriented" >> >> Kind regards, >> >> Charles Moulliard >> >> Senior Enterprise Architect (J2EE, .NET, SOA) >> Apache Camel/ServiceMix Committer >> >> *** >> - Blog : http://cmoulliard.blogspot.com >> - Twitter : http://twitter.com/cmoulliard >> - Linkedlin : http://www.linkedin.com/in/charlesmoulliard >> >> >> >> On Tue, Jun 1, 2010 at 5:01 AM, Freeman Fang wrote: >>> And here is my +1 for moving karaf to a TLP. >>> >>> Best Regards >>> Freeman >>> On 2010-5-31, at 下午5:14, Gert Vanthienen wrote: >>> L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: "... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications" Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki wrote: > > I would like to say 'yes' for TLP (even if my vote doesn't count). > > I try contribute Karaf from time to time and I wish continue doing that, > when it will move to top level too. > > For me it does not make sense to try close all OSGi releated things in > Felix > project. At this moment we have Aries which is also very closer to OSGi > but > it's not a part of Felix. > > Best regards, > Lukasz Dywicki > > > Jarek Gawor-2 wrote: >> >> I would like to be involved with this TLP as well. >> >> Thanks, >> Jarek >> >> On Friday, May 28, 2010, Guillaume Nodet wrote: >>> >>> It seems there is a consensus to move Karaf as a TLP, at least amongst >>> people involved in Karaf (the other felix committers haven't really >>> expressed any opinion). >>> >>> I think the next steps would be to draft a proposed resolution to the >>> board, >>> which would include: >>> * the project goal >>> * the project PMC (including the chair) >>> >>> In order to create an open community from the start, I'd like to invite >>> anyone with an Apache account willing to contribute to Karaf to raise >>> hands >>> so that we can build this list. I don't think opening it wider for now >>> would be wise, but I do thing we should have a very low entry bar for >>> committership (but that can be discussed later). >>> >>> I'll try to come up with a proposal for Karaf's project goal asap, but >>> anyone is welcome to give it a try and propose some wording. >>> >>> FWIW, it would like the following, we just need to fill the : >>> >>> WHEREAS, the Board of Directors deems it to be in the best >>> interests of the Foundation and consistent with the >>> Foundation's purpose to establish a Project Management >>> Committee charged with the creation and maintenance of >>> open-source software related to a machine learning platform >>> for distribution at no charge to the public. >>> >>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management >>> Committee (PMC), to be known as the "Apache Karaf Project", >>> be and hereby is established pursuant to Bylaws of the >>> Foundation; and be it further >>> >>> RESOLVED, that the Apache Karaf Project be and hereby is >>> responsible for the creation and maintenance of software >>> related to XXX; and be it further >>> >>> RESOLVED, that the office of "Vice President, A
Re: [DISCUSS] Move Karaf as a TLP
Why would we limit Karaf to the integration world ? Karaf may be used as the base platform for ActiveMQ, Directory, James, Geronimo, ServiceMix. All of those are not necesseraly geared toward integration imho, and even if they were, Karaf itself does not have anything specific to this area imho. I still think David's the best choice so far: "an OSGI based runtime for assembling enterprise servers" On Tue, Jun 1, 2010 at 09:06, Charles Moulliard wrote: > +1 > > Here is a new suggestion based on remarks : > > "an OSGI-based runtime for assembling enterprise server applications > integration oriented" > > Kind regards, > > Charles Moulliard > > Senior Enterprise Architect (J2EE, .NET, SOA) > Apache Camel/ServiceMix Committer > > *** > - Blog : http://cmoulliard.blogspot.com > - Twitter : http://twitter.com/cmoulliard > - Linkedlin : http://www.linkedin.com/in/charlesmoulliard > > > > On Tue, Jun 1, 2010 at 5:01 AM, Freeman Fang wrote: >> And here is my +1 for moving karaf to a TLP. >> >> Best Regards >> Freeman >> On 2010-5-31, at 下午5:14, Gert Vanthienen wrote: >> >>> L.S., >>> >>> Adding my (late) +1 for moving Karaf to a TLP >>> >>> Not sure if you're still looking for someone to take an initial stab >>> at the project goal or if that's being discussed on the Felix PMC at >>> the moment, but here's my proposal anyway: >>> "... for the creation and maintenance of >>> a small, extensible and enterprise-ready OSGi-based server runtime, >>> capable of being a base framework for building other enterprise >>> server applications, >>> as well as the necessary tools, add-ons and components to facilitate >>> building these applications" >>> >>> Regards, >>> >>> Gert Vanthienen >>> >>> >>> >>> On 30 May 2010 22:53, Lukasz Dywicki wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: > > I would like to be involved with this TLP as well. > > Thanks, > Jarek > > On Friday, May 28, 2010, Guillaume Nodet wrote: >> >> It seems there is a consensus to move Karaf as a TLP, at least amongst >> people involved in Karaf (the other felix committers haven't really >> expressed any opinion). >> >> I think the next steps would be to draft a proposed resolution to the >> board, >> which would include: >> * the project goal >> * the project PMC (including the chair) >> >> In order to create an open community from the start, I'd like to invite >> anyone with an Apache account willing to contribute to Karaf to raise >> hands >> so that we can build this list. I don't think opening it wider for now >> would be wise, but I do thing we should have a very low entry bar for >> committership (but that can be discussed later). >> >> I'll try to come up with a proposal for Karaf's project goal asap, but >> anyone is welcome to give it a try and propose some wording. >> >> FWIW, it would like the following, we just need to fill the : >> >> WHEREAS, the Board of Directors deems it to be in the best >> interests of the Foundation and consistent with the >> Foundation's purpose to establish a Project Management >> Committee charged with the creation and maintenance of >> open-source software related to a machine learning platform >> for distribution at no charge to the public. >> >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management >> Committee (PMC), to be known as the "Apache Karaf Project", >> be and hereby is established pursuant to Bylaws of the >> Foundation; and be it further >> >> RESOLVED, that the Apache Karaf Project be and hereby is >> responsible for the creation and maintenance of software >> related to XXX; and be it further >> >> RESOLVED, that the office of "Vice President, Apache Karaf" be >> and hereby is created, the person holding such office to >> serve at the direction of the Board of Directors as the chair >> of the Apache Karaf Project, and to have primary responsibility >> for management of the projects within the scope of >> responsibility of the Apache Karaf Project; and be it further >> >> RESOLVED, that the persons listed immediately below be and >> hereby are appointed to serve as the initial members of the >> Apache Karaf Project: >>>
Re: [DISCUSS] Move Karaf as a TLP
+1 Here is a new suggestion based on remarks : "an OSGI-based runtime for assembling enterprise server applications integration oriented" Kind regards, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel/ServiceMix Committer *** - Blog : http://cmoulliard.blogspot.com - Twitter : http://twitter.com/cmoulliard - Linkedlin : http://www.linkedin.com/in/charlesmoulliard On Tue, Jun 1, 2010 at 5:01 AM, Freeman Fang wrote: > And here is my +1 for moving karaf to a TLP. > > Best Regards > Freeman > On 2010-5-31, at 下午5:14, Gert Vanthienen wrote: > >> L.S., >> >> Adding my (late) +1 for moving Karaf to a TLP >> >> Not sure if you're still looking for someone to take an initial stab >> at the project goal or if that's being discussed on the Felix PMC at >> the moment, but here's my proposal anyway: >> "... for the creation and maintenance of >> a small, extensible and enterprise-ready OSGi-based server runtime, >> capable of being a base framework for building other enterprise >> server applications, >> as well as the necessary tools, add-ons and components to facilitate >> building these applications" >> >> Regards, >> >> Gert Vanthienen >> >> >> >> On 30 May 2010 22:53, Lukasz Dywicki wrote: >>> >>> I would like to say 'yes' for TLP (even if my vote doesn't count). >>> >>> I try contribute Karaf from time to time and I wish continue doing that, >>> when it will move to top level too. >>> >>> For me it does not make sense to try close all OSGi releated things in >>> Felix >>> project. At this moment we have Aries which is also very closer to OSGi >>> but >>> it's not a part of Felix. >>> >>> Best regards, >>> Lukasz Dywicki >>> >>> >>> Jarek Gawor-2 wrote: I would like to be involved with this TLP as well. Thanks, Jarek On Friday, May 28, 2010, Guillaume Nodet wrote: > > It seems there is a consensus to move Karaf as a TLP, at least amongst > people involved in Karaf (the other felix committers haven't really > expressed any opinion). > > I think the next steps would be to draft a proposed resolution to the > board, > which would include: > * the project goal > * the project PMC (including the chair) > > In order to create an open community from the start, I'd like to invite > anyone with an Apache account willing to contribute to Karaf to raise > hands > so that we can build this list. I don't think opening it wider for now > would be wise, but I do thing we should have a very low entry bar for > committership (but that can be discussed later). > > I'll try to come up with a proposal for Karaf's project goal asap, but > anyone is welcome to give it a try and propose some wording. > > FWIW, it would like the following, we just need to fill the : > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project Management > Committee charged with the creation and maintenance of > open-source software related to a machine learning platform > for distribution at no charge to the public. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC), to be known as the "Apache Karaf Project", > be and hereby is established pursuant to Bylaws of the > Foundation; and be it further > > RESOLVED, that the Apache Karaf Project be and hereby is > responsible for the creation and maintenance of software > related to XXX; and be it further > > RESOLVED, that the office of "Vice President, Apache Karaf" be > and hereby is created, the person holding such office to > serve at the direction of the Board of Directors as the chair > of the Apache Karaf Project, and to have primary responsibility > for management of the projects within the scope of > responsibility of the Apache Karaf Project; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache Karaf Project: > > * xxx > > * ... > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that X > be appointed to the office of Vice President, Apache Karaf, to > serve in accordance with and subject to the direction of the > Board of Directors and the Bylaws of the Foundation until > death, resignation, retirement, removal or disqualification, > or until a successor is appointed; and be it further > > RESOLVED, that the initial Apache Karaf PMC be and hereby is > tasked with the creation of a set of by
