Re: Discuss: Use DS for karaf bundles
-1: I don't really see any real benefit In changing the current approach to DS. There are minor pros and cons in each approach, but the less external dependencies the better. Also less is more :-) -- *Ioannis Canellos* *Blog: http://iocanel.blogspot.com <http://iocanel.blogspot.com/>* *Twitter: iocanel*
Re: Transitive feature/bundle dependencies
I think that the original intention was not to have the dependency attribute on jclouds-api-rackspace-cloudidentity. Most probably this was a side effect of splitting a feature into multiple features. Of course, the problem that you describe may apply to other cases too. So, I think that the change you propose makes sense. Other thoughts? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: Minimal karaf distro
I totally agree with you. Do you know, if your work on this task will be very huge? and when do you think, than end user could be use this new karaf? (just to have an idea !) It requires a couple of man days for the core. And almost the same amount of time for the commands. Now if we could create an annotation processor that would help reducing the annotation boilerplate in commands it could take a little less. This has been scheduled for 4.x. I don't know when 4.x is planned. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: [DISCUSS] Migration to SCR
OK then 4.x it is. And when do u feel its the right time to create a 4.x branch? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
[DISCUSS] Migration to SCR
A while back we discussed about migration from Blueprint to SCR and we all agreed that it was a nice thing to do. The question is how to do it, without making maintenance hard and also without taking ages to deliver this new feature. I think that this should be done in 3 steps: i) Migrate from Blueprint to SCR. ii) Define features for Aries Blueprint iii) Make Blueprint Optional. The first step could be done as part of a Karaf 3.1.0 release. Since all changes are internal and the only thing that would be required is to install SCR by default, it doesn't have to be a major release (in fact it could even be a micro release). The benefit of this approach is that we will not have to maintain an other branch that would require extra maintenance, until we are ready for step (ii). Once we have SCR in our Karaf 3 branch, we can define features for aries blueprint and wait for the rest of the projects of the eco system to pickup those features, were necessary. When camel, cxf, activemq have picked up the changes in our features and have performed a release or two, we can proceed to the final step and have Blueprint not installed by default Thoughts? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: [DISCUSS] Migration to SCR
I would plan this for Karaf 4.0.0, even if it's internal. While I don't have a strong objection on having it as part of a 4.x release, that would mean that it will get pushed back way into the future. 3.x release took us almost 3 years to get out and we stalled 2.3.x for 1.5 year in favour of 3.x. What I take from that experience, is that its not a good idea to push stuff to major releases, when they are candidates for a major release. It's an important jump internally in Karaf, and should be addressed in a major release. I agree that this is an important change. Semantic versioning doesn't force us to push important changes to major releases. Since we are talking about a change that is transparent to the user, the importance of the change is a good reason to deliver it asap :-) We just release Karaf 3.0.0, and we have to let people and other projects to move smoothly (even if as you said, you should not have impact). This is another good reason, for not rushing a 4.x release. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: [DISCUSS] Migration to SCR
As I mentioned earlier, I am not really interested in the release version per se, but primary in the time to market and secondarily on what it means in terms of maintenance. As in all things, the key is balance. Release often is guaranteed way of delivering value to users, releasing too often may send out the wrong message (is it just me, or people tend to become uneasy with very often major releases?). Also releasing very often means, that as a community we will be supporting each major release for a small period of time, or we will need to increase the number of major versions we support at any given time. Do we have the luxury to do so? For example, let's assume that we go for a 4.x in say 3 months It has proven a bit hard to maintain the long living 3.x branch along with 2.x (module restructures made it not trivial to just cherry-pick fixes from one branch to the other). If we add a third branch into the mix, it will become even harder. So what are we supposed to do here? Push the release back 6 - 12 months, or until we decide we no longer need to support 2.x? In that case we could hold of creating a 4.x branch until we get near that time (to avoid the maintenance overhead). We could use this time and follow Dan's suggestion about letting other projects adopt the feature changes. But still it does sound like a long time which is meant to become even longer as new features will pile up for 4.x. Thoughts? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: Minimal karaf distro
@Ioannis: agree, but I wonder the value of using DS instead of Blueprint, or the overwork plumbing to use pure OSGi insteand of DS or Blueprint ;) The value of using DS instead of Blueprint focuses around those areas: i) smaller footprint ii) proxy free iii) improved lifecycle management of components. iv) you get metatype metadata for free (less maintenance). v) increased control / transparency - way easier to diagnose issues (see scr commands and scr mbeans). From my point of view the biggest problem with blueprint is that is the lacking lifecycle management features of DS. So in many cases, we currently register services, commands mbeans, even if the core service required for all those is missing. Then we are using proxies or service trackers to wait or check if the service is actually there. Of course, this is no biggie (other than initializing and registering unusable objects) when we know that eventually everything is going to be there, but when you want to try to make things as decoupled as possible and go for the minimum this can be a problem. Why? because you can end up waiting forever on services that wait for a proxy and so on. An other really important point, is that when you are using DS, you are able to see and interact with the state of your components, see which components have unsatisfied dependencies and how your components are wired together. With blueprint everything is a black box. For these reasons I also feel that it doesn't worth going for a pure OSGi api solution, since you gain (i) (ii) but still loose all the others and also have the burden of maintenance. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: Minimal karaf distro
I had the impression to read an e-mail from Peter Kriens ;) LOL I know DS interests. My point was more DS or Blueprint vs OSGi native. It was not between DS and Blueprint. Ooops. I think that I misunderstood your question. The problem with the plain OSGi approach, is that its extremely hard to get it done right and really hard to maintain it. In the simplest case, you have a service that depends on an other service and using a plain service tracker is pretty straight forward. When a service has more than one service dependencies the complexity starts to increase. You'll need to be extra careful to prevent concurrency issues and the resulting code will be hard to deal with (tons of boilerplate all over the place). And of course, transparency and control wise we wouldn't even be as near as DS can get us ;-) -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: Minimal karaf distro
From my point of view blueprint is fine. It does simplify things a lot and our users do use it. That doesn't mean that Karaf needs to use it too. Decoupling Karaf from blueprint, not only allows Karaf to have a smaller footprint, but also allows provides more flexibility since Karaf could be used with different versions/implementations of Blueprint etc. So this is actually a step forward. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: Minimal karaf distro
@Achim: I don't fancy plumbing myself. @Chrisitan: Let's make one step at the time: Replace Blueprint with DS and then we can consider if it worths turning to pure OSGi APIs (just for the feature service). @Jean Baptiste: Agree, but still it doesn't mean that we have to use one or the other, using no Blueprint should be an option. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: Minimal karaf distro
Well, the minimal distribution we have was always meant to be the minimum possible distro, that could allow everything else to start via features. So I am 100% aligned with Christian on this. The only reason that the minimal distribution does not look like this already, is that it has been a bit painful to isolate and decouple parts of Karaf from each other. So the minimal distro could just be: osgi framework + config admin + scr + pax-url + karat features. In my demo branch (https://github.com/iocanel/karaf/tree/karaf-light) it looks like this with the addition of shell, but that can be made optional too. @Achim: Even though I see real value in such a thin server . The real value comes from making Karaf so modular that it makes the extremely thin server possible ;-) Don't forget that we are building a runtime for modular applications, making the runtime itself modular is a must imho. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: Minimal karaf distro
If the distribution only starts framework, config admin, scr pax-url karaf features, then minimal = net. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: [VOTE] Release Apache Karaf version 3.0.0
-1 The minimal distribution does not work, which sounds like a show stopper? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: [VOTE] Release Apache Karaf version 3.0.0
Please find my comments inline: 2/ the minimal distribution didn't exist in Karaf 2.3.x, so we can't consider that as a regression. That's not quite accurate. The minimal distribution exists ever since Karaf 2.1.x and all releases so far did manage to boot offline, but additional features where downloaded from the internet. From my pov it is a regression and its a regression that that in the past justified a (-1). We've cancelled at least one release in the past due to this issue. 3/ agree that the featuresBoot for minimal distribution should be more minimal. I would keep config, kar, management, but I would remove ssh and region for instance. I would even remove config kar and go just with management as was the case with previous releases. Minimal distribution is like this since 3.0.0.RC1 (it's not something that we changed for 3.0.0). 3.0.0.RC1 did manage to boot offline without issues. This seems to be broken post 3.0.0.RC1. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: [VOTE] Release Apache Karaf version 3.0.0
Given the low popularity of the minimal release and given the fact that issue can be worked around with internet access I'll change my vote to +0. We can fix the offline support as part of a 3.0.1 release. I don't mind having a distribution that would be extra small and would also require internet connection ( a net installer distro ), if its size justifies the effort. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: A Blueprint Free Karaf
@Achim: package commands do use SCR (are you looking at the karat-light branch?). @Andreas: The github fork serves just experimentation purposes. This idea could be hardly presented as a patch or a pull request (so it needed its own branch). @Guillaume: I wouldn't want this idea to be yet an other reason to stall 3.0. If the features justify it a quick new major release sounds ok to me. Of course rebasing to the current trunk (3.0) is something that needs to happen anyway. So the real question is can that rebase happen before we release 3.0?. If so, everything is ok. If not, then I guess we will have to bear the burden of maintaining 2.3, 3.x 4.x for a while. If 3.0 is something that is going to happen next week or the week after I could do some late nights to rebase to 3.0 (helping hands are more than welcome). wdyt? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: A Blueprint Free Karaf
I would like to clarify, that DS is not an alternative DI framework. It's more like a component framework that shines at managing the lifecycle/dependencies of components than anything else. Karaf itself hardly ever use traditional DI. So far it has been using Blueprint in order to wire services together (in a DI like manner). But do not get yourself confused, the fact that is handling services in a DI-syle manner does not mean that Karaf is heavily relying on DI. What I want to say, is that the whole idea of this poc, is to promote a better way to handle services inside Karaf. It has nothing to do with DI.
Re: A Blueprint Free Karaf
Regardless of the impact of this change, the apis provided by Karaf are not affected. The only thing that is affected is the way that services are wired together and of course the bundles that are started up by default. So I think that it could be delivered as a minor release of 3.x or even 2.x (e.g. 2.4). We don't want to stall 3.0.0 any longer. We also don't want to maintain 3 different major branches. Since moving it to 3.1 totally respects semantic versioning, I think that we could go with that. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: A Blueprint Free Karaf
Well, when I started that POC, I wasn't targeting any future release of Karaf, as I was not sure if people will like it anyway. I don't want to stall Karaf 3.0.0, that's true. But if we can prepare the ground and finally add this in a Karaf 3.x (as Dan suggested) it would be a HUGE win for everyone. Mostly, because we will be able to ship it without rushing a Karaf 4.x which would mean extra overhead in maintaining multiple major version (especially when we can hardly managed 2.x and 3.x). @Achim: The original idea was to replace blueprint with scr and make blueprint optional for all distros (not installed by default, but being available as an option just like spring). The benefits: i) A better tool for the job. ii) Smaller footprint. iii) Freedom for the user to use the impl and version of blueprint of his choice. @Johan: By no means I'd like to limit the users options. But that doesn't mean that we should use the same things that the users will do. The users are building apps and they can pick the most fitting tool and we on the other hand are building a runtime and we need to pick the best tool for our job. It doesn't have to be the same tool. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: A Blueprint Free Karaf
Right now, there isn’t a “blueprint” feature that CXF can depend on. We can add one for 3.1 or 4.0, but if CXF then depends on it, then it would no longer load into any 2.3.x Karaf without also doing a 2.3.x release. That’s mostly my point, removing something that is there by default in 2.3 or 3.0 WILL have user impact. It’s not a major one, but it is something that needs to be considered on how to manage it, particularly for frameworks that tend to try and keep a range of compatible Karaf versions supported. Regardless of the version that we introduce the change, the described impact is unavoidable. Since we do have 2 distributions (main minimal) we could keep blueprint by default in the main, add a blueprint feature in all new releases (3.x and 2.x) and at some point in the future we can revisit (when we have a decent range of karaf versions with the blueprint feature in it). -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
A Blueprint Free Karaf
For anyone curious on how Karaf without Blueprint would look like, here is a karaf branch that is free of blueprint: https://github.com/iocanel/karaf/tree/karaf-light (it's a fork of the karat-2.3.x branch). It is actually a refactored karaf 2.3.x that removes blueprint from all modules (yet still provides blueprint as feaures). Karaf specific blueprint namespace handlers have moved to optional bundles so that they can still be used if needed. Blueprint has been replaced with Felix SCR (including the shell commands). Moreover, misc refactorings on features and startup bundles have been performed in order to reduce the size and the amount of bundles in the minimal distro. The result is a minimal distribution that starts 12 bundles [1] (out of 37 which were part of karaf 2.3.3 minimal distro). 10 of those bundle were blueprint bundles and the rest are extra noise. My motivation behind this refactoring was: i) I like declarative services more than blueprint. ii) I've been working on projects that are packaged inside the karaf minimal distro which would benefit from a smaller size (e.g. jclouds-cli). iii) I wanted to make a karaf distro as flexible as possible. Please note that my main focus was the minimal distribution and also this is not 100% polished. Enjoy! [1]: The bundle list of the minimal distro: ID State Level Name [ 0] [Active ] [0] System Bundle (4.0.3) [ 1] [Active ] [5] OPS4J Pax Url - mvn: (1.3.6) [ 2] [Active ] [5] OPS4J Pax Url - wrap: (1.3.6) [ 3] [Active ] [8] OPS4J Pax Logging - API (1.7.1) [ 4] [Active ] [8] OPS4J Pax Logging - Service (1.7.1) [ 5] [Active ] [ 10] Apache Felix Configuration Admin Service (1.6.0) [ 6] [Active ] [ 11] Apache Felix File Install (3.2.6) [ 7] [Active ] [ 13] Apache Felix Declarative Services (1.6.2) [ 8] [Active ] [ 25] Apache Karaf :: Shell :: Console (2.3.4.SNAPSHOT) [ 9] [Active ] [ 30] Apache Karaf :: Features :: Core (2.3.4.SNAPSHOT) [ 10] [Active ] [ 30] Apache Karaf :: Features :: Command (2.3.4.SNAPSHOT) [ 11] [Active ] [ 30] Apache Karaf :: Shell :: Log Commands (2.3.4.SNAPSHOT) [ 12] [Active ] [ 30] Apache Karaf :: Shell :: OSGi Commands (2.3.4.SNAPSHOT) -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: Board Report for December, 2013
+1
Re: Which config.properties and startup.properties with admin:create ?
Conceptually, since parent and children share the same system folder, they should also share the same startup.properties and most probably config.properties too. -- Ioannis Canellos
Re: Role based security for Karaf JMX access
Hi David, There have been long discussions in the past about more fine grained security than what we currently have. In most cases the discussion has been focused around commands but there is a clear need for more fine grained control over jmx too. With the quick glimpse at the commits, I think that the approach makes a lot of sense to me and I'd love to see those ideas being part of Karaf. On Tue, Aug 6, 2013 at 1:22 PM, dav...@apache.org wrote: Hi all, I have started an implementation of Role based security for JMX access into Karaf. Up until now, remote JMX access was guarded by one role. If you had that role you could access everything. With my changes you can define roles (ACLs) per MBean, per method or based on arguments to an MBean invocation. There are also wildcards that can be used to define general rules for all MBeans which provide default behaviour for any MBean which doesn't have a specific ACL. It works like this. The bin/karaf launch script sets -Djavax.management.builder.initial to specify a Karaf-provided MBean Server Builder. This builder guards/intercepts any MBean invocations and checks the roles of the current user for the current invocation. These roles are set through the existing Karaf JAAS intergration. If the current user doesn't have the required roles an exception is thrown and the invocation does not proceed. ACLs for the various MBeans are defined alongside other Karaf configuration in the cfg/ directory and read through OSGi ConfigAdmin. The PID/file name is based on the MBean Object Name, for example an MBean called org.apache.karaf:type=bundles,name=root is mapped to a file jmx.acl.org.apache.karaf.bundles.root.cfg. This file can contain an ACL like this: list : viewer, manager restart : manager stop(java.lang.String)[0] : admin # String argument match stop(java.lang.String)[/([1-4])?[0-9]/] : admin # Regexp argument match stop(java.lang.String) : manager # any other arguments match this If no rules can be found for the current invocation the system will search in a higher level cfg file, with as highest level jmx.acl.cfg which contains the following 'catchall' rules. get* : viewer is* : viewer set* : admin * : admin Whenever a matching rule is found, that is used and the code doesn't look any further. So the most specific definition wins. Certain rules need to have broad access, e.g. an admin role. It's not practical to have to specify 'admin' as a role with every single access control declaration. For this I have introduced groups. While other solutions might be possible, groups are widely supported in security systems so I used those. E.g. to address the 'admin' use-case above you might have a user (joe) who needs rights to every MBean in the system. For this you add joe to the AdminGroup. The AdminGroup then has every role that is defined in the system. It's not magic, because every time you add a new role to the system you need to update the AdminGroup, but it's manageable. Finally I added a special MBean org.apache.karaf.security that allows you to find out whether the current user has the right roles to use a certain mbean or invoke a certain invocation. This can be used when building a management console/GUI to hide things that map to operations that the current user has no right to anyway. It's not 100% watertight in the sense that a specific role can be specified for a specific value (e.g. only 'admin' can stop bundle 0), so there is still a chance that the attempted invocation is rejected, but in general it should be a help to building smart consoles. BTW I'm planning to add bulk operations to this one, that's still a to-do. Couple of notes: * It's all very pluggable. You can switch JAAS back-ends, ConfigAdmin implementations, or even the whole JMX guard implementation (which is not very big) by specifying another MBean Server Builder. * You can log into JMX without credentials when using a local JConsole or directly in the process. When no credentials are found the JMX guard will refuse any operation. * I added a bunch of Karaf Console commands to administer JAAS groups. * JAAS Groups are not yet supported by all JAAS/Karaf backends. I added it to the PropertiesBackingEngine. They can be added gradually. * The idea is to also add Role-based Access to the Karaf Console commands at some point going forward, but that's a separate piece of work... So... the question is: would the Karaf community be interested in this Role based JMX security? I would be more than happy to donate it. My current implementation can be viewed in here: * addition of group support: https://github.com/bosschaert/karaf/commit/6598f088c53aa5bce217cdc2e066a96f8f3d5d37 * role-based access to JMX: https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f Best regards, David dav...@apache.org da...@redhat.com david.bosscha...@gmail.com -- Ioannis
Re: [VOTE] Switch from svn to git
+1 On Tue, Jun 25, 2013 at 8:45 PM, Charles Moulliard ch0...@gmail.com wrote: +1 On Tue, Jun 25, 2013 at 11:12 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, to follow the discussion that we had some weeks ago, I start here a formal vote to migrate our scm from svn to git. Please vote to approve this switch: [ ] +1 Approve the switch (from svn to git) [ ] -1 Do not approve the switch (please provide specific comments) This vote will be open for 72 hours. Thanks, Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Create KarafEE as a Karaf subproject
Even though the concerns about an orphaned subproject are valid, I am not worried about it, as I don't think it has a real impact in the community or the project itself. So I am perfectly fine with having it as a subproject. On Wed, May 15, 2013 at 4:50 PM, Achim Nierbeck bcanh...@googlemail.comwrote: Hi Charles, I really like the idea of the KarafEE project, though right now I have some doubts. First of all it looks like it's being a orphaned sub-project at the TomEE Project, so yes this makes it valid to ask for a transfer, but who's gonna be the main maintainer for it? Right now we have about already about 4 different subprojects of wich only one is really maintained right now. EIK for example the main committer just vanished after the sources had been moved. I really don't want to end up with another orphaned sub-project in the karaf space, especially since right now we're lacking some manpower. We still get enough votes for releases, that's a good sign. On the other hand my gut feeling tells me we're having a decreasing size of active committers for about 6 to 9 Month. But this is just my humble opinion, I really would love to be proven wrong :D regards, Achim 2013/5/13 Romain Manni-Bucau rmannibu...@gmail.com Hi Charles, wonder if it shouldn't just be a subproject of Geronimo which is already a JavaEE/OSGi container on top of Karaf that said +1 to get it maintained (personally i don't have enough time to support it as i try to do with TomEE) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/5/13 Charles Moulliard ch0...@gmail.com Hi, Some weeks ago (thx to Romain and others) we have discussed about KarafEE future. This project which is until now part of Apache TomEE was an attempt to promote JEE concepts top of Karaf Multicontainer OSGI runtime (using OpenEJB, OpenJPA OpenWebbeans). Unfortunately, it will not be longer maintained by TomEE contributors and should find a new home. This is mainly the reason why I contact Karaf Dev Team to propose to submit to a vote the following suggestions : [1] : Moving KarafEE code from Apache TomEE to KarafEE as a subproject [2] : Propose that KarafEE becomes a Karaf subproject supporting OSGI EE Features (JTA, JPA, EJB, CDI, ...) If everybody agree and both votes succeed, then I propose to orchestrate the work of moving the code from TomEE to KarafEE, creating doc pages describing goals of the projects, ... Regards, -- Charles Moulliard Apache Committer / Sr. Enterprise Architect (RedHat) Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/ -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Discuss: How to handle incompatibility in Karaf 3 shell
I've raised the same concerns a couple of months ago. The answer I got back then is that there is a way to make commands be compatible with both 2.x and 3.x. I think that camel commands already are and they do so by declaring the gogo package as private (not 100% sure, I'll have to check) On Fri, May 10, 2013 at 10:24 AM, Christian Schneider ch...@die-schneider.net wrote: There is still a compatibility issuue in Karaf 3 with at least ActiveMQ. It is described in the two issues below: https://issues.apache.org/**jira/browse/KARAF-2307https://issues.apache.org/jira/browse/KARAF-2307 https://issues.apache.org/**jira/browse/AMQ-4492https://issues.apache.org/jira/browse/AMQ-4492 In fact it is two issues: 1. The package org.apache.felix.gogo.**commands.basic was moved to org.apache.karaf.shell.**commands.basic. 2. The package org.apache.karaf.shell.console is now at version 3.0.0 which is incompatible to the range of [2,3) ActiveMQ imports. So for the issue 1 we have two options: a. Create the new package in upcoming 2.x versions. + We a clean state in Karaf 3 with the old package removed. The problem is that as soon as - ActiveMQ switches it will not work with older 2.x versions anymore. b. Create the old package in Karaf 3 + All present versions of ActiveMQ will still work - As soon as ActiveMQ switches it will not be compatible with Karaf 2.x anymore - Karaf 3 contains old packages while it should clean up these things in a major release There is also the option to create old and new packages in Karaf 2.x and 3 so ActiveMQ will work in both versions. We then later have too remove to old package for karaf 3 at some point. The issue 2 is less dramatic as it can be fixed by a wider import of the package version in ActiveMQ. Still I wonder if we could do better here. For API packages we could version each package separately so as long as a package is incompatible it could still report the old version which would make it more compatible. This can be handled with a package info file in the package like in the OSGi specs. So in any case I think this shows we should have a good concept for package versioning for API packages. What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Task scheduler in Karaf
Cool On Wed, Apr 24, 2013 at 4:25 PM, Roedl Lukas lukas.ro...@ait.ac.at wrote: Hi, Yes I saw that it's now included in 3.0.0.RC1. I just wanted to know if it's worth working on a patch ;-) So I'll transform that into a patch and open a Jira the next days... Best regards, Lukas -Ursprüngliche Nachricht- Von: j...@nanthrax.net [mailto:j...@nanthrax.net] Gesendet: Mittwoch, 24. April 2013 15:18 An: dev@karaf.apache.org Betreff: Re: Task scheduler in Karaf Hi, The scheduler provided by Ioannis has been included in 3.0.0.RC1. Before the 3.0.0.GA release (or 3.1.0 depending of the timing), I plan to add the following new features: - enhancement of the jledit support provided by Ioannis as well (task started) - enhancement of the sub-shell support (it looks like the Cisco IoS shell environment) (task started) - new optional feature to provide a service wrapper based on commons-daemon instead of JSW (POC on my github) - new optional features for a complete scheduler (bundle, service, etc) powered by Quartz (my purpose is not to try to focus on Sling as it's not the same platform as Karaf) (TODO). The purpose of the last point is to provide a feature as we did for encryption: - the basic feature works a simple as possible as out of the box - if the user requires more advanced setting, it can enable and install advanced feature. For instance, about encryption, the user can enabled the jasypt support. Any help is welcome ! If you want to share what you did, I would be glad to review it with you. Regards JB On 2013-04-24 14:41, roedll wrote: More than a year ago Ioannis Canellos posted that he added a rudimentary scheduler as a new module to trunk. (See http://karaf.922171.n3.nabble.com/Introducing-a-task-scheduler-in-Kara f-td3185322.html for details) In the following discussion some people suggested to use Quartz and/or the scheduler implementation from Apache Sling (which already uses Quartz). As the Apache Sling implementation only implements support for SCR and not Blueprint it's unfortunately not plug and play in Karaf (without activating the SCR support) I've recently implemented Blueprint support for one of our projects and now wonder if this functionality would be of interest for Karaf?! -- View this message in context: http://karaf.922171.n3.nabble.com/Task-scheduler-in-Karaf-tp4028481.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)
The more complex the wiring is, the largest the number of potential issues. Let's keep things as simple as possible. Moreover, I find the large number of bundles, as a result of unwinding libs intimidating to the new users. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [VOTE] Release Karaf version 2.3.1
+1 -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [VOTE] Release Apache Karaf version 2.3.1
The minimal distribution fails to start because its missing the org.apache.karaf.jaas.authz-2.3.1.jar from the system repo. Having one of two flavor not being able to start, seems like a show stopper, but I am not sure. What do you thing? -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Idea: Allow users to patch feature files
Some of the views expressed so far: i) Allow defining an alternate location for a feature repository. ii) Allow overriding a feature repository or bundle url using a mapping. iii) Using version feature version ranges to resolve the right version to use. Some thoughts about each idea. i) I'd love to be able to do that, even though in most cases modifying the feature repo in the system directory does work for me. We could take this one step further an be able to modify the feature repo itself, using the editor we have in trunk (mostly as a dev tool). ii) I like this idea too. This would solve the recent problem we had with spring versions. We could just let the user define a mapping like mvn:org.springframework/*/[3,4] = mvn:org.springframework/*/3.1.2.RELEASE and it would be awesome. iii) This would definetely solve a lot of problems, without direct user interaction. I think that we should maybe start with this point but maybe also grant the user the power to do things like i) and ii). I hope I didn't miss anything. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [PROPOSAL] Karaf release policy and branches
Currently we are at 2.3.0 and 2.2.10. Does it mean that if we get out 2.4 to provide new features to our users, we will stop working on 2.2.x? How would this work when we get 3.0.0 out? -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Create Karaf 2.4.x branch
+1 on creating a 2.4 branch. Personally I am ok at adding new features on micro releases as long as they don't change the API, especially considering the speed at which we bring out new major and minor ones. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Text editing in the Karaf console
I've update issue: https://issues.apache.org/jira/browse/KARAF-2044 with 2 patches, one for trunk and one for 2.3.x. If there are no objections I'd like to commit those and maybe also for 2.2.x. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Text editing in the Karaf console
I moved the project to https://github.com/jledit/jledit and cut a first release. So we can finally add a command for editing. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Text editing in the Karaf console
For now I have pushed it at: https://github.com/iocanel/vial -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Text editing in the Karaf console
I am not sure if having it as part of the Karaf trunk would be a really good idea. Such editor can have a wider scope than the container itself and at its early days it could use a faster release cycle and/or contributions from other communities with similar needs that are not using karaf. Of course, there is always the maintenance burden of an extra subproject which we should take into consideration. Thoughts? -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Text editing in the Karaf console
I took a stub at creating a console text editor written in java based on jansi and jline. The current implementation is quite simple, loads the whole file into the memory and allows simple text editing operations, scrolling and also undo/redo, paste, save etc. There is a lot of cleaning up to do and a lot of space for improvements and I was wondering which would be the ideal home for this project. Thoughts? -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [VOTE] Release Karaf version 2.2.10
+1 -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Text editing in the Karaf console
Hi guys, One feature I've always liked to have in the karaf console is the ability to edit text files. See https://issues.apache.org/jira/browse/KARAF-2044 I took a stub last night, to integrate existing editors that might be present in the system with the Karaf console (e.g. vi, nano or edit in windows). To my surprise starting the editor as a new Process and wiring input and output seems to just work. There are just a few things I'd like to solve before committing and I wanted some ideas: i) I can pass the terminal height and width to the process, but how do I get those values get updated if I resize while the editor is open? ii) Some editor don't take kindly the delete character and prefer backspace (changing ascii 127 to ascii 8). Is this safe to do. Is there a better way to handle it? iii) After closing the editor, the console sometimes gets flaky arrow keys might stop working etc. Thoughts? -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [Discuss] Apache Karaf 2.2.10 RC soon?
+ 1 for the 2.2.10 RC. We can discuss about 3.0.0 in an other thread. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [PROPOSAL] Create Karaf Features sub-project
On Fri, Oct 19, 2012 at 11:00 AM, Jean-Baptiste Onofré j...@nanthrax.netwrote: In my previous e-mail, my intention is not to host the feature of others projects (it's the responsibility of others projects). The purpose is to host (at least temporary) the projects that don't provide features descriptor natively (spring for instance). Yeah, we took the discussion a bit far... :-D So for spring, since there are now actual ties to Karaf we could do that. I don't know for the enterprise features. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [PROPOSAL] Create Karaf Features sub-project
The idea seems good at first glance, but there are things that we need consider. In many cases a feature descriptor is not portable between major Karaf versions, and it also happens that it breaks between minor versions. Even from Karaf 2.2.x to Karaf 2.3.x I've seen third party features break. So it may seem that most features could decoupled from the underlying version of Karaf, but practically this is not always the case. An example: In the spring feature case, we also have the spring deployer. Where will the source of spring deployer will be hosted and which are going to be the versions of fileinstall and karaf that the deployer will be built against? -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [VOTE] Release Karaf version 2.3.0
Tried with various projects that provide Karaf features. Here's my +1 -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Apache Karaf 2.3.0 very close
I agree with JB at all points. I feel that holding back 2.3 in favor of 3.0.0 was a bad idea and I wouldn't want to see the same happening to future 2.x versions. If there is need for a 2.4 let's get it done regardless of when we'll do 3.0.0. -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [DISCUSS] Karaf 2.x and aliases for 3.x commands
I don't like the aliases either for the same reasons (completion). +1 -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Shell command to initially persist a config pid
I am not sure if it would be a good idea to persist any config pid to etc. Imagine you have a config admin impl that persists to a DB or a central server internally. In this case you would rather not want to persist to the etc dir too. That's a good use case for the bypass property we already have, isn't it? -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: WebConsole versioning
That's interesting. What are the long term goals here? If the long term vision is to have this console adopted by other runtimes, that are currently use the felix web console, then the suggestion no 2 makes a lot of sense. If we don't have a clean goal set here. I'd say keep a single branch, till we release karaf 3 or until we have an other target platform than karaf 2.2.x. This will reduce the maintainance. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [DISCUSSION] OSGi core version in Karaf version
I've no problem with either of those since the 4.3 release of the core does not break backward compatibility (compared to 5.0) -- also fine with that approach (BUT, AFAIK 2.3.x had been ported to 4.3 already) Then our views are completely aligned :-) -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [VOTE] Release Apache Karaf 2.2.9
+1
Thoughts on KARAF-1718
Hi, I have created and attached a patch for: https://issues.apache.org/jira/browse/KARAF-1718 I have it scheduled for 3.1.0, but if you agree we could also have it in 3.0.0. It pretty much works as is, but if we agree to have it in 3.0.0 I could work on a couple more improvements that I have in mind. Thoughts? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [Vote][WebConsole] Camel / CXF / ServiceMix modules
I think that a release as a subproject is really needed. I am already aware of people using it and building on top of it and they would like to have a release. I am not sure though, if the subproject should move into trunk. Here are some thoughts about it. I feel that trunk needs to have one and only one webconsole. Either the felix webconsole or the karaf-webconsole, but I don't fancy having them both, for the obvious reasons. From the aesthetic point of view, I am +1000 for karaf-webconsole. For ease of development, I am +1000 for karaf-webconsole (this is just a personal view and not something based on objective criteria). I couldn't oversee however the fact that the felix webconsole is widely used, people have built stuff on top of it, etc. Would it be possible to reuse/wrap/bridge felix webconsole stuff in karaf-webconsole? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Telling whether startup is really complete
I've read a lot of interesting opinions and I'd like to share mine: i) The Karaf shell should start asap, unless explicitly configured. The enter thing is nice but should be optional imho. ii) Determining when Karaf is started is one thing, determining when an application is started is another. iii) A log entry that says Karaf has started sounds enough, we can optionally provide that info through the info command. iv) Different users have different needs on what started means. To cover all cases we could allow the user to use a configuration file that will contain requirements (package, service etc) and have everyone configure it however he wishes. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Adding Webconsole Plugin for SCR
Hmmm, going through that thread again I realized that I misunderstood Achims proposal :-S I still like it but I don't feel that this will solve the current issue. I am still +1 for it, but for the current problem I was thinking for something like: feature resolver=(obr) description=Declarative Service support version=3.0.0-SNAPSHOT name=scr ... capability feature=webconsole bundlemvn:org.apache.karaf.scr/org.apache.karaf.scr.webconsole. plugin/3.0.0-SNAPSHOT/bundle /capability /feature Where capability could specify a feature (as shown above), a package, a service etc. When the scr feature gets installed, the feature service could check if the defined capability is meet in our container and if so install the webconsole plugin. Also, after a feature gets installed it could have a look at the existing installed features and see if there are new capabilities that are meet. I think that this would be really usefull, especially for the management, diagnostic, webconsole related features. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [VOTE] Release Apache Karaf 2.2.8
Ideally, a micro release should guarantee forward and backward compatibility. I'd say though that the particular issue doesn't sound like a show stopper to me. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [VOTE] Release Apache Karaf 2.2.8
+1 Checked the main and the minimal distributions and both look ok. Tested with a couple of features provided with choourl, overall seems fine. A minor issue that I notice is that some of them do not work properly unless we modify startup properties, we need to address that in future releases. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: When executing commands using karaf's bin/shell there is a huge delay before the command exits.
By the way if you want to take a closer look, I was working on this: https://github.com/jclouds/jclouds-cli which is a jclouds interactive shell based on karaf and I was trying to also add support for non interactive mode. In the current master of the project, I use a modified version of the Main class that uses a System.exit as a workaround. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [PROPOSAL] Use paxexam-karaf on Karaf 2.3.x branch
JB, I was about to bring this proposal forward myself! A huge +1. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: When executing commands using karaf's bin/shell there is a huge delay before the command exits.
System.exit is of course a way to make sure you get a fast exit. The problem is that if something is to be cleaned up in the background it will simply be cut off. So the cleaner way is to not use System.exit and make sure our background threads terminate fast. This can be a bit tricky though :-) Totally agree, the question is do we care if the threads are cleaned up properlly when using bin/shell. From what I understand the purpose is to execute commands outside OSGi, so that they can be used in scripts etc. In such case exiting fast seems really important. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: karaf-maven-plugin work
Hi Brian, thanks for the contribution. Whatever, option you choose it will be highly appreciated :-) I'll try to find some cycles and review your patch. Keep it up! -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: svn commit: r1346392 - /karaf/trunk/assemblies/features/framework/src/main/resources/resources/etc/org.ops4j.pax.url.mvn.cfg
Guys, why don't we use maven filtering capabilities and have different filters per profile? We could then use a release profile with clean repo configuration while the rest of profile use snapshots to aid development. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [HEADS UP] Ssh agent and key authentication support
I may lost some bits, but couldn't we just reuse the users keys and authorized hosts, instead of creating, adding or removing? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Add a scope feature-url
In terms of completion this would make a difference. However, it is lacking context in my opinion. For example when a user sees the repo scope, he can be easily get confused and think that this refers to maven repos etc. Generally, speaking we need to be careful regarding the commands scope. If the scope is too generic, then it will gather a lot of commands under it and in the it will loose its purpose (such case were the osgi commands, they used to be an umbrella for many different things). On the other hand, if we normalize scopes too much and start splitting concepts across different scopes. the number of scope will be hard for the users to follow. Moreover, it will weaken the sub shells concept (there will be not much use to enter a subshells with only just a couple of commands). The key here is balance. I feel the currently the features scope is well balance and I think we should leave them as they are. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Karaf 2.3.x branch guideline
Why not having jdk 1.7 support in the 2.2.x branch? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [VOTE] Release Apache Karaf 2.2.6 RC#4
Did a quick walkthrough through the cli. Experimented with misc projects and everything looks cool. What I didn't like at all is the user experience with the choose url. The idea is fantastic, but I didn't have a smooth experience with none of the features I choose: Some of them have outdated urls, some other have broken features etc. I am giving it a +1, as it is definitely not a show stopper, but we do need to improve this. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: table printer for Karaf commands
True, but releasing 3.0.0 should not block us from delivering functionality to 2.2.x or even 2.3.x. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Karaf 3 alternative for packages:exports missing?
Agree, it something that even us got really confused about, imagine the impact that will have on the users. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Update on Karaf 3.0.0
Great news! I'd like to make a really trivial aesthetic comment. Could the sub shell prompt have no parenthesis when no sub shell is active: karaf@root region karaf@root(region) exit karaf@root -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: Board Report March 2012
I think we also have a new committer, don't we? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
Re: [Discussion] Apache Karaf projects for Google Summer of Code 2012
+1 for the GSOC and Andreas idea. I have said in the past, that we have a lot of sub projects for our size. Maybe we need to come with more ideas about sub projects. Any idea how are we going to draw the students attention? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Karaf and Security provider
I don't know if its up to date. I was under the impression that you can use the bouncy castle jce provider just by installing it as bundle. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [VOTE] Release Apache Karaf Cellar 2.2.3
Here is my +1 ! On Fri, Jan 27, 2012 at 11:50 AM, Jean-Baptiste Onofré j...@nanthrax.netwrote: Hi, We solved 39 issues in this release: https://issues.apache.org/**jira/secure/ReleaseNote.jspa?** projectId=12311140version=**12317140https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140version=12317140 Staging repository: https://repository.apache.org/**content/repositories/**orgapachekaraf-143/https://repository.apache.org/content/repositories/orgapachekaraf-143/ Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Not approve the release (please provide specific comments) This vote will be open for 72 hours. Thanks, Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: SCR Tools for Karaf
Yes, it makes sense to me. My main point was that since it was such an old request it should be propably ported to 2.x.something too. A 2.2.3 sounds great to me! -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Features chooseurl
Hi all, I noticed the addition of the choose url command, which I really like. It actually implements what we have discussed countless of times about an easy way of letting the user install 3rd party features. I'd really like to see the file that contains the repository urls, hosted on the web rather than built inside the distro, so that its easier to add, remove update urls or even have different ranges for different karaf versions. Since the user will need to have internet access in order to install those urls, I think it really makes sense. What do you think? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Database commands for Karaf
I think the most appropriate place for this kind of stuff is geronimo since the general idea for geronimo is to provide EE funcionality that elaborates other projects. Yeah, Geronimo would be a great place too, as long as it can provide a feature descriptor that would allow its use in plain Karaf. But I really don't think that this would be a problem. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Database commands for Karaf
I agree with Andreas here. I think that they are beyond Karaf's scope. Maybe they should be part of ServiceMix or an other project. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Minimal distribution
Hi all, After the talk about the size of distributions I started giving a look at the minimal distribution. An obvious change is to remove management and standard from the boot features in order to decrease the size of the distribution to 33 bundles. However, this is still a very large number of bundles imho. Some things that I think that could be removed from the framework features, which is the base are: Apache Aries Quiesce Manager (0.3.1) Apache Aries Blueprint JEXL evaluator (0.1.0) Apache Aries Quiesce API (0.3.0) Apache Aries Blueprint CM (0.3.3.SNAPSHOT) Apache Aries Blueprint Annotation Impl (0.3.2) Apache Aries Blueprint Core Compatiblity Fragment Bundle (0.4.1.SNAPSHOT) Apache ServiceMix :: Bundles :: asm (3.3.0.2) Apache Aries Blueprint Annotation API (0.3.2) Apache Aries Proxy Service (0.4.1.SNAPSHOT) Commons JEXL (2.0) Region Digraph (1.0.0.v20110524) Apache XBean OSGI Bundle Utilitiess (3.7) Apache XBean :: Classpath Resource Finder (3.7) Apache Karaf :: Region :: Persistence (3.0.0.SNAPSHOT) Most of these bundles I think that are related to regions. Can they be removed from the framework feature and add it as a separate one? I don't know if this is possible and that's the purpose of my email. Can you please confirm if its ok to do so? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Minimal distribution
Thanks for the responses! I'll give it a shot. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [Proposition] - Apache KarafEE
Reading all these interesting views I come to realize that so far all app servers that use OSGi, actually ported their existing codebase into OSGi leaving a gap, since they were not originally designed for that job. What I find really exciting is the fact that this is the only approach I am aware of, that goes the other way around (building EE features on top of OSGi). I am really curious to see how it will evolve. Really interesting stuff. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Error messages in Karaf 3.0.0
Hi, is it just me or the error messages have been messed up? I was experimenting on a fresh trunk and I noticed that bundle:install feature:add-url commands, no longer display what went wrong (e.g. unresolved constraints etc). Is this something that is done on purpose? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Size of karaf distributions
When I was working on the minimal distribution, the original plan was to install only the things that were required for the feature service to run. All others could be installed later on. If I remember correctly management, ssh etc were not supposed to be part of the minimal distribution. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [VOTE] Release Apache Karaf 2.2.5
+1 for the release. I tried it with lot of external features and it seems cool to me. While playing with it I found the existence of the aliases to the 3.x commands a bit annoying. (Not a show stopper). As the wrapper code changed to gpl - does it make sense we fork the wrapper with a apache license at apache. So it stays available for us in the future? It does for me. I really like this idea. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [VOTE] Release Apache Karaf 2.2.5
An other glitch I found is that the code completion on the config:list --pid is not working (it works for the rest of the config commands). Not a show stopper. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Fork of the wrapper code
+ 1 -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [Proposition] - Apache KarafEE
I think that we all are +1 on the effort Charles put to integrate Karaf with OpenEJB. Different views has been expressed on where and how (I reusing Charles words). This talk reminded me of an old one we had, when we first started talking about subprojects, there was an argument on what should be a subproject, what should be part of the main project etc. An interesting idea was then expressed (I think it was Guillaumes idea but not sure). The idea was to provide an online registry of feature descriptors provided by subprojects or 3rd party. So any Karaf instance with access to the internet can browse through the available feature descriptors available for that version of Karaf and directly use the descriptor and install features from it. So, what this idea has to do with the current discussion? Well, if we implement it, then its only a matter of few commands to converrt any Karaf instance to a Karaf EE. (Regardless of this talk this is really needed imho). From the feedback we will receive from the community we can discuss again if we need to create a packaging for this solution and how/where it will be maintained. That's my 0.2 drachma ( Since using the national currency is becoming a trend ... ) -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Archetypes to create a Web project for Karaf
Awesome idea! A couple of thoughts on GWT. There are some commonly used patterns around GWT. Some of them (e.g. the command pattern) would be really interesting inside OSGi, as they could leverage the OSGi service registry and produce real value. That's something I always wanted to do but never had the time. An archetype for gwt that will include those patterns would be awesome. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [Proposition] - Apache KarafEE
Hi Jean Baptiste, Will we host a public cave repository, so that anyone can pull features from there? On 15 Δεκ 2011, at 2:40 μ.μ., Jean-Baptiste Onofré wrote: Hi Ioannis, the features providing is a target in Cave: Cave aim to be a feature repository, gathering all features from several projects and Karaf can register to a features Cave repository (like a Maven repo). Regards JB On 12/15/2011 11:52 AM, Ioannis Canellos wrote: I think that we all are +1 on the effort Charles put to integrate Karaf with OpenEJB. Different views has been expressed on where and how (I reusing Charles words). This talk reminded me of an old one we had, when we first started talking about subprojects, there was an argument on what should be a subproject, what should be part of the main project etc. An interesting idea was then expressed (I think it was Guillaumes idea but not sure). The idea was to provide an online registry of feature descriptors provided by subprojects or 3rd party. So any Karaf instance with access to the internet can browse through the available feature descriptors available for that version of Karaf and directly use the descriptor and install features from it. So, what this idea has to do with the current discussion? Well, if we implement it, then its only a matter of few commands to converrt any Karaf instance to a Karaf EE. (Regardless of this talk this is really needed imho). From the feedback we will receive from the community we can discuss again if we need to create a packaging for this solution and how/where it will be maintained. That's my 0.2 drachma ( Since using the national currency is becoming a trend ... ) -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: [Proposition] - Apache KarafEE
Guillaume, yes this is exactly what I had in mind. Now if we do it using Cave, that's ok with me, but preferably this would be an awesome out of the box feature (by that I mean that it would be awsome as feature without requiring additional bundle/feature installation or configuration). Now, if we had something like this in Karaf 3.x and communicated (blogs, tweets and all the likes) how easy it is to make an EE container out of vanilla Karaf using such it, we could then easily determine if there is room, interest and real value for the required to maintain it. I want to clarify again, that I am not against a KarafEE subproject, I am just not sure if we have the numbers to support it. From my experience with Cellar, I see that the maintenance of a subproject requires a lot of effort. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [Proposition] - Apache KarafEE
Kudos to Charles for the work with the OpenEJB community. My only slight concern is that the number of sub projects is getting big compared to the size of the community. On 14 Δεκ 2011, at 4:35 μ.μ., j...@nanthrax.net wrote: Hi Glen SMX doesn't include OpenEJB. It's an integration oriented platform. What we propose is an JEE application server in OSGi as TomEE for Tomcat. The purpose is to be Karaf oriented, Geronimo uses Karaf but wraps and hide a lot of Karaf features. Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://wwx.talend.com - Reply message - From: Glen Mazza gma...@talend.com To: dev@karaf.apache.org Subject: [Proposition] - Apache KarafEE Date: Wed, Dec 14, 2011 3:29 pm What would be the difference between KarafEE and ServiceMix? As with Geronimo and ServiceMix, all I can see is that you want to build on top of Karaf, but go in a different direction from what they have done (fine), but, at the same time, directly affiliate it with Karaf (perhaps not-so-fine). So far, Karaf forms a nice core that is embedded by multiple open-source (ServiceMix, Geronimo) and commercial application containers (Talend ESB, for example). No problem there, and its speaks well of Karaf that it is used so often. Let there be 14 projects that build on top of Karaf, each with their own ideas of which is best, and let the market decide. But I'm not sure this wrap you're proposing should be called Karaf (or KarafEE) itself, or be directly associated with Karaf. Let it be an independent Apache project needing to compete fair and square with Karaf's other wrappers, e.g., ServiceMix and Geronimo. In the documentation business, Apache Cocoon and BIRT (and probably other publishing tools) wrap Apache FOP (PDF generator), there is no Apache FOP EE that wrapped itself in order to offer super-features provided by the separate projects that wrap it. FOP focuses on remaining a solid tool that higher level documentation/publishing applications want to incorporate, and more importantly, does not (!) compete with those products gracious enough to wrap it. It's a nice division--good fences make good neighbors. Same thing with Tomcat -- very nicely incorporated by GlassFish, JBoss, Geronimo, SpringSource (what they call Enterprise Tomcat, but still a separate product and team) and probably others. The Tomcat team, like the Karaf team, is very bright and I'm sure quite capable of making their own wrap and competing with their wrappers--but they wisely (IMO) resist, probably a major reason for Tomcat's heavy adoption and longevity. Regards, Glen On 12/14/2011 07:40 AM, Charles Moulliard wrote: Hi, As you probably knows, I work with OpenEJB community since a couple of weeks to be able to deploy OpenEJB 4.0.0-SNAPSHOT on Apache Karaf. The OpenEJB container can already been deployed and EJBs jars registered. Work should be done around OpenEJB to be able to easily scan (like we do for deploy directory in Karaf) new or updated EJB jars file and add karaf command. When this new brick will be ready, everything will be in place to propose/provide an Apache KarafEE (EE = Enterprise Edition) release packaging OpenEJB, OpenJPA, Aries JPA, Aries JNDI, Pax Web, Aries Transaction Manager. The first question/remark that I will receive from the communauty will be : Great/Brillant idea but Apache Geronimo is already there and use Apache Karaf. So why developing a new server : There a lot of good reasons why we should do that and study my suggestion carefully but some arguments could be : (1) concurrence in this area is always good comparing to what we have in J2EE world, JBoss, TomEE, Glassfish. J2EE are de facto servers used in major and many Java projects. OSGI is not yet recognized as a robust and simple solution to be used due to lack of tooling, complexity to package and create bundles. So having a new OSGI true J2EE server could help to spread the world, (2) The packaging and deployment approach of Apache Geronimo is a bit different from Karaf and some of the Karaf features are not enable (e.g : features, ...). (3) The Geronimo web console cannot be reused for Apache Karaf and now with our new WebConsole we are independent of Apache WebConsole Felix (4) EJB is back since spec EJB3 like also JPA and more and more project does not longer use de facto Spring ! (5) With Cellar/Fabric we have a strong foundation to deploy/manage/use Karaf in the cloud and design multi-servers architecture. KarafEE could be like Cellar, new WebConsole a subproject having its own assembly release process. It will contain assembly process, featurs, karaf commands, branding and web consoles stuffs. Remark : I have proposed also for OpenEJB that they have a karaf-assembly but our sub-project could be designed for that purpose -
Re: Introducing a task scheduler in Karaf
As we are marching towards 3.0.0 release and we haven't done anything about it (its still in primitive state) maybe its a good idea to remove it from trunk and maybe put it in the sandbox or something. What do you think? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Introducing a task scheduler in Karaf
Yes, I was thinking something like this. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Karaf 2nd call meeting
+1 on both days. On Wed, Dec 7, 2011 at 6:24 PM, Andreas Pieber anpie...@gmail.com wrote: Both days would work; but I would prefer the 28th ...and btw +1 to the half-year-pre-birthday-skype-meeting :-) Kind regards, Andreas On Wed, Dec 7, 2011 at 16:33, Jamie G. jamie.goody...@gmail.com wrote: Either date would work for me :) Jamie On Wed, Dec 7, 2011 at 11:51 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, For the first Karaf birthday (2011-06-16), we had our first Karaf meeting. As reminder, the meeting notes are available online: https://cwiki.apache.org/confluence/display/KARAF/Apache+Karaf+First+Birthday+Meeting+%282011-06-16%29 It was 6 months ago (time is running out :)), and I propose a new meeting. The purpose is to review the roadmap, check where we are regarding the previous meeting, etc. I would propose two dates: - Thursday 21st of December, 8pm GMT+1 - Wednesday 28th of December, 8pm GMT+1 WDYT ? If we are agree, I will create the wiki page to register the attendees and define the agenda. Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
obr resolver and jre.properties
Hi, I was fooling around with my jre.properites and I noticed, that even if I comment out some packages, I can still see them as exported with packages:export command. Of course my bundles will not import them (which is expected) but it can be kind of confusing. Is this something expected? I tried to find a previous discussion/issue on this and didn't find any. I also noticed an interesting side effect of it: When I have the obr resolver installed, and my feature has a dependency bundle that exports such a package (that is commented in the jre.properties), the bundle will not get installed, since the resolver belives that the dependency is already met (which is not true). I am doing something retarded here, or is this package command/admin thingy? -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Fwd: [jira] [Created] (KARAF-1060) use bash file extenstions: karaf - karaf.sh
I would assume that it only needs it for associating sh extention with cygwin. But I can't know for sure, I haven't used a directx container for a while :-P -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: karaf-maven-plugin docs
Awesome !!! -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [DISCUSS] Roadmap for 3.0 release
Awesome! Let's start focusing for mid December and see how it goes! -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: Fragments in Karaf 3.x and OSGi 4.3
Did you try to do a refresh on the host bundle (C) ? This is needed in order to have fragments be resolved. Hi Guillaume, actually the features:install does that for me, as expected. Even if I do it manually, It still makes no difference. I have some more findings, that simply things: Even if bundle D does not require package *yet.another.package* it will still not get attached. So my problem could be expressed the following way: A bundle that imports packages exported by fragments, is not be able to have *ANY* fragment attached to it. If you just try to install jclouds feature, you can see that blobstore core bundle can't get attached to jclouds-core. Thanks. -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
Re: [DISCUSSION] Heading towards Apache Karaf 2.2.5 Release Candidate
+1 Note: Since we have put in several jaas improvements, I would like also like to see a backing engine for ldap, so that jaas commands can be used with the ldap login module. So if anyone has a few cycles for it, that would be great! -- *Ioannis Canellos* * FuseSource http://fusesource.com ** Blog: http://iocanel.blogspot.com ** Apache Karaf http://karaf.apache.org/ Committer PMC Apache Camel http://camel.apache.org/ Committer Apache ServiceMix http://servicemix.apache.org/ Committer Apache Gora http://incubator.apache.org/gora/ Committer Apache DirectMemory http://incubator.apache.org/directmemory/ Committer *
