Re: Aries

2018-12-03 Thread Ryan Moquin
I was always wondering how to use a resource repository with Karaf.. I want
to be able to leverage requirements and capabilities.. I haven't really
quite figured out how to leverage them properly yet.. figuring that out is
on my to do list though :)

Ryan

On Wed, Nov 28, 2018, 1:23 AM Jean-Baptiste Onofré  Hi,
>
> I think it's related to the mail I sent last week: better and dynamic
> usage of resource repository with features resolver. It's what we
> discussed with Christian.
>
> Clearly today, Karaf features provide unique functionalities and
> description, not covered by other repository (like subsystem or resource
> repository), I'm thinking about configuration, features flags, inner
> features, etc.
>
> However, it would make sense to start Karaf with a minimal features set
> and then leverage resources repositories at runtime, dynamically.
>
> The first step I proposed is basically to add commands to manipulate the
> resources repository at runtime and add resource repository element in
> features repositories.
> Today, it's already possible to use resources repositories, defining it
> (in XML or JSON) in etc/org.apache.karaf.features.cfg. This
> configuration is evaluated when the features service starts and used by
> the features resolver.
> The propose is:
> 1. add resource:repo-add and other commands to add/remove resource
> repositories at runtime and then perform a new evaluation of the
> resolution.
> 2. add  element in features repo (as we have )
> allowing to define "open" features and relay on resources repository.
>
> So, to be clear, I don't want to change the current features service
> which, again, provide unique features, and it's the minimal layer to
> start a karaf runtime. My proposal is to extend & improve the features
> service to better leverage the resources repositories. The user then can
> focus only on a resource repository and won't be "forced" to use a
> features repository.
>
> Regards
> JB
>
> On 28/11/2018 06:38, Christian Schneider wrote:
> > I understand that you are seeking a more standard way than karaf
> > features to deploy parts of an application. Indeed subsystems look like
> > a good way at first. Unfortunately they add a lot of complexity to a
> > system. So almost no one uses them.
> >
> > Currently there are two major ways of packaging an application:
> > - karaf features (uses repository + + requirements under the covers). A
> > feature repo is described in xml. The bundles from all the required
> > features form the repository. The bundles with dependency=false form the
> > requirements.
> > - repository + requirements based approach like used by bnd (without
> > features). They currently use a pom file to describe a repository +
> > requirements in a bndrun file.
> >
> > So I agree it would be great to have a more standard way to package
> > applications. I discussed with JB that we could make more explicit  use
> > of repositories for karaf features. The idea is to describe karaf
> > features using a backing repository + required bundles for each feature.
> > We could describe the repository for the feature in a pom and refer to
> > it in the feature repo file. The features would then only contain the
> > required bundles.
> >
> > This approach would provide a repository in pom form for all karaf
> > features that is then also usable by bnd for packaging. So projects like
> > aries would only need to provide one common form of feature description.
> >
> > Besides this there is a standardisation effort at the OSGi alliance for
> > features. Currently the work in progress there looks more like karaf 2
> > featues, so it is not usable for karaf but maybe in the next iteraion a
> > repository based approach is considered.
> >
> > Chritian
> >
> >
> > Am Di., 27. Nov. 2018 um 21:56 Uhr schrieb Leschke, Scott
> > mailto:slesc...@medline.com>>:
> >
> > It wasn’t really a dev request per se, more of a curiosity question
> > as to whether something along those lines was being considered as it
> > would seem to make the implementations more easily consumable in a
> > variety of OSGi environments.  My primary interest is in Karaf which
> > is why I guess I targeted this list. Perhaps I should have thought
> > that through better.
> >
> > __ __
> >
> > As for how something like that were structured, I don’t know
> > really.  I only have passing familiarity with the Subsystem spec and
> > that it sort of overlaps and extends what Karaf Features do, at
> > least to my knowledge. My take is that a Karaf Feature commonly maps
> > to an OSGi service spec. implementation, even if the names don’t
> > match exactly
> >
> > __ __
> >
> > I readily admit that I could be grossly mistaken on that.
> >
> > __ __
> >
> > Scott
> >
> > __ __
> >
> > *From:* David Jencks  > >
> > *Sent:* Tuesday, November 27, 2018 2:08 PM
> > *To:* 

Re: Karaf - touching config files

2018-12-03 Thread Ryan Moquin
To the file?  Nope, it's always the same with no modification when I tell
the editor to reload it.

Ryan

On Mon, Dec 3, 2018, 8:16 AM Jean-Baptiste Onofré  Hi Ryan,
>
> Did you see the property added ? I guess it's felix.fileinstall.dir right ?
>
> Regards
> JB
>
> On 03/12/2018 14:04, Ryan Moquin wrote:
> > Both have happened to me.  I develop on windows.  All I have to do is
> > open a config file while karaf is running, modify it save it and then my
> > text editor will tell me the file was modified on disk and ask if I want
> > to reload it. This happens every time.  I have to avoid the same config
> > being used in different blueprint bundles or turn off update-strategy
> > reload because it will trigger an infinite reloading process.
> >
> > Ryan
> >
> >
> > On Mon, Dec 3, 2018, 7:38 AM Jean-Baptiste Onofré  >  wrote:
> >
> > Hi Lukasz,
> >
> > I guess you mean that it adds the felix.fileinstall property.
> >
> > It allows Karaf (actually Felix FileInstall) to load the
> configuration
> > from the cfg file.
> >
> > For 1, it's an expected behavior as you use reload. However, you
> should
> > not have an infinite loop as only the first one add the property.
> >
> > For 2, you should have an exception but not blocker for Karaf usage.
> >
> > Can you provide some details about the property/config ?
> >
> > Regards
> > JB
> >
> > On 03/12/2018 12:01, Lukasz Lech wrote:
> > > Is there a reason why Karaf is touching config files when loading
> them
> > > using cm:property-placeholder (Blueprint config)?
> > >
> > >
> > >
> > > There are 2 issues with that:
> > >
> > >
> > >
> > > 1)  If using update-strategy=”reload”, if 2 bundles are
> > loading the
> > > same config, they trigger their updates in infinite loop
> > >
> > > 2)  In docker container, I need to give explicite write
> > permissions
> > > to user running karaf (in standard setup, using Openshift ‘anyuid’
> > > concept, a user running Karaf can read all files in container, but
> > > cannot modify them).
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Lukasz Lech
> > >
> >
> > --
> > 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: Running Karaf 4.2.1 with OpenJDK 11

2018-12-03 Thread Ryan Moquin
Hi JB,

Gotcha, I must not have hit those spots luckily.  Looking forward to
4.2.2.  Always get excited for another release.  I noticed a thread about
the issues with output in various terminals.  I am hitting that in Windows
10, maybe that's one of them, though I thought that was more of an ssh lib
issues (the name of the lib escapes me at the moment.)

Ryan

On Mon, Dec 3, 2018, 8:24 AM Jean-Baptiste Onofré  Hi Ryan,
>
> all depends what part of Karaf you are using ;)
>
> Karaf 4.2.2 will be better in term of Java 11 support.
>
> Regards
> JB
>
> On 03/12/2018 14:08, Ryan Moquin wrote:
> > FWIW, I was surprised that I didn't run into any trouble with OpenJDK 11
> > and 4.2.1.. maybe there is still something strange going in some cases.
> >
> > Thanks for all the great work the Karaf team does.
> >
> > Ryan
> >
> > On Fri, Nov 30, 2018, 11:51 PM Freeman Fang  >  wrote:
> >
> > Hi,
> >
> > FYI, we have better JDK11 support for the coming Karaf 4.2.2. Could
> > you please try with Karaf 4.2.2-SNAPSHOT for now to see if you still
> > have issue?
> >
> > Thanks!
> > -
> > Freeman(Yue) Fang
> >
> > Red Hat, Inc.
> >
> >
> >
> >
> >
> >> On Dec 1, 2018, at 2:51 AM, Javier Delgadillo
> >> mailto:jdelgadi...@esri.com>> wrote:
> >>
> >> Hello everyone,
> >>
> >> We’re in the process of switching our custom Karaf application to
> >> OpenJDK from Oracle JRE.  We’ve successfully ported it to OpenJDK
> >> 8, but I’m having troubles getting it to run using OpenJDK 11.
> >>
> >> Summary: Building and running with OpenJDK8 works as expected.
> >>
> >> If I build the application with OpenJDK11 and run with OpenJDK11,
> >> I see this when running karaf.vat:
> >> C >.\karaf.bat
> >> karaf.bat: Enabling Java debug options:
> >>
>  -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
> >> OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was
> >> deprecated in version 9.0 and will likely be removed in a future
> >> release.
> >> Listening for transport dt_socket at address: 5005
> >> ERROR: Error parsing system bundle export statement:
> >>
>  
> org.osgi.dto;version="1.0",org.osgi.resource;version="1.0",org.osgi.resource.dto;version="1.0";uses:="org.osgi.d
> >>
>  
> to",org.osgi.framework;version="1.8",org.osgi.framework.dto;version="1.8";uses:="org.osgi.dto",org.osgi.framework.hooks.bundle;version="1.1";uses:="org.osgi.framewor
> >>
>  
> k",org.osgi.framework.hooks.resolver;version="1.0";uses:="org.osgi.framework.wiring",org.osgi.framework.hooks.service;version="1.1";uses:="org.osgi.framework",org.os
> >>
>  
> gi.framework.hooks.weaving;version="1.1";uses:="org.osgi.framework.wiring",org.osgi.framework.launch;version="1.2";uses:="org.osgi.framework",
> org.osgi.framework.name
> >> 
> >>
>  
> space;version="1.1";uses:="org.osgi.resource",org.osgi.framework.startlevel;version="1.0";uses:="org.osgi.framework",org.osgi.framework.startlevel.dto;version="1.0";
> >>
>  
> uses:="org.osgi.dto",org.osgi.framework.wiring;version="1.2";uses:="org.osgi.framework,org.osgi.resource",org.osgi.framework.wiring.dto;version="1.2";uses:="org.osgi
> >>
>  
> .dto,org.osgi.resource.dto",org.osgi.service.condpermadmin;version="1.1.1";uses:="org.osgi.framework,org.osgi.service.permissionadmin",org.osgi.service.packageadmin;
> >>
>  
> version="1.2";uses:="org.osgi.framework",org.osgi.service.permissionadmin;version="1.2",org.osgi.service.resolver;version="1.0";uses:="org.osgi.resource",
> org.osgi.se
> >> 
> >>
>  
> rvice.startlevel;version="1.1";uses:="org.osgi.framework",org.osgi.service.url;version="1.0",org.osgi.util.tracker;version="1.5.1";uses:="org.osgi.framework",org.apa
> >>
>  
> che.karaf.version;version="4.2.1",org.apache.karaf.jaas.boot.principal;uses:=javax.security.auth;version="4.2.1",org.apache.karaf.jaas.boot;uses:="javax.security.aut
> >>
>  
> h,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version="4.2.1",,org.apache.karaf.branding,
> >> sun.misc, org.apache
> >> .karaf.diagnostic.core;uses:=org.osgi.framework;version=4.2.1,
> >>
>  
> org.apache.karaf.diagnostic.core.common;uses:=org.apache.karaf.diagnostic.core;version=4.2.1,
> >> org.apac
> >>
>  
> he.karaf.jaas.boot;uses:="javax.security.auth,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version=4.2.1,
> >> org.a
> >>
>  pache.karaf.jaas.boot.principal;uses:=javax.security.auth;version=4.2.1
> >> org.osgi.framework.BundleException: Exported package names cannot
> >> be zero length.
> >> at
> >>
>  
> org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:876)
> 

Re: Running Karaf 4.2.1 with OpenJDK 11

2018-12-03 Thread Jean-Baptiste Onofré
Hi Javier,

4.2.2 is plan to vote for next week end. So we can expect a release on
dist and Maven Central for beginning of next week.

Regarding your question, if it works from Karaf vanilla, there's no
reason it doesn't work in a custom distribution.

Regards
JB

On 03/12/2018 17:46, Javier Delgadillo wrote:
> Is there a schedule for releasing 4.2.2?  We need to release something
> sooner rather than later, so we’ll stick with running on OpenJDK 8
> unless a release of 4.2.2 is imminent.  Then we’ll upgrade to 4.2.2 on
> our next release after 4.2.2 comes out.
> 
>  
> 
> What’s puzzling to me is that if I download vanilla 4.2.1 and manually
> install our repo and features, everything comes up just fine.  It’s only
> when I run our build to create the customizations for the distribution
> that I see the errors.
> 
>  
> 
> -Javier
> 
>  
> 
> *From: *Freeman Fang 
> *Reply-To: *"user@karaf.apache.org" 
> *Date: *Friday, November 30, 2018 at 8:51 PM
> *To: *"user@karaf.apache.org" 
> *Subject: *Re: Running Karaf 4.2.1 with OpenJDK 11
> 
>  
> 
> Hi,
> 
>  
> 
> FYI, we have better JDK11 support for the coming Karaf 4.2.2. Could you
> please try with Karaf 4.2.2-SNAPSHOT for now to see if you still have issue?
> 
>  
> 
> Thanks!
> 
> -
> 
> Freeman(Yue) Fang
> 
> 
> Red Hat, Inc. 
> 
>  
> 
>  
> 
>  
> 
> On Dec 1, 2018, at 2:51 AM, Javier Delgadillo  > wrote:
> 
>  
> 
> Hello everyone,
> 
>  
> 
> We’re in the process of switching our custom Karaf application to
> OpenJDK from Oracle JRE.  We’ve successfully ported it to OpenJDK 8,
> but I’m having troubles getting it to run using OpenJDK 11.
> 
>  
> 
> Summary: Building and running with OpenJDK8 works as expected.
> 
>  
> 
> If I build the application with OpenJDK11 and run with OpenJDK11, I
> see this when running karaf.vat:
> 
> C >.\karaf.bat
> 
> karaf.bat: Enabling Java debug options:
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
> 
> OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was
> deprecated in version 9.0 and will likely be removed in a future
> release.
> 
> Listening for transport dt_socket at address: 5005
> 
> ERROR: Error parsing system bundle export statement:
> 
> org.osgi.dto;version="1.0",org.osgi.resource;version="1.0",org.osgi.resource.dto;version="1.0";uses:="org.osgi.d
> 
> 
> to",org.osgi.framework;version="1.8",org.osgi.framework.dto;version="1.8";uses:="org.osgi.dto",org.osgi.framework.hooks.bundle;version="1.1";uses:="org.osgi.framewor
> 
> 
> k",org.osgi.framework.hooks.resolver;version="1.0";uses:="org.osgi.framework.wiring",org.osgi.framework.hooks.service;version="1.1";uses:="org.osgi.framework",org.os
> 
> 
> gi.framework.hooks.weaving;version="1.1";uses:="org.osgi.framework.wiring",org.osgi.framework.launch;version="1.2";uses:="org.osgi.framework",org.osgi.framework.name
> 
> 
> space;version="1.1";uses:="org.osgi.resource",org.osgi.framework.startlevel;version="1.0";uses:="org.osgi.framework",org.osgi.framework.startlevel.dto;version="1.0";
> 
> 
> uses:="org.osgi.dto",org.osgi.framework.wiring;version="1.2";uses:="org.osgi.framework,org.osgi.resource",org.osgi.framework.wiring.dto;version="1.2";uses:="org.osgi
> 
> 
> .dto,org.osgi.resource.dto",org.osgi.service.condpermadmin;version="1.1.1";uses:="org.osgi.framework,org.osgi.service.permissionadmin",org.osgi.service.packageadmin;
> 
> 
> version="1.2";uses:="org.osgi.framework",org.osgi.service.permissionadmin;version="1.2",org.osgi.service.resolver;version="1.0";uses:="org.osgi.resource",org.osgi.se
> 
> 
> 
> 
> rvice.startlevel;version="1.1";uses:="org.osgi.framework",org.osgi.service.url;version="1.0",org.osgi.util.tracker;version="1.5.1";uses:="org.osgi.framework",org.apa
> 
> 
> che.karaf.version;version="4.2.1",org.apache.karaf.jaas.boot.principal;uses:=javax.security.auth;version="4.2.1",org.apache.karaf.jaas.boot;uses:="javax.security.aut
> 
> 
> h,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version="4.2.1",,org.apache.karaf.branding,
> sun.misc, org.apache
> 
> .karaf.diagnostic.core;uses:=org.osgi.framework;version=4.2.1,
> 
> org.apache.karaf.diagnostic.core.common;uses:=org.apache.karaf.diagnostic.core;version=4.2.1,
> org.apac
> 
> 
> he.karaf.jaas.boot;uses:="javax.security.auth,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version=4.2.1,
> org.a
> 
> pache.karaf.jaas.boot.principal;uses:=javax.security.auth;version=4.2.1
> 
> org.osgi.framework.BundleException: Exported package 

Re: Running Karaf 4.2.1 with OpenJDK 11

2018-12-03 Thread Javier Delgadillo
Is there a schedule for releasing 4.2.2?  We need to release something sooner 
rather than later, so we’ll stick with running on OpenJDK 8 unless a release of 
4.2.2 is imminent.  Then we’ll upgrade to 4.2.2 on our next release after 4.2.2 
comes out.

What’s puzzling to me is that if I download vanilla 4.2.1 and manually install 
our repo and features, everything comes up just fine.  It’s only when I run our 
build to create the customizations for the distribution that I see the errors.

-Javier

From: Freeman Fang 
Reply-To: "user@karaf.apache.org" 
Date: Friday, November 30, 2018 at 8:51 PM
To: "user@karaf.apache.org" 
Subject: Re: Running Karaf 4.2.1 with OpenJDK 11

Hi,

FYI, we have better JDK11 support for the coming Karaf 4.2.2. Could you please 
try with Karaf 4.2.2-SNAPSHOT for now to see if you still have issue?

Thanks!
-
Freeman(Yue) Fang

Red Hat, Inc.



On Dec 1, 2018, at 2:51 AM, Javier Delgadillo 
mailto:jdelgadi...@esri.com>> wrote:

Hello everyone,

We’re in the process of switching our custom Karaf application to OpenJDK from 
Oracle JRE.  We’ve successfully ported it to OpenJDK 8, but I’m having troubles 
getting it to run using OpenJDK 11.

Summary: Building and running with OpenJDK8 works as expected.

If I build the application with OpenJDK11 and run with OpenJDK11, I see this 
when running karaf.vat:
C >.\karaf.bat
karaf.bat: Enabling Java debug options: 
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in 
version 9.0 and will likely be removed in a future release.
Listening for transport dt_socket at address: 5005
ERROR: Error parsing system bundle export statement: 
org.osgi.dto;version="1.0",org.osgi.resource;version="1.0",org.osgi.resource.dto;version="1.0";uses:="org.osgi.d
to",org.osgi.framework;version="1.8",org.osgi.framework.dto;version="1.8";uses:="org.osgi.dto",org.osgi.framework.hooks.bundle;version="1.1";uses:="org.osgi.framewor
k",org.osgi.framework.hooks.resolver;version="1.0";uses:="org.osgi.framework.wiring",org.osgi.framework.hooks.service;version="1.1";uses:="org.osgi.framework",org.os
gi.framework.hooks.weaving;version="1.1";uses:="org.osgi.framework.wiring",org.osgi.framework.launch;version="1.2";uses:="org.osgi.framework",org.osgi.framework.name
space;version="1.1";uses:="org.osgi.resource",org.osgi.framework.startlevel;version="1.0";uses:="org.osgi.framework",org.osgi.framework.startlevel.dto;version="1.0";
uses:="org.osgi.dto",org.osgi.framework.wiring;version="1.2";uses:="org.osgi.framework,org.osgi.resource",org.osgi.framework.wiring.dto;version="1.2";uses:="org.osgi
.dto,org.osgi.resource.dto",org.osgi.service.condpermadmin;version="1.1.1";uses:="org.osgi.framework,org.osgi.service.permissionadmin",org.osgi.service.packageadmin;
version="1.2";uses:="org.osgi.framework",org.osgi.service.permissionadmin;version="1.2",org.osgi.service.resolver;version="1.0";uses:="org.osgi.resource",org.osgi.se
rvice.startlevel;version="1.1";uses:="org.osgi.framework",org.osgi.service.url;version="1.0",org.osgi.util.tracker;version="1.5.1";uses:="org.osgi.framework",org.apa
che.karaf.version;version="4.2.1",org.apache.karaf.jaas.boot.principal;uses:=javax.security.auth;version="4.2.1",org.apache.karaf.jaas.boot;uses:="javax.security.aut
h,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version="4.2.1",,org.apache.karaf.branding,
 sun.misc, org.apache
.karaf.diagnostic.core;uses:=org.osgi.framework;version=4.2.1, 
org.apache.karaf.diagnostic.core.common;uses:=org.apache.karaf.diagnostic.core;version=4.2.1,
 org.apac
he.karaf.jaas.boot;uses:="javax.security.auth,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version=4.2.1,
 org.a
pache.karaf.jaas.boot.principal;uses:=javax.security.auth;version=4.2.1
org.osgi.framework.BundleException: Exported package names cannot be zero 
length.
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:876)
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:215)
at 
org.apache.felix.framework.ExtensionManager.(ExtensionManager.java:261)
at org.apache.felix.framework.Felix.(Felix.java:429)
at 
org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
at org.apache.karaf.main.Main.launch(Main.java:256)
at org.apache.karaf.main.Main.main(Main.java:178)
Error installing bundle listed in startup.properties with url: 
mvn:org.apache.karaf.features/org.apache.karaf.features.extension/4.2.1 and 
startlevel: 1

In data/log/karaf.log, I see this:
Nov 30, 

Re: Aries JAX-RS Whiteboard

2018-12-03 Thread Jean-Baptiste Onofré
No problem ;)

Regards
JB

On 03/12/2018 14:59, Christian Schneider wrote:
> Pretty cool .. sorry I missed that.
> 
> Christian
> 
> Am Mo., 3. Dez. 2018 um 08:33 Uhr schrieb Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>>:
> 
> Hi,
> 
> yes, it's what I said in my previous e-mail: Karaf example + features in
> Aries.
> 
> Regards
> JB
> 
> On 03/12/2018 08:27, Christian Schneider wrote:
> > Hi JB,
> >
> > can you add the jax-rs-whiteboard feature to the aries repo? I
> think it
> > makes sense to have it with the jax-rs code so it can be used with
> > different karaf versions.
> >
> > Christian
> >
> > Am Mo., 3. Dez. 2018 um 07:39 Uhr schrieb Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>  >>:
> >
> >     Hi Markus,
> >
> >     yes I will push the PRs (Karaf example with feature repo + Aries
> >     features repo that will replace the one in Karaf example)
> later today.
> >
> >     Regards
> >     JB
> >
> >     On 03/12/2018 06:03, Markus Rathgeb wrote:
> >     > Hi JB,
> >     >
> >     >     as I'm creating the Aries JAXRS feature for Karaf, I'm
> >     currently using
> >     >     the one from Aries.
> >     >
> >     >
> >     > could you share your feature?
> >     >
> >     > Best regards,
> >     > Markus
> >
> >     --
> >     Jean-Baptiste Onofré
> >     jbono...@apache.org 
> >
> >     http://blog.nanthrax.net
> >     Talend - http://www.talend.com
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com
> 

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


Re: Aries JAX-RS Whiteboard

2018-12-03 Thread Christian Schneider
Pretty cool .. sorry I missed that.

Christian

Am Mo., 3. Dez. 2018 um 08:33 Uhr schrieb Jean-Baptiste Onofré <
j...@nanthrax.net>:

> Hi,
>
> yes, it's what I said in my previous e-mail: Karaf example + features in
> Aries.
>
> Regards
> JB
>
> On 03/12/2018 08:27, Christian Schneider wrote:
> > Hi JB,
> >
> > can you add the jax-rs-whiteboard feature to the aries repo? I think it
> > makes sense to have it with the jax-rs code so it can be used with
> > different karaf versions.
> >
> > Christian
> >
> > Am Mo., 3. Dez. 2018 um 07:39 Uhr schrieb Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>>:
> >
> > Hi Markus,
> >
> > yes I will push the PRs (Karaf example with feature repo + Aries
> > features repo that will replace the one in Karaf example) later
> today.
> >
> > Regards
> > JB
> >
> > On 03/12/2018 06:03, Markus Rathgeb wrote:
> > > Hi JB,
> > >
> > > as I'm creating the Aries JAXRS feature for Karaf, I'm
> > currently using
> > > the one from Aries.
> > >
> > >
> > > could you share your feature?
> > >
> > > Best regards,
> > > Markus
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org 
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com


Re: Karaf - touching config files

2018-12-03 Thread Jean-Baptiste Onofré
Hi Ryan,

Did you see the property added ? I guess it's felix.fileinstall.dir right ?

Regards
JB

On 03/12/2018 14:04, Ryan Moquin wrote:
> Both have happened to me.  I develop on windows.  All I have to do is
> open a config file while karaf is running, modify it save it and then my
> text editor will tell me the file was modified on disk and ask if I want
> to reload it. This happens every time.  I have to avoid the same config
> being used in different blueprint bundles or turn off update-strategy
> reload because it will trigger an infinite reloading process.
> 
> Ryan
> 
> 
> On Mon, Dec 3, 2018, 7:38 AM Jean-Baptiste Onofré   wrote:
> 
> Hi Lukasz,
> 
> I guess you mean that it adds the felix.fileinstall property.
> 
> It allows Karaf (actually Felix FileInstall) to load the configuration
> from the cfg file.
> 
> For 1, it's an expected behavior as you use reload. However, you should
> not have an infinite loop as only the first one add the property.
> 
> For 2, you should have an exception but not blocker for Karaf usage.
> 
> Can you provide some details about the property/config ?
> 
> Regards
> JB
> 
> On 03/12/2018 12:01, Lukasz Lech wrote:
> > Is there a reason why Karaf is touching config files when loading them
> > using cm:property-placeholder (Blueprint config)?
> >
> >  
> >
> > There are 2 issues with that:
> >
> >  
> >
> > 1)  If using update-strategy=”reload”, if 2 bundles are
> loading the
> > same config, they trigger their updates in infinite loop
> >
> > 2)  In docker container, I need to give explicite write
> permissions
> > to user running karaf (in standard setup, using Openshift ‘anyuid’ 
> > concept, a user running Karaf can read all files in container, but
> > cannot modify them).
> >
> >  
> >
> > Best regards,
> >
> > Lukasz Lech
> >
> 
> -- 
> 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: Running Karaf 4.2.1 with OpenJDK 11

2018-12-03 Thread Ryan Moquin
FWIW, I was surprised that I didn't run into any trouble with OpenJDK 11
and 4.2.1.. maybe there is still something strange going in some cases.

Thanks for all the great work the Karaf team does.

Ryan

On Fri, Nov 30, 2018, 11:51 PM Freeman Fang  Hi,
>
> FYI, we have better JDK11 support for the coming Karaf 4.2.2. Could you
> please try with Karaf 4.2.2-SNAPSHOT for now to see if you still have issue?
>
> Thanks!
> -
> Freeman(Yue) Fang
>
> Red Hat, Inc.
>
>
>
>
>
> On Dec 1, 2018, at 2:51 AM, Javier Delgadillo 
> wrote:
>
> Hello everyone,
>
> We’re in the process of switching our custom Karaf application to OpenJDK
> from Oracle JRE.  We’ve successfully ported it to OpenJDK 8, but I’m having
> troubles getting it to run using OpenJDK 11.
>
> Summary: Building and running with OpenJDK8 works as expected.
>
> If I build the application with OpenJDK11 and run with OpenJDK11, I see
> this when running karaf.vat:
> C >.\karaf.bat
> karaf.bat: Enabling Java debug options:
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
> OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated
> in version 9.0 and will likely be removed in a future release.
> Listening for transport dt_socket at address: 5005
> ERROR: Error parsing system bundle export statement:
> org.osgi.dto;version="1.0",org.osgi.resource;version="1.0",org.osgi.resource.dto;version="1.0";uses:="org.osgi.d
>
> to",org.osgi.framework;version="1.8",org.osgi.framework.dto;version="1.8";uses:="org.osgi.dto",org.osgi.framework.hooks.bundle;version="1.1";uses:="org.osgi.framewor
>
> k",org.osgi.framework.hooks.resolver;version="1.0";uses:="org.osgi.framework.wiring",org.osgi.framework.hooks.service;version="1.1";uses:="org.osgi.framework",org.os
>
> gi.framework.hooks.weaving;version="1.1";uses:="org.osgi.framework.wiring",org.osgi.framework.launch;version="1.2";uses:="org.osgi.framework",
> org.osgi.framework.name
>
> space;version="1.1";uses:="org.osgi.resource",org.osgi.framework.startlevel;version="1.0";uses:="org.osgi.framework",org.osgi.framework.startlevel.dto;version="1.0";
>
> uses:="org.osgi.dto",org.osgi.framework.wiring;version="1.2";uses:="org.osgi.framework,org.osgi.resource",org.osgi.framework.wiring.dto;version="1.2";uses:="org.osgi
>
> .dto,org.osgi.resource.dto",org.osgi.service.condpermadmin;version="1.1.1";uses:="org.osgi.framework,org.osgi.service.permissionadmin",org.osgi.service.packageadmin;
>
> version="1.2";uses:="org.osgi.framework",org.osgi.service.permissionadmin;version="1.2",org.osgi.service.resolver;version="1.0";uses:="org.osgi.resource",
> org.osgi.se
>
> rvice.startlevel;version="1.1";uses:="org.osgi.framework",org.osgi.service.url;version="1.0",org.osgi.util.tracker;version="1.5.1";uses:="org.osgi.framework",org.apa
>
> che.karaf.version;version="4.2.1",org.apache.karaf.jaas.boot.principal;uses:=javax.security.auth;version="4.2.1",org.apache.karaf.jaas.boot;uses:="javax.security.aut
> h,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version="4.2.1",,org.apache.karaf.branding,
> sun.misc, org.apache
> .karaf.diagnostic.core;uses:=org.osgi.framework;version=4.2.1,
> org.apache.karaf.diagnostic.core.common;uses:=org.apache.karaf.diagnostic.core;version=4.2.1,
> org.apac
> he.karaf.jaas.boot;uses:="javax.security.auth,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version=4.2.1,
> org.a
> pache.karaf.jaas.boot.principal;uses:=javax.security.auth;version=4.2.1
> org.osgi.framework.BundleException: Exported package names cannot be zero
> length.
> at
> org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:876)
> at
> org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:215)
> at
> org.apache.felix.framework.ExtensionManager.(ExtensionManager.java:261)
> at org.apache.felix.framework.Felix.(Felix.java:429)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
> at org.apache.karaf.main.Main.launch(Main.java:256)
> at org.apache.karaf.main.Main.main(Main.java:178)
> Error installing bundle listed in startup.properties with url:
> mvn:org.apache.karaf.features/org.apache.karaf.features.extension/4.2.1 and
> startlevel: 1
>
> In data/log/karaf.log, I see this:
> Nov 30, 2018 9:16:56 AM org.apache.karaf.main.Main launch
> INFO: Installing and starting initial bundles
> Nov 30, 2018 9:16:56 AM org.apache.karaf.main.Main main
> SEVERE: Could not launch framework
> java.lang.RuntimeException: Error installing bundle listed in
> startup.properties with url:
> mvn:org.apache.karaf.features/org.apache.karaf.features.extension/4.2.1 and
> startlevel: 1
> at org.apache.karaf.main.Main.installAndStartBundles(Main.java:550)
> at org.apache.karaf.main.Main.launch(Main.java:273)
> at 

Re: Karaf - touching config files

2018-12-03 Thread Ryan Moquin
Both have happened to me.  I develop on windows.  All I have to do is open
a config file while karaf is running, modify it save it and then my text
editor will tell me the file was modified on disk and ask if I want to
reload it. This happens every time.  I have to avoid the same config being
used in different blueprint bundles or turn off update-strategy reload
because it will trigger an infinite reloading process.

Ryan


On Mon, Dec 3, 2018, 7:38 AM Jean-Baptiste Onofré  Hi Lukasz,
>
> I guess you mean that it adds the felix.fileinstall property.
>
> It allows Karaf (actually Felix FileInstall) to load the configuration
> from the cfg file.
>
> For 1, it's an expected behavior as you use reload. However, you should
> not have an infinite loop as only the first one add the property.
>
> For 2, you should have an exception but not blocker for Karaf usage.
>
> Can you provide some details about the property/config ?
>
> Regards
> JB
>
> On 03/12/2018 12:01, Lukasz Lech wrote:
> > Is there a reason why Karaf is touching config files when loading them
> > using cm:property-placeholder (Blueprint config)?
> >
> >
> >
> > There are 2 issues with that:
> >
> >
> >
> > 1)  If using update-strategy=”reload”, if 2 bundles are loading the
> > same config, they trigger their updates in infinite loop
> >
> > 2)  In docker container, I need to give explicite write permissions
> > to user running karaf (in standard setup, using Openshift ‘anyuid’
> > concept, a user running Karaf can read all files in container, but
> > cannot modify them).
> >
> >
> >
> > Best regards,
> >
> > Lukasz Lech
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: Karaf - touching config files

2018-12-03 Thread Jean-Baptiste Onofré
Hi Lukasz,

I guess you mean that it adds the felix.fileinstall property.

It allows Karaf (actually Felix FileInstall) to load the configuration
from the cfg file.

For 1, it's an expected behavior as you use reload. However, you should
not have an infinite loop as only the first one add the property.

For 2, you should have an exception but not blocker for Karaf usage.

Can you provide some details about the property/config ?

Regards
JB

On 03/12/2018 12:01, Lukasz Lech wrote:
> Is there a reason why Karaf is touching config files when loading them
> using cm:property-placeholder (Blueprint config)?
> 
>  
> 
> There are 2 issues with that:
> 
>  
> 
> 1)  If using update-strategy=”reload”, if 2 bundles are loading the
> same config, they trigger their updates in infinite loop
> 
> 2)  In docker container, I need to give explicite write permissions
> to user running karaf (in standard setup, using Openshift ‘anyuid’ 
> concept, a user running Karaf can read all files in container, but
> cannot modify them).
> 
>  
> 
> Best regards,
> 
> Lukasz Lech
> 

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


Karaf - touching config files

2018-12-03 Thread Lukasz Lech
Is there a reason why Karaf is touching config files when loading them using 
cm:property-placeholder (Blueprint config)?

There are 2 issues with that:


1)  If using update-strategy="reload", if 2 bundles are loading the same 
config, they trigger their updates in infinite loop

2)  In docker container, I need to give explicite write permissions to user 
running karaf (in standard setup, using Openshift 'anyuid'  concept, a user 
running Karaf can read all files in container, but cannot modify them).

Best regards,
Lukasz Lech