Re: Karaf 4.4.4 and OpenJdk 21

[Bengt Rodehav]

OK - thanks.

/Bengt

Den tis 28 nov. 2023 kl 15:24 skrev Jean-Baptiste Onofré :

> It's what I said: Karaf itself works fine with JDK17+, however, third
> parties (like Aries Blueprint & Aries Proxy) are not yet compatible.
> I'm preparing new Aries releases to support this (including ASM 9.6
> update, etc, for JDK17+).
>
> Regards
> JB
>
> On Tue, Nov 28, 2023 at 2:59 PM Bengt Rodehav  wrote:
> >
> > I now compile for Java 17 (not 21 like I tried first). I use Karaf
> 4.4.4. I
> > get the following exception when running on OpenJDK 21:
> >
> > 2023-11-28T14:28:12,731 | ERROR | Blueprint Extender: 1 |
> > BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
> > 1.10.3 | Unable to start container for blueprint bundle
> > se.digia.bundles.jqueryui_1_8_16/7.0.0
> > org.osgi.service.blueprint.container.ComponentDefinitionException:
> > java.lang.IllegalArgumentException: Invalid Java version 65
> > at
> >
> org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:141)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:81)
> > ~[?:?]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
> > at
> >
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:90)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:810)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:784)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:765)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:699)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:666)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:81)
> > ~[?:?]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
> > at
> >
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:90)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:360)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:338)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:162)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BlueprintContainerImpl.processProcessors(BlueprintContainerImpl.java:572)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:417)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:298)
> > ~[?:?]
> > at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
> > ~[?:?]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
> > at
> >
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> > ~[?:?]
> > at
> >
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:45)
> > ~[?:?]
> > at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
> > ~[?:?]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
> > at
> >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> > ~[?:?]
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> > ~[?:?]
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> > ~[?:?]
> > at java.lang.Thread.run(Thread.java:1583) [?:?]
> > Caused by: java.lang.IllegalArgumentException: Invalid Java version 65
> > at
> >
> org.apache.aries.proxy.impl.ProxyUtils.getWeavingJavaVersion(ProxyUtils.java:104)
> > ~[?:?]
> > at
> >
> org.apache.aries.proxy.impl.interfaces.InterfaceCombiningClassAdapter.(InterfaceCombiningClassAdapter.java:79)
> > ~[?:?]
> > at
> >
> org.apache.aries.proxy.impl.interfaces.ProxyClassLoader.createProxyClass(ProxyClassLoader.java:155)
&

Re: Karaf 4.4.4 and OpenJdk 21

[Bengt Rodehav]

I now compile for Java 17 (not 21 like I tried first). I use Karaf 4.4.4. I
get the following exception when running on OpenJDK 21:

2023-11-28T14:28:12,731 | ERROR | Blueprint Extender: 1 |
BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
1.10.3 | Unable to start container for blueprint bundle
se.digia.bundles.jqueryui_1_8_16/7.0.0
org.osgi.service.blueprint.container.ComponentDefinitionException:
java.lang.IllegalArgumentException: Invalid Java version 65
at
org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:141)
~[?:?]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:81)
~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:90)
~[?:?]
at
org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:810)
~[?:?]
at
org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:784)
~[?:?]
at
org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:765)
~[?:?]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:699)
~[?:?]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:666)
~[?:?]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:81)
~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:90)
~[?:?]
at
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:360)
~[?:?]
at
org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:338)
~[?:?]
at
org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:162)
~[?:?]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.processProcessors(BlueprintContainerImpl.java:572)
~[?:?]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:417)
~[?:?]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:298)
~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at
org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
~[?:?]
at
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:45)
~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
~[?:?]
at java.lang.Thread.run(Thread.java:1583) [?:?]
Caused by: java.lang.IllegalArgumentException: Invalid Java version 65
at
org.apache.aries.proxy.impl.ProxyUtils.getWeavingJavaVersion(ProxyUtils.java:104)
~[?:?]
at
org.apache.aries.proxy.impl.interfaces.InterfaceCombiningClassAdapter.(InterfaceCombiningClassAdapter.java:79)
~[?:?]
at
org.apache.aries.proxy.impl.interfaces.ProxyClassLoader.createProxyClass(ProxyClassLoader.java:155)
~[?:?]
at
org.apache.aries.proxy.impl.interfaces.InterfaceProxyGenerator.getProxyInstance(InterfaceProxyGenerator.java:97)
~[?:?]
at
org.apache.aries.proxy.impl.AsmProxyManager.createNewProxy(AsmProxyManager.java:80)
~[?:?]
at
org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingInterceptingProxy(AbstractProxyManager.java:77)
~[?:?]
at
org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingProxy(AbstractProxyManager.java:42)
~[?:?]
at
org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.createProxy(AbstractServiceReferenceRecipe.java:332)
~[?:?]
at
org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:125)
~[?:?]
... 27 more

But when I run on OpenJDK 17 it works fine. Is this due to the problem you
mentioned regarding Aries Blueprint/Proxy? It looks like ASM is being used.
However Karaf 4.4.4 uses ASM 9.5 which should support OpenJDK 21.

I thought that generally a new Java version is backwards compatible.
Meaning that a specific java runtime would handle classes compiled for an
older java version. In this case, if I compile for java 17 I should be able
to run in on a java runtime >= 17. But this does not seem to be the case...

/Bengt

Den mån 27 nov. 2023 kl 17:31 skrev Bengt Rodehav :

> Thanks for the quick reply,
>
> /Bengt
>
> Den mån 27 nov. 2023 kl 15:16 skrev Jean-Baptiste Onofré  >:
>
>> Hi
>>
>> Karaf almost but not third parties (Aries Blueprint/Proxy, etc).
>>
>> I'm

Re: Building Karaf 4.4.4

[Bengt Rodehav]

Thanks!

Den tis 28 nov. 2023 kl 10:51 skrev Jean-Baptiste Onofré :

> That's probably the issue. Let me try to reproduce on a Windows VM.
>
> I will keep you posted.
>
> Regards
> JB
>
> On Mon, Nov 27, 2023 at 5:32 PM Bengt Rodehav  wrote:
> >
> > I'm building on Windows.
> >
> > /Bengt
> >
> > Den mån 27 nov. 2023 kl 15:18 skrev Jean-Baptiste Onofré <
> j...@nanthrax.net>:
> >
> > > Hi,
> > >
> > > winsw is part of the base feature.
> > >
> > > Are you building on Windows or Unix ?
> > >
> > > Regards
> > > JB
> > >
> > > On Mon, Nov 27, 2023 at 1:22 PM Bengt Rodehav 
> wrote:
> > > >
> > > > I have downloaded the source distribution of Karaf 4.4.4. When
> building I
> > > > get the following error message:
> > > >
> > > >  Could not find artifact com.sun.winsw:winsw:exe:net4:2.3.0
> > > >
> > > > I can't find this artifact in Maven central (only older versions).
> Also,
> > > I
> > > > googled this and found the following project in Github:
> > > > https://github.com/winsw/winsw
> > > >
> > > > But it seems to be for .NET, not for java.
> > > >
> > > > Can anyone explain this and point me to where I can download the
> > > necessary
> > > > dependency?
> > > >
> > > > /Bengt
> > >
>

Re: Building Karaf 4.4.4

[Bengt Rodehav]

I'm building on Windows.

/Bengt

Den mån 27 nov. 2023 kl 15:18 skrev Jean-Baptiste Onofré :

> Hi,
>
> winsw is part of the base feature.
>
> Are you building on Windows or Unix ?
>
> Regards
> JB
>
> On Mon, Nov 27, 2023 at 1:22 PM Bengt Rodehav  wrote:
> >
> > I have downloaded the source distribution of Karaf 4.4.4. When building I
> > get the following error message:
> >
> >  Could not find artifact com.sun.winsw:winsw:exe:net4:2.3.0
> >
> > I can't find this artifact in Maven central (only older versions). Also,
> I
> > googled this and found the following project in Github:
> > https://github.com/winsw/winsw
> >
> > But it seems to be for .NET, not for java.
> >
> > Can anyone explain this and point me to where I can download the
> necessary
> > dependency?
> >
> > /Bengt
>

Re: Karaf 4.4.4 and OpenJdk 21

[Bengt Rodehav]

Thanks for the quick reply,

/Bengt

Den mån 27 nov. 2023 kl 15:16 skrev Jean-Baptiste Onofré :

> Hi
>
> Karaf almost but not third parties (Aries Blueprint/Proxy, etc).
>
> I'm starting Karaf 4.5.x with full JDK21 support.
>
> Thanks !
> Regards
> JB
>
> On Mon, Nov 27, 2023 at 1:50 PM Bengt Rodehav  wrote:
> >
> > Does Karaf 4.4.4 work with OpenJdk 21?
> >
> > /Bengt
>

Karaf 4.4.4 and OpenJdk 21

[Bengt Rodehav]

Does Karaf 4.4.4 work with OpenJdk 21?

/Bengt

Building Karaf 4.4.4

[Bengt Rodehav]

I have downloaded the source distribution of Karaf 4.4.4. When building I
get the following error message:

 Could not find artifact com.sun.winsw:winsw:exe:net4:2.3.0

I can't find this artifact in Maven central (only older versions). Also, I
googled this and found the following project in Github:
https://github.com/winsw/winsw

But it seems to be for .NET, not for java.

Can anyone explain this and point me to where I can download the necessary
dependency?

/Bengt

Re: [PROPOSAL] Release Karaf 2.3.4 end of this week, 2.4.0 next week ?

[Bengt Rodehav]

Perfect - looking forward to it!

/Bengt


2014/1/8 Jean-Baptiste Onofré 

> It's already done and will be included in the next releases.
>
> Same for utils. For Felix ConfigAdmin, I'm checking the impacts.
>
> Regards
> JB
>
>
> On 01/08/2014 12:07 PM, Bengt Rodehav wrote:
>
>> Guillaume has released a new version of FileInstall (3.2.8) that I would
>> love to be included in these versions of Karaf. Is that possible?
>>
>> See:
>>
>> http://apache-felix.18485.x6.nabble.com/VOTE-Release-Utils-
>> 1-4-2-and-FileInstall-3-2-8-td5006385.html
>>
>> /Bengt
>>
>>
>> 2014/1/7 Charles Moulliard 
>>
>>  +1
>>>
>>>
>>> On Tue, Jan 7, 2014 at 1:10 AM, Freeman Fang 
>>> wrote:
>>>
>>>  +1
>>>> －
>>>> Freeman(Yue) Fang
>>>>
>>>> Red Hat, Inc.
>>>> FuseSource is now part of Red Hat
>>>>
>>>>
>>>>
>>>> On 2014-1-6, at 下午5:34, Jean-Baptiste Onofré wrote:
>>>>
>>>>  Hi guys,
>>>>>
>>>>> I started to work on Jira for 2.3.4 and 2.4.0.
>>>>>
>>>>> As we released 2.3.3 in September, I think it's the good time to
>>>>>
>>>> release
>>>
>>>> a 2.3.4 maintenance release.
>>>>
>>>>>
>>>>> WDYT ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbono...@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Charles Moulliard
>>> Apache Committer / Architect @RedHat
>>> Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [PROPOSAL] Release Karaf 2.3.4 end of this week, 2.4.0 next week ?

[Bengt Rodehav]

Guillaume has released a new version of FileInstall (3.2.8) that I would
love to be included in these versions of Karaf. Is that possible?

See:

http://apache-felix.18485.x6.nabble.com/VOTE-Release-Utils-1-4-2-and-FileInstall-3-2-8-td5006385.html

/Bengt


2014/1/7 Charles Moulliard 

> +1
>
>
> On Tue, Jan 7, 2014 at 1:10 AM, Freeman Fang 
> wrote:
>
> > +1
> > －
> > Freeman(Yue) Fang
> >
> > Red Hat, Inc.
> > FuseSource is now part of Red Hat
> >
> >
> >
> > On 2014-1-6, at 下午5:34, Jean-Baptiste Onofré wrote:
> >
> > > Hi guys,
> > >
> > > I started to work on Jira for 2.3.4 and 2.4.0.
> > >
> > > As we released 2.3.3 in September, I think it's the good time to
> release
> > a 2.3.4 maintenance release.
> > >
> > > WDYT ?
> > >
> > > Regards
> > > JB
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> >
> >
>
>
> --
> Charles Moulliard
> Apache Committer / Architect @RedHat
> Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io
>

Re: [PROPOSAL] Karaf 3.0.0.RC1 in 3 weeks, 2.3.1 and 2.2.10 in preparation

[Bengt Rodehav]

JB, is the Blueprint problem related to the issue I had with iPOJO in Karaf
2.3.0?

http://mail-archives.apache.org/mod_mbox/karaf-user/201211.mbox/%3CCAJ0TPG+sQ8_nVcZMe3uL9fXbwz3CfcEgre6C4+N=hqsqijp...@mail.gmail.com%3E

/Bengt


2012/11/15 Jean-Baptiste Onofré 

> Hi guys,
>
> I'm working on Karaf trunk about the issue that we have to fix for the
> first Release Candidate, especially around the sub-shell.
>
> I think we should be in-line to cut off 3.0.0.RC1 in 3 weeks. It won't be
> an "official" release, but a first RC to get some feedbacks from the users.
>
> On the other hand, Karaf 2.3.0 and 2.2.9 are impacted by an issue in Aries
> Blueprint (introduced in Blueprint 0.3.2 and 1.0.1).
> I'm focus on it and we have to fix this issue before cutting off 2.3.1 and
> 2.2.10. It will certainly require a new Aries Blueprint release, so I gonna
> deal with the Aries guys.
>
> WDYT ?
>
> Regards
> JB--
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>

Re: [PROPOSAL] Create "Karaf Features" sub-project

[Bengt Rodehav]

As a Karaf user I like the idea that JB proposes although I understand that
it might be hard to implement. I think that in order to externalize the
feature descriptors the feature mechanism must be stable in itself. I think
that is a requirement even for other projects to provide Karaf feature
descriptors. I also think it makes sense not to version the feature
mechanism together with Karaf - it should be a common descriptor format
that Karaf and others can depend on.

If not, then I think Guillaume, Ioannis and Freeman are rigth - it wouldn't
work. But, if possible, I would suggest:

a) Break out the feature mechanism into its own sub project with its own
versioning.
b) Try to stabilize the feature mechanism so that others can use it. At a
minimum minor version updates should be backwards compatible and major
version updates should be rare and announced.

/Bengt



2012/10/18 Freeman Fang 

> Yeah, I'm with Guillaume and Ioannis here.
> －
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://fusesource.com | http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> weibo: http://weibo.com/u/1473905042
>
> On 2012-10-18, at 下午4:14, Guillaume Nodet wrote:
>
> > Yeah, that's also my fear.  If we need to have a separate definition for
> > each karaf version, I'm not really sure there's a huge win in
> externalizing
> > those from the karaf branches.
> > Maybe that's not too much the case between 2.2 and 2.3, but I kinda fear
> > 2.3 / 3.0 need a lot of changes, even in some projects themselves.
> >
> > On Thu, Oct 18, 2012 at 9:52 AM, Ioannis Canellos 
> wrote:
> >
> >> The idea seems good at first glance, but there are things that we need
> >> consider.
> >>
> >> In many cases a feature descriptor is not portable between major Karaf
> >> versions, and it also happens that it breaks between minor versions.
> >>
> >> Even from Karaf 2.2.x to Karaf 2.3.x I've seen third party features
> break.
> >> So it may seem that most features could decoupled from the underlying
> >> version of Karaf, but practically this is not always the case.
> >>
> >> An example: In the spring feature case, we also have the spring
> deployer.
> >> Where will the source of spring deployer will be hosted and which are
> going
> >> to be the versions of fileinstall and karaf that the deployer will be
> built
> >> against?
> >>
> >>
> >> --
> >> *Ioannis Canellos*
> >> *
> >>
> >> **
> >> Blog: http://iocanel.blogspot.com
> >> **
> >> Twitter: iocanel
> >> *
> >>
> >
> >
> >
> > --
> > 
> > Guillaume Nodet
> > 
> > Blog: http://gnodet.blogspot.com/
> > 
> > FuseSource, Integration everywhere
> > http://fusesource.com
>
>

Re: [INFO] System repo, artifacts resolution and aether

[Bengt Rodehav]

It seems like you are right JB. I did this:

On Karaf 2.2.5 I set the property "org.ops4j.pax.url.mvn.repositories" to
an empty list. I then renamed a local jar so that it could no longer be
found locally. This gave me an error when a feature needing that bundle
were to be installed.

Actually I have done this before when using Karaf 1.6.0 but for some reason
this configuration had been removed from my custom server...

I did notice that (in Karaf 2.2.5) there is also a property called
"org.ops4j.pax.url.mvn.useFallbackRepositories" which by default is set to
false. If I set it to true, then Karaf will connect to the Internet and
download artifact (from some unknown default set of repositories). I also
noticed that this option did not exist back in Karaf 1.6.0.

So...maybe (I'm guessing now), back in Karaf 1.6.0 when I had set
the "org.ops4j.pax.url.mvn.repositories" property to an empty list, perhaps
pax-url-mvn still used the fallback repositories? Back then Karaf used
version 1.1.2 of pax-url-mvn while in Karaf 2.2.5 version 1.2.8 of
pax-url-mvn is used. Just speculating...

Anyway, your suggestion works for me although I would rather have an
"offline" option if you think it's OK.

I think  it's a bit tricky to configure pax-url-mvn and it would be good to
make the configuration clearer (and also document it a bit better). E g
what does the "org.ops4j.pax.url.mvn.disableAether" option actually do and
how does the resolution process work? Are we simulating maven artifact
resolution or are we actually using maven's own artifact resolution.

Thanks for your help JB,

/Bengt



2012/2/3 Bengt Rodehav 

> OK - I'll verify that,
>
> /Bengt
>
> 2012/2/3 Jean-Baptiste Onofré 
>
>> Hi Bengt,
>>
>> I don't think that the behaviour changed in any Karaf version. I don't
>> think any bug has been fixed around.
>> It should work with any Karaf >= 2.2.0 version.
>>
>> Regards
>> JB
>>
>>
>> On 02/03/2012 12:59 PM, Bengt Rodehav wrote:
>>
>>> Just to clarify,
>>>
>>> Did this behaviour change in some version of Karaf (2.2.0?)? I mean is
>>> this
>>> a known bug that has been corrected?
>>>
>>> /Bengt
>>>
>>> 2012/2/3 Jean-Baptiste Onofré
>>>
>>>  Hi Bengt,
>>>>
>>>> no I mean in any version since 2.2.0: if you remove all repositories in
>>>> etc/org.ops4j.pax.url.mvn.cfg, you will be in offline mode (it means
>>>> that
>>>> Karaf will use only artifacts present in the system repo).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 02/03/2012 09:44 AM, Bengt Rodehav wrote:
>>>>
>>>>  Thanks I appreciate it.
>>>>>
>>>>> When you say it's already available I guess you mean on trunk - right?
>>>>> I
>>>>> think the problems I've had was on version 2.2.0 (I haven't tested
>>>>> since).
>>>>> At that time I don't think removing all repositories helped. There were
>>>>> still some default search that was not disabled (possibly to Central).
>>>>> Has
>>>>> this behaviour changed on trunk?
>>>>>
>>>>> /Bengt
>>>>>
>>>>> 2012/2/3 Jean-Baptiste Onofré
>>>>>
>>>>>  Hi Bengt,
>>>>>
>>>>>>
>>>>>> basically, the "offline" mode is already possible, you just have to
>>>>>> remove
>>>>>> all repositories in the etc/org.ops4j.pax.url.mvn.cfg.
>>>>>>
>>>>>> However, I will add a special option in pax-url for that.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 02/02/2012 07:24 PM, Bengt Rodehav wrote:
>>>>>>
>>>>>>  Link URL looks interesting although I would regard them as a
>>>>>> complement
>>>>>>
>>>>>>> to
>>>>>>> direct maven resolving.
>>>>>>>
>>>>>>> I'v always considered the maven support in Karaf as a very useful
>>>>>>> feature.
>>>>>>> Especially during development since Karaf will pick up my newly built
>>>>>>> artifacts directly from my local maven repository. I'm sure it is
>>>>>>> also
>>>>>>> useful for populating the bundle cach

Re: [INFO] System repo, artifacts resolution and aether

[Bengt Rodehav]

OK - I'll verify that,

/Bengt

2012/2/3 Jean-Baptiste Onofré 

> Hi Bengt,
>
> I don't think that the behaviour changed in any Karaf version. I don't
> think any bug has been fixed around.
> It should work with any Karaf >= 2.2.0 version.
>
> Regards
> JB
>
>
> On 02/03/2012 12:59 PM, Bengt Rodehav wrote:
>
>> Just to clarify,
>>
>> Did this behaviour change in some version of Karaf (2.2.0?)? I mean is
>> this
>> a known bug that has been corrected?
>>
>> /Bengt
>>
>> 2012/2/3 Jean-Baptiste Onofré
>>
>>  Hi Bengt,
>>>
>>> no I mean in any version since 2.2.0: if you remove all repositories in
>>> etc/org.ops4j.pax.url.mvn.cfg, you will be in offline mode (it means that
>>> Karaf will use only artifacts present in the system repo).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 02/03/2012 09:44 AM, Bengt Rodehav wrote:
>>>
>>>  Thanks I appreciate it.
>>>>
>>>> When you say it's already available I guess you mean on trunk - right? I
>>>> think the problems I've had was on version 2.2.0 (I haven't tested
>>>> since).
>>>> At that time I don't think removing all repositories helped. There were
>>>> still some default search that was not disabled (possibly to Central).
>>>> Has
>>>> this behaviour changed on trunk?
>>>>
>>>> /Bengt
>>>>
>>>> 2012/2/3 Jean-Baptiste Onofré
>>>>
>>>>  Hi Bengt,
>>>>
>>>>>
>>>>> basically, the "offline" mode is already possible, you just have to
>>>>> remove
>>>>> all repositories in the etc/org.ops4j.pax.url.mvn.cfg.
>>>>>
>>>>> However, I will add a special option in pax-url for that.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 02/02/2012 07:24 PM, Bengt Rodehav wrote:
>>>>>
>>>>>  Link URL looks interesting although I would regard them as a
>>>>> complement
>>>>>
>>>>>> to
>>>>>> direct maven resolving.
>>>>>>
>>>>>> I'v always considered the maven support in Karaf as a very useful
>>>>>> feature.
>>>>>> Especially during development since Karaf will pick up my newly built
>>>>>> artifacts directly from my local maven repository. I'm sure it is also
>>>>>> useful for populating the bundle cache directly from the Internet
>>>>>> although
>>>>>> I would never use that feature in production (I create a custom
>>>>>> distribution containing everything I need instead).
>>>>>>
>>>>>> What I'm trying to say is that I don't want to take away the maven
>>>>>> support
>>>>>> since it's really useful (in development) but I would like to be able
>>>>>> to
>>>>>> control it (in production) so that:
>>>>>>
>>>>>> *Priority 1*: I can stop maven from downloading anything from the
>>>>>> Internet
>>>>>>
>>>>>> ("offline" mode). This I think must be mandatory for any production
>>>>>> system
>>>>>> - how else do you know what code you are running?
>>>>>>
>>>>>> *Priority 2*: I can restrict maven to only use artifacts contained in
>>>>>> my
>>>>>>
>>>>>> custom distribution (mainly the system folder). This would stop maven
>>>>>> from
>>>>>> accessing my local maven repo. This would make it easier to verify
>>>>>> that
>>>>>> my
>>>>>> custom distribution contains everything before moving to production.
>>>>>>
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>> 2012/2/2 Toni Menzel
>>>>>>
>>>>>>  FYI, with "making the link URL handler more clever" i mean probably
>>>>>>
>>>>>>  encoding the Maven coordinates (GAV) into the link url somehow (by
>>>>>>> convention), so that it allows to fallback to some other handler
>>>>>>> (aether
>>>>>>> e.g.) when the link cannot be resolved. No

Re: [INFO] System repo, artifacts resolution and aether

[Bengt Rodehav]

Just to clarify,

Did this behaviour change in some version of Karaf (2.2.0?)? I mean is this
a known bug that has been corrected?

/Bengt

2012/2/3 Jean-Baptiste Onofré 

> Hi Bengt,
>
> no I mean in any version since 2.2.0: if you remove all repositories in
> etc/org.ops4j.pax.url.mvn.cfg, you will be in offline mode (it means that
> Karaf will use only artifacts present in the system repo).
>
> Regards
> JB
>
>
> On 02/03/2012 09:44 AM, Bengt Rodehav wrote:
>
>> Thanks I appreciate it.
>>
>> When you say it's already available I guess you mean on trunk - right? I
>> think the problems I've had was on version 2.2.0 (I haven't tested since).
>> At that time I don't think removing all repositories helped. There were
>> still some default search that was not disabled (possibly to Central). Has
>> this behaviour changed on trunk?
>>
>> /Bengt
>>
>> 2012/2/3 Jean-Baptiste Onofré
>>
>>  Hi Bengt,
>>>
>>> basically, the "offline" mode is already possible, you just have to
>>> remove
>>> all repositories in the etc/org.ops4j.pax.url.mvn.cfg.
>>>
>>> However, I will add a special option in pax-url for that.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 02/02/2012 07:24 PM, Bengt Rodehav wrote:
>>>
>>>  Link URL looks interesting although I would regard them as a complement
>>>> to
>>>> direct maven resolving.
>>>>
>>>> I'v always considered the maven support in Karaf as a very useful
>>>> feature.
>>>> Especially during development since Karaf will pick up my newly built
>>>> artifacts directly from my local maven repository. I'm sure it is also
>>>> useful for populating the bundle cache directly from the Internet
>>>> although
>>>> I would never use that feature in production (I create a custom
>>>> distribution containing everything I need instead).
>>>>
>>>> What I'm trying to say is that I don't want to take away the maven
>>>> support
>>>> since it's really useful (in development) but I would like to be able to
>>>> control it (in production) so that:
>>>>
>>>> *Priority 1*: I can stop maven from downloading anything from the
>>>> Internet
>>>>
>>>> ("offline" mode). This I think must be mandatory for any production
>>>> system
>>>> - how else do you know what code you are running?
>>>>
>>>> *Priority 2*: I can restrict maven to only use artifacts contained in my
>>>>
>>>> custom distribution (mainly the system folder). This would stop maven
>>>> from
>>>> accessing my local maven repo. This would make it easier to verify that
>>>> my
>>>> custom distribution contains everything before moving to production.
>>>>
>>>>
>>>> /Bengt
>>>>
>>>> 2012/2/2 Toni Menzel
>>>>
>>>>  FYI, with "making the link URL handler more clever" i mean probably
>>>>
>>>>> encoding the Maven coordinates (GAV) into the link url somehow (by
>>>>> convention), so that it allows to fallback to some other handler
>>>>> (aether
>>>>> e.g.) when the link cannot be resolved. Not sure yet. Maybe you guys
>>>>> have
>>>>> an idea?
>>>>>
>>>>> On Thu, Feb 2, 2012 at 6:33 PM, Toni Menzel
>>>>>  wrote:
>>>>>
>>>>>  One thing you can do is using "link" URLs.
>>>>>
>>>>>> This is implemented in the pax-url-link project and resolves URLs
>>>>>> like:
>>>>>> link:classpath:META-INF/links/junit.link to an InputStream that
>>>>>>
>>>>>> contains
>>>>>> text with first line treated as the real URL.
>>>>>> So, for example, if you include a file with content:
>>>>>> mvn:org.junit/junit/4.8.2
>>>>>> in Classpath at location /META-INF/links/junit.link, you will get the
>>>>>> maven resolution.
>>>>>> But you also could have another runtime dependency resolving the
>>>>>> aforementioned link in class path like:
>>>>>> classpath:junit.jar
>>>>>> which then would use an embedded jar.
>>>>>> You see this brings in some indirection into the r

Re: [INFO] System repo, artifacts resolution and aether

[Bengt Rodehav]

Thanks I appreciate it.

When you say it's already available I guess you mean on trunk - right? I
think the problems I've had was on version 2.2.0 (I haven't tested since).
At that time I don't think removing all repositories helped. There were
still some default search that was not disabled (possibly to Central). Has
this behaviour changed on trunk?

/Bengt

2012/2/3 Jean-Baptiste Onofré 

> Hi Bengt,
>
> basically, the "offline" mode is already possible, you just have to remove
> all repositories in the etc/org.ops4j.pax.url.mvn.cfg.
>
> However, I will add a special option in pax-url for that.
>
> Regards
> JB
>
>
> On 02/02/2012 07:24 PM, Bengt Rodehav wrote:
>
>> Link URL looks interesting although I would regard them as a complement to
>> direct maven resolving.
>>
>> I'v always considered the maven support in Karaf as a very useful feature.
>> Especially during development since Karaf will pick up my newly built
>> artifacts directly from my local maven repository. I'm sure it is also
>> useful for populating the bundle cache directly from the Internet although
>> I would never use that feature in production (I create a custom
>> distribution containing everything I need instead).
>>
>> What I'm trying to say is that I don't want to take away the maven support
>> since it's really useful (in development) but I would like to be able to
>> control it (in production) so that:
>>
>> *Priority 1*: I can stop maven from downloading anything from the Internet
>>
>> ("offline" mode). This I think must be mandatory for any production system
>> - how else do you know what code you are running?
>>
>> *Priority 2*: I can restrict maven to only use artifacts contained in my
>>
>> custom distribution (mainly the system folder). This would stop maven from
>> accessing my local maven repo. This would make it easier to verify that my
>> custom distribution contains everything before moving to production.
>>
>>
>> /Bengt
>>
>> 2012/2/2 Toni Menzel
>>
>>  FYI, with "making the link URL handler more clever" i mean probably
>>> encoding the Maven coordinates (GAV) into the link url somehow (by
>>> convention), so that it allows to fallback to some other handler (aether
>>> e.g.) when the link cannot be resolved. Not sure yet. Maybe you guys have
>>> an idea?
>>>
>>> On Thu, Feb 2, 2012 at 6:33 PM, Toni Menzel
>>>  wrote:
>>>
>>>  One thing you can do is using "link" URLs.
>>>> This is implemented in the pax-url-link project and resolves URLs like:
>>>> link:classpath:META-INF/links/**junit.link to an InputStream that
>>>> contains
>>>> text with first line treated as the real URL.
>>>> So, for example, if you include a file with content:
>>>> mvn:org.junit/junit/4.8.2
>>>> in Classpath at location /META-INF/links/junit.link, you will get the
>>>> maven resolution.
>>>> But you also could have another runtime dependency resolving the
>>>> aforementioned link in class path like:
>>>> classpath:junit.jar
>>>> which then would use an embedded jar.
>>>> You see this brings in some indirection into the resolving process.
>>>> In Karaf i could think of shipping a "batteries-included" artifact that
>>>> includes many frequently used components, another (maybe an
>>>>
>>> enterprise.jar)
>>>
>>>> that contains another set of embedded batteries.
>>>> Good thing is, you never lose the ability to possibly fall back to mvn
>>>> resolvers taking down the artifact from outer space (online maven).
>>>>
>>>> Did you consider this, yet?
>>>> Toni
>>>>
>>>> On Thu, Feb 2, 2012 at 10:04 AM, Jean-Baptiste Onofré>>> wrote:
>>>>
>>>>  Hi all,
>>>>>
>>>>> On Karaf trunk (3.0), we currently from an issue around artifact
>>>>> resolution (due to pax-url/aether).
>>>>>
>>>>> It's something that David, Achim and I are aware, but I would like to
>>>>> warn and inform everyone (to avoid unpredictable behaviors ;)).
>>>>>
>>>>> 1/ SNAPSHOT resolution
>>>>> Currently, the system repo doesn't contain Maven metadata, sha1, Maven
>>>>> properties files. So, Aether always downloads the SNAPSHOT from Central
>>>>>
>>>> and
>>>

Re: [INFO] System repo, artifacts resolution and aether

[Bengt Rodehav]

I have been experimenting with the config.properties  regarding this before
but I remember having problems preventing the normal maven way of
resolving. I'll take a look at this again.

/Bengt

2012/2/2 Toni Menzel 

> On Thu, Feb 2, 2012 at 10:03 PM, Bengt Rodehav  wrote:
>
> > Yes, of course there are uses for "online" mode. I hope noone believes
> that
> > I want to remove that possibility. It can even be the default as long as
> > there are ways to "lock down" Karaf. It's both a matter of "security"
> > (don't use unknown or untested code in production) and of "convenience"
> > (verify in development that the installation includes everything needed).
> >
> > @Toni
> >
> > >What you also can do is using a local, shipped with karaf maven
> repository
> > >and set that as the only one (already possible)
> >
> > I wasn't aware of this. Can you enlighten me about how this is done?
> >
>
> Well, you can always set the repositories in Pax URL via System-, Bundle
> and/or directly inside the URL. Not really sure what the standards do look
> like in Karaf, but i bet its set in a config properties file. There you'd
> set repositories to some local, relative folder.
> Of cause, some initial routine needs to create/unpack that repository (it
> will look like you .m2/repositories e.g.) initially.
> Or you ship that in the standard karaf.zip.
>
> Hope that is clear?
>
>
> >
> > /Bengt
> >
> > 2012/2/2 Toni Menzel 
> >
> > > On Thu, Feb 2, 2012 at 8:28 PM, Christian Schneider <
> > > ch...@die-schneider.net
> > > > wrote:
> > >
> > > > I also think the offline feature is really important. At talend for
> > > > example we want
> > > > to make sure our distribution works when offline so this setting
> could
> > > > also be useful for tests.
> > > >
> > > > On the other hand I would not really say that downloading artifacts
> on
> > > > demand would never happen in production.
> > > > I can very well imagine deploying a very small container and then
> > > > downloading libs and custom applications from
> > > > a company maven repo. Of course this is different from downloading
> from
> > > > the internet but from the karaf point of view it
> > > > is not an offline mode.
> > > >
> > >
> > > correct!
> > > And when you think about cloud deployment, or at least a clustered
> setup,
> > > you'd be thankful for one central source.  All karaf instances
> > (technically
> > > "naked" would take their artifacts from there.
> > > If you want it more sophisticated (e.g. a push approach), you'd use
> > Apache
> > > ACE perhaps (inside Karaf). In the long run i could see some kind of
> > deeper
> > > integration of the two projects for initial provisioning (say, Karaf
> has
> > > just the bare bone container and bootstrapping stuff, everything else
> > comes
> > > from an ACE Repository.
> > > Just an idea so far..
> > >
> > >
> > > >
> > > > Christian
> > > >
> > > > Am 02.02.2012 19:24, schrieb Bengt Rodehav:
> > > >
> > > >  Link URL looks interesting although I would regard them as a
> > complement
> > > to
> > > >> direct maven resolving.
> > > >>
> > > >> I'v always considered the maven support in Karaf as a very useful
> > > feature.
> > > >> Especially during development since Karaf will pick up my newly
> built
> > > >> artifacts directly from my local maven repository. I'm sure it is
> also
> > > >> useful for populating the bundle cache directly from the Internet
> > > although
> > > >> I would never use that feature in production (I create a custom
> > > >> distribution containing everything I need instead).
> > > >>
> > > >> What I'm trying to say is that I don't want to take away the maven
> > > support
> > > >> since it's really useful (in development) but I would like to be
> able
> > to
> > > >> control it (in production) so that:
> > > >>
> > > >> *Priority 1*: I can stop maven from downloading anything from the
> > > Internet
> > > >> ("offline" mode). This I think must be mandatory for any production
> > > 

Re: [INFO] System repo, artifacts resolution and aether

[Bengt Rodehav]

Yes, of course there are uses for "online" mode. I hope noone believes that
I want to remove that possibility. It can even be the default as long as
there are ways to "lock down" Karaf. It's both a matter of "security"
(don't use unknown or untested code in production) and of "convenience"
(verify in development that the installation includes everything needed).

@Toni

>What you also can do is using a local, shipped with karaf maven repository
>and set that as the only one (already possible)

I wasn't aware of this. Can you enlighten me about how this is done?

/Bengt

2012/2/2 Toni Menzel 

> On Thu, Feb 2, 2012 at 8:28 PM, Christian Schneider <
> ch...@die-schneider.net
> > wrote:
>
> > I also think the offline feature is really important. At talend for
> > example we want
> > to make sure our distribution works when offline so this setting could
> > also be useful for tests.
> >
> > On the other hand I would not really say that downloading artifacts on
> > demand would never happen in production.
> > I can very well imagine deploying a very small container and then
> > downloading libs and custom applications from
> > a company maven repo. Of course this is different from downloading from
> > the internet but from the karaf point of view it
> > is not an offline mode.
> >
>
> correct!
> And when you think about cloud deployment, or at least a clustered setup,
> you'd be thankful for one central source.  All karaf instances (technically
> "naked" would take their artifacts from there.
> If you want it more sophisticated (e.g. a push approach), you'd use Apache
> ACE perhaps (inside Karaf). In the long run i could see some kind of deeper
> integration of the two projects for initial provisioning (say, Karaf has
> just the bare bone container and bootstrapping stuff, everything else comes
> from an ACE Repository.
> Just an idea so far..
>
>
> >
> > Christian
> >
> > Am 02.02.2012 19:24, schrieb Bengt Rodehav:
> >
> >  Link URL looks interesting although I would regard them as a complement
> to
> >> direct maven resolving.
> >>
> >> I'v always considered the maven support in Karaf as a very useful
> feature.
> >> Especially during development since Karaf will pick up my newly built
> >> artifacts directly from my local maven repository. I'm sure it is also
> >> useful for populating the bundle cache directly from the Internet
> although
> >> I would never use that feature in production (I create a custom
> >> distribution containing everything I need instead).
> >>
> >> What I'm trying to say is that I don't want to take away the maven
> support
> >> since it's really useful (in development) but I would like to be able to
> >> control it (in production) so that:
> >>
> >> *Priority 1*: I can stop maven from downloading anything from the
> Internet
> >> ("offline" mode). This I think must be mandatory for any production
> system
> >> - how else do you know what code you are running?
> >>
> >> *Priority 2*: I can restrict maven to only use artifacts contained in my
> >> custom distribution (mainly the system folder). This would stop maven
> from
> >> accessing my local maven repo. This would make it easier to verify that
> my
> >> custom distribution contains everything before moving to production.
> >>
> >>
> >> /Bengt
> >>
> >> 2012/2/2 Toni Menzel
> >>
> >>  FYI, with "making the link URL handler more clever" i mean probably
> >>> encoding the Maven coordinates (GAV) into the link url somehow (by
> >>> convention), so that it allows to fallback to some other handler
> (aether
> >>> e.g.) when the link cannot be resolved. Not sure yet. Maybe you guys
> have
> >>> an idea?
> >>>
> >>> On Thu, Feb 2, 2012 at 6:33 PM, Toni Menzel
> >>>  wrote:
> >>>
> >>>  One thing you can do is using "link" URLs.
> >>>> This is implemented in the pax-url-link project and resolves URLs
> like:
> >>>> link:classpath:META-INF/links/**junit.link to an InputStream that
> >>>> contains
> >>>> text with first line treated as the real URL.
> >>>> So, for example, if you include a file with content:
> >>>> mvn:org.junit/junit/4.8.2
> >>>> in Classpath at location /META-INF/links/junit.link, you will get the
> >>>> maven resol

Re: [INFO] System repo, artifacts resolution and aether

[Bengt Rodehav]

Link URL looks interesting although I would regard them as a complement to
direct maven resolving.

I'v always considered the maven support in Karaf as a very useful feature.
Especially during development since Karaf will pick up my newly built
artifacts directly from my local maven repository. I'm sure it is also
useful for populating the bundle cache directly from the Internet although
I would never use that feature in production (I create a custom
distribution containing everything I need instead).

What I'm trying to say is that I don't want to take away the maven support
since it's really useful (in development) but I would like to be able to
control it (in production) so that:

*Priority 1*: I can stop maven from downloading anything from the Internet
("offline" mode). This I think must be mandatory for any production system
- how else do you know what code you are running?

*Priority 2*: I can restrict maven to only use artifacts contained in my
custom distribution (mainly the system folder). This would stop maven from
accessing my local maven repo. This would make it easier to verify that my
custom distribution contains everything before moving to production.


/Bengt

2012/2/2 Toni Menzel 

> FYI, with "making the link URL handler more clever" i mean probably
> encoding the Maven coordinates (GAV) into the link url somehow (by
> convention), so that it allows to fallback to some other handler (aether
> e.g.) when the link cannot be resolved. Not sure yet. Maybe you guys have
> an idea?
>
> On Thu, Feb 2, 2012 at 6:33 PM, Toni Menzel  wrote:
>
> > One thing you can do is using "link" URLs.
> > This is implemented in the pax-url-link project and resolves URLs like:
> > link:classpath:META-INF/links/junit.link to an InputStream that contains
> > text with first line treated as the real URL.
> > So, for example, if you include a file with content:
> > mvn:org.junit/junit/4.8.2
> > in Classpath at location /META-INF/links/junit.link, you will get the
> > maven resolution.
> > But you also could have another runtime dependency resolving the
> > aforementioned link in class path like:
> > classpath:junit.jar
> > which then would use an embedded jar.
> > You see this brings in some indirection into the resolving process.
> > In Karaf i could think of shipping a "batteries-included" artifact that
> > includes many frequently used components, another (maybe an
> enterprise.jar)
> > that contains another set of embedded batteries.
> > Good thing is, you never lose the ability to possibly fall back to mvn
> > resolvers taking down the artifact from outer space (online maven).
> >
> > Did you consider this, yet?
> > Toni
> >
> > On Thu, Feb 2, 2012 at 10:04 AM, Jean-Baptiste Onofré  >wrote:
> >
> >> Hi all,
> >>
> >> On Karaf trunk (3.0), we currently from an issue around artifact
> >> resolution (due to pax-url/aether).
> >>
> >> It's something that David, Achim and I are aware, but I would like to
> >> warn and inform everyone (to avoid unpredictable behaviors ;)).
> >>
> >> 1/ SNAPSHOT resolution
> >> Currently, the system repo doesn't contain Maven metadata, sha1, Maven
> >> properties files. So, Aether always downloads the SNAPSHOT from Central
> and
> >> overrides the file locally in system repo.
> >> For instance, if you change the Karaf features file locally in the
> build,
> >> the generated distribution will embed the updated file, but this file
> will
> >> be overrided (when you perform feature:list or feature:list-url) by the
> one
> >> on snapshot remote repo.
> >> A "simple" workaround is to deploy the feature file (mvn deploy), but
> >> it's really ugly.
> >>
> >> 2/ Karaf bootstrap time
> >> A side effect is that Karaf 3.0 is really long to start and bootstrap,
> >> because Karaf checkes for update for each bundles/artifacts in system
> repo.
> >> I evaluated that Karaf 3 takes 10 more times than Karaf 2 to start
> >> (depending of the network connection).
> >>
> >> I consider it as a major issue, and I'm focusing on it (on both Karaf
> and
> >> Pax URL).
> >>
> >> Regards
> >> JB
> >> --
> >> Jean-Baptiste Onofré
> >> jbono...@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
> >
> >
> > --
> > Toni Menzel Source 
> >
> >
>
>
> --
> Toni Menzel Source 
>

Re: [INFO] System repo, artifacts resolution and aether

[Bengt Rodehav]

While you're looking at this problem, could you also consider making it
possible to run Karaf in "offline" mode?

I've had several issues when moving from development to production. In
development I think that I have included all the necessary artifacts in my
custom distribution. But then in production (where there is sometimes no
Internet connection from the servers) it turns out that artifacts were
missing.

I have looked for a way to run Karaf in a mode similar to "mvn -o" so that
I can verify that I have included everything. Running Karaf as a service
(under Windows) helps since maven's local repository is not found but
artifacts can still be downloaded from the Internet.

This is not only for development though. I really do NOT want Karaf to
download any artifacts from the Internet in production - even if it were
possible. I only want to use the exact artifacts that have been verified in
the testing phase.

Although not exactly the problem you are looking at it seems related.

/Bengt

2012/2/2 Jean-Baptiste Onofré 

> Just a remark, the SNAPSHOT resolution is considered as "normal" from an
> aether perspective as the local system repo doesn't contain metadata.
>
> Regards
> JB
>
>
> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré wrote:
>
>> Hi all,
>>
>> On Karaf trunk (3.0), we currently from an issue around artifact
>> resolution (due to pax-url/aether).
>>
>> It's something that David, Achim and I are aware, but I would like to
>> warn and inform everyone (to avoid unpredictable behaviors ;)).
>>
>> 1/ SNAPSHOT resolution
>> Currently, the system repo doesn't contain Maven metadata, sha1, Maven
>> properties files. So, Aether always downloads the SNAPSHOT from Central
>> and overrides the file locally in system repo.
>> For instance, if you change the Karaf features file locally in the
>> build, the generated distribution will embed the updated file, but this
>> file will be overrided (when you perform feature:list or
>> feature:list-url) by the one on snapshot remote repo.
>> A "simple" workaround is to deploy the feature file (mvn deploy), but
>> it's really ugly.
>>
>> 2/ Karaf bootstrap time
>> A side effect is that Karaf 3.0 is really long to start and bootstrap,
>> because Karaf checkes for update for each bundles/artifacts in system
>> repo.
>> I evaluated that Karaf 3 takes 10 more times than Karaf 2 to start
>> (depending of the network connection).
>>
>> I consider it as a major issue, and I'm focusing on it (on both Karaf
>> and Pax URL).
>>
>> Regards
>> JB
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [Discussion] Security improvements

[Bengt Rodehav]

You're probably right that Shiro doesn't support all low-level permissions
the way JAAS does. Which I guess means that JAAS cannot go away. On the
other hand JAAS is totally unuitable for complex authorisation based on
permission hierarchies and roles.

In order to cover both ends I think that JAAS + something else (perhaps
Shiro) is needed. Don't know how they would inter-operate though. Also,
perhaps Karaf does not want another dependency...

It would be nice if JAAS and Shiro could inter-operate somehow. Then you
could have very coarse grained security in Karaf core and optionally allow
the developers to use Shiro for fine grained security (with an optional
dependency).

/Bengt

2012/1/31 Łukasz Dywicki 

> Hi,
> The Shiro proposal looks sexy, but we can not leave JAAS. As the security
> mechanism, JAAS is an standard built in in many places where we need it.
> For example we can control reflection access by using a corresponding
> permission.
>
> From one hand we need typical authorization for web application up to
> singular resource level, from other we need a low level security layer for
> gogo. That's can not be controled only by Shiro nor SpringSecurity.
>
> I believe that Shiro is correct solution for part of our problems but I
> also a bit afraid about adding next dependency to Karaf core.
>
> Best regards,
> Lukasz Dywicki
> --
> Code-House
> http://code-house.org
>
> Wiadomość napisana przez Bengt Rodehav w dniu 30 sty 2012, o godz. 20:09:
>
> > You are of course right Andreas. I just wanted to mention that moving to
> > Shiro instead of sticking with JAAS might make the implementation a lot
> > easier and more flexible.
> >
> > /Bengt
> >
> > 2012/1/30 Andreas Pieber 
> >
> >> Shiro will also work with apache wicket quite fine. But I think we
> should
> >> rather fixate first what we want to do and then decide how to do this.
> >>
> >> Kind regards,
> >> Andreas
> >> On Jan 30, 2012 6:45 PM, "Bengt Rodehav"  wrote:
> >>
> >>> I use Apache Shiro for both authentication and authorisation. JAAS is
> far
> >>> from ideal when it comes to complex authorisation schemes. The command
> >> tree
> >>> that you are talking about could be mapped using permissions in Shiro.
> >> You
> >>> would then create roles as needed - both fine grained and coarse
> grained
> >>> (which most would do).
> >>>
> >>> I'm not an expert but have a look at this:
> >>>
> >>> http://shiro.apache.org/authorization.html
> >>>
> >>> And to learn more about the flexibility with Shiro's permissions look
> at
> >>> this:
> >>>
> >>> http://shiro.apache.org/permissions.html
> >>>
> >>> I think it would be a perfect fit.
> >>>
> >>> /Bengt
> >>>
> >>> 2012/1/30 Christian Schneider 
> >>>
> >>>> I think a typical system for authorization would have resource level
> >>>> rights like "bundle:install" and high level roles that each have a set
> >> of
> >>>> those rights.
> >>>> This works of course but is a lot of configuration work. So we should
> >> be
> >>>> sure we really need that before we implement it.
> >>>>
> >>>> Another thing is that I think it only makes very limited sense to have
> >>>> authorization only on the UI level like Karaf commands or webconsole.
> >> The
> >>>> core are the
> >>>> services and there the authorization is most important. In the UI I
> >> would
> >>>> use the roles and rights mostly to make things visible or not. So it
> >>> would
> >>>> be a convenience feature
> >>>> to see only the commands you may call but even if you can see all the
> >>>> services behind the commands should block access to anything you
> should
> >>> not
> >>>> be able to do.
> >>>>
> >>>> So to make this work we have to do authentication on the UI level and
> >>> then
> >>>> forward the authorized principle to the service call where it should
> be
> >>>> checked. Ideally the forwarding and checking should be mostly
> >> transparent
> >>>> so we do not have to litter the whole "business" code with security
> >> code.
> >>>>
> >>>> Any ideas how this can be done in OSGi? I have read about using  java
&g

Re: [Discussion] Security improvements

[Bengt Rodehav]

You are of course right Andreas. I just wanted to mention that moving to
Shiro instead of sticking with JAAS might make the implementation a lot
easier and more flexible.

/Bengt

2012/1/30 Andreas Pieber 

> Shiro will also work with apache wicket quite fine. But I think we should
> rather fixate first what we want to do and then decide how to do this.
>
> Kind regards,
> Andreas
> On Jan 30, 2012 6:45 PM, "Bengt Rodehav"  wrote:
>
> > I use Apache Shiro for both authentication and authorisation. JAAS is far
> > from ideal when it comes to complex authorisation schemes. The command
> tree
> > that you are talking about could be mapped using permissions in Shiro.
> You
> > would then create roles as needed - both fine grained and coarse grained
> > (which most would do).
> >
> > I'm not an expert but have a look at this:
> >
> > http://shiro.apache.org/authorization.html
> >
> > And to learn more about the flexibility with Shiro's permissions look at
> > this:
> >
> > http://shiro.apache.org/permissions.html
> >
> > I think it would be a perfect fit.
> >
> > /Bengt
> >
> > 2012/1/30 Christian Schneider 
> >
> > > I think a typical system for authorization would have resource level
> > > rights like "bundle:install" and high level roles that each have a set
> of
> > > those rights.
> > > This works of course but is a lot of configuration work. So we should
> be
> > > sure we really need that before we implement it.
> > >
> > > Another thing is that I think it only makes very limited sense to have
> > > authorization only on the UI level like Karaf commands or webconsole.
> The
> > > core are the
> > > services and there the authorization is most important. In the UI I
> would
> > > use the roles and rights mostly to make things visible or not. So it
> > would
> > > be a convenience feature
> > > to see only the commands you may call but even if you can see all the
> > > services behind the commands should block access to anything you should
> > not
> > > be able to do.
> > >
> > > So to make this work we have to do authentication on the UI level and
> > then
> > > forward the authorized principle to the service call where it should be
> > > checked. Ideally the forwarding and checking should be mostly
> transparent
> > > so we do not have to litter the whole "business" code with security
> code.
> > >
> > > Any ideas how this can be done in OSGi? I have read about using  java
> > > security manager with OSGi but I am not sure if this is the right way.
> > >
> > > As Guillaume wrote we should have real use cases. For example if the
> only
> > > one who has access to the Karaf shell or web console then it makes no
> > sense
> > > to have fine grained security.
> > >
> > > Christian
> > >
> > > Am 30.01.2012 16:28, schrieb Guillaume Nodet:
> > >
> > >  Then, we're talking more about authorization than roles, which makes
> > >> sense to me.
> > >> But we should not mix both.  So what you're wiring is more command
> > >> level authorization, but we should not use roles to explicit those.
> > >>
> > >> Defining a role per command is just not scalable and new commands
> > >> won't be able to leverage them.  I think we need a mechanism that can
> > >> support coarse grained role definition and I don't think this goes in
> > >> that way.
> > >>
> > >> I may have missed something in your explanation, but I don't really
> > >> like the idea to have one role per command.
> > >>
> > >>
> > >>
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > > Open Source Architect
> > > Talend Application Integration Division http://www.talend.com
> > >
> > >
> >
>

Re: [Discussion] Security improvements

[Bengt Rodehav]

I use Apache Shiro for both authentication and authorisation. JAAS is far
from ideal when it comes to complex authorisation schemes. The command tree
that you are talking about could be mapped using permissions in Shiro. You
would then create roles as needed - both fine grained and coarse grained
(which most would do).

I'm not an expert but have a look at this:

http://shiro.apache.org/authorization.html

And to learn more about the flexibility with Shiro's permissions look at
this:

http://shiro.apache.org/permissions.html

I think it would be a perfect fit.

/Bengt

2012/1/30 Christian Schneider 

> I think a typical system for authorization would have resource level
> rights like "bundle:install" and high level roles that each have a set of
> those rights.
> This works of course but is a lot of configuration work. So we should be
> sure we really need that before we implement it.
>
> Another thing is that I think it only makes very limited sense to have
> authorization only on the UI level like Karaf commands or webconsole. The
> core are the
> services and there the authorization is most important. In the UI I would
> use the roles and rights mostly to make things visible or not. So it would
> be a convenience feature
> to see only the commands you may call but even if you can see all the
> services behind the commands should block access to anything you should not
> be able to do.
>
> So to make this work we have to do authentication on the UI level and then
> forward the authorized principle to the service call where it should be
> checked. Ideally the forwarding and checking should be mostly transparent
> so we do not have to litter the whole "business" code with security code.
>
> Any ideas how this can be done in OSGi? I have read about using  java
> security manager with OSGi but I am not sure if this is the right way.
>
> As Guillaume wrote we should have real use cases. For example if the only
> one who has access to the Karaf shell or web console then it makes no sense
> to have fine grained security.
>
> Christian
>
> Am 30.01.2012 16:28, schrieb Guillaume Nodet:
>
>  Then, we're talking more about authorization than roles, which makes
>> sense to me.
>> But we should not mix both.  So what you're wiring is more command
>> level authorization, but we should not use roles to explicit those.
>>
>> Defining a role per command is just not scalable and new commands
>> won't be able to leverage them.  I think we need a mechanism that can
>> support coarse grained role definition and I don't think this goes in
>> that way.
>>
>> I may have missed something in your explanation, but I don't really
>> like the idea to have one role per command.
>>
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>

Re: [VOTE] Release Apache Karaf 2.2.5

[Bengt Rodehav]

OK - thanks for the explanation JB.

I was hoping that Sonatype could share their version with Karaf but I guess
they weren't that cooperative then.

/Bengt

2011/12/22 Jean-Baptiste Onofré 

> Hi Bengt,
>
> yes it's postponed because we have an issue here (mostly political ;)).
>
> Let me explain (sorry for the noise in this thread):
>
> 1/ for the wrapper, we are stuck to an "old" version, the last one
> provided under Apache license (the "new" versions are GPL based, which is
> not Apache compliant). Our version only provides the native library (dll)
> for Windows 32 bits.
> 2/ Sonatype (for Nexus) checked out the wrapper source to just compile it
> on Windows 64 bits platform. So the source code is exactly the same, just a
> compilation on 64 bits Windows platform. Unfortunately, Sonatype doesn't
> provide this wrapper (it's reserved for Nexus), so we can't use it in Karaf.
> 3/ The only solution that I see, it's to do the same as Sonatype did:
> checkout the wrapper source and compile on Windows 64 bits platform, to get
> a dll that we can ship in Karaf.
>
> To do that, I have to setup a virtual machine, and I need more time.
>
> That's the explanation ;)
>
> Regards
> JB
>
>
> On 12/22/2011 10:36 AM, Bengt Rodehav wrote:
>
>> I noticed that Karaf-1010 ( https://issues.apache.org/**
>> jira/browse/KARAF-1010 <https://issues.apache.org/jira/browse/KARAF-1010>)
>> is not yet resolved. I guess that means Karaf still doesn't support
>> Windows
>> 7 64bit. It was scheduled for this release but it seems to have been
>> postphoned.
>>
>> /Bengt
>>
>> 2011/12/22 Andreas Pieber
>>
>>  Tested on various platforms and with my projects; works pretty fine.
>>> Build
>>> works fine on windows 7 32bit and archlinux 64bit (mvn 2.2.1&  java 5).
>>>
>>> Upgraded and tested also my Karaf based projects to 2.2.5 (RC) and
>>> mentioned no problems -->
>>>
>>> +1 (binding)
>>>
>>> Good work guys!
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> On Thu, Dec 22, 2011 at 07:52, Jean-Baptiste Onofré
>>> wrote:
>>>
>>>  +1 (binding)
>>>>
>>>> Tested with some sample bundles, Cellar, Cave, some Camel routes.
>>>>
>>>> However, I noticed:
>>>>
>>>> 1/ a warn exception on the webconsole:
>>>> 2011-12-22
>>>>
>>> 07:45:46.953:WARN:/:org.ops4j.pax.web.service.spi.model.
>>> ServletModel-5:
>>>
>>>> Failed to instantiate plugin org.apache.felix.webconsole.**
>>>> internal.compendium.ComponentsServlet
>>>> java.lang.NoClassDefFoundError: org.apache.felix.scr.ScrService
>>>> not
>>>> found by org.apache.karaf.webconsole.console [73]
>>>> It's already a known issue (I raised a Jira for that). It's not a
>>>> problem
>>>> on 2.2.5, but an issue that we have to address.
>>>> 2/ a warn on pax-web-jetty:
>>>> 2011-12-22 07:50:14,003 | WARN  | g.ops4j.pax.web) |
>>>> NIOSocketConnectorWrapper| ternal.NIOSocketConnectorWrapper
>>>> 45 | 70 - org.ops4j.pax.web.pax-web-jetty - 1.0.8 | Connection on
>>>> port
>>>> 8181 cannot be open. Reason: Address already in use
>>>> Not a big deal, but something to fix in Pax Web.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 12/22/2011 04:18 AM, Jamie G. wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> We resolved 54 issues in this release (web page will be published post
>>>>> RC promotion):
>>>>> https://svn.apache.org/repos/asf/karaf/site/trunk/src/**main/**<https://svn.apache.org/repos/**asf/karaf/site/trunk/src/main/**>
>>>>> webapp/index/community/download/karaf-2.2.5-release.page<
>>>>>
>>>> https://svn.apache.org/repos/**asf/karaf/site/trunk/src/main/**
>>> webapp/index/community/**download/karaf-2.2.5-release.**page<https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.2.5-release.page>
>>>
>>>>
>>>>
>>>>> Staging repository:
>>>>> https://repository.apache.org/content/repositories/**<https://repository.apache.org/**content/repositories/**>
>>>>> orgapachekaraf-382/<
>>>>>
>>>> https://repository.apache.org/**content/repositories/**
>>> orgapachekaraf-382/<https://repository.apache.org/content/repositories/orgapachekaraf-382/>
>>> >
>>>
>>>>
>>>>> Release tags:
>>>>> https://svn.apache.org/repos/asf/karaf/tags/karaf-2.2.5/<https://svn.apache.org/repos/**asf/karaf/tags/karaf-2.2.5/>
>>>>> <
>>>>>
>>>> https://svn.apache.org/repos/**asf/karaf/tags/karaf-2.2.5/<https://svn.apache.org/repos/asf/karaf/tags/karaf-2.2.5/>
>>> >
>>>
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>> --
>>>> 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
>

Re: [VOTE] Release Apache Karaf 2.2.5

[Bengt Rodehav]

I noticed that Karaf-1010 ( https://issues.apache.org/jira/browse/KARAF-1010 )
is not yet resolved. I guess that means Karaf still doesn't support Windows
7 64bit. It was scheduled for this release but it seems to have been
postphoned.

/Bengt

2011/12/22 Andreas Pieber 

> Tested on various platforms and with my projects; works pretty fine. Build
> works fine on windows 7 32bit and archlinux 64bit (mvn 2.2.1 & java 5).
> Upgraded and tested also my Karaf based projects to 2.2.5 (RC) and
> mentioned no problems -->
>
> +1 (binding)
>
> Good work guys!
>
> Kind regards,
> Andreas
>
> On Thu, Dec 22, 2011 at 07:52, Jean-Baptiste Onofré 
> wrote:
>
> > +1 (binding)
> >
> > Tested with some sample bundles, Cellar, Cave, some Camel routes.
> >
> > However, I noticed:
> >
> > 1/ a warn exception on the webconsole:
> > 2011-12-22
> 07:45:46.953:WARN:/:org.ops4j.**pax.web.service.spi.model.**ServletModel-5:
> > Failed to instantiate plugin org.apache.felix.webconsole.**
> > internal.compendium.**ComponentsServlet
> > java.lang.**NoClassDefFoundError: org.apache.felix.scr.**ScrService not
> > found by org.apache.karaf.webconsole.**console [73]
> > It's already a known issue (I raised a Jira for that). It's not a problem
> > on 2.2.5, but an issue that we have to address.
> > 2/ a warn on pax-web-jetty:
> > 2011-12-22 07:50:14,003 | WARN  | g.ops4j.pax.web) |
> > NIOSocketConnectorWrapper| ternal.**NIOSocketConnectorWrapper
> > 45 | 70 - org.ops4j.pax.web.pax-web-**jetty - 1.0.8 | Connection on port
> > 8181 cannot be open. Reason: Address already in use
> > Not a big deal, but something to fix in Pax Web.
> >
> > Regards
> > JB
> >
> >
> > On 12/22/2011 04:18 AM, Jamie G. wrote:
> >
> >> Hi,
> >>
> >> We resolved 54 issues in this release (web page will be published post
> >> RC promotion):
> >> https://svn.apache.org/repos/**asf/karaf/site/trunk/src/main/**
> >> webapp/index/community/**download/karaf-2.2.5-release.**page<
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.2.5-release.page
> >
> >>
> >> Staging repository:
> >> https://repository.apache.org/**content/repositories/**
> >> orgapachekaraf-382/<
> https://repository.apache.org/content/repositories/orgapachekaraf-382/>
> >>
> >> Release tags:
> >> https://svn.apache.org/repos/**asf/karaf/tags/karaf-2.2.5/<
> https://svn.apache.org/repos/asf/karaf/tags/karaf-2.2.5/>
> >>
> >> 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.
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>

Re: [PROPOSAL] Towards Karaf 3.0.0

[Bengt Rodehav]

Thanks JB - I just wanted to make sure that all use cases (especially mine
of course) are covered.

Looking forward to 3.0!

/Bengt

2011/7/12 Jean-Baptiste Onofré 

> Hi Bengt,
>
> Thanks for your reminder and your feedback about your Karaf usage.
>
> I also use Karaf as a pure container (used in Kalumet/AutoDeploy and
> BuildEraser), so I have the same concerns as yours :)
>
> I will plan your Jira on Karaf 3.0.0 as it parts of the
> profiles/distributions/KAR enhancements.
>
> Regards
> JB
>
>
>
> On Tue 12/07/11 10:28 , Bengt Rodehav  wrote::
>
> Just a little input from a humble user of Karaf...
>
> Karaf is not only used by other "projects" like ServiceMix and Geronimo. It
> is also used by end users like me. For me, Karaf is a deployment container
> I
> use to implement my products. I find it very hard to customize a Karaf
> server for the purposes of my product. I've created a couple of JIRA's
> regarding this already (which I think has been postphoned to Karaf 3.1).
>
> The way you describe KAR files sounds excellent to me. I could start with a
> fresh Karaf installation and then install a KAR file which will upgrade
> Karaf to become a container for my product. It would include all the
> necessary bundles as well as all the customization of Karaf needed. A dream
> come true.
>
> I realize that when adding configuration settings via a KAR file, there
> might be conflicts. Don't let this stop you from implementing this feature.
> A lot of use cases (like mine) would not have more than one KAR containing
> configuration settings anyway. Let's start by making that work and then (in
> the next release) make it possible to handle potentially conflicting
> configuration settings.
>
> Please don't target all efforts towards pleasing ServiceMix and Geronimo
> (although I do of course realize that is very important). Not every user of
> Karaf is a whole project with resources to customize Karaf (and do it again
> for every new release of Karaf...).
>
> /Bengt
>
>
>
> 2011/7/12 Andreas Pieber anpie...@gmail.com>
>
> > On Tue, Jul 12, 2011 at 8:33 AM, Charles Moulliard cmoulli...@gmail.com>
> > wrote:
> > > Hi,
> > >
> > > If we can with Karaf 3.x proposes a mechanism to upgrade platform from
> > > karaf 3.x to 3.y easily, that would be awesome and great. We are OSGI
> > > compliant but we don't use it internally to "patch/deploy hotfix" the
> > > platform.
> >
> > +1; I'm completely with your here!
> >
> > > This is a pitch. We do not need something very complex but a
> > > process which will deploy new jars files for the core and update
> > > config files. Then the question will be can we update config files
> > > when users modify them 
> >
> > Yeah, but to point out the core again: Look at the Apache SMX project
> > for example. There are a lot of modifications to Karaf and the config
> > files to make everything together nicely. Think about out target here:
> > The SMX assembly file should look something like (without the entire
> > mvn syntax by now):
> >
> > karaf-maven-plugin
> > assembe
> > cxf kar (as is from cxf project)
> > amq kar (as is from amq)
> > smx kar (as is from smx)
> >
> > Full stop; nothing else required *DREAMING* :)
> >
> > Kind regards,
> > Andreas
> >
> > >
> > > Just 2 cents
> > >
> > > Regards,
> > >
> > > Charles Moulliard
> > >
> > > Apache Committer
> > >
> > > Blog : http://cmoulliard.blogspot.com>
> > > Twitter : http://twitter.com/cmoulliard>
> > > Linkedin : http://www.linkedin.com/in/charlesmoulliard>
> > > Skype: cmoulliard
> > >
> > >
> > >
> > > On Tue, Jul 12, 2011 at 8:23 AM, Andreas Pieber anpie...@gmail.com>
> > wrote:
> > >> Hey David,
> > >>
> > >> On Tue, Jul 12, 2011 at 8:12 AM, David Jencks david_jen...@yahoo.com>
> > wrote:
> > >>> You can include replacement jre.properties and other properties files
> > in a kar that will overwrite the existing ones.  In any case you have to
> > restart the server to pick up the new files.
> > >>>
> > >>> However obviously you can only do this with one kar file before they
> > interfere.
> > >>
> > >> Yeah, exactly this is problem :(
> > >>
> > >>> Has anyone suggested a practical way to deal with this?
> > >>
> > >> Maybe prov

Re: [PROPOSAL] Towards Karaf 3.0.0

[Bengt Rodehav]

Just a little input from a humble user of Karaf...

Karaf is not only used by other "projects" like ServiceMix and Geronimo. It
is also used by end users like me. For me, Karaf is a deployment container I
use to implement my products. I find it very hard to customize a Karaf
server for the purposes of my product. I've created a couple of JIRA's
regarding this already (which I think has been postphoned to Karaf 3.1).

The way you describe KAR files sounds excellent to me. I could start with a
fresh Karaf installation and then install a KAR file which will upgrade
Karaf to become a container for my product. It would include all the
necessary bundles as well as all the customization of Karaf needed. A dream
come true.

I realize that when adding configuration settings via a KAR file, there
might be conflicts. Don't let this stop you from implementing this feature.
A lot of use cases (like mine) would not have more than one KAR containing
configuration settings anyway. Let's start by making that work and then (in
the next release) make it possible to handle potentially conflicting
configuration settings.

Please don't target all efforts towards pleasing ServiceMix and Geronimo
(although I do of course realize that is very important). Not every user of
Karaf is a whole project with resources to customize Karaf (and do it again
for every new release of Karaf...).

/Bengt



2011/7/12 Andreas Pieber 

> On Tue, Jul 12, 2011 at 8:33 AM, Charles Moulliard 
> wrote:
> > Hi,
> >
> > If we can with Karaf 3.x proposes a mechanism to upgrade platform from
> > karaf 3.x to 3.y easily, that would be awesome and great. We are OSGI
> > compliant but we don't use it internally to "patch/deploy hotfix" the
> > platform.
>
> +1; I'm completely with your here!
>
> > This is a pitch. We do not need something very complex but a
> > process which will deploy new jars files for the core and update
> > config files. Then the question will be can we update config files
> > when users modify them 
>
> Yeah, but to point out the core again: Look at the Apache SMX project
> for example. There are a lot of modifications to Karaf and the config
> files to make everything together nicely. Think about out target here:
> The SMX assembly file should look something like (without the entire
> mvn syntax by now):
>
> karaf-maven-plugin
> assembe
> cxf kar (as is from cxf project)
> amq kar (as is from amq)
> smx kar (as is from smx)
>
> Full stop; nothing else required *DREAMING* :)
>
> Kind regards,
> Andreas
>
> >
> > Just 2 cents
> >
> > Regards,
> >
> > Charles Moulliard
> >
> > Apache Committer
> >
> > Blog : http://cmoulliard.blogspot.com
> > Twitter : http://twitter.com/cmoulliard
> > Linkedin : http://www.linkedin.com/in/charlesmoulliard
> > Skype: cmoulliard
> >
> >
> >
> > On Tue, Jul 12, 2011 at 8:23 AM, Andreas Pieber 
> wrote:
> >> Hey David,
> >>
> >> On Tue, Jul 12, 2011 at 8:12 AM, David Jencks 
> wrote:
> >>> You can include replacement jre.properties and other properties files
> in a kar that will overwrite the existing ones.  In any case you have to
> restart the server to pick up the new files.
> >>>
> >>> However obviously you can only do this with one kar file before they
> interfere.
> >>
> >> Yeah, exactly this is problem :(
> >>
> >>> Has anyone suggested a practical way to deal with this?
> >>
> >> Maybe provide "extension points" in the configuration files? Maybe
> >> someone else has a more "ground-shaking suggestion"? :) But my guts
> >> say that this will be a VERY valuable feature for Karaf since it may
> >> be possible then to start an empty Karaf and simply "upgrade" it to
> >> SMX, or Geronimo or any parts of both you may like to have without
> >> ever toughing a text-editor and all those hassels about jre exports
> >> and bot delegation :(
> >>
> >> Thanks and kind regards,
> >> Andreas
> >>
> >>>
> >>> thanks!
> >>> david jencks
> >>>
> 
>  Kind regards,
>  Andreas
> 
>  On Tue, Jul 12, 2011 at 12:05 AM, David Jencks <
> david_jen...@yahoo.com> wrote:
> >
> > On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote:
> > 
> >
> >> * Karaf profiles & Kar files (IMHO this is one of the most important
> >> features for 3.x and not present in the issues by now; there had
> been
> >> considerable work on this by David, but still, we're missing a
> >> possibility to start e.g. CXF without modifying some files in etc)
> >
> > I'm really hoping that 3.0.0 will have the minimal and standard
> assemblies created using kars/features rather than the old style
> maven-assembly-plugin.  I haven't been able to work on this for a while but
> i thought I left it in a state as least as functional as the old-style
> servers.  The only bit I recall as missing is the legal files.
> >
> > What are you looking for to start e.g. cxf?  IIRC you can assemble a
> server including a cxf feature as a boot feature, or add it in later as a
> regular feature
> >
> >

Re: Problems with features startlevel

[Bengt Rodehav]

At first sight it sounds like the custom.properties file should help me with
a lot of the stuff I need. However, I have troubles getting it to work. Two
questions:

1. Can I specify additional system properties somewhere? Or perhaps an
additional location (except for system.properties) where I can put my custom
system.properties without having to modify system.propereties?

2. I'm trying to add cglib as a bundle to start initially without modifying
startup.properties. I then created a custom.properties file where I put the
following line:

*
> karaf.auto.start.40=org/apache/servicemix/bundles/org.apache.servicemix.bundles.cglib/2.1_3_4/org.apache.servicemix.bundles.cglib-2.1_3_4.jar
> *


But it doesn't work. On startup I get the following error message:

*Error installing bundle
>  org/apache/servicemix/bundles/org.apache.servicemix.bun
> dles.cglib/2.1_3_4/org.apache.servicemix.bundles.cglib-2.1_3_4.jar:
> java.lang.Ar
> rayIndexOutOfBoundsException: 1*


Also, the custom.properties that comes with Karaf is not empty. It contains
the following line:

*karaf.systemBundlesStartLevel=50*


If this is a default, then it shouldn't be in custom.properties. I think
custom.properties should be empty in the Karaf distribution. In fact one can
argue that the file shouldn't be included at all in the distribution and
that it should be created if any customisation is needed.

I think if I can avoid having to modify startup.properties and
system.properties and instead use custom.properties I can come a long way.
However, I can't presently see how that would solve the customisation of the
actual launching of Karaf/java (java options, console title etc). I think
also customisation of karaf-wrapper.conf is important since that's what I
really use and it contains a lot of things that Karaf needs mixed with stuff
that I need to customise.

/Bengt


2011/2/13 Guillaume Nodet 

> I'd like us to double check why the etc/custom.properties isn't
> sufficient, as that was the exact goal, i.e. an empty placeholder
> where one could easily define any overriden properties.  So we may
> want to improve / fix any problem there first
>
> On Sun, Feb 13, 2011 at 08:45,   wrote:
> > Quick update regarding your latest e-mail. I propose to upgrade the karaf
> > scripts (in the bin directory) to be able to read a file in the etc
> > directory (for instance etc/karaf.rc) in which you can put several custom
> > configuration (window title on windows, java options, karaf home,
> instances
> > name, etc). I have to think deeper about that but defintely it makes
> sense.
> > We already extended the branding.properties to allow users to customize
> the
> > karaf prompt in addition of the welcome message, so it's the same area of
> > customization.
> >
> > Regards
> > JB
> > 
> > From: Bengt Rodehav 
> > Sender: bengt.rode...@gmail.com
> > Date: Sat, 12 Feb 2011 20:11:45 +0100
> > To: ; 
> > Subject: Re: Problems with features startlevel
> > You're welcome. I think Karaf is an extremely versatile deployment
> platform
> > and I gladly contribute.
> > BTW, I haven't looked at exactly how ServiceMix customizes Karaf but I
> > imagine they customize quite a lot. A good criteria for good
> customisation
> > support might be when ServiceMix can use a new version of Karaf without
> > changing any of the files packaged with Karaf...
> > /Bengt
> >
> > 2011/2/12 
> >>
> >> Thanks Bengt for your complete feedback. I'm gonna raise some Jiras
> about
> >> that.
> >>
> >> Regards
> >> JB
> >> 
> >> From: Bengt Rodehav 
> >> Sender: bengt.rode...@gmail.com
> >> Date: Sat, 12 Feb 2011 16:57:38 +0100
> >> To: ; 
> >> ReplyTo: u...@karaf.apache.org
> >> Subject: Re: Problems with features startlevel
> >> Hello JB and Andreas,
> >> Just read the documentation about "custom distribution". Good
> >> documentation. It is very close to the way I handle things today. What I
> >> would like to avoid, however, is, e g having to edit
> >> system.properties/startup.properties everytime I upgrade to a new
> version of
> >> Karaf. I would prefer to keep them intact and instead put my custom
> system
> >> properties in a "custom_system.properties" and my extra bundles in a
> >> "custom_startup.properties", and so on. Why not one extra level of
> >> indirection? Karaf could allow the user to specify (e g in
> >> karaf-custom.cfg...) in what additional locations Karaf should look for
> >> additional 

Re: Web Console problem (Re: [VOTE] Release Karaf version 2.1.1)

[Bengt Rodehav]

Also looked at the http feature in Karaf 1.6.0 where I have never encounted
this problem. It looks like this:



  org.osgi.service.http.port=8181


 mvn:org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1.2

 
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jetty-bundle/6.1.22_1
mvn:org.ops4j.pax.web/pax-web-api/0.7.2
mvn:org.ops4j.pax.web/pax-web-spi/0.7.2
mvn:org.ops4j.pax.web/pax-web-runtime/0.7.2
mvn:org.ops4j.pax.web/pax-web-jetty/0.7.2


Still Jetty 6.1.22 but an older version of the ServiceMix wrapper (6.1.22_1
instead of 6.1.22_2) but in combination with pax-web 0.7.2.

/Bengt

2010/11/12 Bengt Rodehav 

> Guillaume,
>
> I'm not sure if this mail was meant for me. It seems like you started a new
> thread (which was wise).
>
> Anyway, no I think this is really strange. Like Richard pointed out, it
> seems like it's a JRE problem. Looking at the stacktrace it seems to involve
> calls from Jetty. I had been assuming that different versions of Jetty, by
> accident, is more or less prone to be exposed to this bug. If then pax-web
> uses different versions of Jetty then that could cause one version of
> pax-web to work and the other one to fail.
>
> Note that just because pax-web 0.7.2 seems to work for me, it doesn't mean
> that the same problem can't happen with 0.7.2. It might just not be as
> likely given my configuration.
>
> Why Equinox doesn't show this problem is a mystery to me. But if everything
> is about unlucky timing then I guess changing from Felix to Equinox probably
> changes the timing and maybe, by luck, the bug won't appear.
>
> Looking at the Karaf features file that comes from pax-web, the following
> features are listed in version 0.7.3:
>
>   
> mvn:org.mortbay.jetty/jetty-util/6.1.19
> mvn:org.mortbay.jetty/jetty/6.1.19
>   
>
>   
> mvn:org.mortbay.jetty/jetty-util/6.1.22
> mvn:org.mortbay.jetty/jetty/6.1.22
>   
>
> In version 0.7.2 only the 6.1.19 version is listed.
>
> However, looking at Karaf's own feature file that comes bundled with Karaf
> 2.1.0, the http feature looks like this:
>
> 
> 
> org.osgi.service.http.port=8181
> 
>
>  
> mvn:org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1.2
>
>  
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jetty-bundle/6.1.22_2
> mvn:org.ops4j.pax.web/pax-web-api/0.7.3
> mvn:org.ops4j.pax.web/pax-web-spi/0.7.3
> mvn:org.ops4j.pax.web/pax-web-runtime/0.7.3
> mvn:org.ops4j.pax.web/pax-web-jetty/0.7.3
> 
>
> So, it seems like the ServiceMix OSGi wrapper of Jetty 6.1.22 is being used
> regardless of what version of pax-web I use. Can't say this makes it any
> clearer - but it's interesting...
>
> Do you know why the ServiceMix wrapper is necessary. What about the one
> provided by Jetty (via pax-web feature file)? Is it not fit for OSGi?
>
> /Bengt
>
>
>
> 2010/11/12 Guillaume Nodet 
>
> If the pax-web 0.7.3 doesn't work and pax-web 0.7.2 seems to not have
>> that problem, have you tried to see what in pax-web could actually
>> cause the issue ?
>>
>> 2010/11/12 Łukasz Dywicki :
>> > +1 too :)
>> >
>> > -Original Message-
>> > From: James Strachan [mailto:james.strac...@gmail.com]
>> > Sent: Thursday, November 11, 2010 4:08 PM
>> > To: dev@karaf.apache.org
>> > Subject: Re: [VOTE] Release Karaf version 2.1.1
>> >
>> > +1
>> >
>> > On 10 November 2010 23:35, Jamie G.  wrote:
>> >> Hi,
>> >>
>> >> We resolved 16 issues in this release (may take some time for cwiki to
>> >> update with this page):
>> >> https://cwiki.apache.org/confluence/display/KARAF/Karaf+2.1.1+Release
>> >>
>> >> Staging repository:
>> >> https://repository.apache.org/content/repositories/orgapachekaraf-057/
>> >>
>> >> Release tags:
>> >> http://svn.apache.org/repos/asf/karaf/tags/karaf-2.1.1/
>> >>
>> >> 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.
>> >>
>> >
>> >
>> >
>> > --
>> > James
>> > ---
>> > FuseSource
>> > Email: ja...@fusesource.com
>> > Web: http://fusesource.com
>> > Twitter: jstrachan
>> > Blog: http://macstrac.blogspot.com/
>> >
>> > Open Source Integration
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> 
>> Blog: http://gnodet.blogspot.com/
>> 
>> Open Source SOA
>> http://fusesource.com
>>
>
>

Re: Web Console problem (Re: [VOTE] Release Karaf version 2.1.1)

[Bengt Rodehav]

Guillaume,

I'm not sure if this mail was meant for me. It seems like you started a new
thread (which was wise).

Anyway, no I think this is really strange. Like Richard pointed out, it
seems like it's a JRE problem. Looking at the stacktrace it seems to involve
calls from Jetty. I had been assuming that different versions of Jetty, by
accident, is more or less prone to be exposed to this bug. If then pax-web
uses different versions of Jetty then that could cause one version of
pax-web to work and the other one to fail.

Note that just because pax-web 0.7.2 seems to work for me, it doesn't mean
that the same problem can't happen with 0.7.2. It might just not be as
likely given my configuration.

Why Equinox doesn't show this problem is a mystery to me. But if everything
is about unlucky timing then I guess changing from Felix to Equinox probably
changes the timing and maybe, by luck, the bug won't appear.

Looking at the Karaf features file that comes from pax-web, the following
features are listed in version 0.7.3:

  
mvn:org.mortbay.jetty/jetty-util/6.1.19
mvn:org.mortbay.jetty/jetty/6.1.19
  

  
mvn:org.mortbay.jetty/jetty-util/6.1.22
mvn:org.mortbay.jetty/jetty/6.1.22
  

In version 0.7.2 only the 6.1.19 version is listed.

However, looking at Karaf's own feature file that comes bundled with Karaf
2.1.0, the http feature looks like this:



org.osgi.service.http.port=8181


 mvn:org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1.2

 
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jetty-bundle/6.1.22_2
mvn:org.ops4j.pax.web/pax-web-api/0.7.3
mvn:org.ops4j.pax.web/pax-web-spi/0.7.3
mvn:org.ops4j.pax.web/pax-web-runtime/0.7.3
mvn:org.ops4j.pax.web/pax-web-jetty/0.7.3


So, it seems like the ServiceMix OSGi wrapper of Jetty 6.1.22 is being used
regardless of what version of pax-web I use. Can't say this makes it any
clearer - but it's interesting...

Do you know why the ServiceMix wrapper is necessary. What about the one
provided by Jetty (via pax-web feature file)? Is it not fit for OSGi?

/Bengt



2010/11/12 Guillaume Nodet 

> If the pax-web 0.7.3 doesn't work and pax-web 0.7.2 seems to not have
> that problem, have you tried to see what in pax-web could actually
> cause the issue ?
>
> 2010/11/12 Łukasz Dywicki :
> > +1 too :)
> >
> > -Original Message-
> > From: James Strachan [mailto:james.strac...@gmail.com]
> > Sent: Thursday, November 11, 2010 4:08 PM
> > To: dev@karaf.apache.org
> > Subject: Re: [VOTE] Release Karaf version 2.1.1
> >
> > +1
> >
> > On 10 November 2010 23:35, Jamie G.  wrote:
> >> Hi,
> >>
> >> We resolved 16 issues in this release (may take some time for cwiki to
> >> update with this page):
> >> https://cwiki.apache.org/confluence/display/KARAF/Karaf+2.1.1+Release
> >>
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachekaraf-057/
> >>
> >> Release tags:
> >> http://svn.apache.org/repos/asf/karaf/tags/karaf-2.1.1/
> >>
> >> 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.
> >>
> >
> >
> >
> > --
> > James
> > ---
> > FuseSource
> > Email: ja...@fusesource.com
> > Web: http://fusesource.com
> > Twitter: jstrachan
> > Blog: http://macstrac.blogspot.com/
> >
> > Open Source Integration
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com
>

Re: [VOTE] Release Karaf version 2.1.1

[Bengt Rodehav]

Jamie,

I created the following ticket in JIRA:

https://issues.apache.org/jira/browse/KARAF-273

/Bengt

2010/11/12 Jamie G. 

> @Bengt  I'm sorry to hear that your encountering issues pax-web 0.7.3,
> could you raise on issue in Karaf's Jira for tracking this? While I
> don't think we'll roll back a version (trying to maintain
> dependencies), perhaps a new 0.8.x or 0.7.x series release of pax-web
> will resolve your issue and could be incorporated into a future Karaf
> patch?
>
> On Fri, Nov 12, 2010 at 8:11 AM, Hiram Chirino 
> wrote:
> > +1
> >
> > Regards,
> > Hiram
> >
> > FuseSource
> > Web: http://fusesource.com/
> >
> >
> >
> >
> > On Wed, Nov 10, 2010 at 6:35 PM, Jamie G. 
> wrote:
> >> Hi,
> >>
> >> We resolved 16 issues in this release (may take some time for cwiki to
> >> update with this page):
> >> https://cwiki.apache.org/confluence/display/KARAF/Karaf+2.1.1+Release
> >>
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachekaraf-057/
> >>
> >> Release tags:
> >> http://svn.apache.org/repos/asf/karaf/tags/karaf-2.1.1/
> >>
> >> 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.
> >>
> >
>

Re: [VOTE] Release Karaf version 2.1.1

[Bengt Rodehav]

I noticed that Karaf 2.1.1 still uses pax-web 0.7.3 (as Karaf 2.1.0 did). I
have great problems using pax-web 0.73 (and 0.8.0 which was recently
released). I don't know where the problems lies but staying with pax-web
0.7.2 seems to temporarily solve the problem - maybe Karaf should consider
doing that.

There is a thread at the Felix user list about this:

http://old.nabble.com/Web-console-issues-td30106481.html

and it is also
discussed in the following JIRA:

https://issues.apache.org/jira/browse/FELIX-1032

/Bengt

2010/11/11 Jamie G. 

> Hi,
>
> We resolved 16 issues in this release (may take some time for cwiki to
> update with this page):
> https://cwiki.apache.org/confluence/display/KARAF/Karaf+2.1.1+Release
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-057/
>
> Release tags:
> http://svn.apache.org/repos/asf/karaf/tags/karaf-2.1.1/
>
> 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.
>