Karaf Feature vs. OBR

[David Leangen]

Hi!

I am trying to wrap my head around the differences between an OBR and a Karaf 
Feature. The concepts seem to be overlapping.

An OBR has an index of the contained bundles, as well as meta information, 
which includes requirements and capabilities. An OBR is therefore very useful 
for resolving bundles, and partitioning bundles into some kind of category. It 
can also be versioned, and can contained different versions of bundles. An OBR 
could potentially be used to keep snapshots of system releases. I believe that 
this is somewhat how Apache ACE works. (A Distribution can be rolled back by 
simply referring to a different OBR and allowing the system to re-resolve.) The 
actual bundles need to be stored somewhere. The OBR index needs to provide 
links to that storage.

A Karaf Feature is basically an index of bundles (and configurations), too. I 
think that it can also be versioned, and can contain different versions of 
bundles. Like an OBR, it is very useful for partitioning bundles into some kind 
of category, so the groups of bundles can be manipulated as a single unit. Just 
like an OBR, the Karaf Feature also needs to provide a link to the bundles. 
AFAIU, resolution is done somehow in Karaf, based on the bundles available via 
the Features, so in the end the entire mechanism seems almost identical to what 
the OBR is doing.


So many similarities!


I understand that a Feature can include configurations, which is nice, but why 
have a competing non-official standard against an official standard? If 
configurations is the only problem, then why not build it on top of OBRs, 
rather than creating something completely new and different and competing?

Is it to try to force lock-in to Karaf? Or am I completely missing something?


Thanks for explaining! :-)


Cheers,
=David

Re: org.ops4j.pax.url.wrap/2.5.2 missing org.slf4j package?

[Achim Nierbeck]

Thank good for Karaf features, I don't actually have to "FIX" a bundle
(like re-invent the world a second time) [1]
I just need to make sure the feature declares a capability that a bundle
"should" have, though
I've to admit that those requirements added by bnd is actually more
hindering then helpful.

regards, Achim

[1] -
https://github.com/ops4j/org.ops4j.pax.web/commit/72935c741bf76fc2397253d3cba4f9a9b712cee8


2017-06-13 23:16 GMT+02:00 :

> > the easiest would be to actually remove that "new" requirement for those
> > components.
> > A fix for this is on it's way for Pax Web, so you'll have something
> that'll
> > work for you.
>
> Sorry Achim, you'll need to spell that out. What is that you'd fix? Create
> a pax-web bundle that contains and exports the javax.servlet packages?
>
> Thanks in advance of the fix though.
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: org.ops4j.pax.url.wrap/2.5.2 missing org.slf4j package?

[tom]

> the easiest would be to actually remove that "new" requirement for those
> components.
> A fix for this is on it's way for Pax Web, so you'll have something that'll
> work for you.

Sorry Achim, you'll need to spell that out. What is that you'd fix? Create a 
pax-web bundle that contains and exports the javax.servlet packages?

Thanks in advance of the fix though.

Re: org.ops4j.pax.url.wrap/2.5.2 missing org.slf4j package?

[Achim Nierbeck]

Tom,

the easiest would be to actually remove that "new" requirement for those
components.
A fix for this is on it's way for Pax Web, so you'll have something that'll
work for you.

regards, Achim


2017-06-13 19:40 GMT+02:00 :

>
> I'm trying to build a custom karaf distribution with the "karaf-assembly"
> maven packaging.
> I am making slow progress :-)
>
> My latest issue comes about through trying to resolve lack of a
> javax.servlet package requirement.
> So I naively included the org.apache.felix:org.apache.felix.http.servlet-api
> bundle as a dependency of the feature I'm including in my assembly. This is
> what we normally use in development in bndtools, but we normally use apache
> felix HTTP rather than pax-web generally.
>
> As soon as I do that I get an odd build failure:
> Unable to resolve org.ops4j.pax.url.wrap/2.5.2: missing requirement
> [org.ops4j.pax.url.wrap/2.5.2] osgi.wiring.package; filter:="(&(osgi.wiring.
> package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]
>
> If I remove org.apache.felix.http.servlet-api it builds, and I can run
> the resulting karaf. My karaf shell fu isn't that great, but feature:list
> shows me that "wrap" is "started", and
>   bundle:info mvn:org.ops4j.pax.url/pax-url-wrap/2.5.2/jar/uber
> shows me that it imports the org.slf4j package. I don't know how to find
> out where it resolves that from from the shell, but the web console shows
> me:
>
> Imported Packages
> org.slf4j,version=1.7.25 from org.ops4j.pax.logging.pax-logging-api (5)
> org.slf4j,version=1.6.6 from org.ops4j.pax.logging.pax-logging-api (5)
> org.slf4j,version=1.5.11 from org.ops4j.pax.logging.pax-logging-api (5)
> org.slf4j,version=1.4.3 from org.ops4j.pax.logging.pax-logging-api (5)
>
> So I don't understand why I'm suddenly getting a resolution failure for
> slf4j from pax.url.wrap.
>
> I also don't understand why including 
> org.apache.felix:org.apache.felix.http.servlet-api
> suddenly causes this, nothing in the manifest for it would appear to
> indicate a need for it. All it is is a simple bundle that contains and
> exports the javax.servlet api.
>
> To sidestep the the question, how *should* I resolve the requirement for
> javax.servlet package? There doesn't seem to be a pax-web bundle that I can
> find that provides the javax.servlet package.
>
> Thanks (again).
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

org.ops4j.pax.url.wrap/2.5.2 missing org.slf4j package?

[tom]

I'm trying to build a custom karaf distribution with the "karaf-assembly" maven 
packaging. 
I am making slow progress :-)

My latest issue comes about through trying to resolve lack of a javax.servlet 
package requirement. 
So I naively included the org.apache.felix:org.apache.felix.http.servlet-api 
bundle as a dependency of the feature I'm including in my assembly. This is 
what we normally use in development in bndtools, but we normally use apache 
felix HTTP rather than pax-web generally.

As soon as I do that I get an odd build failure:
Unable to resolve org.ops4j.pax.url.wrap/2.5.2: missing requirement 
[org.ops4j.pax.url.wrap/2.5.2] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]

If I remove org.apache.felix.http.servlet-api it builds, and I can run the 
resulting karaf. My karaf shell fu isn't that great, but feature:list shows me 
that "wrap" is "started", and
  bundle:info mvn:org.ops4j.pax.url/pax-url-wrap/2.5.2/jar/uber
shows me that it imports the org.slf4j package. I don't know how to find out 
where it resolves that from from the shell, but the web console shows me:

Imported Packages
org.slf4j,version=1.7.25 from org.ops4j.pax.logging.pax-logging-api (5)
org.slf4j,version=1.6.6 from org.ops4j.pax.logging.pax-logging-api (5)
org.slf4j,version=1.5.11 from org.ops4j.pax.logging.pax-logging-api (5)
org.slf4j,version=1.4.3 from org.ops4j.pax.logging.pax-logging-api (5)

So I don't understand why I'm suddenly getting a resolution failure for slf4j 
from pax.url.wrap.

I also don't understand why including 
org.apache.felix:org.apache.felix.http.servlet-api suddenly causes this, 
nothing in the manifest for it would appear to indicate a need for it. All it 
is is a simple bundle that contains and exports the javax.servlet api.

To sidestep the the question, how *should* I resolve the requirement for 
javax.servlet package? There doesn't seem to be a pax-web bundle that I can 
find that provides the javax.servlet package.

Thanks (again).

Re: Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[tom]

> On 13 June 2017 at 16:50 Jean-Baptiste Onofré  wrote:
> 
> 
> Yeah, you have to add the snapshot repository in your pom.xml:
OK, yes, that's better.
Thanks.


Now all I need to do is work out why I can't apparently satisfy 
   (&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))"
despite Karaf including SCR. 

Hmm. Karaf seems to have SCR 2.0.10. I don't know why I need <2, it's just what 
bndtools builds in as a requirement. Ah, confusion between API version and 
software version. 
from Karaf console, bundle:headers on felix.scr:
   
osgi.extender;uses:=org.osgi.service.component;osgi.extender=osgi.component;version:Version=1.3
which is presumably what the requirement is referencing, so that ought to be 
satisfied.

So no idea why that requirement can't be satisfied.
Anyway, that's for tomorrow.

Thanks.

Re: Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[tom]

Windows, yes.

> On 13 June 2017 at 15:51 Jean-Baptiste Onofré  wrote:
> 
> 
> By the way, are you on Windows ?
> 
> Regards
> JB
> 
> On 06/13/2017 04:44 PM, t...@quarendon.net wrote:
> > 
> >> On 13 June 2017 at 15:02 Jean-Baptiste Onofré  wrote:
> >>
> >>
> >> Hi Tom
> >>
> >> It has been fixed and will be included in 4.1.2.
> >>
> > Ah, good. 4.1 seems unusable as far as I can see otherwise.
> > 
> > I've been looking around, but I can't find where I might get a snapshot 
> > build from, what repository I would need to point at?
> > 
> > Sorry for all the questions. I have more!
> > Thanks.
> > 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[Jean-Baptiste Onofré]

Yeah, you have to add the snapshot repository in your pom.xml:




apache-snapshots
Apache Snapshots Repository

http://repository.apache.org/content/groups/snapshots-group

false


true


   

Regards
JB

On 06/13/2017 05:49 PM, t...@quarendon.net wrote:



On 13 June 2017 at 15:50 Jean-Baptiste Onofré  wrote:


Do you have a chance to test with 4.1.2-SNAPSHOT ?


That's what I'm wanting to do, I just can't work out where to get it. I naively 
put
4.1.2-SNAPSHOT
as my karaf version in the pom, but it doesn't find it, as I presumably need to 
point at a snapshot repository somewhere. That was really my question. What URL 
should I use for the snapshot URL?

Thanks.



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

Re: Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[tom]

> On 13 June 2017 at 15:50 Jean-Baptiste Onofré  wrote:
> 
> 
> Do you have a chance to test with 4.1.2-SNAPSHOT ?

That's what I'm wanting to do, I just can't work out where to get it. I naively 
put 
4.1.2-SNAPSHOT
as my karaf version in the pom, but it doesn't find it, as I presumably need to 
point at a snapshot repository somewhere. That was really my question. What URL 
should I use for the snapshot URL? 

Thanks.

Warning exception when launching Karaf client

[Leschke, Scott]

I see the following in the log when I start a client session on Windows. The 
client appears to be working OK but it seems like this is an issue.

2017-06-13T10:04:43,086 | WARN  | sshd-SshServer[6c21e678]-nio2-thread-3 |  
| 49 - org.jline - 3.2.0 | Unable to retrieve 
infocmp for type dummy
java.io.IOException: Cannot run program "infocmp": CreateProcess error=2, The 
system cannot find the file specified
  at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) ~[?:?]
  at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:547) ~[?:?]
  at 
org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:156)
 ~[?:?]
  at 
org.jline.terminal.impl.LineDisciplineTerminal.(LineDisciplineTerminal.java:101)
 ~[?:?]
  at 
org.jline.terminal.impl.ExternalTerminal.(ExternalTerminal.java:48) ~[?:?]
  at 
org.jline.terminal.impl.ExternalTerminal.(ExternalTerminal.java:40) ~[?:?]
  at org.apache.karaf.shell.ssh.SshTerminal.(SshTerminal.java:43) 
~[?:?]
  at 
org.apache.karaf.shell.ssh.ShellFactoryImpl$ShellImpl.start(ShellFactoryImpl.java:103)
 ~[?:?]
  at 
org.apache.sshd.server.channel.ChannelSession.sendResponse(ChannelSession.java:363)
 ~[47:org.apache.sshd.core:1.4.0]

Re: Understanding features and dependencies

[Achim Nierbeck]

Regarding the capabilities,

both.
It's determined by A) the bundles manifest entry. But in certain cases
those bundles don't explicit describe their capabilities fully.
In those cases it helps if the feature itself does describe that
capability.

regards, Achim


2017-06-13 13:55 GMT+02:00 Stephen Kitt :

> Hi Jean-Baptiste,
>
> On Tue, 13 Jun 2017 10:41:26 +0200
> Jean-Baptiste Onofré  wrote:
> > I think there's two questions:
> >
> > 1. Why does a refresh happen ?
> > A refresh can happen for instance when an optional import is resolved
> > (when installing a feature or a bundle) or when a new package version
> > is installed matching a version range.
> > So, especially in the case of optional import, you should check the
> > import of your bundle.
>
> OK, thanks.
>
> > 2. Why does your bundle not able to refresh ?
> > That's probably the most important. Maybe, you keep the bundle
> > context as member of a class and so it becomes invalid after the
> > refresh.
>
> That’s possible in some cases. Our main issue is that some of our
> bundles maintain state and don’t really like being stopped and started
> (in particular, our persistence bundles and our clustering bundles).
>
> > Before dealing with dependency or prerequisite, I would start to
> > address those points.
> >
> > The dependency flag is not a "complete" inner feature, so it's normal
> > that the feature is not installed if another one already provides the
> > corresponding capabilities.
>
> OK. Are capabilities here determined by explicit 
> declarations in the feature XML, or are they based on bundle manifest
> declarations?
>
> Regards,
>
> Stephen
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[Jean-Baptiste Onofré]

Do you have a chance to test with 4.1.2-SNAPSHOT ?

Thanks !
Regards
JB

On 06/13/2017 04:44 PM, t...@quarendon.net wrote:



On 13 June 2017 at 15:02 Jean-Baptiste Onofré  wrote:


Hi Tom

It has been fixed and will be included in 4.1.2.


Ah, good. 4.1 seems unusable as far as I can see otherwise.

I've been looking around, but I can't find where I might get a snapshot build 
from, what repository I would need to point at?

Sorry for all the questions. I have more!
Thanks.



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

Re: Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[Jean-Baptiste Onofré]

By the way, are you on Windows ?

Regards
JB

On 06/13/2017 04:44 PM, t...@quarendon.net wrote:



On 13 June 2017 at 15:02 Jean-Baptiste Onofré  wrote:


Hi Tom

It has been fixed and will be included in 4.1.2.


Ah, good. 4.1 seems unusable as far as I can see otherwise.

I've been looking around, but I can't find where I might get a snapshot build 
from, what repository I would need to point at?

Sorry for all the questions. I have more!
Thanks.



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

Re: Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[tom]

> On 13 June 2017 at 15:02 Jean-Baptiste Onofré  wrote:
> 
> 
> Hi Tom
> 
> It has been fixed and will be included in 4.1.2.
> 
Ah, good. 4.1 seems unusable as far as I can see otherwise.

I've been looking around, but I can't find where I might get a snapshot build 
from, what repository I would need to point at?

Sorry for all the questions. I have more!
Thanks.

Re: Exception starting karaf custom distro "minimal example" from docs

[Achim Nierbeck]

regarding your "maven" confidence ... do you happen to have a "Proxy"
connected to your maven setup?
In rare cases, or flaky internet connections your bundles might not have
been a jar at all, but a http error code ;)
This happens in rare cases.
Best to do a mvn clean install -U for updating all dependencies.

regards, Achim


2017-06-13 15:26 GMT+02:00 :

> > On 13 June 2017 at 12:32 Jean-Baptiste Onofré  wrote:
> >
> >
> > I don't understand why you have the pax-web feature.
> >
> > Do you have it defined in bootFeatures ? Or do you install it by hand ?
> >
> > I can confirm that I don't have pax-web feature on my custom distro.
>
> So I created a completely fresh directory, deleted the contents of my .m2
> maven repository cache, created a pom.xml file with your example contents
> in, and ran "mvn clean install".
>
> I ran target/assembly/bin/karaf.bat.
> feature:list then lists pax-http as "started".
>
> Interestingly though I have no exceptions in the log file.
>
> Well that's interesting.
> Worryingly, deleting my .m2 directory contents seems to have altered the
> behaviour. Going back to my original example, it now works closer to how I
> would expect.
> I admit my knowledge of Maven is low, but it's a cache isn't it?
> Re-downloading the dependencies ought not to have changed anything? That
> worries me.
>
> The good news is that this seems to have fixed things. I no longer have
> odd exceptions in the log.
>
> Confidence in Karaf has increased, confidence in maven lowered!
> Thanks for the help.
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[Jean-Baptiste Onofré]

Hi Tom

It has been fixed and will be included in 4.1.2.

Regards
JB

On 06/13/2017 03:51 PM, t...@quarendon.net wrote:

Start up Karaf with the "bin/karaf.bat" shell script.

At the console type
help bundle:info
You get:
gogo: NullPointerException: "in" is null!

If I run this from the official 4.1.1 install, it looks like this is trying to 
"more" the help contents or something. I get a colon, and if you press q it 
goes back to the prompt. You get no help output though. If I do the same on 4.0.6, I get 
paginated help out, so something has changed there.

Run this from a "custom assembly" consisting of the "standard" feature, and I 
get:


2017-06-13T14:33:11,173 | ERROR | Karaf local console user karaf | ShellUtil
| 55 - org.apache.karaf.shell.core - 4.1.1 | Exception 
caught while executing command
java.lang.NumberFormatException: For input string: "43B"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
~[?:?]
at java.lang.Integer.parseInt(Integer.java:580) [?:?]
at java.lang.Integer.(Integer.java:867) [?:?]
at 
org.fusesource.jansi.AnsiOutputStream.write(AnsiOutputStream.java:122) 
[86:org.fusesource.jansi:1.14.0]
at java.io.FilterOutputStream.write(FilterOutputStream.java:125) [?:?]
at 
java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458) 
[?:?]
at org.apache.felix.gogo.runtime.Pipe$MultiChannel.write(Pipe.java:644) 
[55:org.apache.karaf.shell.core:4.1.1]
at java.nio.channels.Channels.writeFullyImpl(Channels.java:78) [?:?]
at java.nio.channels.Channels.writeFully(Channels.java:101) [?:?]
at java.nio.channels.Channels.access$000(Channels.java:61) [?:?]
at java.nio.channels.Channels$1.write(Channels.java:174) [?:?]
at java.io.PrintStream.write(PrintStream.java:480) [?:?]
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [?:?]
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) 
[?:?]
at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) [?:?]
at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) 
[?:?]
at java.io.PrintStream.write(PrintStream.java:527) [?:?]
at java.io.PrintStream.print(PrintStream.java:669) [?:?]
at java.io.PrintStream.println(PrintStream.java:806) [?:?]
at org.apache.felix.gogo.jline.Posix._main(Posix.java:128) 
[55:org.apache.karaf.shell.core:4.1.1]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:?]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:497) ~[?:?]
at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:136) 
[55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand.lambda$wrap$0(SessionFactoryImpl.java:195)
 [55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand$$Lambda$37/1313854807.execute(Unknown
 Source) [55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand.execute(SessionFactoryImpl.java:241)
 [55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
 [55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
 [55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560) 
[55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:486) 
[55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375) 
[55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417) 
[55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) 
[55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) 
[55:org.apache.karaf.shell.core:4.1.1]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[?:?]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
2017-06-13T14:33:11,177 | ERROR | Karaf local console user karaf | ShellUtil
| 55 - org.apache.karaf.shell.core - 4.1.1 | Exception 
caught while executing command
java.lang.NumberFormatException: For input 

Karaf termination caused by typing something incorrect on the gogo shell in 4.1.1

[tom]

Start up Karaf with the "bin/karaf.bat" shell script.

At the console type
help bundle:info
You get:
gogo: NullPointerException: "in" is null!

If I run this from the official 4.1.1 install, it looks like this is trying to 
"more" the help contents or something. I get a colon, and if you press q it 
goes back to the prompt. You get no help output though. If I do the same on 
4.0.6, I get paginated help out, so something has changed there.

Run this from a "custom assembly" consisting of the "standard" feature, and I 
get:


2017-06-13T14:33:11,173 | ERROR | Karaf local console user karaf | ShellUtil
| 55 - org.apache.karaf.shell.core - 4.1.1 | Exception 
caught while executing command
java.lang.NumberFormatException: For input string: "43B"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
~[?:?]
at java.lang.Integer.parseInt(Integer.java:580) [?:?]
at java.lang.Integer.(Integer.java:867) [?:?]
at 
org.fusesource.jansi.AnsiOutputStream.write(AnsiOutputStream.java:122) 
[86:org.fusesource.jansi:1.14.0]
at java.io.FilterOutputStream.write(FilterOutputStream.java:125) [?:?]
at 
java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458) 
[?:?]
at org.apache.felix.gogo.runtime.Pipe$MultiChannel.write(Pipe.java:644) 
[55:org.apache.karaf.shell.core:4.1.1]
at java.nio.channels.Channels.writeFullyImpl(Channels.java:78) [?:?]
at java.nio.channels.Channels.writeFully(Channels.java:101) [?:?]
at java.nio.channels.Channels.access$000(Channels.java:61) [?:?]
at java.nio.channels.Channels$1.write(Channels.java:174) [?:?]
at java.io.PrintStream.write(PrintStream.java:480) [?:?]
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [?:?]
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) 
[?:?]
at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) [?:?]
at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) 
[?:?]
at java.io.PrintStream.write(PrintStream.java:527) [?:?]
at java.io.PrintStream.print(PrintStream.java:669) [?:?]
at java.io.PrintStream.println(PrintStream.java:806) [?:?]
at org.apache.felix.gogo.jline.Posix._main(Posix.java:128) 
[55:org.apache.karaf.shell.core:4.1.1]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:?]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:497) ~[?:?]
at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:136) 
[55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand.lambda$wrap$0(SessionFactoryImpl.java:195)
 [55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand$$Lambda$37/1313854807.execute(Unknown
 Source) [55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand.execute(SessionFactoryImpl.java:241)
 [55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
 [55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
 [55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560) 
[55:org.apache.karaf.shell.core:4.1.1]
at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:486) 
[55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375) 
[55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417) 
[55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) 
[55:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) 
[55:org.apache.karaf.shell.core:4.1.1]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[?:?]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
2017-06-13T14:33:11,177 | ERROR | Karaf local console user karaf | ShellUtil
| 55 - org.apache.karaf.shell.core - 4.1.1 | Exception 
caught while executing command
java.lang.NumberFormatException: For input string: "43BF"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
~[?:?]

Re: Exception starting karaf custom distro "minimal example" from docs

[tom]

> On 13 June 2017 at 12:32 Jean-Baptiste Onofré  wrote:
> 
> 
> I don't understand why you have the pax-web feature.
> 
> Do you have it defined in bootFeatures ? Or do you install it by hand ?
> 
> I can confirm that I don't have pax-web feature on my custom distro.

So I created a completely fresh directory, deleted the contents of my .m2 maven 
repository cache, created a pom.xml file with your example contents in, and ran 
"mvn clean install".

I ran target/assembly/bin/karaf.bat.
feature:list then lists pax-http as "started".

Interestingly though I have no exceptions in the log file.

Well that's interesting. 
Worryingly, deleting my .m2 directory contents seems to have altered the 
behaviour. Going back to my original example, it now works closer to how I 
would expect. 
I admit my knowledge of Maven is low, but it's a cache isn't it? Re-downloading 
the dependencies ought not to have changed anything? That worries me.

The good news is that this seems to have fixed things. I no longer have odd 
exceptions in the log.

Confidence in Karaf has increased, confidence in maven lowered!
Thanks for the help.

JDBC Pool problem

[Bellski]

Hello. Can't understand how to make pooled datasource.

installed pax-jdbc-pool-dbcp2, pax-jdbc-config and etc

I make org.ops4j.pool.datasource-db.cfg
osgi.jdbc.driver.name = PostgreSQL JDBC Driver-pool
dataSourceName=db
serverName = localhost
portNumber = 5432
databaseName = db
user = user
password = user


and nothing

2017-06-13T15:45:13,717 | INFO  |
fileinstall-E:\projects\cas_10_02_2017\tool\ae-karaf\karaf\target\assembly\etc
| fileinstall  | 6 - org.apache.felix.fileinstall -
3.5.8 | Creating configuration from org.ops4j.pool.datasource-cas2db.cfg

I read this post 
http://karaf.922171.n3.nabble.com/Problem-with-Karaf-4-0-3-and-Postgres-db-td4044862.html
did the same and nothing ;/







--
View this message in context: 
http://karaf.922171.n3.nabble.com/JDBC-Pool-problem-tp4050699.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Understanding features and dependencies

[Stephen Kitt]

Hi Jean-Baptiste,

On Tue, 13 Jun 2017 10:41:26 +0200
Jean-Baptiste Onofré  wrote:
> I think there's two questions:
> 
> 1. Why does a refresh happen ?
> A refresh can happen for instance when an optional import is resolved
> (when installing a feature or a bundle) or when a new package version
> is installed matching a version range.
> So, especially in the case of optional import, you should check the
> import of your bundle.

OK, thanks.

> 2. Why does your bundle not able to refresh ?
> That's probably the most important. Maybe, you keep the bundle
> context as member of a class and so it becomes invalid after the
> refresh.

That’s possible in some cases. Our main issue is that some of our
bundles maintain state and don’t really like being stopped and started
(in particular, our persistence bundles and our clustering bundles).

> Before dealing with dependency or prerequisite, I would start to
> address those points.
> 
> The dependency flag is not a "complete" inner feature, so it's normal
> that the feature is not installed if another one already provides the
> corresponding capabilities.

OK. Are capabilities here determined by explicit 
declarations in the feature XML, or are they based on bundle manifest
declarations?

Regards,

Stephen


pgptsVxyK9vd6.pgp
Description: OpenPGP digital signature

Re: Understanding features and dependencies

[Stephen Kitt]

On Tue, 13 Jun 2017 13:27:24 +0200
Guillaume Nodet  wrote:
> 2017-06-13 10:35 GMT+02:00 Stephen Kitt :
> > As we understand things (and this is the main point I would like to
> > clarify), in Karaf 4, based on the feature declaration above:
> > * (re)starting odl-ttp-model-rest would restart odl-ttp-model,
> >   odl-mdsal-apidocs etc. (which is a problem because e.g.
> >   odl-mdsal-broker is very likely to already be running when we
> > install another feature)
> > * adding “dependency="true"” would disable this
> > * adding “prerequisite="true"” would also disable this, and ensure
> > that the corresponding feature is started before odl-ttp-model-rest
> 
> That's wrong.  There's no relationship between how a feature is
> defined and the bundle being refreshed when the feature is installed.
> A bundle will be refreshed if:
>   * it has been updated
>   * it has been uninstalled
>   * one of its dependencies is refreshed
>   * a new optional dependency has been installed

OK, thanks, so reasoning about refreshes only makes sense at the bundle
level and features should only be considered as defining groups of
bundles, with no impact on refresh “propagation”. Is that right?

What exactly do “dependency="true"” and “prerequisite="true"” do? The
documentation isn’t very clear on this, and trying to extrapolate rules
based on behaviour obviously isn’t productive ;-).

> When installing feature, you can use the --verbose flag which will
> print why bundles are being refreshed.

Yes, I’ve been using that quite a bit.

This leads me to a follow-on: given the above refresh rules, why would
installing the *same* feature twice in a row cause some of its bundles
to be refreshed? Can wrapped bundles wreak havoc here? I’m seeing stuff
like

Refreshing bundles:
com.fasterxml.jackson.datatype.jackson-datatype-json-org/2.3.2
(Should be wired to:
org.opendaylight.netconf.sal-rest-docgen/1.6.0.SNAPSHOT (through
[com.fasterxml.jackson.datatype.jackson-datatype-json-org/2.3.2]
osgi.wiring.package; filter:="(osgi.wiring.package=org.json)"))

and further down

org.opendaylight.netconf.sal-rest-docgen/1.6.0.SNAPSHOT (Wired to
com.fasterxml.jackson.datatype.jackson-datatype-json-org/2.3.2
which is being refreshed)

which suggests there’s a wiring loop — could it be related to wrapping
org.json?

Regards,

Stephen


pgpek40LDADMo.pgp
Description: OpenPGP digital signature

Re: Exception starting karaf custom distro "minimal example" from docs

[Jean-Baptiste Onofré]

I don't understand why you have the pax-web feature.

Do you have it defined in bootFeatures ? Or do you install it by hand ?

I can confirm that I don't have pax-web feature on my custom distro.

Regards
JB

On 06/13/2017 11:13 AM, t...@quarendon.net wrote:



On 13 June 2017 at 09:08 Jean-Baptiste Onofré  wrote:


Hi Tom,

Here's a pom.xml to do what you want:


As far as I can see that's the same as the "minimal example" in the docs.
If I use your example, I still get errors:

2017-06-13T09:46:01,692 | ERROR | FelixDispatchQueue | 
pax-web-extender-whiteboard  | 118 - 
org.ops4j.pax.web.pax-web-extender-whiteboard - 6.0.3 | FrameworkEvent ERROR - 
org.ops4j.pax.web.pax-web-extender-whiteboard
org.osgi.framework.BundleException: Activator start error in bundle 
org.ops4j.pax.web.pax-web-extender-whiteboard [118].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2288) 
[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) [?:?]
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371) [?:?]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
 [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
Caused by: java.lang.ClassCastException: 
org.apache.felix.httplite.osgi.HttpServiceImpl cannot be cast to 
org.osgi.service.http.HttpService

and
2017-06-13T09:50:23,076 | ERROR | paxweb-config-2-thread-1 | Felix  
  |  -  -  | Bundle org.apache.felix.inventory [36] 
EventDispatcher: Error during dispatch. (java.lang.ClassCastException: 
org.apache.felix.httplite.osgi.HttpServiceImpl cannot be cast to 
org.osgi.service.http.HttpService)

and

2017-06-13T09:50:23,076 | ERROR | FelixDispatchQueue | inventory
| 36 - org.apache.felix.inventory - 1.0.4 | FrameworkEvent ERROR - 
org.apache.felix.inventory
java.lang.ClassCastException: org.apache.felix.httplite.osgi.HttpServiceImpl 
cannot be cast to org.osgi.service.http.HttpService

etc.

The "javax.servlet two chains" issue has gone. However that comes back if I specify "enterprise" instead of 
"standard" in my "bootFeatures" (investigating I had a "org.apache.karaf.features.cfg" file that 
specified some things that I had inherited from another example -- deleted that now).


This clearly indicates to be that there are just some incompatible bundles 
there. org.ops4j.pax.web.pax-web-extender-whiteboard is expecting 
org.apache.felix.httplite.osgi.HttpServiceImpl to be a 
org.osgi.service.http.HttpService when it's not, or at least not the same 
org.osgi.service.http.HttpService class.


Closing Karaf down and then starting it up again though, it still just hangs 
with no output of any kind, no logging.



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

Re: Understanding features and dependencies

[Guillaume Nodet]

2017-06-13 10:35 GMT+02:00 Stephen Kitt :

> Hi,
>
> As we continue to try to migrate OpenDaylight to Karaf 4, it’s become
> very clear that we need to understand exactly what feature dependencies
> entail. (And yes, I’ll submit documentation patches once we’ve done
> so.)
>
> OpenDaylight (ODL) defines lots and lots of features, some of which
> contain bundles which survive refreshes, many of which don’t. In
> real-world deployments, the Karaf distributions which are built tend to
> use boot features to start the features they’re interested in. We make
> extensive use of feature dependencies of course, e.g.
>
> 
> odl-ttp-model
> odl-mdsal-apidocs
> odl-restconf
> odl-mdsal-broker
> 
>
> In Karaf 3 all this works fine.
>
> In Karaf 4 we’re having lots of issues related to bundle refreshes, so
> we’ve been trying to figure out how to avoid them. Of course,
> “feature:install --no-auto-refresh” works, but that’s not ideal (at
> least, I don’t think it is). We thought perhaps using the dependency or
> prerequisite attributes might help.
>
> As we understand things (and this is the main point I would like to
> clarify), in Karaf 4, based on the feature declaration above:
> * (re)starting odl-ttp-model-rest would restart odl-ttp-model,
>   odl-mdsal-apidocs etc. (which is a problem because e.g.
>   odl-mdsal-broker is very likely to already be running when we install
>   another feature)
> * adding “dependency="true"” would disable this
> * adding “prerequisite="true"” would also disable this, and ensure that
>   the corresponding feature is started before odl-ttp-model-rest
>

That's wrong.  There's no relationship between how a feature is defined and
the bundle being refreshed when the feature is installed.
A bundle will be refreshed if:
  * it has been updated
  * it has been uninstalled
  * one of its dependencies is refreshed
  * a new optional dependency has been installed

When installing feature, you can use the --verbose flag which will print
why bundles are being refreshed.


>
> We hoped the second option would solve our problems, but in our
> experimentation it seems that declaring features in this way means they
> aren’t necessarily installed. (I’m hoping I can still dig up examples.)
> As in,
>
> 
> 
> 
>
> results in a distribution where
>
> feature:install a
>
> doesn’t necessarily install b. Is that supposed to be the case?
>
> We also thought that declaring prerequisites would work too, especially
> since our feature dependencies are acyclic and so it is actually
> possible to initialise all our features in a given order. But when we
> tried this we ran into stack overflows. (I’ll do it again and file
> bugs.)
>
> Does this make any sense at all?
>
> Regards,
>
> Stephen
>



-- 

Guillaume Nodet

Re: Exception starting karaf custom distro "minimal example" from docs

[tom]

> On 13 June 2017 at 09:08 Jean-Baptiste Onofré  wrote:
> 
> 
> Hi Tom,
> 
> Here's a pom.xml to do what you want:

As far as I can see that's the same as the "minimal example" in the docs. 
If I use your example, I still get errors:

2017-06-13T09:46:01,692 | ERROR | FelixDispatchQueue | 
pax-web-extender-whiteboard  | 118 - 
org.ops4j.pax.web.pax-web-extender-whiteboard - 6.0.3 | FrameworkEvent ERROR - 
org.ops4j.pax.web.pax-web-extender-whiteboard
org.osgi.framework.BundleException: Activator start error in bundle 
org.ops4j.pax.web.pax-web-extender-whiteboard [118].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2288) 
[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) [?:?]
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371) [?:?]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
 [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
Caused by: java.lang.ClassCastException: 
org.apache.felix.httplite.osgi.HttpServiceImpl cannot be cast to 
org.osgi.service.http.HttpService

and
2017-06-13T09:50:23,076 | ERROR | paxweb-config-2-thread-1 | Felix  
  |  -  -  | Bundle org.apache.felix.inventory [36] 
EventDispatcher: Error during dispatch. (java.lang.ClassCastException: 
org.apache.felix.httplite.osgi.HttpServiceImpl cannot be cast to 
org.osgi.service.http.HttpService)

and 

2017-06-13T09:50:23,076 | ERROR | FelixDispatchQueue | inventory
| 36 - org.apache.felix.inventory - 1.0.4 | FrameworkEvent ERROR - 
org.apache.felix.inventory
java.lang.ClassCastException: org.apache.felix.httplite.osgi.HttpServiceImpl 
cannot be cast to org.osgi.service.http.HttpService

etc.

The "javax.servlet two chains" issue has gone. However that comes back if I 
specify "enterprise" instead of "standard" in my "bootFeatures" (investigating 
I had a "org.apache.karaf.features.cfg" file that specified some things that I 
had inherited from another example -- deleted that now).


This clearly indicates to be that there are just some incompatible bundles 
there. org.ops4j.pax.web.pax-web-extender-whiteboard is expecting 
org.apache.felix.httplite.osgi.HttpServiceImpl to be a 
org.osgi.service.http.HttpService when it's not, or at least not the same 
org.osgi.service.http.HttpService class.


Closing Karaf down and then starting it up again though, it still just hangs 
with no output of any kind, no logging.

Re: Understanding features and dependencies

[Jean-Baptiste Onofré]

Hi Stephen,

I think there's two questions:

1. Why does a refresh happen ?
A refresh can happen for instance when an optional import is resolved (when 
installing a feature or a bundle) or when a new package version is installed 
matching a version range.
So, especially in the case of optional import, you should check the import of 
your bundle.


2. Why does your bundle not able to refresh ?
That's probably the most important. Maybe, you keep the bundle context as member 
of a class and so it becomes invalid after the refresh.


Before dealing with dependency or prerequisite, I would start to address those 
points.


The dependency flag is not a "complete" inner feature, so it's normal that the 
feature is not installed if another one already provides the corresponding 
capabilities.


Regards
JB

On 06/13/2017 10:35 AM, Stephen Kitt wrote:

Hi,

As we continue to try to migrate OpenDaylight to Karaf 4, it’s become
very clear that we need to understand exactly what feature dependencies
entail. (And yes, I’ll submit documentation patches once we’ve done
so.)

OpenDaylight (ODL) defines lots and lots of features, some of which
contain bundles which survive refreshes, many of which don’t. In
real-world deployments, the Karaf distributions which are built tend to
use boot features to start the features they’re interested in. We make
extensive use of feature dependencies of course, e.g.

 
 odl-ttp-model
 odl-mdsal-apidocs
 odl-restconf
 odl-mdsal-broker
 

In Karaf 3 all this works fine.

In Karaf 4 we’re having lots of issues related to bundle refreshes, so
we’ve been trying to figure out how to avoid them. Of course,
“feature:install --no-auto-refresh” works, but that’s not ideal (at
least, I don’t think it is). We thought perhaps using the dependency or
prerequisite attributes might help.

As we understand things (and this is the main point I would like to
clarify), in Karaf 4, based on the feature declaration above:
* (re)starting odl-ttp-model-rest would restart odl-ttp-model,
   odl-mdsal-apidocs etc. (which is a problem because e.g.
   odl-mdsal-broker is very likely to already be running when we install
   another feature)
* adding “dependency="true"” would disable this
* adding “prerequisite="true"” would also disable this, and ensure that
   the corresponding feature is started before odl-ttp-model-rest

We hoped the second option would solve our problems, but in our
experimentation it seems that declaring features in this way means they
aren’t necessarily installed. (I’m hoping I can still dig up examples.)
As in,

 
 
 

results in a distribution where

 feature:install a

doesn’t necessarily install b. Is that supposed to be the case?

We also thought that declaring prerequisites would work too, especially
since our feature dependencies are acyclic and so it is actually
possible to initialise all our features in a given order. But when we
tried this we ran into stack overflows. (I’ll do it again and file
bugs.)

Does this make any sense at all?

Regards,

Stephen



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

Understanding features and dependencies

[Stephen Kitt]

Hi,

As we continue to try to migrate OpenDaylight to Karaf 4, it’s become
very clear that we need to understand exactly what feature dependencies
entail. (And yes, I’ll submit documentation patches once we’ve done
so.)

OpenDaylight (ODL) defines lots and lots of features, some of which
contain bundles which survive refreshes, many of which don’t. In
real-world deployments, the Karaf distributions which are built tend to
use boot features to start the features they’re interested in. We make
extensive use of feature dependencies of course, e.g.


odl-ttp-model
odl-mdsal-apidocs
odl-restconf
odl-mdsal-broker


In Karaf 3 all this works fine.

In Karaf 4 we’re having lots of issues related to bundle refreshes, so
we’ve been trying to figure out how to avoid them. Of course,
“feature:install --no-auto-refresh” works, but that’s not ideal (at
least, I don’t think it is). We thought perhaps using the dependency or
prerequisite attributes might help.

As we understand things (and this is the main point I would like to
clarify), in Karaf 4, based on the feature declaration above:
* (re)starting odl-ttp-model-rest would restart odl-ttp-model,
  odl-mdsal-apidocs etc. (which is a problem because e.g.
  odl-mdsal-broker is very likely to already be running when we install
  another feature)
* adding “dependency="true"” would disable this
* adding “prerequisite="true"” would also disable this, and ensure that
  the corresponding feature is started before odl-ttp-model-rest

We hoped the second option would solve our problems, but in our
experimentation it seems that declaring features in this way means they
aren’t necessarily installed. (I’m hoping I can still dig up examples.)
As in,





results in a distribution where

feature:install a

doesn’t necessarily install b. Is that supposed to be the case?

We also thought that declaring prerequisites would work too, especially
since our feature dependencies are acyclic and so it is actually
possible to initialise all our features in a given order. But when we
tried this we ran into stack overflows. (I’ll do it again and file
bugs.)

Does this make any sense at all?

Regards,

Stephen


pgp7CK5uvRtYj.pgp
Description: OpenPGP digital signature

Re: Exception starting karaf custom distro "minimal example" from docs

[Jean-Baptiste Onofré]

Hi Tom,

Here's a pom.xml to do what you want:


http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>


  4.0.0

  example
  my-karaf
  1.0.0-SNAPSHOT
  karaf-assembly

  

  org.apache.karaf.features
  framework
  4.1.1
  kar


  org.apache.karaf.features
  standard
  4.1.1
  features
  xml

  


  

  
org.apache.karaf.tooling
karaf-maven-plugin
4.1.1
true

  
standard
  
  1.8

  

  



It's what I used during ApacheCon to build a custom distribution of Karaf 
embedding Cellar (I removed the Cellar part for you).


Regards
JB

On 06/13/2017 09:52 AM, t...@quarendon.net wrote:

I've attempted to build a simple custom Karaf distribution using the maven 
plugin and the karaf-assembly packaging.
I can build the assembly, but when I start the result I get an exception.

My pom configuration is currently very simple, just:


 
 org.apache.karaf.features
 framework
 ${karafVersion}
 kar
 
 
 org.apache.karaf.features
 standard
 ${karafVersion}
 features
 xml
compile
 

...

 
 org.apache.karaf.tooling
 karaf-maven-plugin
 
 
 
 
 standard
 
 
 
 1.8
 
 


karafVersion is 4.1.1

So I'm just bundling karaf, I'm not including anything else. This is the "minimal 
example" in the karaf docs.

On startup I get the log here : 
https://gist.github.com/tomq42/47403ec44413fdc517c70dc3cccbf0cb

I get the same if I specify "minimal" in "bootFeatures".
Am I doing something wrong here?

Thanks.



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