Re: Karaf target audience and release granularity

2018-08-18 Thread Matt Sicker
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

2018-03-14 Thread Matt Sicker
I'm more familiar with log4j myself. However, OSGi issues with Spring seem
to be a common issue thanks to Spring snubbing OSGi for a while. Chances
are that this has improved a bit in Spring 5 thanks to Java 9 modules
forcing them to embrace modularity again, though that doesn't help in this
scenario, sorry.

On 13 March 2018 at 23:23, munishgupta.asr <munishgupta@gmail.com>
wrote:

> Hi Matt,
>
> Thanks for guiding on Same like pax-logging-service issue. we are in good
> shape for that.
>
> same like that, earlier org.springframework libraries were also downloaded
> and started when we were running the package. we were defining these as
> bootfeatures during prepare package.
> org.apache.karaf.tooling
> karaf-maven-plugin
> ${apache-karaf.maven.plugin.version}
> true
> 
>  false
>  
>   framework
>   standard
>   eventadmin
>   jasypt-encryption
>   config
>   jpa/1.0.4
>   openjpa
>   transaction
>   spring
>   spring-dm
>   spring-dm-web
>   scr
>   http
>   war
>  
>
> but after upgrading to 4.2.0, These spring libraries are not getting
> downloaded and started. When i start my project, it fails with the OSGI
> wiring issues for spring dependency like org.springframework.web.servlet
>
> then I am trying to add it as OSGI bundle in features.xml by adding like
> bundle
> start-level="85">wrap:mvn:org.springframework/spring-webmvc/
> 4.3.7.RELEASE
>
> but it still fails. Can you give any pointers here?
>
>
>
>
>
> --
> 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

2018-03-06 Thread Matt Sicker
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

2018-03-02 Thread Matt Sicker
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

2018-03-01 Thread Matt Sicker
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

2017-10-19 Thread Matt Sicker
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

2017-10-19 Thread Matt Sicker
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

2017-07-19 Thread Matt Sicker
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

2017-06-12 Thread Matt Sicker
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...

2017-05-25 Thread Matt Sicker
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

2017-05-25 Thread Matt Sicker
>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...

2017-05-25 Thread Matt Sicker
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...

2017-05-24 Thread Matt Sicker
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...

2017-05-24 Thread Matt Sicker
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...

2017-05-24 Thread Matt Sicker
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...

2017-05-24 Thread Matt Sicker
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...

2017-05-24 Thread Matt Sicker
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...

2017-05-24 Thread Matt Sicker
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

2017-05-22 Thread Matt Sicker
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

2017-04-20 Thread Matt Sicker
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

2017-01-30 Thread Matt Sicker
 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

2017-01-15 Thread Matt Sicker
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

2017-01-04 Thread Matt Sicker
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

2016-10-10 Thread Matt Sicker
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

2016-09-25 Thread Matt Sicker
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>


Re: Log4j 1.x will not work in Java 9, need to migrate to 2.x

2016-09-25 Thread Matt Sicker
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>


Log4j 1.x will not work in Java 9, need to migrate to 2.x

2016-08-10 Thread Matt Sicker
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

2016-07-27 Thread Matt Sicker
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

2016-05-12 Thread Matt Sicker
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

2016-04-19 Thread Matt Sicker
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

2016-03-19 Thread Matt Sicker
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

2016-02-14 Thread Matt Sicker
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

2016-02-10 Thread Matt Sicker
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

2016-02-04 Thread Matt Sicker
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

2016-02-04 Thread Matt Sicker
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

2016-01-13 Thread Matt Sicker
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

2015-12-17 Thread Matt Sicker
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

2015-12-17 Thread Matt Sicker
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

2014-10-13 Thread Matt Sicker
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

2014-10-08 Thread Matt Sicker
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

2014-09-16 Thread Matt Sicker
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

2014-09-10 Thread Matt Sicker
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

2014-09-03 Thread 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.


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

2014-09-03 Thread Matt Sicker
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

2014-09-01 Thread Matt Sicker
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

2014-08-31 Thread Matt Sicker
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

2014-08-31 Thread Matt Sicker
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

2014-08-31 Thread Matt Sicker
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

2014-07-29 Thread Matt Sicker
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?

2014-07-21 Thread Matt Sicker
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?

2014-07-21 Thread Matt Sicker
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?

2014-07-20 Thread Matt Sicker
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?

2014-07-20 Thread Matt Sicker
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

2014-07-18 Thread Matt Sicker
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

2014-07-17 Thread Matt Sicker
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

2014-07-10 Thread Matt Sicker
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

2014-07-09 Thread Matt Sicker
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

2014-07-08 Thread Matt Sicker
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

2014-06-30 Thread Matt Sicker
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

2014-06-18 Thread Matt Sicker
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

2014-06-16 Thread Matt Sicker
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

2014-06-16 Thread Matt Sicker
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

2014-06-16 Thread Matt Sicker
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


Re: Were you guys still interested in adopting Log4j2 for your logging system?

2014-05-28 Thread Matt Sicker
Oh neat. Well, if you find any problems with the OSGi support, please let
us know!


On 27 May 2014 23:50, Jean-Baptiste Onofré j...@nanthrax.net wrote:

 Hi Matt,

 I started to work on the log4j2 support in Pax Logging (so in Karaf):

 https://ops4j1.jira.com/browse/PAXLOGGING-145

 I updated dependencies for the next Pax Logging version. I plan to
 complete log4j2 support next week.

 Regards
 JB


 On 05/28/2014 01:03 AM, Matt Sicker wrote:

 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.


 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com




-- 
Matt Sicker boa...@gmail.com


Were you guys still interested in adopting Log4j2 for your logging system?

2014-05-27 Thread Matt Sicker
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