Re: Karaf target audience and release granularity
on-premises and able to use > a > >>> cloud structure with clusters and so on. > >>> > >>> So, we are using karaf for that, OSGi services lets us to build > >>> "microservices" and have a easier reuse of Negotial Rules, with common > >>> transactions and so on (icks for XA . > >>> > >>> Well, it works, but we have some headaches, we had to build or own > >>> dependency mechanism, because every single feature refreshed the hell > of > >>> karaf, we also built an remote admin to update services on-the-fly in > >>> every > >>> single customer, it's working quite nicely, we still have some trouble > >>> with > >>> failed bundles, but nothing irremediable. > >>> > >>> Two things that would help us a lot, a spring-boot like app and an > easier > >>> way to update karaf version, for the updates we had to create a updater > >>> which saves a list of negotial bundles, reinstall karaf and restores > the > >>> bundles, it works but it's quite meh. > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html > >>> > >> > >> -- > >> Jean-Baptiste Onofré > > > >> jbonofre@ > > > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > > > > > > > > > > > > -- > > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker
Re: KARAF 4.1.5 & pax-logging-service
The plugin docs for log4j2 itself [1] covers more about it. If you’re trying to extend an existing appender, you’ll have to extend its corresponding manager class instead (an appender in v2 is more of a configuration mechanism while the manager handles the underlying data sink). I’d also suggest discussing with the Apache list if you’d like to integrate or request your feature upstream. [1]: http://logging.apache.org/log4j/2.x/manual/plugins.html On Tue, Mar 6, 2018 at 21:18, munishgupta.asr <munishgupta@gmail.com> wrote: > Hello JB, > > As you suggested and mentioned like that "If so, you should update your > appender to log4j2 style and attach to pax-logging-log4j2". > > I was trying to do that but it seems creating custom appenders is very > different here. earlier I was extending fileappenders and providing > configuration parameters in constructor through CFG file. but now it looks > very different. > > is there sample examples to refer about how to create custom file appenders > and attach it with pax-logging-log4j2 as fragment? > > or is there any way to still use pax-logging-service with KARAF 4.1.x > onwards as we are OK with log4j1 implementation. > > can you please help? kindly answer. > > Regards > Munish > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html > -- Matt Sicker <boa...@gmail.com>
Re: KARAF 4.1.5 & pax-logging-service
If you have a custom log4j 1 appender, there's limited support in log4j-1.2-api which you can add on to the log4j2 stuff, though I'm not sure how that would interact without some fragment hackery. On 2 March 2018 at 03:34, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Thanks, please let me know if you have any issue. > > Regards > JB > > On 03/02/2018 10:33 AM, munishgupta.asr wrote: > > Thanks JB. > > > > I will try and get back with results. > > > > Regards > > Munish > > > > > > > > -- > > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <boa...@gmail.com>
Re: [PROPOSAL] - Manual feature
I like that idea. I've always been a fan of being able to develop offline while I'm on a plane or train or somewhere with poor signal (or no desire to tether to LTE). On 1 March 2018 at 07:50, Francois Papon <francois.pa...@openobject.fr> wrote: > Hi guys, > > I'm thinking about adding the Karaf manual in a dedicated feature and > publishing it in html with the http service. > > It would be usefull for users connected to a local network without any > access to internet. > > Thoughts ? > > Francois > > > -- Matt Sicker <boa...@gmail.com>
Re: [DISCUSS] Improve colored logging output
Sorry, not Logstash: Logback. On 19 October 2017 at 23:43, Matt Sicker <boa...@gmail.com> wrote: > I really like the colour scheme that Spring Boot uses by default with > Logstash and Log4j2 and is what I tend to copy/paste into my own logging > config files. > > On 19 October 2017 at 16:33, Guillaume Nodet <gno...@apache.org> wrote: > >> I'm wondering about improving the colored logging output in both the >> "log:display" command and when running "bin/karaf run". >> I'm thinking about keeping the log file the way it is, but simplifying the >> output on the console and improving the color a bit. >> >> 23:11:44.198 *INFO* [pool-14-thread-3] Registering commands for bundle >> org.apache.karaf.log.core/4.2.0.SNAPSHOT >> >> 23:11:51.043 *ERROR* [Karaf local console user karaf] Exception caught >> while executing command >> >> ... >> >> 23:15:19.481 *DEBUG* [Karaf local console user karaf] Executing command: >> 'ld' >> >> I've currently reused the maven color scheme, so *debug* *info* *warning* >> *error*. >> >> The current behavior is that "bin/karaf run" is uncolored, while >> "log:display" have fully colored lines, both having the same output as the >> log file. The problem with the log file pattern is that it oftens does >> not >> fit in the screen, even with a large one. >> >> If you have any thoughts, let me know... >> I have the above code ready to commit, but I'm happy to change the scheme, >> drop it, or whatever else... >> >> Cheers, >> Guillaume >> > > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
Re: [DISCUSS] Improve colored logging output
I really like the colour scheme that Spring Boot uses by default with Logstash and Log4j2 and is what I tend to copy/paste into my own logging config files. On 19 October 2017 at 16:33, Guillaume Nodet <gno...@apache.org> wrote: > I'm wondering about improving the colored logging output in both the > "log:display" command and when running "bin/karaf run". > I'm thinking about keeping the log file the way it is, but simplifying the > output on the console and improving the color a bit. > > 23:11:44.198 *INFO* [pool-14-thread-3] Registering commands for bundle > org.apache.karaf.log.core/4.2.0.SNAPSHOT > > 23:11:51.043 *ERROR* [Karaf local console user karaf] Exception caught > while executing command > > ... > > 23:15:19.481 *DEBUG* [Karaf local console user karaf] Executing command: > 'ld' > > I've currently reused the maven color scheme, so *debug* *info* *warning* > *error*. > > The current behavior is that "bin/karaf run" is uncolored, while > "log:display" have fully colored lines, both having the same output as the > log file. The problem with the log file pattern is that it oftens does not > fit in the screen, even with a large one. > > If you have any thoughts, let me know... > I have the above code ready to commit, but I'm happy to change the scheme, > drop it, or whatever else... > > Cheers, > Guillaume > -- Matt Sicker <boa...@gmail.com>
Re: [Proposal] New subproject rcomp - Reactive components framework
not gathering a critical mass of components to > draw > > more people. > > Another risk is that the RComponent API or the reactor streams have some > > unexpected limitations. > > The big opportunity I see is that the rcomp API is very simple so the > > barrier of entry is low. > > I also hope that this might become a new foundation for a simpler and > more > > modern Apache Camel. > > > > So this all depends on getting some support by you all. > > > > Christian > > > > > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > http://www.talend.com > > > > > > > -- > > Guillaume Nodet > -- Matt Sicker <boa...@gmail.com>
Re: [PROPOSAL] Apache Karaf Slack & discuss about GitBox
I've discussed with someone on the ASF Slack about getting a Matrix server set up. That would allow you to use IRC, Slack, Matrix, or a few other protocols to chat with the same channels, PMs, etc. On 12 June 2017 at 07:14, Achim Nierbeck <bcanh...@googlemail.com> wrote: > I have my doubts about slack ... > > the nice thing about slack: > you don't miss anything > > the bad thing about slack: > you don't miss anything > > and it's a memory hog > > regards, Achim > > > > > 2017-06-12 14:07 GMT+02:00 Jonathan Schoreels < > jonathan.schore...@gmail.com> > : > > > That's a good idea. As pointed out, the integration with Github is really > > good and could help a lot to follow/discuss PR/Features/Bugs. > > > > Jonathan > > > > 2017-06-12 13:37 GMT+02:00 Jamie G. <jamie.goody...@gmail.com>: > > > > > In regards to slack, I do find it very convenient to use. Very low > > > barrier of entry to new users and contributors. > > > > > > As the email distributions are the official place for communication > > > (User/Dev) I'd be happy having day to day community chat on IRC & > > > Slack. > > > > > > > > > > > > On Mon, Jun 12, 2017 at 3:20 AM, Jean-Baptiste Onofré <j...@nanthrax.net > > > > > wrote: > > > > Hi team, > > > > > > > > Slack is very popular communication channel for developer. Lot of > > Apache > > > > projects are using it and it's pretty convenient. > > > > > > > > I wonder if it makes sense to propose a Apache Karaf Slack room in > > > addition > > > > of IRC. Thoughts ? > > > > > > > > On the other hand, Apache now provides GitBox: > > > > > > > > https://gitbox.apache.org/ > > > > > > > > GitBox enables bi-directional sync to GitHub and links committer's > > > accounts, > > > > allowing greater use of GitHub functionality by contributors and > > > committers. > > > > > > > > There's no rush but I think it could be interesting for Karaf, > > > especially to > > > > get more contributions via GitHub Pull Requests. > > > > > > > > Thoughts ? > > > > > > > > On the other hand, I will send an e-mail explaining the "clean" steps > > to > > > do > > > > when merging a GitHub PR (to automatically update the PR, etc). > > > > > > > > Regards > > > > JB > > > > -- > > > > Jean-Baptiste Onofré > > > > jbono...@apache.org > > > > http://blog.nanthrax.net > > > > Talend - http://www.talend.com > > > > > > > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > Software Architect / Project Manager / Scrum Master > -- Matt Sicker <boa...@gmail.com>
Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...
I remember there being a bug involving the packages property in only the properties file format, not sure if it was fixed. Do you get the same issue when using the XML format? On 25 May 2017 at 12:14, James Carman <ja...@carmanconsulting.com> wrote: > Okay, I've found a work-around for me, but I think it brings up a slight > improvement. By default, Log4j will only search in the > org.apache.logging.log4j.core.* packages for plugins. So, while the > fragment host approach does work to get my classes into the > "org.ops4j.pax.logging.pax-logging-log4j2" bundle (not pax-logging-service > as described in the instructions/examples), Log4j will not find them, > because they're not in the correct package structure. By moving my custom > layout to a package underneath that root package, I was able to get things > working properly. We need a way to change the package list that Log4j > searches. I tried setting the log4j2.packages property in the > configuration file, but it doesn't seem to be working. Thoughts? > > > > > On Thu, May 25, 2017 at 10:09 AM Matt Sicker <boa...@gmail.com> wrote: > > > It's possible there's an issue with the shading going on. Ideally, log4j2 > > should be split into at least log4j-api and log4j-core, but pax-logging > > shades them together for some reason. > > > > On 25 May 2017 at 00:55, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > > > > Hi guys, > > > > > > I will take a look on this one. It sounds like a missing > > > activator/fragment host in pax-logging-log4jv2. > > > > > > Regards > > > JB > > > > > > > > > On 05/25/2017 02:38 AM, James Carman wrote: > > > > > >> I can try to help if you guys want. Want me to tinker? I think we > will > > >> want to update the docs too, since folks will need to generate those > dat > > >> files. > > >> On Wed, May 24, 2017 at 8:31 PM Matt Sicker <boa...@gmail.com> wrote: > > >> > > >> Oh, well that certainly sounds like a problem! There's an activator in > > >>> both > > >>> log4j-api and log4j-core from what I recall, so pax-logging might > need > > >>> something custom as well. > > >>> > > >>> On 24 May 2017 at 17:41, James Carman <ja...@carmanconsulting.com> > > >>> wrote: > > >>> > > >>> So, I've done a bit of digging. Log4j2 ships with an Activator that > > sets > > >>>> up a BundleListener which scans (looks for Log4j2Plugins.dat files) > > >>>> > > >>> bundles > > >>> > > >>>> for any plugins to be registered. Since log4j itself is not loaded > > as a > > >>>> bundle (it appears to be shaded into pax-logging-log4j2), that > > Activator > > >>>> doesn't run. Perhaps we should delegate to Log4j's internal > Activator > > >>>> during the start() method of the Pax Logging Activator > > >>>> (org.ops4j.pax.logging.log4j2.internal.Activator)? Do we cover > this > > >>>> behavior in some other way? > > >>>> > > >>>> > > >>>> On Wed, May 24, 2017 at 3:32 PM James Carman < > > >>>> ja...@carmanconsulting.com > > >>>> > > >>>> wrote: > > >>>> > > >>>> So, am I way off base with my approach or anything? Should Karaf be > > >>>>> installing pax-logging-service? Or, is pax-logging-log4j2 taking > its > > >>>>> > > >>>> place > > >>>> > > >>>>> for Karaf? Is there anything special we have to do to implement a > > >>>>> > > >>>> custom > > >>> > > >>>> Layout using pax-logging? Is there a working example I can use to > > >>>>> > > >>>> install > > >>>> > > >>>>> into karaf to see if it works for me? > > >>>>> > > >>>>> > > >>>>> On Wed, May 24, 2017 at 3:20 PM Matt Sicker <boa...@gmail.com> > > wrote: > > >>>>> > > >>>>> I mostly work on Log4j2, though I try to answer questions about it > on > > >>>>>> ops4j > > >>>>>> and karaf due to pax-logging. > > >>>>>> > > >>>>>> On 24 May 2017 at 14:17, James Carman
Re: [UPDATE] Remove org.json dependency
>From what I understand, this only applies to the org.json dependency. Most people tend to use Jackson or Gson in my experience which are appropriately licensed. On 25 May 2017 at 08:41, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Yeah, but we are using json for our "webconsole plugins". So, I'm changing > in our plugins. > > Regards > JB > > > On 05/25/2017 03:39 PM, Achim Nierbeck wrote: > >> Hi JB, >> >> I thought the felix team did some effort in replacing all that json stuff >> with internal handling. >> We should just update to the latest then ... >> >> regards, Achim >> >> >> 2017-05-25 15:38 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >> >> Hi, >>> >>> Chris Mattmann (new Legal VP) sent a reminder about json dependency use: >>> >>> --- >>> As the new Legal VP, I am reminding everyone that the >>> grandfather exception for the JSON License and Apache projects >>> ended last month. As sent by Jim (our prior Legal VP) the relevant >>> text is below and I want to highlight the following statement: >>> >>> If you have been using it, and have done so in a *release*, AND there has >>> been NO pushback from your community/eco-system, you have a temporary >>> exclusion from the Cat-X classification thru April 30, 2017. At that >>> point >>> in time, >>> >>> ANY and ALL usage of these JSON licensed artifacts are DISALLOWED. >>> --- >>> >>> We are using json (org.json/json) in the WebConsole. I created KARAF-5148 >>> to track this and I'm evaluating different alternatives. >>> >>> Regards >>> JB >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <boa...@gmail.com>
Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...
It's possible there's an issue with the shading going on. Ideally, log4j2 should be split into at least log4j-api and log4j-core, but pax-logging shades them together for some reason. On 25 May 2017 at 00:55, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi guys, > > I will take a look on this one. It sounds like a missing > activator/fragment host in pax-logging-log4jv2. > > Regards > JB > > > On 05/25/2017 02:38 AM, James Carman wrote: > >> I can try to help if you guys want. Want me to tinker? I think we will >> want to update the docs too, since folks will need to generate those dat >> files. >> On Wed, May 24, 2017 at 8:31 PM Matt Sicker <boa...@gmail.com> wrote: >> >> Oh, well that certainly sounds like a problem! There's an activator in >>> both >>> log4j-api and log4j-core from what I recall, so pax-logging might need >>> something custom as well. >>> >>> On 24 May 2017 at 17:41, James Carman <ja...@carmanconsulting.com> >>> wrote: >>> >>> So, I've done a bit of digging. Log4j2 ships with an Activator that sets >>>> up a BundleListener which scans (looks for Log4j2Plugins.dat files) >>>> >>> bundles >>> >>>> for any plugins to be registered. Since log4j itself is not loaded as a >>>> bundle (it appears to be shaded into pax-logging-log4j2), that Activator >>>> doesn't run. Perhaps we should delegate to Log4j's internal Activator >>>> during the start() method of the Pax Logging Activator >>>> (org.ops4j.pax.logging.log4j2.internal.Activator)? Do we cover this >>>> behavior in some other way? >>>> >>>> >>>> On Wed, May 24, 2017 at 3:32 PM James Carman < >>>> ja...@carmanconsulting.com >>>> >>>> wrote: >>>> >>>> So, am I way off base with my approach or anything? Should Karaf be >>>>> installing pax-logging-service? Or, is pax-logging-log4j2 taking its >>>>> >>>> place >>>> >>>>> for Karaf? Is there anything special we have to do to implement a >>>>> >>>> custom >>> >>>> Layout using pax-logging? Is there a working example I can use to >>>>> >>>> install >>>> >>>>> into karaf to see if it works for me? >>>>> >>>>> >>>>> On Wed, May 24, 2017 at 3:20 PM Matt Sicker <boa...@gmail.com> wrote: >>>>> >>>>> I mostly work on Log4j2, though I try to answer questions about it on >>>>>> ops4j >>>>>> and karaf due to pax-logging. >>>>>> >>>>>> On 24 May 2017 at 14:17, James Carman <ja...@carmanconsulting.com> >>>>>> >>>>> wrote: >>>> >>>>> >>>>>> I know. ;) And I meant no slight to you. I didn't know you were >>>>>>> >>>>>> one >>> >>>> of >>>> >>>>> the contributors these days. I have checked out the code and I'm >>>>>>> >>>>>> going >>>> >>>>> to >>>>>> >>>>>>> poke around a bit. >>>>>>> >>>>>>> On Wed, May 24, 2017 at 3:15 PM Matt Sicker <boa...@gmail.com> >>>>>>> >>>>>> wrote: >>> >>>> >>>>>>> That would be on the ops4j lists, though that's mostly the same >>>>>>>> >>>>>>> people as >>>>>> >>>>>>> here. >>>>>>>> >>>>>>>> On 24 May 2017 at 13:31, James Carman <ja...@carmanconsulting.com >>>>>>>> >>>>>>> >>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> I think I must be doing something wrong. Hopefully one of the >>>>>>>>> >>>>>>>> PAX >>> >>>> folks >>>>>>> >>>>>>>> can help here. I wonder if I should just reach out to them >>>>>>>>> >>>>>>>> directly or >>>>>> >>>>>>> if >>>>>>>> >>>>>>>>> this is a karaf-specific issue with PAX? >>>>>>>>> >>>>>>>
Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...
Yes, if you can figure anything out, that'd be great! On 24 May 2017 at 19:38, James Carman <ja...@carmanconsulting.com> wrote: > I can try to help if you guys want. Want me to tinker? I think we will > want to update the docs too, since folks will need to generate those dat > files. > On Wed, May 24, 2017 at 8:31 PM Matt Sicker <boa...@gmail.com> wrote: > > > Oh, well that certainly sounds like a problem! There's an activator in > both > > log4j-api and log4j-core from what I recall, so pax-logging might need > > something custom as well. > > > > On 24 May 2017 at 17:41, James Carman <ja...@carmanconsulting.com> > wrote: > > > > > So, I've done a bit of digging. Log4j2 ships with an Activator that > sets > > > up a BundleListener which scans (looks for Log4j2Plugins.dat files) > > bundles > > > for any plugins to be registered. Since log4j itself is not loaded as > a > > > bundle (it appears to be shaded into pax-logging-log4j2), that > Activator > > > doesn't run. Perhaps we should delegate to Log4j's internal Activator > > > during the start() method of the Pax Logging Activator > > > (org.ops4j.pax.logging.log4j2.internal.Activator)? Do we cover this > > > behavior in some other way? > > > > > > > > > On Wed, May 24, 2017 at 3:32 PM James Carman < > ja...@carmanconsulting.com > > > > > > wrote: > > > > > > > So, am I way off base with my approach or anything? Should Karaf be > > > > installing pax-logging-service? Or, is pax-logging-log4j2 taking its > > > place > > > > for Karaf? Is there anything special we have to do to implement a > > custom > > > > Layout using pax-logging? Is there a working example I can use to > > > install > > > > into karaf to see if it works for me? > > > > > > > > > > > > On Wed, May 24, 2017 at 3:20 PM Matt Sicker <boa...@gmail.com> > wrote: > > > > > > > >> I mostly work on Log4j2, though I try to answer questions about it > on > > > >> ops4j > > > >> and karaf due to pax-logging. > > > >> > > > >> On 24 May 2017 at 14:17, James Carman <ja...@carmanconsulting.com> > > > wrote: > > > >> > > > >> > I know. ;) And I meant no slight to you. I didn't know you were > > one > > > of > > > >> > the contributors these days. I have checked out the code and I'm > > > going > > > >> to > > > >> > poke around a bit. > > > >> > > > > >> > On Wed, May 24, 2017 at 3:15 PM Matt Sicker <boa...@gmail.com> > > wrote: > > > >> > > > > >> > > That would be on the ops4j lists, though that's mostly the same > > > >> people as > > > >> > > here. > > > >> > > > > > >> > > On 24 May 2017 at 13:31, James Carman < > ja...@carmanconsulting.com > > > > > > >> > wrote: > > > >> > > > > > >> > > > I think I must be doing something wrong. Hopefully one of the > > PAX > > > >> > folks > > > >> > > > can help here. I wonder if I should just reach out to them > > > >> directly or > > > >> > > if > > > >> > > > this is a karaf-specific issue with PAX? > > > >> > > > > > > >> > > > On Wed, May 24, 2017 at 2:29 PM Matt Sicker <boa...@gmail.com > > > > > >> wrote: > > > >> > > > > > > >> > > > > At compile time, an annotation processor in log4j-core > > > generates a > > > >> > .dat > > > >> > > > > file containing some metadata about scanned plugins. These > JAR > > > >> > resource > > > >> > > > > files are loaded at plugin scan time where reflection is > used > > to > > > >> > > > > investigate the classes and instantiate plugins based on > > config > > > >> > files. > > > >> > > > > Alternatively, there's an option you can set to scan a > > > particular > > > >> > list > > > >> > > of > > > >> > > > > packages for additional plugins, though I think that uses > the > > > >> context > > &
Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...
Oh, well that certainly sounds like a problem! There's an activator in both log4j-api and log4j-core from what I recall, so pax-logging might need something custom as well. On 24 May 2017 at 17:41, James Carman <ja...@carmanconsulting.com> wrote: > So, I've done a bit of digging. Log4j2 ships with an Activator that sets > up a BundleListener which scans (looks for Log4j2Plugins.dat files) bundles > for any plugins to be registered. Since log4j itself is not loaded as a > bundle (it appears to be shaded into pax-logging-log4j2), that Activator > doesn't run. Perhaps we should delegate to Log4j's internal Activator > during the start() method of the Pax Logging Activator > (org.ops4j.pax.logging.log4j2.internal.Activator)? Do we cover this > behavior in some other way? > > > On Wed, May 24, 2017 at 3:32 PM James Carman <ja...@carmanconsulting.com> > wrote: > > > So, am I way off base with my approach or anything? Should Karaf be > > installing pax-logging-service? Or, is pax-logging-log4j2 taking its > place > > for Karaf? Is there anything special we have to do to implement a custom > > Layout using pax-logging? Is there a working example I can use to > install > > into karaf to see if it works for me? > > > > > > On Wed, May 24, 2017 at 3:20 PM Matt Sicker <boa...@gmail.com> wrote: > > > >> I mostly work on Log4j2, though I try to answer questions about it on > >> ops4j > >> and karaf due to pax-logging. > >> > >> On 24 May 2017 at 14:17, James Carman <ja...@carmanconsulting.com> > wrote: > >> > >> > I know. ;) And I meant no slight to you. I didn't know you were one > of > >> > the contributors these days. I have checked out the code and I'm > going > >> to > >> > poke around a bit. > >> > > >> > On Wed, May 24, 2017 at 3:15 PM Matt Sicker <boa...@gmail.com> wrote: > >> > > >> > > That would be on the ops4j lists, though that's mostly the same > >> people as > >> > > here. > >> > > > >> > > On 24 May 2017 at 13:31, James Carman <ja...@carmanconsulting.com> > >> > wrote: > >> > > > >> > > > I think I must be doing something wrong. Hopefully one of the PAX > >> > folks > >> > > > can help here. I wonder if I should just reach out to them > >> directly or > >> > > if > >> > > > this is a karaf-specific issue with PAX? > >> > > > > >> > > > On Wed, May 24, 2017 at 2:29 PM Matt Sicker <boa...@gmail.com> > >> wrote: > >> > > > > >> > > > > At compile time, an annotation processor in log4j-core > generates a > >> > .dat > >> > > > > file containing some metadata about scanned plugins. These JAR > >> > resource > >> > > > > files are loaded at plugin scan time where reflection is used to > >> > > > > investigate the classes and instantiate plugins based on config > >> > files. > >> > > > > Alternatively, there's an option you can set to scan a > particular > >> > list > >> > > of > >> > > > > packages for additional plugins, though I think that uses the > >> context > >> > > > > ClassLoader which might not work properly in your scenario. > >> > > > > > >> > > > > On 24 May 2017 at 11:22, James Carman < > ja...@carmanconsulting.com > >> > > >> > > > wrote: > >> > > > > > >> > > > > > Any advice on how I might be able to fight my way through it? > >> How > >> > > does > >> > > > > > Log4j2 "discover" those @Plugin-annotated classes? Does it > use > >> > some > >> > > > form > >> > > > > > of classpath scanning? Is it scoped to certain packages only? > >> I'm > >> > > > > > thinking I might have to attach to the pax-logging-log4j2 > bundle > >> > as a > >> > > > > host > >> > > > > > in order to augment its classpath so that it can see my stuff. > >> > > > > > > >> > > > > > On Wed, May 24, 2017 at 12:20 PM Matt Sicker < > boa...@gmail.com> > >> > > wrote: > >> > > > > > > >>
Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...
I mostly work on Log4j2, though I try to answer questions about it on ops4j
and karaf due to pax-logging.
On 24 May 2017 at 14:17, James Carman <ja...@carmanconsulting.com> wrote:
> I know. ;) And I meant no slight to you. I didn't know you were one of
> the contributors these days. I have checked out the code and I'm going to
> poke around a bit.
>
> On Wed, May 24, 2017 at 3:15 PM Matt Sicker <boa...@gmail.com> wrote:
>
> > That would be on the ops4j lists, though that's mostly the same people as
> > here.
> >
> > On 24 May 2017 at 13:31, James Carman <ja...@carmanconsulting.com>
> wrote:
> >
> > > I think I must be doing something wrong. Hopefully one of the PAX
> folks
> > > can help here. I wonder if I should just reach out to them directly or
> > if
> > > this is a karaf-specific issue with PAX?
> > >
> > > On Wed, May 24, 2017 at 2:29 PM Matt Sicker <boa...@gmail.com> wrote:
> > >
> > > > At compile time, an annotation processor in log4j-core generates a
> .dat
> > > > file containing some metadata about scanned plugins. These JAR
> resource
> > > > files are loaded at plugin scan time where reflection is used to
> > > > investigate the classes and instantiate plugins based on config
> files.
> > > > Alternatively, there's an option you can set to scan a particular
> list
> > of
> > > > packages for additional plugins, though I think that uses the context
> > > > ClassLoader which might not work properly in your scenario.
> > > >
> > > > On 24 May 2017 at 11:22, James Carman <ja...@carmanconsulting.com>
> > > wrote:
> > > >
> > > > > Any advice on how I might be able to fight my way through it? How
> > does
> > > > > Log4j2 "discover" those @Plugin-annotated classes? Does it use
> some
> > > form
> > > > > of classpath scanning? Is it scoped to certain packages only? I'm
> > > > > thinking I might have to attach to the pax-logging-log4j2 bundle
> as a
> > > > host
> > > > > in order to augment its classpath so that it can see my stuff.
> > > > >
> > > > > On Wed, May 24, 2017 at 12:20 PM Matt Sicker <boa...@gmail.com>
> > wrote:
> > > > >
> > > > > > It could be a bug in log4j2 itself rather than pax-logging. I
> > worked
> > > on
> > > > > > some OSGi support in log4j2 a while back, and I'm not sure if
> this
> > > is a
> > > > > new
> > > > > > issue or an existing one.
> > > > > >
> > > > > > On 24 May 2017 at 05:43, James Carman <
> ja...@carmanconsulting.com>
> > > > > wrote:
> > > > > >
> > > > > > > I tried adding pax-logging-service to startup.properties (after
> > > > putting
> > > > > > it
> > > > > > > into the system repo) and I still have the issue. So, the
> > ultimate
> > > > > issue
> > > > > > > isn't the fragment host necessarily. My issue is that it can't
> > fine
> > > > my
> > > > > > > custom layout class. I've tried using the name from the @Plugin
> > > > > > annotation.
> > > > > > > I've tried using the fully-qualified class name. Nothing seems
> to
> > > > work.
> > > > > > > Here's the declaration of my layout:
> > > > > > >
> > > > > > > @Plugin(name = "MyJsonLayout", category = Node.CATEGORY,
> > > elementType
> > > > =
> > > > > > > Layout.ELEMENT_TYPE, printObject = true)
> > > > > > > public class MyJsonLayout extends AbstractStringLayout {
> > > > > > > ...
> > > > > > > }
> > > > > > >
> > > > > > > and here's what I've changed in the logging config file:
> > > > > > >
> > > > > > > log4j2.rootLogger.appenderRef.RollingFile.ref = RollingFile
> > > > > > > # Rolling file appender
> > > > > > > log4j2.appender.rolling.type = RollingRandomAccessFile
> > > > > > > log4j2.appender.rolling.name = RollingFile
> > > > > > > log4j2.appender.rolling.fileName = ${karaf.home}/log/aetos.log
> > > > > > > log4j2.appender.rolling.filePattern =
> > > ${karaf.home}/log/a
Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...
That would be on the ops4j lists, though that's mostly the same people as
here.
On 24 May 2017 at 13:31, James Carman <ja...@carmanconsulting.com> wrote:
> I think I must be doing something wrong. Hopefully one of the PAX folks
> can help here. I wonder if I should just reach out to them directly or if
> this is a karaf-specific issue with PAX?
>
> On Wed, May 24, 2017 at 2:29 PM Matt Sicker <boa...@gmail.com> wrote:
>
> > At compile time, an annotation processor in log4j-core generates a .dat
> > file containing some metadata about scanned plugins. These JAR resource
> > files are loaded at plugin scan time where reflection is used to
> > investigate the classes and instantiate plugins based on config files.
> > Alternatively, there's an option you can set to scan a particular list of
> > packages for additional plugins, though I think that uses the context
> > ClassLoader which might not work properly in your scenario.
> >
> > On 24 May 2017 at 11:22, James Carman <ja...@carmanconsulting.com>
> wrote:
> >
> > > Any advice on how I might be able to fight my way through it? How does
> > > Log4j2 "discover" those @Plugin-annotated classes? Does it use some
> form
> > > of classpath scanning? Is it scoped to certain packages only? I'm
> > > thinking I might have to attach to the pax-logging-log4j2 bundle as a
> > host
> > > in order to augment its classpath so that it can see my stuff.
> > >
> > > On Wed, May 24, 2017 at 12:20 PM Matt Sicker <boa...@gmail.com> wrote:
> > >
> > > > It could be a bug in log4j2 itself rather than pax-logging. I worked
> on
> > > > some OSGi support in log4j2 a while back, and I'm not sure if this
> is a
> > > new
> > > > issue or an existing one.
> > > >
> > > > On 24 May 2017 at 05:43, James Carman <ja...@carmanconsulting.com>
> > > wrote:
> > > >
> > > > > I tried adding pax-logging-service to startup.properties (after
> > putting
> > > > it
> > > > > into the system repo) and I still have the issue. So, the ultimate
> > > issue
> > > > > isn't the fragment host necessarily. My issue is that it can't fine
> > my
> > > > > custom layout class. I've tried using the name from the @Plugin
> > > > annotation.
> > > > > I've tried using the fully-qualified class name. Nothing seems to
> > work.
> > > > > Here's the declaration of my layout:
> > > > >
> > > > > @Plugin(name = "MyJsonLayout", category = Node.CATEGORY,
> elementType
> > =
> > > > > Layout.ELEMENT_TYPE, printObject = true)
> > > > > public class MyJsonLayout extends AbstractStringLayout {
> > > > > ...
> > > > > }
> > > > >
> > > > > and here's what I've changed in the logging config file:
> > > > >
> > > > > log4j2.rootLogger.appenderRef.RollingFile.ref = RollingFile
> > > > > # Rolling file appender
> > > > > log4j2.appender.rolling.type = RollingRandomAccessFile
> > > > > log4j2.appender.rolling.name = RollingFile
> > > > > log4j2.appender.rolling.fileName = ${karaf.home}/log/aetos.log
> > > > > log4j2.appender.rolling.filePattern =
> ${karaf.home}/log/aetos.log.%i
> > > > > # uncomment to not force a disk flush
> > > > > log4j2.appender.rolling.immediateFlush = false
> > > > > log4j2.appender.rolling.append = true
> > > > > log4j2.appender.rolling.layout.type =
> > com.myco.log4j.json.MyJsonLayout
> > > > > log4j2.appender.rolling.policies.type = Policies
> > > > > log4j2.appender.rolling.policies.size.type =
> > SizeBasedTriggeringPolicy
> > > > > log4j2.appender.rolling.policies.size.size = 200MB
> > > > >
> > > > > As I said, I tried just using layout.type = MyJsonLayout, but that
> > > > doesn't
> > > > > work either. Do we have an example where something like this works
> > > that
> > > > I
> > > > > can reverse engineer?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > James
> > > > >
> > > > > On Tue, May 23, 2017 at 7:03 PM James Carman <
> > > ja...@carmanconsulting.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I am trying to use a custo
Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...
At compile time, an annotation processor in log4j-core generates a .dat
file containing some metadata about scanned plugins. These JAR resource
files are loaded at plugin scan time where reflection is used to
investigate the classes and instantiate plugins based on config files.
Alternatively, there's an option you can set to scan a particular list of
packages for additional plugins, though I think that uses the context
ClassLoader which might not work properly in your scenario.
On 24 May 2017 at 11:22, James Carman <ja...@carmanconsulting.com> wrote:
> Any advice on how I might be able to fight my way through it? How does
> Log4j2 "discover" those @Plugin-annotated classes? Does it use some form
> of classpath scanning? Is it scoped to certain packages only? I'm
> thinking I might have to attach to the pax-logging-log4j2 bundle as a host
> in order to augment its classpath so that it can see my stuff.
>
> On Wed, May 24, 2017 at 12:20 PM Matt Sicker <boa...@gmail.com> wrote:
>
> > It could be a bug in log4j2 itself rather than pax-logging. I worked on
> > some OSGi support in log4j2 a while back, and I'm not sure if this is a
> new
> > issue or an existing one.
> >
> > On 24 May 2017 at 05:43, James Carman <ja...@carmanconsulting.com>
> wrote:
> >
> > > I tried adding pax-logging-service to startup.properties (after putting
> > it
> > > into the system repo) and I still have the issue. So, the ultimate
> issue
> > > isn't the fragment host necessarily. My issue is that it can't fine my
> > > custom layout class. I've tried using the name from the @Plugin
> > annotation.
> > > I've tried using the fully-qualified class name. Nothing seems to work.
> > > Here's the declaration of my layout:
> > >
> > > @Plugin(name = "MyJsonLayout", category = Node.CATEGORY, elementType =
> > > Layout.ELEMENT_TYPE, printObject = true)
> > > public class MyJsonLayout extends AbstractStringLayout {
> > > ...
> > > }
> > >
> > > and here's what I've changed in the logging config file:
> > >
> > > log4j2.rootLogger.appenderRef.RollingFile.ref = RollingFile
> > > # Rolling file appender
> > > log4j2.appender.rolling.type = RollingRandomAccessFile
> > > log4j2.appender.rolling.name = RollingFile
> > > log4j2.appender.rolling.fileName = ${karaf.home}/log/aetos.log
> > > log4j2.appender.rolling.filePattern = ${karaf.home}/log/aetos.log.%i
> > > # uncomment to not force a disk flush
> > > log4j2.appender.rolling.immediateFlush = false
> > > log4j2.appender.rolling.append = true
> > > log4j2.appender.rolling.layout.type = com.myco.log4j.json.MyJsonLayout
> > > log4j2.appender.rolling.policies.type = Policies
> > > log4j2.appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
> > > log4j2.appender.rolling.policies.size.size = 200MB
> > >
> > > As I said, I tried just using layout.type = MyJsonLayout, but that
> > doesn't
> > > work either. Do we have an example where something like this works
> that
> > I
> > > can reverse engineer?
> > >
> > > Thanks,
> > >
> > > James
> > >
> > > On Tue, May 23, 2017 at 7:03 PM James Carman <
> ja...@carmanconsulting.com
> > >
> > > wrote:
> > >
> > > > I am trying to use a custom layout and I'm following the examples (I
> > > > think). We had one that worked in Karaf 3.0.x. Anyway, I set up the
> > > > fragment host like this:
> > > >
> > > >
> > > > org.apache.felix
> > > > maven-bundle-plugin
> > > > 3.3.0
> > > > true
> > > > true
> > > >
> > > >
> > > >
> > > >
> > org.ops4j.pax.logging.pax-logging-service
> > > >
> > > >
> > > >
> > > >
> > > > However, my bundle will not resolve this way. I don't see that bundle
> > > > being loaded in Karaf 4.1.1:
> > > > karaf@root()> list -t 0 -s | grep -i log 19:01:18
> > > > 5 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-api
> > > > 6 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-log4j2
> > > > 36 │ Active │ 30 │ 4.1.1 │ org.apache.karaf.log.core
> > > >
> > > > I tried binding to "org.ops4j.pax.logging.pax-logging-api", but that
> > > > didn't work either. Did this process change for 4.1.x?
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker <boa...@gmail.com>
> >
>
--
Matt Sicker <boa...@gmail.com>
Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...
It could be a bug in log4j2 itself rather than pax-logging. I worked on
some OSGi support in log4j2 a while back, and I'm not sure if this is a new
issue or an existing one.
On 24 May 2017 at 05:43, James Carman <ja...@carmanconsulting.com> wrote:
> I tried adding pax-logging-service to startup.properties (after putting it
> into the system repo) and I still have the issue. So, the ultimate issue
> isn't the fragment host necessarily. My issue is that it can't fine my
> custom layout class. I've tried using the name from the @Plugin annotation.
> I've tried using the fully-qualified class name. Nothing seems to work.
> Here's the declaration of my layout:
>
> @Plugin(name = "MyJsonLayout", category = Node.CATEGORY, elementType =
> Layout.ELEMENT_TYPE, printObject = true)
> public class MyJsonLayout extends AbstractStringLayout {
> ...
> }
>
> and here's what I've changed in the logging config file:
>
> log4j2.rootLogger.appenderRef.RollingFile.ref = RollingFile
> # Rolling file appender
> log4j2.appender.rolling.type = RollingRandomAccessFile
> log4j2.appender.rolling.name = RollingFile
> log4j2.appender.rolling.fileName = ${karaf.home}/log/aetos.log
> log4j2.appender.rolling.filePattern = ${karaf.home}/log/aetos.log.%i
> # uncomment to not force a disk flush
> log4j2.appender.rolling.immediateFlush = false
> log4j2.appender.rolling.append = true
> log4j2.appender.rolling.layout.type = com.myco.log4j.json.MyJsonLayout
> log4j2.appender.rolling.policies.type = Policies
> log4j2.appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
> log4j2.appender.rolling.policies.size.size = 200MB
>
> As I said, I tried just using layout.type = MyJsonLayout, but that doesn't
> work either. Do we have an example where something like this works that I
> can reverse engineer?
>
> Thanks,
>
> James
>
> On Tue, May 23, 2017 at 7:03 PM James Carman <ja...@carmanconsulting.com>
> wrote:
>
> > I am trying to use a custom layout and I'm following the examples (I
> > think). We had one that worked in Karaf 3.0.x. Anyway, I set up the
> > fragment host like this:
> >
> >
> > org.apache.felix
> > maven-bundle-plugin
> > 3.3.0
> > true
> > true
> >
> >
> >
> > org.ops4j.pax.logging.pax-logging-service
> >
> >
> >
> >
> > However, my bundle will not resolve this way. I don't see that bundle
> > being loaded in Karaf 4.1.1:
> > karaf@root()> list -t 0 -s | grep -i log 19:01:18
> > 5 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-api
> > 6 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-log4j2
> > 36 │ Active │ 30 │ 4.1.1 │ org.apache.karaf.log.core
> >
> > I tried binding to "org.ops4j.pax.logging.pax-logging-api", but that
> > didn't work either. Did this process change for 4.1.x?
> >
>
--
Matt Sicker <boa...@gmail.com>
Re: Half patch for logging documentation
I think you need to specify which lookup to use in ${placeholder} things in
the log4j2 properties file example. For example: ${sys:foo.bar} for the
foo.bar system property. <
https://logging.apache.org/log4j/2.x/manual/lookups.html>
I'm not sure what happens when you don't use a prefix as it's not clearly
documented.
On 22 May 2017 at 08:32, Arunan Balasubramaniam <
arunan.balasubraman...@interlinksoftware.com> wrote:
>
> Hi,
>
> the user documentation still refers to configuring logging using log4j(1)
> while Karaf has moved on to log4j2. I started updating the documentation
> but did not feel confident changing anything from the "Advanced
> configuration" stage towards the bottom of the documentation. The changes I
> made up to that point are available at https://github.com/NetNow/
> karaf/commit/e0a592117bb259833f8500c6c534c2f1deb13d22 in case they are of
> use; but if that commit were applied as-is, the manual would have
> instructions for both log4j and log4j2 configuration in it which is
> possibly worse than now.
>
> By the way, the file etc/org.ops4j.pax.logging.cfg has a few log4j(1)
> properties left in but commented out at the bottom.
>
> Regards,
> Arunan
>
--
Matt Sicker <boa...@gmail.com>
Re: Karaf starting slow on new mac
Oh wow, I had that same issue in Log4j a while back. I added quick fix instructions on our building page. Just add your host name to /etc/hosts. I wonder if it's an IPv6 problem in macOS? On Thu, Apr 20, 2017 at 01:36, Milen Dyankov <milendyan...@gmail.com> wrote: > See https://thoeni.io/post/macos-sierra-java/ > > On Wed, Apr 19, 2017 at 9:01 PM, Achim Nierbeck <bcanh...@googlemail.com> > wrote: > > > Hi, > > > > first you should post your question on the users list, issues is actually > > for the issue tracker :) > > second, I'm using macOS Sierra, and everything is running fine so I can > not > > reproduce this. > > > > regards, Achim > > > > 2017-04-19 20:35 GMT+02:00 Aaron Jones <ajo...@warrenrogers.com>: > > > > > I have tried using several different versions including 3.0.3 and > 4.1.1. > > > My operating system is macOS Sierra Version 10.12.4 and I am using the > > Java > > > JVM 1.8. I do not have a stack trace because nothing is technically > > erring > > > out but just running extremely slow. I first noticed a problem when > > > integration tests weren’t passing on my new laptop but the exact same > > code > > > was passing on a coworkers laptop. He is running an older version > macOS. > > We > > > think it has something to do with macOS Sierra because we had another > > > developer test on his box and got the same behavior I was getting. It > > seems > > > like it is taking longer than normal on the RMI steps of the startup > > > process. Even when downloading a clean version of Kara and starting it, > > the > > > process takes 15+ secs on a new Mac and less than 3 secs on the older > > > version of macOS. The is nothing that I can find of people having the > > same > > > problem so this was the only other place I thought to come. Thank you > for > > > any help in advance. > > > -- > > > This e-mail, any and all files transmitted with it, and all > corresponding > > > e-mail messages are confidential and intended solely for the use of the > > > individual or entity to whom they are addressed. If you have received > > this > > > email in error, please notify the sender immediately by return e-mail. > If > > > you are not the named addressee, you should not disseminate, distribute > > or > > > copy this e-mail. Disclosing, copying, distributing or taking any > action > > in > > > reliance on the contents of this information is strictly prohibited. > > > > > > > > > > > -- > > > > Apache Member > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer > & > > Project Lead > > blog <http://notizblog.nierbeck.de/> > > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > > > Software Architect / Project Manager / Scrum Master > > > > > > -- > http://about.me/milen > -- Matt Sicker <boa...@gmail.com>
Re: Towards Karaf (Container) 4.1.0
it's more complex and requires more time, then, I will release > >>>>>>>>> 4.1.0-M1 tomorrow evening, the 4.1.0 (GA) will be released 3 > weeks > >>>>>>>>> later, giving time for us to fix the jline/command issue. > >>>>>>>>> > >>>>>>>>> Thanks ! > >>>>>>>>> Regards > >>>>>>>>> JB > >>>>>>>>> > >>>>>>>>> On 01/29/2017 11:31 AM, Jean-Baptiste Onofré wrote: > >>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> the problem is clearly an incompatible version of jline > >>>>>>>>>> (resulting of > >>>>>>>>>> the update we did in Karaf 4.1.x). It breaks other projects > which > >>>>>>>>>> are > >>>>>>>>>> using directly jline (for completer for instance). > >>>>>>>>>> > >>>>>>>>>> So, the other projects should be refactored (camel, activemq, > >>>>>>>>>> ...) to > >>>>>>>>>> not relay on jline but Karaf (for the completer for instance). > >>>>>>>>>> > >>>>>>>>>> Anyway, it means that Karaf 4.1.0 is not yet ready to support > any > >>>>>>>>>> other > >>>>>>>>>> projects. > >>>>>>>>>> > >>>>>>>>>> So, I'm going to 4.1.0-M1 first and we will invite maximum of > >>>>>>>>>> people to > >>>>>>>>>> test on this milestone in order to clearly identify the breaking > >>>>>>>>>> changes > >>>>>>>>>> and provide max backward compatibility when possible. > >>>>>>>>>> > >>>>>>>>>> I already changed the version in Jira and I will cut 4.1.0-M1 > >>>>>>>>>> later > >>>>>>>>>> today. > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> JB > >>>>>>>>>> > >>>>>>>>>> On 01/28/2017 03:32 PM, Jean-Baptiste Onofré wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi guys, > >>>>>>>>>>> > >>>>>>>>>>> as you might know, I'm preparing the Karaf 4.1.0 release. > >>>>>>>>>>> > >>>>>>>>>>> We are mostly ok, but during my tests, I found that Camel (at > >>>>>>>>>>> least > >>>>>>>>>>> 2.18.1) commands are not available in the shell. > >>>>>>>>>>> > >>>>>>>>>>> I suspect because they use the "old" style. > >>>>>>>>>>> > >>>>>>>>>>> I also see lot of small annoying behaviors in the shell console > >>>>>>>>>>> (on > >>>>>>>>>>> completion especially). > >>>>>>>>>>> > >>>>>>>>>>> So, even we are mostly ready, I'm not sure it's fully ready for > >>>>>>>>>>> production. > >>>>>>>>>>> > >>>>>>>>>>> Instead of directly releasing Karaf 4.1.0, I propose to release > >>>>>>>>>>> 4.1.0-M1 > >>>>>>>>>>> as a tech preview. I would allow people to review and test > >>>>>>>>>>> 4.1.0-M1 but > >>>>>>>>>>> give a good message that's a tech preview. > >>>>>>>>>>> > >>>>>>>>>>> WDYT ? > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> JB > >>>>>>>>>>> > >>>>>>>>>>> On 01/05/2017 03:39 PM, Jean-Baptiste Onofré wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi guys, > >>>>>>>>>>>> > >>>>>>>>>>>> I started the updates and fixes for Karaf 4.1.0. > >>>>>>>>>>>> > >>>>>>>>>>>> As dependencies, we will need Pax Exam 4.10.0 and Pax Web > 6.0.1. > >>>>>>>>>>>> Achim > >>>>>>>>>>>> and I will tackle this as it's pre-requisite for 4.1.0. > >>>>>>>>>>>> > >>>>>>>>>>>> I plan to create karaf-4.1.x branch next week for a release > the > >>>>>>>>>>>> following week. > >>>>>>>>>>>> > >>>>>>>>>>>> Thoughts ? > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> Regards > >>>>>>>>>>>> JB > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > Software Architect / Project Manager / Scrum Master > -- Matt Sicker <boa...@gmail.com>
Re: [PROPOSAL] Add convenient and "starter" examples in Karaf Container distribution
Sounds amazing! I've always found the hardest part about getting developers
to use OSGi is the lack of clear, up to date examples. It's probably why
Spring Boot has been so successful, and it's also why I've started working
on a similar project in Log4j.
A related tool that might super useful for Karaf in the future is Atomist <
https://www.atomist.com/> which can be used to provide project
templates/editors to add or configure optional features and such with new
and existing projects.
On 15 January 2017 at 12:15, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Hi guys,
>
> In the preparation for the Karaf 4.1.0 release, I'm working on the final
> touches on the developer guide.
>
> As part of this, I created simple example projects:
> - Service with pure OSGi (registration/reference)
> - Configuration management with ConfigAdmin service
> - Configuration with ManagedService
> - Configuration with ManagedServiceFactory
> - Service with Blueprint (registration/reference)
> - Service with DS/SCR (registration/reference)
> - Create a custom Command
> - Create a custom MBean
> - Create a custom URL NamespaceHandler
> - Logging custom appender
> - Create a custom deployer
> - Create a custom JAAS LoginModule
> - Security realm usage
> - Encryption service usage
> - Create a servlet
> - Create a WAB and use service
> - Use Karaf JNDI
> - Use and manipulate JDBC service
> - Use and manipulate JMS service
> - Use of JPA & JTA
> - Use of CDI
> - Use of CXF for WebServices (very quick and simple, README is referencing
> CXF website/samples)
> - Use of Camel in Karaf (very quick and simple, README is referencing
> Camel website/samples)
> - Profiles
>
> I tried basically to list the most common questions/requests we got from
> users when they start with Karaf.
>
> These samples and new developer guide are already ready, I will create a
> pull request tonight or Tuesday (I'm traveling tomorrow).
>
> I did:
> - a samples module containing those samples, including a README for each
> sample
> - moved the content of demo in samples (demo is removed)
> - updated the developer guide based on README in those samples
> - add new archetypes ("starter") to create the code of the samples too
>
> The idea is to provide quick ways (starters) for end-users to start with
> Karaf, providing practical samples. It's a first start/transition waiting
> for Karaf Boot. However, as Karaf Boot
>
> I plan to add the same things in Decanter (create custom collector,
> appenders, alerters, ...) and Cellar (use of distribution map, DOSGi, ...).
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Matt Sicker <boa...@gmail.com>
Re: Karaf 4.1 and JDK9
There are way too many unready dependencies, agreed. Making JDK 9 a goal for 4.2 sounds reasonable. On 4 January 2017 at 07:10, Guillaume Nodet <gno...@apache.org> wrote: > Agreed. > Especially, things are still moving in the JDK land and we may expect > additional breakages, so I would not hold Karaf 4.1 for that. > We can't really claim to support Java 9 support before it's even released > ;-) > > 2017-01-04 13:33 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > > > Hi Achim, > > > > For Karaf 4.1, the purpose is not to fully support JDK9 but to start the > > required improvements. > > > > I plan to release Karaf 4.1.0 by the end of this week as it is, with full > > JDK8 support, and JDK9 support preview (not fully tested). > > > > I would consider the full JDK9 support for Karaf 4.2. I'm pretty sure > that > > other projects (Pax Web as you said, but also Aries Proxy) are not fully > > ready, so, it's not really possible to announce a full JDK9 support. > > > > My plan is to create the karaf-4.1.x branch tomorrow, and then, prepare > > the full JDK9 support on master. > > > > Thoughts ? > > > > Regards > > JB > > > > > > On 01/04/2017 01:25 PM, Achim Nierbeck wrote: > > > >> Hi, > >> > >> got a question regarding Karaf 4.1 and JDK9 compatibility. > >> I've seen we had numerous issues regarding JDK9 for Karaf 4.1. > >> Is it our goal to have Karaf 4.1 runnable with JDK9? > >> If so, the ops4j community just came across some major drawbacks. > >> > >> First it just seemed like we just need to bump the version for ASM in > >> Pax-Web [1][2][3] and everything is smooth, but it's not. > >> > >> It turned out we also need another upgrade for ASM 6 in Aries [4], but > >> again this isn't the only thing. > >> > >> It turns out, Jetty 9.3.x isn't compatible with JDK9, so an upgrade to > >> Jetty 9.4 might be needed. > >> Again this turns out to be more complex then first anticipated. > >> As it turns out, neither Jetty 9.3 nor 9.4 are ready to go for ASM 6, > but > >> still rely on version 5 [5]. > >> Not to speak of the need to bump Pax-Web to version 6.1 for using Jetty > >> 9.4. > >> > >> So how do we handle JDK9 for Karaf 4.1? > >> Is it our main goal to support JDK9 from head start? > >> If the answer is yes, we need to do a lot more then what we've done so > >> far. > >> Just to mention one thing that needs to be done instantly, have a build > >> which uses JDK9 to run our tests. That should already cover most of the > >> issues we came across. > >> Also I would like to hold back the release for 4.1 for a while to make > >> sure > >> we have all project we or our users depend on straightened for JDK9. > >> > >> > >> regards, Achim > >> > >> [1] - https://issues.apache.org/jira/browse/KARAF-4912 > >> [2] - https://ops4j1.jira.com/browse/PAXWEB-1047 > >> [3] - https://issues.apache.org/jira/browse/KARAF-4913 > >> [4] - https://issues.apache.org/jira/browse/ARIES-1646 > >> [5] - > >> https://ops4j1.jira.com/browse/PAXWEB-1047?focusedCommentId= > >> 39702=com.atlassian.jira.plugin.system.issuetabpanels%3 > >> Acomment-tabpanel#comment-39702 > >> > >> > >> > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > > -- > > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > -- Matt Sicker <boa...@gmail.com>
Re: [HEADS UP] Next releases
Sweet! Looking forward to the Mesos setup, sounds interesting. On 10 October 2016 at 00:43, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi all, > > Just a rough schedule for the next release: > > - in the coming two weeks (probably end of this week or next one): > -- Cellar 4.0.3 (including support of bundles and features update, > hazelcast upgrade and other bug fixes) > -- Decanter 1.3.0 (elasticsearch upgrade, fix on kafka appender, new > features) > - in two weeks: > -- Container 4.0.8: the ARM/Solaris issue should be fixed now (that was an > important regression in 4.0.6 & 4.0.7). Other fixes and upgrades are coming > too. > > Blog: > - Karaf & Cellar with Mesos and Marathon: last week, I prepared a blog > post showing how to use Karaf and Cellar on Mesos and Marathon. I will push > on my github the dockerfile and marathon json. I will propose the docker > image as official (based on alpine/jre). > I planned to do a talk based on that during ApacheCon but my talk proposal > has been declined. > I plan to publish this post during the week end. > > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <boa...@gmail.com>
Re: Log4j 1.x will not work in Java 9, need to migrate to 2.x
I mean old config files written for log4j should work in log4j2. Log4j 2 already has a properties file syntax, but it's different from the old 1.x format. On 25 September 2016 at 12:31, Guillaume Nodet <gno...@apache.org> wrote: > Fwiw, pax-logging-log4j2 is the backend for Karaf 4.1. > And we already support log4j configuration style > (though prepended with log4j2 instead of log4j). > > 2016-09-25 17:32 GMT+02:00 Matt Sicker <boa...@gmail.com>: > > > As a quick followup, we're working on supporting log4j 1.x configuration > > files in 2.x lately, so eventually we should be able to switch the > default > > backend (or at least the default used in Karaf 4.1). > > > > On 11 August 2016 at 09:29, Achim Nierbeck <bcanh...@googlemail.com> > > wrote: > > > > > Hi Matt, > > > > > > we're not directly using Log4j 1.x it's used by Pax-Logging which > itself > > > brings along a lot of needed stuff. > > > So to fullfill what you are requesting we would need to replace > > Pax-Logging > > > by Log4j2 and therefore require a lot > > > of changes to stuff that has been working with Pax-Logging as > Pax-Logging > > > provides all kinds of APIs with only one implementation which is log4j > 1 > > > right now. But you can also use log4j 2 as alternate backend. > > > > > > regards, Achim > > > > > > > > > 2016-08-10 15:51 GMT+02:00 Matt Sicker <boa...@gmail.com>: > > > > > > > Hello guys, I noticed in Karaf 4.0.5, Log4j 1.x is still being used > as > > > the > > > > logging framework. This is no longer supported in Java 9 due to being > > end > > > > of life and a bug involving the JDK version number string having > > changed > > > > format significantly. > > > > > > > > Are there plans to make Log4j 2.x the default in Karaf 4.1 or 5.0? If > > > not, > > > > I can help you guys migrate. We're keeping track of migration efforts > > in > > > > this issue: https://issues.apache.org/jira/browse/LOG4J2-1473 > > > > > > > > -- > > > > Matt Sicker <boa...@gmail.com> > > > > > > > > > > > > > > > > -- > > > > > > Apache Member > > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > > > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > Committer > > & > > > Project Lead > > > blog <http://notizblog.nierbeck.de/> > > > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > > > > > Software Architect / Project Manager / Scrum Master > > > > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > > > > -- > > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > -- Matt Sicker <boa...@gmail.com>
Log4j 1.x will not work in Java 9, need to migrate to 2.x
Hello guys, I noticed in Karaf 4.0.5, Log4j 1.x is still being used as the logging framework. This is no longer supported in Java 9 due to being end of life and a bug involving the JDK version number string having changed format significantly. Are there plans to make Log4j 2.x the default in Karaf 4.1 or 5.0? If not, I can help you guys migrate. We're keeping track of migration efforts in this issue: https://issues.apache.org/jira/browse/LOG4J2-1473 -- Matt Sicker <boa...@gmail.com>
Re: [UPDATE] Releases schedule
Welcome back! On 27 July 2016 at 11:25, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi guys, > > Now that I'm back from vacation, I will work and prepare Decanter 1.1.1 > release. The plan is to submit to vote for the end of this week. > > We are working on couple of new features with Christian. > > For Container releases, we will tackle that next week. > > Regards > JB > > On 07/03/2016 08:52 PM, Jean-Baptiste Onofré wrote: > >> Hi all, >> >> just a quick update about the releases schedule. >> >> End of this week and during the week end, I should be able to submit >> Cellar 4.0.1 and Decanter 1.1.1 to vote. >> >> Karaf Container 4.0.6 and 3.0.8 are planned for end of the following week. >> >> On the other hand, I worked on couple of PoC around Docker and >> karaf-boot. I will give you more details soon. >> >> Regards >> JB >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <boa...@gmail.com>
Re: [PROPOSAL] Karaf Boot roadmap
I'd imagine the equivalent Karaf Boot CLI tools would be maven plugin goals.
On 12 May 2016 at 16:39, Serge Huber <shu...@jahia.com> wrote:
> This looks really great. I just had a couple of suggestion :
>
> - Could it be possible to use the samples as “project archetypes” ? So
> that users would have even less to write ? I’m thinking especially at
> developing a REST service alongside with a set of integration tests that
> would start the server and use a REST client to test the REST service.
> - Should we think about a CLI interface similar to what exists in the
> front-end development world ? I’m thinking of something like the Angular 2
> CLI that was just announced ? https://cli.angular.io
> I’m not sure how this would integrate with Maven but I was mostly thinking
> about total beginners to both Karaf and Maven (mostly those coming maybe
> from Gradle, Ant or Bndtools).
>
> WDYT ?
>
> cheers,
> Serge… officially on vacation :)
>
> > On 11 mai 2016, at 10:04, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> >
> > Hi all,
> >
> > Karaf Boot code is now on the Apache Git:
> >
> > https://git.apache.org/karaf-boot.git/
> >
> > with the github mirror:
> >
> > https://github.com/apache/karaf-boot
> >
> > I created the component in Jira.
> >
> > I will update the website with karaf-boot description.
> >
> > I propose the following roadmap for karaf-boot, heading to the first 1.0
> release:
> >
> > 1. Bootstrapping
> >
> > As a reminder, karaf-boot has two goals:
> > - simplify the way to create module and application for developers
> > - simplify the bootstrapping as a "standalone" application (leveraging
> the container feature)
> >
> > Currently, we mostly address the first point. Our starters provide
> annotations allowing to easily create application. The
> karaf-boot-maven-plugin "calls" the annotation processor in the starters,
> and other plugins behind the hood to easily generate artifacts.
> >
> > Now, we have to address the second point: bootstrapping. I started a PoC
> on that.
> > I created new starters for bootstrapping:
> > - karaf-boot-starter-feature creates a feature using the dependencies
> and project artifact
> > - karaf-boot-starter-distribution creates both zip and tar.gz Karaf
> custom distribution embedding the current project artifact and dependencies
> > - karaf-boot-starter-distribution-rjar is similar to distribution, but
> it's a runnable jar (using a custom Main)
> > - karaf-boot-starter-docker creates a docker image embedding the custom
> distribution
> >
> > Now, the karaf-boot-maven-plugin is checking the dependencies to find
> one of these bootstrap starter, and react accordingly.
> > However, most of the logic is in the plugin, leveraging
> karaf-maven-plugin (assembly and archive goals for instance).
> > If this approach works (and is easy), I don't think it's the most
> elegant way.
> > I think we should create a @bootstrap annotation on a Runnable class in
> the bootstrap starters. The annotated class is responsible of the bootstrap
> artifact creation. An abstract bootstrap starter provide an annotation
> processor that look for @bootstrap annotation and run the class in a
> thread. The karaf-boot-maven-plugin just delegates the bootstrapping to the
> starter.
> >
> > WDYT ?
> >
> > 2. New starters
> > ---
> > We have to extend the coverage of the starter to address more use cases.
> I'm thinking about starters for test (both utest and itest leveraging
> pax-exam), for jaas, for management/MBean, for eventadmin, for decanter,
> for camel, etc.
> >
> > 3. New samples
> > --
> > Related to 2, each new starter should have a corresponding sample. The
> samples are really important as it's where the users start.
> >
> > We should also provide kind of full application use case, multi-module.
> I started this showing how to use different starters in different modules
> (like a Logo construction set).
> >
> > 4. Documentation and Karaf Dev Guide
> >
> > The "new" Karaf Dev guide will be based mostly on karaf-boot. A second
> section ("advanced") can still address non karaf-boot cases.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
>
--
Matt Sicker <boa...@gmail.com>
Re: [PROPOSAL] Create karaf-boot project
One step closer to release! ;) On 19 April 2016 at 23:05, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi all, > > FYI, infra created the karaf-boot git repo. I'm cleaning a bit my github > and I will do the donation asap. For the current contributors, don't > hesitate to push your changes before the donation. > > Thanks, > Regards > JB > > > On 03/21/2016 12:52 PM, Jean-Baptiste Onofré wrote: > >> Hi team, >> >> Regarding the discussion we had couple of months ago, karaf-boot PoC >> started on my github. >> >> In order to give more visibility, and allow anyone to work on it, I >> propose to donate this as a Karaf sub-project or a Karaf Container module. >> >> Right now, I will push some enhancements/new features that I did last >> week, and I will update the README (markdown) to describe the purposes >> and objectives of karaf-boot. >> >> For the donation, I see two ways: >> >> - a new subproject as Decanter, or Cellar, meaning karaf-boot will have >> its own git repo. >> - a module in Karaf Container (so a folder named boot or karaf-boot in >> the Karaf container git repo). >> >> Thoughts ? >> >> Thanks, >> Regards >> JB >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <boa...@gmail.com>
Re: Problems due to the endorsed java.lang.Exception
What's wrong with the class context from
ReflectionUtil.getCurrentStackTrace() that requires a custom implementation
of Exception?
On 18 March 2016 at 12:11, Guillaume Nodet <gno...@apache.org> wrote:
> The getClassContext() method is used in pax-logging to render the exception
> in a nicer way.
> I don't have any problem moving the qualifier to protected or whatever, but
> we'd need to change the code in pax-logging
>
>
>
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
>
>
>
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
>
> It should not be a big deal, but the current code expect the method to be
> public unfortunately.
>
> Guillaume
>
>
> 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>
> > Hi Cristiano,
> >
> > I think you are right, it's probably something existing for a while. I'm
> > just surprised that you encountered now.
> >
> > Let me check your detailed use case that you sent previously.
> >
> > Regards
> > JB
> >
> >
> > On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
> >
> >> Hello all,
> >>
> >> it is some days I was having troubles using CXF services on ServiceMix
> >> (and
> >> it is some days I spam on the mailing list of ServiceMix, Camel and CXF
> >> :-D
> >> ) and I've finally come to the source of my issues which are due to the
> >> "endorsed" java.lang.Exception which is used by Karaf:
> >>
> >>
> >>
> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
> >>
> >> My problem is due to the fact that this class has a public property,
> >> public Class[] getClassContext() {
> >> return classContext;
> >> }
> >> which is seen by JaxB at runtime inside Karaf which cause it to marshall
> >> the Exception in SOAP services with a wrong XML, an XML which include
> >> tags.
> >>
> >> The class in Karaf has not changed since committed by Guillaume Nodet in
> >> 2010, so this issue with CXF has probably always been there.
> >>
> >> In my opinion, this getter should be private or protected as I guess it
> is
> >> only used on the nested class method's getThrowableContext (it is a
> >> replacement for the JRE's class, I don't think there are external
> project
> >> using this modification of the Exception class).
> >>
> >>
> >> To confirm my thesis, I've hacked the
> org.apache.karaf.exception-2.4.0.jar
> >> inside the lib/endorsed folder with a class compiled by myself where
> I've
> >> changed the method to
> >> private Class[] getClassContext() {
> >> return classContext;
> >> }
> >> and with this hack, Karaf has continued to work (and my CXF service now
> >> works properly).
> >>
> >> Do you think there are potential side effects in this fix?
> >> Do you need me to open an issue on Jira to handle the problem?
> >> If it is confirmed that the fix of making this method private, do you
> >> think
> >> it could be included soon on the next Karaf Release?
> >>
> >> Thank you very much to all,
> >> Cristiano
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
>
> Guillaume Nodet
>
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
--
Matt Sicker <boa...@gmail.com>
Re: Known Karaf users
ta to > > thousands of > > >>>>>>>> users across the government. Karaf has undergone rigorous > > security > > >>>>>>>> scans > > >>>>>>>> such as Fortify, Retna and ACAS all while meeting the > performance > > >>>>>>>> requirements expected of a critical system." > > >>>>>>>> > > >>>>>>>> David > > >>>>>>>> > > >>>>>>>> On Sat, Feb 13, 2016 at 9:04 AM, Serge Huber <shu...@jahia.com> > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> I like the idea too. Let me try for Jahia : > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> "Jahia uses Apache Karaf in two of its products : Marketing > > Factory > > >>>>>>>>> and > > >>>>>>>>> Digital Experience Manager (DXM). Marketing Factory actually > uses > > >>>>>>>>> Apache > > >>>>>>>>> Unomi that uses Apache Karaf as its runtime, and DXM uses > Apache > > >>>>>>>>> Karaf as > > >>>>>>>>> an embedded OSGi runtime inside its JavaEE Web Application. > Both > > >>>>>>>>> systems > > >>>>>>>>> are commercially available applications that are deployed at > > large > > >>>>>>>>> customers throughout the world and rely upon Apache Karaf to > > deliver > > >>>>>>>>> high-performance, scalable and highly available solutions”. > > >>>>>>>>> > > >>>>>>>>> How does this read ? Is it acceptable ? > > >>>>>>>>> > > >>>>>>>>> cheers, > > >>>>>>>>>Serge… > > >>>>>>>>> > > >>>>>>>>> On 13 févr. 2016, at 08:48, Christian Schneider < > > >>>>>>>>> ch...@die-schneider.net > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> A list of users of karaf would be nice but I think something > > even > > >>>>>>>>>> better > > >>>>>>>>>> > > >>>>>>>>> would be to have a short success story for each user. > > >>>>>>>>> > > >>>>>>>>> The story could show an overview of the architecture and > > technologies > > >>>>>>>>>> > > >>>>>>>>> they use as well as their business case. > > >>>>>>>>> > > >>>>>>>>> We could then showcase one user in a round robin fashion on the > > karaf > > >>>>>>>>>> > > >>>>>>>>> entry page with a short teaser. A click would go to the full > > story > > >>>>>>>>> and > > >>>>>>>>> > > >>>>>>>>> also give links to all the other stories. > > >>>>>>>>>> > > >>>>>>>>>> Of course we have to agree on some rules how such a story > should > > >>>>>>>>>> look > > >>>>>>>>>> > > >>>>>>>>> like. So for example maybe we maybe would not want too blatant > > >>>>>>>>> advertising > > >>>>>>>>> for the user. > > >>>>>>>>> > > >>>>>>>>> We might also want to set a limit for the size of the story. > > >>>>>>>>>> > > >>>>>>>>>> I could describe what Talend does with Karaf and also ask some > > >>>>>>>>>> users I > > >>>>>>>>>> > > >>>>>>>>> know for their stories. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> What do you think? > > >>>>>>>>>> > > >>>>>>>>>> Christian > > >>>>>>>>>> > > >>>>>>>>>> On 10.02.2016 19:06, Serge Huber wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> Hello, > > >>>>>>>>>>> > > >>>>>>>>>>> I just got a question from management about the list of known > > >>>>>>>>>>> users of > > >>>>>>>>>>> > > >>>>>>>>>> Karaf. > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> I couldn't provide a nice list and his got me thinking about > > putting > > >>>>>>>>>> some users on the home page and then link to a more complete > > list. > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> I can already offer to list my company if that helps :) > > >>>>>>>>>>> > > >>>>>>>>>>> Cheers, > > >>>>>>>>>>>Serge > > >>>>>>>>>>> > > >>>>>>>>>>> Serge Huber > > >>>>>>>>>>> CTO & Co-Founder > > >>>>>>>>>>> > > >>>>>>>>>>> T +41 22 361 3424 > > >>>>>>>>>>> 9 route des Jeunes | 1227 Acacias | Switzerland > > >>>>>>>>>>> jahia.com > > >>>>>>>>>>> SKYPE | LINKEDIN | TWITTER | VCARD > > >>>>>>>>>>> > > >>>>>>>>>>> JOIN OUR COMMUNITY to evaluate, get trained and to discover > why > > >>>>>>>>>>> Jahia > > >>>>>>>>>>> is a leading User Experience Platform (UXP) for Digital > > >>>>>>>>>>> Transformation. > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> -- > > >>>>>>>>>> Christian Schneider > > >>>>>>>>>> http://www.liquid-reality.de > > >>>>>>>>>> > > >>>>>>>>>> Open Source Architect > > >>>>>>>>>> http://www.talend.com > > >>>>>>>>>> > > >>>>>>>>> -- > > >>>>>>> Jean-Baptiste Onofré > > >>>>>>> jbono...@apache.org > > >>>>>>> http://blog.nanthrax.net > > >>>>>>> Talend - http://www.talend.com > > >>>>>>> > > >>>>>> > > >>>>> -- > > >>>>> Jean-Baptiste Onofré > > >>>>> jbono...@apache.org > > >>>>> http://blog.nanthrax.net > > >>>>> Talend - http://www.talend.com > > >>>>> > > >>>> > > >>>> > > >>> -- > > >>> Jean-Baptiste Onofré > > >>> jbono...@apache.org > > >>> http://blog.nanthrax.net > > >>> Talend - http://www.talend.com > > >>> > > > > > > -- Matt Sicker <boa...@gmail.com>
Re: Known Karaf users
That powered-by logo needs an update for the new feather. ;) We use it at my company, I just need to get it OK'd by someone higher up before I go mentioning who. On 10 February 2016 at 13:04, Achim Nierbeck <bcanh...@googlemail.com> wrote: > Hi Serge, > > I know of at least two "companies" though I need to check first if we can > list them ;) > Though as Karaf is also the basis for JBoss and Talend based Products they > most likely have a lot more customers, and I don't know if we can count > those in. AFAIK our biggest "User" is most likely the OpenDayLight Project. > Besides that we have a couple other OpenSource Projects based on Karaf. > > I still dream of all those Projects that actually use Karaf to actually > have the Powered-By-Logo [1] on their site. > > regards, Achim > > [1] - http://www.apache.org/foundation/press/kit/poweredBy/pb-karaf.jpg > > > 2016-02-10 19:06 GMT+01:00 Serge Huber <shu...@jahia.com>: > > > Hello, > > > > I just got a question from management about the list of known users of > > Karaf. > > I couldn't provide a nice list and his got me thinking about putting some > > users on the home page and then link to a more complete list. > > > > I can already offer to list my company if that helps :) > > > > Cheers, > > Serge > > > > Serge Huber > > CTO & Co-Founder > > > > T +41 22 361 3424 > > 9 route des Jeunes | 1227 Acacias | Switzerland > > jahia.com > > SKYPE | LINKEDIN | TWITTER | VCARD > > > > > > > JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia > is > > a leading User Experience Platform (UXP) for Digital Transformation. > > > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > Software Architect / Project Manager / Scrum Master > -- Matt Sicker <boa...@gmail.com>
Re: [ANN] New Karaf website online
I try to explain it to new co-workers as a generic application hosting platform with the ability to update your deployment while it's running in small pieces. On 4 February 2016 at 17:35, Tom Barber <tom.bar...@meteorite.bi> wrote: > Haha, very true! > > I suspect that word isn't required, and instead of a dual polymorphic > container, what the author tried to say was "Karaf provides polymorphic > container and application bootstrapping paradigms to the Enterprise." > > Of course, I still don't know what a single polymorphic container is > either, but I clearly use one! ;) > > On Thu, Feb 4, 2016 at 10:15 PM, Raman Gupta <rocketra...@gmail.com> > wrote: > > > Congrats! > > > > Now, if someone could only explain to me what a "dual polymorphic > > container" is! :-) > > > > Regards, > > Raman > > > > > > On 02/04/2016 10:31 AM, Jean-Baptiste Onofré wrote: > > > Hi all, > > > > > > as you may have seen that the new Karaf website is now online. > > > > > > Don't hesitate to create Jira (with website component) if you see some > > > broken links and rendering issue. > > > > > > Thanks ! > > > Regards > > > JB > > > -- Matt Sicker <boa...@gmail.com>
Re: [ANN] New Karaf website online
It looks great! On 4 February 2016 at 09:31, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi all, > > as you may have seen that the new Karaf website is now online. > > Don't hesitate to create Jira (with website component) if you see some > broken links and rendering issue. > > Thanks ! > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <boa...@gmail.com>
Re: [VOTE] Promote the new website look'n feel
I get the same issue on iPhone in Safari, Chrome, and Firefox all. The main page looks fine, but the other pages with the side nav are screwed up. On 13 January 2016 at 15:04, Milen Dyankov <milendyan...@gmail.com> wrote: > I only checked it my Galaxy Note so it would be good if others can report > about other devices. > > Both the old and the new site work. In that sense the that all the > information is displayed. The difference is the old one allows to zoom in > and out and scroll. The new one seem to have fixed size. It displays the > menu on the left and small part of the actual content on the right and > there seem to be no way to scroll or zoom. > > Best, > Milen > 13 sty 2016 21:53 "Jean-Baptiste Onofré" <j...@nanthrax.net> napisał(a): > > > By mobile, you mean on a phone right ? > > > > Let me try it and fix that. > > > > By the way, does the current website work fine on mobile ? > > > > Thanks > > Regards > > JB > > > > On 01/13/2016 09:16 PM, Milen Dyankov wrote: > > > >> Hi, > >> > >> I'm not sure if this qualifies for -1 but it seams everything except > home > >> page is not mobile device friendly. I really like the home page but the > >> rest is kind of cut in half if you browse it with mobile device. The > only > >> fully visible part is the menu. IMHO this needs to be fixed. May be it's > >> just me but as someone who is doing fair amount of travelling I tend to > >> visit web sites on my phone more often then on my laptop. > >> > >> Best, > >> Milen > >> 13 sty 2016 20:57 "Giuseppe Gerla" <giuseppe.ge...@gmail.com> > napisał(a): > >> > >> +1 (non binding) > >>> > >>> BR > >>> Giuseppe > >>> Il 13/gen/2016 20:56, "Morgan Hautman" <morgan.haut...@gmail.com> ha > >>> scritto: > >>> > >>> +1 non-binding > >>>> > >>>> On 01/13/2016 06:58 PM, Jean-Baptiste Onofré wrote: > >>>> > >>>> Hi all, > >>>>> > >>>>> As already discussed on the mailing list, I would like to promote the > >>>>> > >>>> new > >>> > >>>> website. > >>>>> > >>>>> As reminder, the new website proposal is there: > >>>>> > >>>>> http://maven.nanthrax.net/goodies/karaf/site/ > >>>>> > >>>>> Please vote to approve the new website: > >>>>> > >>>>> [ ] +1 Approve the new website promotion > >>>>> [ ] -1 Don't approve the new website (please provide specific > comments) > >>>>> > >>>>> This vote will be open for at least 72 hours. > >>>>> > >>>>> Thanks, > >>>>> Regards > >>>>> JB > >>>>> > >>>>> > >>>> > >>>> > >>> > >> > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > -- Matt Sicker <boa...@gmail.com>
Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup
Whatever happened to maven archetypes? This could work for this situation rather well. On 17 December 2015 at 04:46, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi, > > Yes, I agree about the PoC approach, but I think PoC can become a project > or as least some module can use the "easy" karaf-boot way. > > My only concern about copy/paste is that the project bootstrapping is > long: personally, using archetype or copy paste from a sample pom is fine > but long, actually longer than just describing couple of dependencies and > plugin. But it could make sense. > > For multi-module, I agree, but I don't see any show stopper: each module > can use karaf-boot and work together (see the samples of service provider > and consumer, karaf-boot should really encourage to leverage the service > approach). > > Regards > JB > > > On 12/17/2015 11:20 AM, Christian Schneider wrote: > >> For me the main purpose of karaf boot in unchanged form is to allow >> people to easily create small proof of concepts. >> In this stage it normally is no issue that you do not use the company >> parent pom. You can start easily with karaf boot and bring your poc to a >> level where management decides to use karaf. >> >> Then at some point you need to transition to a regular project. So you >> can copy the karaf boot parent, edit it to include your company parent >> and other changes you might need and use it for your project(s). >> This transition phase will also happen when you use the blackbox >> karaf-boot plugin but then it will be a lot harder to adapt it to your >> needs. >> >> Another thing we need to look at is the transition from a single module >> project to a multi module project. I think it is really great to let >> people start with a single module/project but to leverage OSGi people >> will want to build multi module projects at some point. This will either >> happen during the transition from poc to a regular project or even >> earlier. So I think we also need to make sure that multi module projects >> can be built easily. For this case I think >> it is natural that the set of modules that form you application will >> have their own parent pom (that of course might depend on a company >> parent). >> >> Christian >> >> On 17.12.2015 10:51, Jean-Baptiste Onofré wrote: >> >>> Hi Serge, >>> >>> It's what I meant by "intrusive": sometime we have to use a company >>> wide parent pom, no choice. So we can't force the usage of a >>> karaf-boot parent IMHO. >>> >>> That's why, after the earlier discussions on the mailing list, I did: >>> - a set of karaf-boot-starter, providing dependencies depending what >>> you need (rest, jpa, shell, etc). They act as BoM and users just have >>> to define in the dependencies set (see the karaf-boot-samples). >>> - as a BoM doesn't bring plugin (only dependencies), and to simplify >>> the build/bootstrapping at maximum, I created the >>> karaf-boot-maven-plugin. This plugin is responsible of scanning the >>> starters, scanning the sources, and depending of those, build and >>> possibly bootstrap the project by wrapping other plugins. >>> >>> So, we are really in a kind of black box, where processes are hidden: >>> and it's one of karaf-boot main purpose. However, I got Christian's >>> point: he's more in the way to not hide as he expects later people >>> won't use karaf-boot to a more advanced/expert way. So, at that time, >>> people can "duplicate" what we have in a parent-pom. >>> >>> That's why maybe we can provide both: >>> - I honestly think that "hide way" will match in 80% of the cases, >>> where people wants to focus on business code and don't care about the >>> plumbing. It's the feedback that I got discussing with different >>> people like Serge, and others (from different background, business, >>> company). >>> - However, at least by documentation or parent pom, we have to provide >>> a way to karaf-boot users to use a very advanced/expert way. I like >>> Christian's idea to use an extender, it makes sense in some use case. >>> The profile or feature generation by annotation or starter scanning is >>> also interesting IMHO. >>> >>> My $0.02 ;) >>> >>> Regards >>> JB >>> >>> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <boa...@gmail.com>
Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup
Well, anything to help migrating from straight Karaf to karaf-boot would be great. On 17 December 2015 at 14:24, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Matt, > > we already have maven archetype, but generally speaking I'm not a big fan. > > Think about karaf boot with gradle, archetype won't help there. > > Personally, I prefer to start with a blank pom more than an archetype ;) > > But definitely, we will provide archetypes. > > Regards > JB > > > On 12/17/2015 05:45 PM, Matt Sicker wrote: > >> Whatever happened to maven archetypes? This could work for this situation >> rather well. >> >> On 17 December 2015 at 04:46, Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> >> Hi, >>> >>> Yes, I agree about the PoC approach, but I think PoC can become a project >>> or as least some module can use the "easy" karaf-boot way. >>> >>> My only concern about copy/paste is that the project bootstrapping is >>> long: personally, using archetype or copy paste from a sample pom is fine >>> but long, actually longer than just describing couple of dependencies and >>> plugin. But it could make sense. >>> >>> For multi-module, I agree, but I don't see any show stopper: each module >>> can use karaf-boot and work together (see the samples of service provider >>> and consumer, karaf-boot should really encourage to leverage the service >>> approach). >>> >>> Regards >>> JB >>> >>> >>> On 12/17/2015 11:20 AM, Christian Schneider wrote: >>> >>> For me the main purpose of karaf boot in unchanged form is to allow >>>> people to easily create small proof of concepts. >>>> In this stage it normally is no issue that you do not use the company >>>> parent pom. You can start easily with karaf boot and bring your poc to a >>>> level where management decides to use karaf. >>>> >>>> Then at some point you need to transition to a regular project. So you >>>> can copy the karaf boot parent, edit it to include your company parent >>>> and other changes you might need and use it for your project(s). >>>> This transition phase will also happen when you use the blackbox >>>> karaf-boot plugin but then it will be a lot harder to adapt it to your >>>> needs. >>>> >>>> Another thing we need to look at is the transition from a single module >>>> project to a multi module project. I think it is really great to let >>>> people start with a single module/project but to leverage OSGi people >>>> will want to build multi module projects at some point. This will either >>>> happen during the transition from poc to a regular project or even >>>> earlier. So I think we also need to make sure that multi module projects >>>> can be built easily. For this case I think >>>> it is natural that the set of modules that form you application will >>>> have their own parent pom (that of course might depend on a company >>>> parent). >>>> >>>> Christian >>>> >>>> On 17.12.2015 10:51, Jean-Baptiste Onofré wrote: >>>> >>>> Hi Serge, >>>>> >>>>> It's what I meant by "intrusive": sometime we have to use a company >>>>> wide parent pom, no choice. So we can't force the usage of a >>>>> karaf-boot parent IMHO. >>>>> >>>>> That's why, after the earlier discussions on the mailing list, I did: >>>>> - a set of karaf-boot-starter, providing dependencies depending what >>>>> you need (rest, jpa, shell, etc). They act as BoM and users just have >>>>> to define in the dependencies set (see the karaf-boot-samples). >>>>> - as a BoM doesn't bring plugin (only dependencies), and to simplify >>>>> the build/bootstrapping at maximum, I created the >>>>> karaf-boot-maven-plugin. This plugin is responsible of scanning the >>>>> starters, scanning the sources, and depending of those, build and >>>>> possibly bootstrap the project by wrapping other plugins. >>>>> >>>>> So, we are really in a kind of black box, where processes are hidden: >>>>> and it's one of karaf-boot main purpose. However, I got Christian's >>>>> point: he's more in the way to not hide as he expects later people >>>>> won't use karaf-boot to a more advanced/expert way. So, at tha
Re: Fwd: [VOTE] Release Apache Karaf 3.0.2
Then it takes at least a couple hours or more to get fully uploaded to Maven Central, and up to 24 hours to be synced across all the Apache download mirrors. On 13 October 2014 12:17, Jamie G. jamie.goody...@gmail.com wrote: The vote's 72 hour period completes in 2.5 hours. If the vote passes then I'll promote the artifacts to nexus, and complete the website updates. Email announcements will follow :) Cheers, J On Mon, Oct 13, 2014 at 2:37 PM, bojjus boj...@gmail.com wrote: Is the official release out? How long would it be when this be available on the maven repos? -- View this message in context: http://karaf.922171.n3.nabble.com/Fwd-VOTE-Release-Apache-Karaf-3-0-2-tp4035831p4035875.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Matt Sicker boa...@gmail.com
Re: [PROPOSAL] Karaf release cycle
Personally, without a really easy way to upgrade Karaf in place, frequent releases can become a bit of a pain. That, or better documentation on how to use the karaf-maven-plugin would help a lot in that regard. On 8 October 2014 00:58, Sobkowiak, Krzysztof krzys.sobkow...@gmail.com wrote: +1 good idea Regards Krzysztof On 08.10.2014 07:52, Jean-Baptiste Onofré wrote: Hi all, Users complained about the variable and long delays between Karaf releases. It's a fair comment and it's something that we have to improve. I propose the following new policy about the releases cycle: - for active branches (3.0.x and 2.4.x), I propose a release every 6 weeks, with maximum extend to 8 weeks. - for eol and maintenance branches (2.2.x and 2.3.x), it's on demand, no strong cycle there. WDYT ? If everybody agrees, I will update the releases schedule page on the website. Regards JB -- Krzysztof Sobkowiak JEE OSS Architect | Technical Architect @ Capgemini | Committer @ ASF Capgemini http://www.pl.capgemini.com/ | Software Solutions Center http://www.pl.capgemini-sdm.com/ | Wroclaw e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com | Twitter: @KSobkowiak Calendar: http://goo.gl/yvsebC -- Matt Sicker boa...@gmail.com
Re: Manifest position
I've even had this error in the past when the manifest WAS the first file in the zip. The jar command always makes it first (or generates one if none is there). Never figured out why it happened because it was somewhat random, and reinstalling things tended to fix it. On 16 September 2014 04:46, Jean-Baptiste Onofré j...@nanthrax.net wrote: It's what I said to Achim on IRC: it's already fixed for 3.0.2. Regards JB On 09/16/2014 11:12 AM, Harald Wellmann wrote: I've just downloaded the latest 3.0.2 SNAPSHOT and I can't reproduce the issue, so it seems to be fixed already, as Achim suggested. Regards, Harald 2014-09-16 11:03 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: FYI: https://issues.apache.org/jira/browse/KARAF-3232 Regards JB On 09/16/2014 11:01 AM, Jean-Baptiste Onofré wrote: Actually, the problem is in Karaf (I thought you use bundle:install). It works fine using bundle:install directly: karaf@root() bundle:install mvn:org.eclipse.jdt.core.compiler/ecj/4.4 Bundle ID: 78 karaf@root() bundle:start 78 karaf@root() I'm creating the corresponding Jira and fix that for 3.0.2 (planned on Friday). Regards JB On 09/16/2014 10:55 AM, Harald Wellmann wrote: It's a features file containing a feature with the following line: bundlemvn:org.eclipse.jdt.core.compiler/ecj/4.4/bundle I got the exception when installing the feature from the Karaf shell via feature:install. BTW, what do you mean by partially released - only the good parts? ;-) Regards, Harald 2014-09-16 10:46 GMT+02:00 Achim Nierbeck bcanh...@googlemail.com: one more question, is it in a features file or through the shell that you get this issue? Cause if it's the features file it could actually be an issue of Karaf itself :D Which should already be fixed for 3.0.2 and 2.3.8 and 4.0.0 of Karaf which are only partially released ;) regards, Achim 2014-09-16 10:43 GMT+02:00 Harald Wellmann hwellmann...@gmail.com: OK, I'll try the wrap for now. If there's really an issue in Pax URL, we should fix it there, and I'm happy to do so, if you can point out the API that Karaf is using here. Thanks, Harald 2014-09-16 10:39 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: Good idea Achim ! Anyway, it's something that we have to address at Pax URL. Let me look for the Jira (else I will create one). Regards JB On 09/16/2014 10:37 AM, Achim Nierbeck wrote: There is a simple workaround available for that. wrap the url :) wrap:mvn:org.eclipse.jdt.core.compiler/ecj/4.4 that's what I did for Pax Web ;) regards, Achim 2014-09-16 10:32 GMT+02:00 Harald Wellmann hwellmann...@gmail.com : Karaf 3.0.1 just gave me the following exception when I tried to install the ECJ bundle: Manifest not present in the first entry of the zip mvn:org.eclipse.jdt.core.compiler/ecj/4.4 I believe it's folklore that the manifest has to be the first entry in a JAR, but in fact, the spec [1] doesn't say so. So why doesn't Karaf simply continue scanning the JAR entries until the manifest is found? [1] http://docs.oracle.com/javase/8/docs/technotes/guides/jar/ jar.html Best regards, Harald -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Apache Member Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead blog http://notizblog.nierbeck.de/ Software Architect / Project Manager / Scrum Master -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: Issue with feature Install
Are you updating the bundles inside the kar and deploying that? Or are you updating bundles that came in a kar? Could you clarify? On 10 September 2014 02:40, SapnaB sapnabhargava...@gmail.com wrote: Hi, I'm using feature install in Karaf 2.3.6, where I deploy specific versions of dependent jars and bundles. Problem arises when I uninstall and then install the same version of a bundle individually(after feature install), mostly due to some bug fix. What I observe is that many times the changes are not reflected in Karaf. Only when I install a new version of the bundle, that I get the latest changes. Is it not recommended to deal with bundles individually after a feature install? I do not want to delete kar file and /data and start all over again. Thanks, Sapna -- View this message in context: http://karaf.922171.n3.nabble.com/Issue-with-feature-Install-tp4035163.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Matt Sicker boa...@gmail.com
Re: [INFO] Update default etc/org.ops4j.pax.url.mvn.cfg on Karaf 3.0.x
Couldn't you make the system repo read-only (or a remote) and make an
additional user directory or something for extra bundles? It could be like
the data/kar/ directory.
On 3 September 2014 06:21, Jean-Baptiste Onofré j...@nanthrax.net wrote:
IMHO, it had negative impact due to the bug that I saw in Pax URL.
Now, on Karaf 3.0.2-SNAPSHOT, with my latest changes (and update to Pax
URL 2.1.0), .m2/repository is not populated by default, and only the system
repo is used.
It's what I named the standalone/atomic production mode.
I agree with your points, but IMHO, it's just different configuration to
do in etc/org.ops4j.pax.url.mvn.cfg that we can document.
Regards
JB
On 09/03/2014 12:58 PM, Christian Schneider wrote:
We had this setting of using the system repo as a local repo at the
start of development of karaf 3. It had quite negative effects.
The problem is that maven will write into the local repo. The system
repo should be read only though. So I think the system repo as a remote
repo is a good choice.
The only problem I see is that some people do not like that a local repo
is written in .m2 for production machines. So it would be great if we
could find a way to optionally
avoid writing into the local repo. I think this case is typical if
people either have all bundles in the system repo or if they always want
to connect to their own nexus or similar server.
In some cases on the other hand I think it is good to have a local repo
as cache for production machines. In the case where the system repo does
not contain all necessary bundles the local repo will
cache all necessary bundles after the first install. So the production
machine is then independent from the internet.
For developer machines as a third case it is good to be able to override
the jars in the system repo with the jars in the local repo. So for
example if I run a snapshot of karaf and work on a module I can do
changes in the module, rebuild it to my local repo and update the bundle
in karaf. I hope this case still works after your change.
Christian
Am 31.08.2014 22:43, schrieb Jean-Baptiste Onofré:
Following this thread, I wonder if it doesn't make sense to add the
system repo as local repo:
org.ops4j.pax.url.mvn.localRepository=file:${karaf.
home}/${karaf.default.repository}
and override the default m2 settings with an empty one in Karaf:
org.ops4j.pax.url.mvn.settings=${karaf.home}/${
karaf.default.repository}/settings.xml
by default, and document how to switch back to Maven local user
configuration.
It would avoid to populate the .m2/repository and force to use the
artifacts from the system repo (so very close to what we have in Karaf
2.x).
WDYT ?
Regards
JB
On 08/31/2014 10:31 PM, Matt Sicker wrote:
I quite like that change. In my Karaf usage, I've always reconfigured
the
.m2/repository directory to be inside KARAF_HOME instead just to isolate
the repositories in the first place. Any sort of change that prefers
usage
of artifact repositories embedded in Karaf are a step forward IMO.
On 31 August 2014 14:36, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hi all,
FYI, I aligned the etc/org.ops4j.pax.url.mvn.cfg files between master
(Karaf 4.x) and Karaf 3.0.x.
Basically, the change is to move the system repo and the kar repo as
default repositories, instead of regular repositories.
It allows Karaf to start quicker on a fresh machine, without any
.m2/repository.
Any objection ?
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Matt Sicker boa...@gmail.com
Re: [INFO] Update default etc/org.ops4j.pax.url.mvn.cfg on Karaf 3.0.x
Maybe some collaboration with Pax URL would help? I don't think many people work on that (might even be just one or two people). Some help would be nice I'm sure! On 3 September 2014 14:55, Christian Schneider ch...@die-schneider.net wrote: Sounds good to me. We could use a directory below data as the local repository and system as a remote. The only problem there is that pax url will then copy all jars from the system repo into the data dir. If we find a way to avoid this then I think this would be great. Christian Am 03.09.2014 15:13, schrieb Matt Sicker: Couldn't you make the system repo read-only (or a remote) and make an additional user directory or something for extra bundles? It could be like the data/kar/ directory. -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: [INFO] Update default etc/org.ops4j.pax.url.mvn.cfg on Karaf 3.0.x
I like the change so far! Also, personally, I don't mind upgrades of things
like Pax, Aries, Felix, BND, etc., as long as they aren't huge releases
(e.g., 2.0 - 3.0) without a good reason. This is mainly due to bugfixes
and such that have caused much pain in the past! ;)
On 1 September 2014 08:25, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Working on this improvement, I faced a couple of severe bugs in Pax URL,
preventing a clean usage of the system repository.
So, I upgraded to Pax URL 2.1.0 on Karaf 3.0.x. I know that we should
avoid such kind of changes for a minor release, however, I think the Pax
URL issues are really important and justify the update.
I did:
- upgrade to Pax URL 2.1.0
- use of the uber bundles
- cleanup in the etc/org.ops4j.pax.url.mvn.cfg configuration file
You can see the commit there:
https://git-wip-us.apache.org/repos/asf?p=karaf.git;a=commitdiff;h=
9c6fccd6b376512fa73e92cfad83ed6062ce9d4f
IMHO, the situation is largely better now, as the system repo is use first.
If you see a problem with this change, please let me know, I will revert
my change.
Thanks,
Regards
JB
On 09/01/2014 10:14 AM, Jean-Baptiste Onofré wrote:
Hi Matt,
I agree.
Let me explain what I have in mind.
Karaf can work in two modes:
- by default, it should be standalone/atomic. I mean here that it should
not use any external folders like the .m2/repository folder.
It means the following configuration in etc/org.ops4j.pax.url.mvn.cfg
file:
-- org.ops4j.pax.url.mvn.settings=${karaf.etc}/settings.xml
where the settings.xml contains an empty settings.xml like:
?xml version=1.0 encoding=UTF-8?
settings/settings
--
org.ops4j.pax.url.mvn.localRepository=${karaf.home}/
${karaf.default.repository}
to use the system repo as local by default (and not .m2/repository)
-- org.ops4j.pax.url.mvn.defaultRepositories=\
${karaf.home}/${karaf.default.repository}@id=system@snapshots, \
${karaf.data}/kar@id=kar@multi@snapshots
-- org.ops4j.pax.url.mvn.repositories=\
http://repo1.maven.org/maven2@id=central, \
http://repository.springsource.com/maven/bundle/
release@id=spring.ebr.release,
\
http://repository.springsource.com/maven/bundles/external@id=spring.
ebr.external,
\
http://repository.apache.org/content/groups/snapshots-
group@id=apache@snapshots@noreleases,
\
https://oss.sonatype.org/content/repositories/snapshots@id=sonatype.
snapshots.deploy@snapshots@norelease,
\
https://oss.sonatype.org/content/repositories/ops4j-
snapshots@id=ops4j.sonatype.snapshots.deploy@snapshots@noreleases
- as an alternative, we document (both in the user guide and using
comments in etc/org.ops4j.pax.url.mnv.cfg) how to switch in development
mode, meaning:
-- comment the org.ops4j.pax.url.mvn.settings property to use the
user .m2/settings.xml
-- comment the org.ops4j.pax.url.mvn.localRepository property to use
the user .m2/repository
WDYT ?
Regards
JB
On 08/31/2014 10:49 PM, Matt Sicker wrote:
Basically, the way I see it, in a developer setting, using your
.m2/repository makes sense as it's likely to have tons of libraries there
already. On production/staging/testing servers, however, it's far more
likely to contain things as much as possible. For instance, I may wish to
run Karaf as a user that has no home directory.
On 31 August 2014 15:43, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Following this thread, I wonder if it doesn't make sense to add the
system
repo as local repo:
org.ops4j.pax.url.mvn.localRepository=file:${karaf.
home}/${karaf.default.
repository}
and override the default m2 settings with an empty one in Karaf:
org.ops4j.pax.url.mvn.settings=${karaf.home}/${
karaf.default.repository}/
settings.xml
by default, and document how to switch back to Maven local user
configuration.
It would avoid to populate the .m2/repository and force to use the
artifacts from the system repo (so very close to what we have in
Karaf 2.x).
WDYT ?
Regards
JB
On 08/31/2014 10:31 PM, Matt Sicker wrote:
I quite like that change. In my Karaf usage, I've always
reconfigured the
.m2/repository directory to be inside KARAF_HOME instead just to
isolate
the repositories in the first place. Any sort of change that prefers
usage
of artifact repositories embedded in Karaf are a step forward IMO.
On 31 August 2014 14:36, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hi all,
FYI, I aligned the etc/org.ops4j.pax.url.mvn.cfg files between master
(Karaf 4.x) and Karaf 3.0.x.
Basically, the change is to move the system repo and the kar repo as
default repositories, instead of regular repositories.
It allows Karaf to start quicker on a fresh machine, without any
.m2/repository.
Any objection ?
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono
Re: [INFO] Update default etc/org.ops4j.pax.url.mvn.cfg on Karaf 3.0.x
I quite like that change. In my Karaf usage, I've always reconfigured the .m2/repository directory to be inside KARAF_HOME instead just to isolate the repositories in the first place. Any sort of change that prefers usage of artifact repositories embedded in Karaf are a step forward IMO. On 31 August 2014 14:36, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, FYI, I aligned the etc/org.ops4j.pax.url.mvn.cfg files between master (Karaf 4.x) and Karaf 3.0.x. Basically, the change is to move the system repo and the kar repo as default repositories, instead of regular repositories. It allows Karaf to start quicker on a fresh machine, without any .m2/repository. Any objection ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: [INFO] Update default etc/org.ops4j.pax.url.mvn.cfg on Karaf 3.0.x
Basically, the way I see it, in a developer setting, using your
.m2/repository makes sense as it's likely to have tons of libraries there
already. On production/staging/testing servers, however, it's far more
likely to contain things as much as possible. For instance, I may wish to
run Karaf as a user that has no home directory.
On 31 August 2014 15:43, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Following this thread, I wonder if it doesn't make sense to add the system
repo as local repo:
org.ops4j.pax.url.mvn.localRepository=file:${karaf.home}/${karaf.default.
repository}
and override the default m2 settings with an empty one in Karaf:
org.ops4j.pax.url.mvn.settings=${karaf.home}/${karaf.default.repository}/
settings.xml
by default, and document how to switch back to Maven local user
configuration.
It would avoid to populate the .m2/repository and force to use the
artifacts from the system repo (so very close to what we have in Karaf 2.x).
WDYT ?
Regards
JB
On 08/31/2014 10:31 PM, Matt Sicker wrote:
I quite like that change. In my Karaf usage, I've always reconfigured the
.m2/repository directory to be inside KARAF_HOME instead just to isolate
the repositories in the first place. Any sort of change that prefers usage
of artifact repositories embedded in Karaf are a step forward IMO.
On 31 August 2014 14:36, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hi all,
FYI, I aligned the etc/org.ops4j.pax.url.mvn.cfg files between master
(Karaf 4.x) and Karaf 3.0.x.
Basically, the change is to move the system repo and the kar repo as
default repositories, instead of regular repositories.
It allows Karaf to start quicker on a fresh machine, without any
.m2/repository.
Any objection ?
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Matt Sicker boa...@gmail.com
Re: [INFO] Update default etc/org.ops4j.pax.url.mvn.cfg on Karaf 3.0.x
By it's far more likely, I meant I'm far more likely.
On 31 August 2014 15:49, Matt Sicker boa...@gmail.com wrote:
Basically, the way I see it, in a developer setting, using your
.m2/repository makes sense as it's likely to have tons of libraries there
already. On production/staging/testing servers, however, it's far more
likely to contain things as much as possible. For instance, I may wish to
run Karaf as a user that has no home directory.
On 31 August 2014 15:43, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Following this thread, I wonder if it doesn't make sense to add the
system repo as local repo:
org.ops4j.pax.url.mvn.localRepository=file:${karaf.home}/${karaf.default.
repository}
and override the default m2 settings with an empty one in Karaf:
org.ops4j.pax.url.mvn.settings=${karaf.home}/${karaf.default.repository}/
settings.xml
by default, and document how to switch back to Maven local user
configuration.
It would avoid to populate the .m2/repository and force to use the
artifacts from the system repo (so very close to what we have in Karaf 2.x).
WDYT ?
Regards
JB
On 08/31/2014 10:31 PM, Matt Sicker wrote:
I quite like that change. In my Karaf usage, I've always reconfigured the
.m2/repository directory to be inside KARAF_HOME instead just to isolate
the repositories in the first place. Any sort of change that prefers
usage
of artifact repositories embedded in Karaf are a step forward IMO.
On 31 August 2014 14:36, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hi all,
FYI, I aligned the etc/org.ops4j.pax.url.mvn.cfg files between master
(Karaf 4.x) and Karaf 3.0.x.
Basically, the change is to move the system repo and the kar repo as
default repositories, instead of regular repositories.
It allows Karaf to start quicker on a fresh machine, without any
.m2/repository.
Any objection ?
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Matt Sicker boa...@gmail.com
--
Matt Sicker boa...@gmail.com
Re: [VOTE] Release Apache Karaf 2.3.6
No corresponding 3.0.x release? :( No vote here as I'm not a committer or anything. Just passing by. On 28 July 2014 21:39, Jamie G. jamie.goody...@gmail.com wrote: Hi, We resolved 70 issues in this release: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.3.6-release.page?view=markup Dependency changes can be reviewed here: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-2.3.x.page?revision=1613719view=markup Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-1008/ Git tag: karaf-2.3.6 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. -- Matt Sicker boa...@gmail.com
Re: Any news on the Log4j 2 upgrade?
Log4j2 has slf4j versions of log4j2 markers, so it would work fine to use the SLF4J ones. In fact, if it helps, you can use the log4j-slf4j-impl bundle to bridge log4j-api and log4j-core into slf4j-api. On 21 July 2014 14:28, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Gareth, I refactored the Markers to use slf4j marker in the case of usage of slf4j pax-logging-service usage, or natively log4j2 native when using log4j pax-logging-service. I will add a couple of unit test about that. Regards JB On 07/21/2014 07:36 PM, Gareth wrote: Hello Jean-Baptiste, I am curious - for the 1.8.0 release are you planning to do anything different with Markers? I understand that Pax Logging currently converts any Markers into an MDC parameter (slf4j.marker) because log4j doesn't support them. However both log4j2 and logback do support Markers natively. Just curious. thanks in advance, Gareth -- View this message in context: http://karaf.922171.n3.nabble. com/Any-news-on-the-Log4j-2-upgrade-tp4034325p4034344.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: Any news on the Log4j 2 upgrade?
I have a fork of pax-logging here: https://github.com/jvz/org.ops4j.pax.logging where I started working on porting some parts for log4j2. On 21 July 2014 23:56, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Matt, I didn't use log4j-slf4j-impl as I did a pax-logging-service native log4j service. However, it could be interesting as a transition to support log4jv2 directly in Karaf without a new version of pax-logging. Let me try it. Thanks for the update Regards JB On 07/21/2014 11:41 PM, Matt Sicker wrote: Log4j2 has slf4j versions of log4j2 markers, so it would work fine to use the SLF4J ones. In fact, if it helps, you can use the log4j-slf4j-impl bundle to bridge log4j-api and log4j-core into slf4j-api. On 21 July 2014 14:28, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Gareth, I refactored the Markers to use slf4j marker in the case of usage of slf4j pax-logging-service usage, or natively log4j2 native when using log4j pax-logging-service. I will add a couple of unit test about that. Regards JB On 07/21/2014 07:36 PM, Gareth wrote: Hello Jean-Baptiste, I am curious - for the 1.8.0 release are you planning to do anything different with Markers? I understand that Pax Logging currently converts any Markers into an MDC parameter (slf4j.marker) because log4j doesn't support them. However both log4j2 and logback do support Markers natively. Just curious. thanks in advance, Gareth -- View this message in context: http://karaf.922171.n3.nabble. com/Any-news-on-the-Log4j-2-upgrade-tp4034325p4034344.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Any news on the Log4j 2 upgrade?
Log4j 2.0 was officially released not that long ago, and 2.0.1 will be released soon with improved OSGi support. Is there any news on PaxLogging or even just Karaf using it? -- Matt Sicker boa...@gmail.com
Re: Any news on the Log4j 2 upgrade?
Sounds good! I may have some pull requests regarding this. On 20 July 2014 23:28, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Matt, I started to work on Log4j v2 support in Pax Logging. It's plan for Pax Logging 1.8.0. I released Pax Logging 1.7.3 last week (with bug fixes and upgrade like support of slf4j 1.7.7). I plan to release Pax Logging 1.8.0 with Log4j v2 support beginning of August. Regards JB On 07/21/2014 01:32 AM, Matt Sicker wrote: Log4j 2.0 was officially released not that long ago, and 2.0.1 will be released soon with improved OSGi support. Is there any news on PaxLogging or even just Karaf using it? -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: [PROPOSAL] Remove default ssh key
Don't forget that ssh-keygen is a real program installed on most computers. ;) On 18 July 2014 03:13, Jean-Baptiste Onofré j...@nanthrax.net wrote: Good idea for the password changes before logging. And agree for these changes in major releases. That's why I proposed two steps: the comment of key on next micro release, the big changes ;) for next major one. Regards JB On 07/18/2014 10:10 AM, Guillaume Nodet wrote: Yeahs, it makes sense to me. One additional thing about the password that comes to my mind, is the ability to integrate the change of password with ssh (when using keyboard interactive, the ssh server can ask the user for a password change before actually logging in, so that changing the password would also work if using bin/start and bin/client). Anyway, those changes are quite important and should be done in minor / major releases but maybe not micro ones. 2014-07-18 9:28 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: Hi Guillaume, I guess you mean default karaf/karaf. Why not doing a kind of unix like bootstrap like the root user: we can consider the karaf user as the root user, so mandatory. Why not defining an empty password by default and at bootstrap, if the password is empty (when starting with bin/karaf), prompt for a password. I would propose two steps: - first to fix the security hole, comment the key and document how to enable/change it (it will be included in next releases) - second, we provide the ssh:key-gen/key-add and passwd commands/MBeans operations + the prompt of password if the karaf password is empty. WDYT ? Regards JB On 07/18/2014 09:21 AM, Guillaume Nodet wrote: In the same line, shouldn't we remove the default user then ? And add command or maybe prompt for credentials at first boot ? And what about child containers ? Should credentials be propagated somehow ? 2014-07-17 21:44 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: Hi all, Following a discussion that we had with Christian, I would like to raise a concern. Now, on Karaf 2.x/3.x/4.x, the JMX layer is secure using RBAC. The MBeanServerBuilder is enabled by default, meaning that it's not possible to locally connect to the MBean server. I think it's good and secure. However, on the other hand, we have a key enabled by default (in etc/keys.properties) and used by default by bin/client. So it means that any user that download a Karaf distribution can connect to any Karaf runtimes by default. On one hand we have a very secure JMX layer (even for local connection), but on the other hand, bin/client can connect to any Karaf running instance (so not very secure). I would like to propose the following: - in etc/keys.properties, we should comment out the default key. We can document how to enable it and how to change the keys. - in bin/client, we should be able to specify a key that we want to use. WDYT ? I already created some Jira about the keys: - KARAF-2786: I would change this one by comment out the default key - KARAF-2836 to allow to specify multiple keys for an user in etc/keys.properties - KARAF-2787 to allow to specify the key to bin/client Thanks, Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: [PROPOSAL] Remove default ssh key
A tool to generate an SSH key and set up the related files would be better than providing a default SSH key. On 17 July 2014 14:44, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, Following a discussion that we had with Christian, I would like to raise a concern. Now, on Karaf 2.x/3.x/4.x, the JMX layer is secure using RBAC. The MBeanServerBuilder is enabled by default, meaning that it's not possible to locally connect to the MBean server. I think it's good and secure. However, on the other hand, we have a key enabled by default (in etc/keys.properties) and used by default by bin/client. So it means that any user that download a Karaf distribution can connect to any Karaf runtimes by default. On one hand we have a very secure JMX layer (even for local connection), but on the other hand, bin/client can connect to any Karaf running instance (so not very secure). I would like to propose the following: - in etc/keys.properties, we should comment out the default key. We can document how to enable it and how to change the keys. - in bin/client, we should be able to specify a key that we want to use. WDYT ? I already created some Jira about the keys: - KARAF-2786: I would change this one by comment out the default key - KARAF-2836 to allow to specify multiple keys for an user in etc/keys.properties - KARAF-2787 to allow to specify the key to bin/client Thanks, Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: [DISCUSS] Release Karaf 2.4.0
JPA with and without bytecode weaving perhaps? On 10 July 2014 15:51, Krzysztof Sobkowiak krzys.sobkow...@gmail.com wrote: Hi I have just tested jdbc, jms, jndi commands and performed some tests with ActiveMQ and Camel. This part looks ok. I'll try to perform some more tests tomorrow. Are there any special parts which should be tested more intensive? Best regards Krzysztof On 09.07.2014 21:16, Jean-Baptiste Onofré wrote: By the way, it's the same Aries * new releases that we will have on master, karaf-3.0.x (for the next 3.0.2) and karaf-2.x (for the next 2.4.0). Just to be clear. Regards JB On 07/09/2014 07:44 PM, Christian Schneider wrote: We should also include the upcoming aries jpa release. It contains some important fixes. The bug in the current aries jpa makes it almost impossible to use. (See https://issues.apache.org/jira/browse/ARIES-1160) JB offered to prepare this release. Christian Am 09.07.2014 17:24, schrieb Guillaume Nodet: Now that Aries releases are done, I'd like to discuss a 2.4.0 release asap. I think it's in a good shape, but i'll do a bit more testing and I would welcome any additional volunteers. Anyway, does anyone as any urgent stuff to put in before we release ? I'd like to start the release friday or monday if nothing requires a delay. Thoughts ? Guillaume -- Krzysztof Sobkowiak JEE OSS Architect | Senior Solution Architect @ Capgemini | Committer @ ASF Capgemini http://www.pl.capgemini.com/ | Software Solutions Center http://www.pl.capgemini-sdm.com/ | Wroclaw e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com | Twitter: @KSobkowiak Calendar: http://goo.gl/yvsebC -- Matt Sicker boa...@gmail.com
Re: [DISCUSS] Release Karaf 2.4.0
I would definitely second the Aries JPA bit. I had to go back to using JDBC instead of JPA due to the problems there. On 9 July 2014 12:57, Jean-Baptiste Onofré j...@nanthrax.net wrote: Agree with Christian, it's what I meant by fixes/enhancements ;) Regards JB On 07/09/2014 07:44 PM, Christian Schneider wrote: We should also include the upcoming aries jpa release. It contains some important fixes. The bug in the current aries jpa makes it almost impossible to use. (See https://issues.apache.org/jira/browse/ARIES-1160) JB offered to prepare this release. Christian Am 09.07.2014 17:24, schrieb Guillaume Nodet: Now that Aries releases are done, I'd like to discuss a 2.4.0 release asap. I think it's in a good shape, but i'll do a bit more testing and I would welcome any additional volunteers. Anyway, does anyone as any urgent stuff to put in before we release ? I'd like to start the release friday or monday if nothing requires a delay. Thoughts ? Guillaume -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: [INFO] Focus on Karaf 3.0.2 and 2.3.6
Can't wait! I've been dying to get us on Java 1.8, and this is the last dependency. :) On 8 July 2014 01:10, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, as the Aries releases vote has started, and Cellar/Cave released, we can now plan a Karaf 3.0.2 release as scheduled. I worked on the OPS4J PAX dependent projects, especially to validate the Java8 support. FYI, this week and the next one, I will focus on Karaf 3.0.2 and 2.3.6 preparation. As noted in the release schedule, the releases should go in vote on July, 25. I'm focussing on it ;) Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: Aw: [INFO] Apache Karaf 3.0.2 will be OSGi r4.3
This is separate from the Aries upgrades, right? On 30 June 2014 13:57, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Benjamin, it's exactly the purpose: - 2.x (2.4.0) will be aligned to 3.0.x, so OSGi 4.3.1 with Felix 4.2.1 and Equinox 3.8.2 - I will create (when necessary) a karaf-3.1.x branch with OSGi r5 (Felix 4.4.0 and Equinox 3.9.1 as we have on master). Regards JB On 06/30/2014 08:07 PM, Benjamin Graf wrote: Hi, maybe create another branch (3.1.x) for r5? It's a bit odd that 2.4 will be r5 ready but no 3.x version. :-) Regards Benjamin *Gesendet:* Montag, 30. Juni 2014 um 13:47 Uhr *Von:* Jean-Baptiste Onofré j...@nanthrax.net *An:* Karaf Dev dev@karaf.apache.org *Betreff:* [INFO] Apache Karaf 3.0.2 will be OSGi r4.3 Hi all, just an important note. We upgraded karaf-3.0.x branch to Felix 4.4.0/Equinox 3.9.1, so OSGi r5 in 3.0.2-SNAPSHOT. I think it wasn't a good upgrade for two reasons: 1/ we changed the OSGi release support in a minor version of a branch 2/ we potentially break dependency projects, it's the case for Pax Web 3.1 for instance. So, I will do the following: - master branch (Karaf 4.0.0-SNAPSHOT) will be OSGi r5, with Felix 4.4.0 and Equinox 3.9.1 (as it's the case right now) - karaf-3.0.x branch (Karaf 3.0.2-SNAPSHOT) will be OSGi r4.3, with Felix 4.2.1 and Equinox 3.8 (as it was in Karaf 3.0.1) I will update the schedule plan on the website too. Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Matt Sicker boa...@gmail.com
Re: Broken Dev Guide
JDBC works easily by using reference interface=javax.sql.DataSource filter=(osgi.jndi.service.name=foo/bar) id=datasource/ where foo/bar is the JNDI path. This would be in a Blueprint file. http://aries.apache.org/modules/jndiproject.html http://karaf.apache.org/manual/latest/users-guide/cdi.html Which version are you looking at the docs for? Those pages all work for me. On 18 June 2014 15:15, bane73 bran...@thegreshams.net wrote: Hi! I'm an OSGI newb trying to learn Karaf for a Spring app I've written at work that seems to be getting overly complex and would be best served modularizing it. Seems modern Spring is not a good fit, so I'm looking to re-plumb. My first task is to convert my Spring-JDBC/Dao layer, after which is to do my Spring-JNDI layer, and finally my Service layer (which is a standard non-web app that runs on a recurring Timer). The User Dev guides so far appear to be helpful, however a few sections I need appear to be missing? * Blueprint and CDI sections have links, but get 404 * There doesn't appear to be corresponding entries in the Dev Guide for how to use the JDBC JNDI services once installed into the Karaf environment? Any guidance/tips would be appreciated. I don't know anything about Blueprint, and event not much on CDI -- been traditionally a Spring-Web guy. But I'm hoping to develop an entire system around OSGI. Here's a summary of what the system currently does (it's an old embedded-perl system that I'm re-architecting): * about a dozen perl-scripts that run as CRON-jobs every x-minutes - each polls a different table in the database looking for work - when work arrives, each of them is responsible for updating a different service (various LDAPs, ADs, email servers, etc) * a web-app that interacts with the database to allow admins an easy way to submit the work (I'll be doing this piece later on; the immediate need is to replicate the cron-job scripts in a java ecosphere). I want to stick with this general approach because I think it's pretty good. But packaging it into a monolithic spring app is getting overwhelming. -- View this message in context: http://karaf.922171.n3.nabble.com/Broken-Dev-Guide-tp4033621.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Matt Sicker boa...@gmail.com
Re: Missing Constraint: Import-Package: com.sun.jersey.api.client
Do you have the jersey client installed in karaf, too? On 16 June 2014 19:54, SapnaB sapnabhargava...@gmail.com wrote: Hi All, I have added some client code in my osgi bundle using jersey. I have added jersey-bundle dependency in my pom.xml as below: dependency groupIdcom.sun.jersey/groupId artifactIdjersey-bundle/artifactId version1.18.1/version /dependency The imported packages in my class are: com.sun.jersey.api.client.* and thats why the Import Package section of pom.xml looks like: Import-Package com.sun.jersey.api.client, org.apache.felix.service.command, org.apache.felix.gogo.commands, org.apache.karaf.shell.console, * /Import-Package problem is after installation, once I start the bundle, I get the following error: Reason: Missing Constraint: Import-Package: com.sun.jersey.api.client; version=[1.18.0,2.0.0) Im really not able to figure out what karaf is trying to say, since I can see the following imports in my manifest: Import-Package: com.sun.jersey.api.client;version=[1.18,2),com.sun.jer sey.api.client.config;version=[1.18,2),javax.ws.rs.core;version=[1.1 ,2),org.apache.felix.gogo.commands;version=[0.10,1),org.apache.felix .service.command;version=[0.10,1);status=provisional,org.apache.karaf .shell.console;version=[2.2,3),org.osgi.service.blueprint;version=[1 .0.0,2.0.0) Any help is greatly appreciated. Thanks, Sapna -- View this message in context: http://karaf.922171.n3.nabble.com/Missing-Constraint-Import-Package-com-sun-jersey-api-client-tp4033550.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Matt Sicker boa...@gmail.com
Re: Missing Constraint: Import-Package: com.sun.jersey.api.client
What do you get when you run headers on those bundle IDs? Or running diag? On 16 June 2014 22:45, SapnaB sapnabhargava...@gmail.com wrote: Hi Matt, I installed all the required jersey jars in karaf and started them too as below: install mvn:com.sun.jersey/jersey-core/1.18.1 install mvn:com.sun.jersey/jersey-server/1.18.1 install mvn:javax.ws.rs/jsr311-api/1.1.1 install mvn:com.sun.jersey/jersey-json/1.18.1 install mvn:org.codehaus.jackson/jackson-core-asl/1.9.2 install mvn:org.codehaus.jackson/jackson-jaxrs/1.9.2 install mvn:org.codehaus.jackson/jackson-mapper-asl/1.9.2 install mvn:org.codehaus.jettison/jettison/1.1 start 362 363 364 365 366 367 368 369 But I still get the same error on starting my bundle: Unable to start bundle 370: The bundle Test_0.0.1.SNAPSHOT [370] could not be resolved. Reason: Missing Constraint: Import-Package: com.sun.jersey.api.client; version=[1.18.0,2.0.0) -Sapna -- View this message in context: http://karaf.922171.n3.nabble.com/Missing-Constraint-Import-Package-com-sun-jersey-api-client-tp4033550p4033554.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Matt Sicker boa...@gmail.com
Re: Missing Constraint: Import-Package: com.sun.jersey.api.client
Well, if they show up in red, that means they're unsatisfied. Check the headers for the dependencies as well to make sure they're exporting everything properly. Sometimes you need to install artifacts with wrap: before the mvn: to add OSGi metadata. On 16 June 2014 23:10, SapnaB sapnabhargava...@gmail.com wrote: Hi Matt, I get manifest headers as well as the import/export packages with dependencies, when I run osgi:headers on the above Bundle ids. The command run on my bundle gives: Apache Karaf :: Shell test/test-mcds Commands (370) --- Manifest-Version = 1.0 Bnd-LastModified = 1402976384349 Tool = Bnd-1.50.0 Built-By = sapbharg Build-Jdk = 1.6.0_24 Created-By = Apache Maven Bundle Plugin Bundle-Name = Apache Karaf :: Shell test/test-mcds Commands Bundle-Description = Provides the test custom command Bundle-SymbolicName = Test Bundle-Version = 0.0.1.SNAPSHOT Bundle-ManifestVersion = 2 Import-Package = com.sun.jersey.api.client;version=[1.18,2), com.sun.jersey.api.client.config;version=[1.18,2), javax.ws.rs.core;version=[1.1,2), org.apache.felix.gogo.commands;version=[0.10,1), org.apache.felix.service.command;status=provisional;version=[0.10,1), org.apache.karaf.shell.console;version=[2.2,3), org.osgi.service.blueprint;version=[1.0.0,2.0.0) Export-Package = test.command; uses:=org.apache.karaf.shell.console, com.sun.jersey.api.client.config, org.apache.felix.gogo.commands, com.sun.jersey.api.client, javax.ws.rs.core; version=0.0.1.SNAPSHOT Is there anything specific ur looking at? -Sapna -- View this message in context: http://karaf.922171.n3.nabble.com/Missing-Constraint-Import-Package-com-sun-jersey-api-client-tp4033550p4033556.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Matt Sicker boa...@gmail.com
Were you guys still interested in adopting Log4j2 for your logging system?
Back at ApacheCon, I spoke with a couple of you, and you were interested in switching to Log4j2 for your logging system. We're most likely going to be releasing 2.0 GA within a month or so, and it would be nice to get the OSGi stuff working right for then. Integration with an OSGi framework/tool like Karaf seems like a great way to make that happen! I've also began using Karaf at work about a month ago, so it'd be nice to learn more about the internals regardless. -- Matt Sicker boa...@gmail.com
