Re: Problem after install pax-trans-tm-narayana with Karaf 4.3.2

[Romain Manni-Bucau]

isnt it a java 11 change (for mjar useless feature)?

->
https://github.com/openjdk/jdk11u/blob/master/src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java#L154

Last time i checked OSGi ecosystem (some libs are) was not ready for this
change leading to some issues like that.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 20 mai 2021 à 08:29, Grzegorz Grzybek  a
écrit :

> Hello
>
>
> bundle://6a2c22d1-9b1f-46a3-b973-3d9276b47679_60.0:1/arjuna-5.10.6.Final.jar#runtime
> looks weird... I've never seen such URL before. Anyone can point to related
> Felix change about these URLs?
>
> I'm currently deep in Pax Web 8 refactoring and I deal with
> bundle/bundleentry resources, but this one looks strange.
>
> Normally, Felix uses bundle://30.0:0/WEB-INF/lib/primefaces-7.0.jar and
> Equinox uses
> bundleentry://30.fwk1976804832/WEB-INF/lib/primefaces-7.0.jar...
>
> regards
> Grzegorz Grzybek
>
> czw., 20 maj 2021 o 08:17 Benjamin Graf 
> napisał(a):
>
> > Hi,
> >
> > it seems there is a bug with embedded resources. I think it is caused by
> > Felix and not Karaf itself.
> >
> > How to reproduce:
> >
> > - Clean start of plain Karaf 4.3.2
> >
> > - feature:install pax-transx-tm-narayana
> >
> > Result:
> >
> > 2021-05-20T08:16:02,787 | WARN  | paxtransx-config-1-thread-1 |
> > pax-transx-tm-narayana   | 60 -
> > org.ops4j.pax.transx.pax-transx-tm-narayana - 0.5.0 | Error starting
> > service
> > java.lang.reflect.InvocationTargetException: null
> >  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method) ~[?:?]
> >  at
> >
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >
> > ~[?:?]
> >  at
> >
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >
> > ~[?:?]
> >  at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
> >  at
> > org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49)
> > ~[?:?]
> >  at
> >
> org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115)
> >
> > ~[?:?]
> >  at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> > [?:?]
> >  at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> >  at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> >
> > [?:?]
> >  at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> >
> > [?:?]
> >  at java.lang.Thread.run(Thread.java:829) [?:?]
> > Caused by: java.lang.IllegalStateException: Stream handler unavailable
> > due to: null
> >  at
> >
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:311)
> >
> > ~[?:?]
> >  at java.net.URL.openConnection(URL.java:1099) ~[?:?]
> >  at
> >
> jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815)
> >
> > ~[?:?]
> >  at
> > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758)
> > ~[?:?]
> >  at
> > jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751)
> > ~[?:?]
> >  at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> >  at
> >
> jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750)
> >
> > ~[?:?]
> >  at
> > jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725)
> > ~[?:?]
> >  at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493)
> > ~[?:?]
> >  at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476)
> > ~[?:?]
> >  at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> >  at
> > jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) ~[?:?]
> >  at
> > jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) ~[?:?]
> >  at
> > jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313)
> ~[?:?]
> >  at java.net.URLClassLoader$1.run(URLClassLoader.java:455) ~[?:?]
> >  at java.net.URLClassLoader$1.run(URLClassLoader.java:452) ~[?:?]
> >  at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> >  at java.net.URLClassLoader.findClass(URLClassLoader.java:451) ~[?:?]
> >  at java.lang.ClassLoader.loadClass(ClassLoader.java:589) ~[?:?]
> >  at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?]
> >  at
> >
> org.jboss.narayana.osgi.jta.internal.OsgiServer.doStart(OsgiServer.java:73)
> >
> > ~[?:?]
> >  at
> > org.jboss.narayana.osgi.jta.internal.OsgiServer.start(OsgiServer.java:66)
> > ~[?:?]
> >  ... 11 more
> > Caused by: java.lang.reflect.InvocationTarget

Re: Problem after install pax-trans-tm-narayana with Karaf 4.3.2

[Grzegorz Grzybek]

Hello

bundle://6a2c22d1-9b1f-46a3-b973-3d9276b47679_60.0:1/arjuna-5.10.6.Final.jar#runtime
looks weird... I've never seen such URL before. Anyone can point to related
Felix change about these URLs?

I'm currently deep in Pax Web 8 refactoring and I deal with
bundle/bundleentry resources, but this one looks strange.

Normally, Felix uses bundle://30.0:0/WEB-INF/lib/primefaces-7.0.jar and
Equinox uses
bundleentry://30.fwk1976804832/WEB-INF/lib/primefaces-7.0.jar...

regards
Grzegorz Grzybek

czw., 20 maj 2021 o 08:17 Benjamin Graf  napisał(a):

> Hi,
>
> it seems there is a bug with embedded resources. I think it is caused by
> Felix and not Karaf itself.
>
> How to reproduce:
>
> - Clean start of plain Karaf 4.3.2
>
> - feature:install pax-transx-tm-narayana
>
> Result:
>
> 2021-05-20T08:16:02,787 | WARN  | paxtransx-config-1-thread-1 |
> pax-transx-tm-narayana   | 60 -
> org.ops4j.pax.transx.pax-transx-tm-narayana - 0.5.0 | Error starting
> service
> java.lang.reflect.InvocationTargetException: null
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:?]
>  at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> ~[?:?]
>  at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> ~[?:?]
>  at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
>  at
> org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49)
> ~[?:?]
>  at
> org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115)
>
> ~[?:?]
>  at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
>  at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>
> [?:?]
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>
> [?:?]
>  at java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: java.lang.IllegalStateException: Stream handler unavailable
> due to: null
>  at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:311)
>
> ~[?:?]
>  at java.net.URL.openConnection(URL.java:1099) ~[?:?]
>  at
> jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815)
>
> ~[?:?]
>  at
> jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758)
> ~[?:?]
>  at
> jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751)
> ~[?:?]
>  at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
>  at
> jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750)
>
> ~[?:?]
>  at
> jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725)
> ~[?:?]
>  at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493)
> ~[?:?]
>  at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476)
> ~[?:?]
>  at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
>  at
> jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) ~[?:?]
>  at
> jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) ~[?:?]
>  at
> jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313) ~[?:?]
>  at java.net.URLClassLoader$1.run(URLClassLoader.java:455) ~[?:?]
>  at java.net.URLClassLoader$1.run(URLClassLoader.java:452) ~[?:?]
>  at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
>  at java.net.URLClassLoader.findClass(URLClassLoader.java:451) ~[?:?]
>  at java.lang.ClassLoader.loadClass(ClassLoader.java:589) ~[?:?]
>  at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?]
>  at
> org.jboss.narayana.osgi.jta.internal.OsgiServer.doStart(OsgiServer.java:73)
>
> ~[?:?]
>  at
> org.jboss.narayana.osgi.jta.internal.OsgiServer.start(OsgiServer.java:66)
> ~[?:?]
>  ... 11 more
> Caused by: java.lang.reflect.InvocationTargetException
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:?]
>  at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> ~[?:?]
>  at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> ~[?:?]
>  at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
>  at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:303)
>
> ~[?:?]
>  at java.net.URL.openConnection(URL.java:1099) ~[?:?]
>  at
> jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815)
>
> ~[?:?]
>  at
> jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758)
> ~[?:?]
>  at
> jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751)
> ~[?:?]
>  at java.security.AccessController.doPrivileged(Native Method) ~[?:?

Problem after install pax-trans-tm-narayana with Karaf 4.3.2

[Benjamin Graf]

Hi,

it seems there is a bug with embedded resources. I think it is caused by 
Felix and not Karaf itself.


How to reproduce:

- Clean start of plain Karaf 4.3.2

- feature:install pax-transx-tm-narayana

Result:

2021-05-20T08:16:02,787 | WARN  | paxtransx-config-1-thread-1 | 
pax-transx-tm-narayana   | 60 - 
org.ops4j.pax.transx.pax-transx-tm-narayana - 0.5.0 | Error starting service

java.lang.reflect.InvocationTargetException: null
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method) ~[?:?]
    at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:?]
    at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
~[?:?]

    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at 
org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49) 
~[?:?]
    at 
org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115) 
~[?:?]
    at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) 
[?:?]

    at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) 
[?:?]
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) 
[?:?]

    at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: java.lang.IllegalStateException: Stream handler unavailable 
due to: null
    at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:311) 
~[?:?]

    at java.net.URL.openConnection(URL.java:1099) ~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815) 
~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758) 
~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751) 
~[?:?]

    at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750) 
~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725) 
~[?:?]

    at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493) ~[?:?]
    at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476) ~[?:?]
    at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
    at 
jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) ~[?:?]
    at 
jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) ~[?:?]
    at 
jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313) ~[?:?]

    at java.net.URLClassLoader$1.run(URLClassLoader.java:455) ~[?:?]
    at java.net.URLClassLoader$1.run(URLClassLoader.java:452) ~[?:?]
    at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
    at java.net.URLClassLoader.findClass(URLClassLoader.java:451) ~[?:?]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:589) ~[?:?]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?]
    at 
org.jboss.narayana.osgi.jta.internal.OsgiServer.doStart(OsgiServer.java:73) 
~[?:?]
    at 
org.jboss.narayana.osgi.jta.internal.OsgiServer.start(OsgiServer.java:66) 
~[?:?]

    ... 11 more
Caused by: java.lang.reflect.InvocationTargetException
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method) ~[?:?]
    at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:?]
    at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
~[?:?]

    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:303) 
~[?:?]

    at java.net.URL.openConnection(URL.java:1099) ~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815) 
~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758) 
~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751) 
~[?:?]

    at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750) 
~[?:?]
    at 
jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725) 
~[?:?]

    at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493) ~[?:?]
    at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476) ~[?:?]
    at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
    at 
jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) ~[?:?]
    at 
jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) ~[?:?]
    at 
jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313) ~[?:?]

    at java.net.URLClassLoader$1.run(URLClassLoader.java:455) ~[?:?]
    at java.net.URLClassLoader$1.run(URLClassLoader.java:4

Re: JAAS in Karaf4/5

[Bernd]

Hello,

Am Mi., 19. Mai 2021 um 11:38 Uhr schrieb Jean-Baptiste Onofre <
j...@nanthrax.net>:

> Karaf5 service could be a nice location, but keep in mind that Karaf5
> service are not OSGi service (the osgi application manager is itself a K5
> service).
>

I guess for normal client code it doesnt matter what component establishes
the context and who provides the implementation, but the packages for the
principals should be available as a bundle (possibly system bundle?) and as
a compile dependency. (Not so sure about the container SPI if I want to
write a login handler or popularte the session context in OSGi or pure Java)


> Let me think about the roadmap/target.
>

I was a bit tied up lately, but you remeber we had planned to have a call
with you. Maybe specifically for Karaf5 it would be good to look into that
again. The last time an app server used a different internal module system
we moved away from it. I really hope the OSGi layer in K5 stays a first
class citizen.

BTW: let us know if we can help with the actual doing. I think Vasil is
currently looking for opportunity for contributions :)

Gruss
Bernd
-- 
www.seeburger.de

>
>

Re: JAAS in Karaf4/5

[Romain Manni-Bucau]

Hi



Le mer. 19 mai 2021 à 11:31, Bernd  a écrit :

> Hello,
>
> I noticed that Karaf provides quite useful principals for Roles, Groups and
> Client. But if I want to consume or create those principals in my own code,
> I have to depend on the karaf-boot bundle.
>
> I wonder:
>
> a) would it make sense for Karaf5 to move the classes to a more focused API
> jar. That would be helpful if I want to build a Microservice Servlet which
> should also run in other containers or if I just dont want to depend on the
> -boot bunfle.
>

For karaf 5 I don't know but a reusable module makes sense to me.
TomEE got some but not being released independently makes it poorly
reusable/perceived.
Maybe a neutral home can help (subproject or incubator?).


>
> b) would it make sense to provide utilities (JAASContext.getClientIP() or
> something)
>
> c) would it make sense to add this to the logger so that it can add this
> (subject/ip) to all log lines generated with active JAAS context.
>

guess it is already supported with attributes or things like that in access
valve or alike (mdc for ex)


>
> d) if I have my own http listener, is there a filter I can use to establish
> the JAAS login and especially also attach the http-client IP principal?
>

attributes, subjects and friends should enable that, main trick is to
authenticate in the used context for the request to attach it to the right
context AFAIK - but you still use a single jaas context


>
> e) we are using Felix RSA/fastbin, I wonder if somebody has experience with
> adding instance-level authentication to something like this (and to RMI)?
>


f) do an optimized jaas context (a lot an be speed up in most cases ;)) in
a "home"


>
> Gruss
> Bernd
>

Re: JAAS in Karaf4/5

[Jean-Baptiste Onofre]

Hi Bernd,

Thanks for your feedback and proposal.

Generally speaking I agree with the proposal.

Karaf5 service could be a nice location, but keep in mind that Karaf5 service 
are not OSGi service (the osgi application manager is itself a K5 service).

So, I think we can already prepare some stuff for Karaf 4.4/4.5.

Let me think about the roadmap/target.

Thanks again !
Regards
JB

> Le 19 mai 2021 à 11:31, Bernd  a écrit :
> 
> Hello,
> 
> I noticed that Karaf provides quite useful principals for Roles, Groups and
> Client. But if I want to consume or create those principals in my own code,
> I have to depend on the karaf-boot bundle.
> 
> I wonder:
> 
> a) would it make sense for Karaf5 to move the classes to a more focused API
> jar. That would be helpful if I want to build a Microservice Servlet which
> should also run in other containers or if I just dont want to depend on the
> -boot bunfle.
> 
> b) would it make sense to provide utilities (JAASContext.getClientIP() or
> something)
> 
> c) would it make sense to add this to the logger so that it can add this
> (subject/ip) to all log lines generated with active JAAS context.
> 
> d) if I have my own http listener, is there a filter I can use to establish
> the JAAS login and especially also attach the http-client IP principal?
> 
> e) we are using Felix RSA/fastbin, I wonder if somebody has experience with
> adding instance-level authentication to something like this (and to RMI)?
> 
> Gruss
> Bernd

JAAS in Karaf4/5

[Bernd]

Hello,

I noticed that Karaf provides quite useful principals for Roles, Groups and
Client. But if I want to consume or create those principals in my own code,
I have to depend on the karaf-boot bundle.

I wonder:

a) would it make sense for Karaf5 to move the classes to a more focused API
jar. That would be helpful if I want to build a Microservice Servlet which
should also run in other containers or if I just dont want to depend on the
-boot bunfle.

b) would it make sense to provide utilities (JAASContext.getClientIP() or
something)

c) would it make sense to add this to the logger so that it can add this
(subject/ip) to all log lines generated with active JAAS context.

d) if I have my own http listener, is there a filter I can use to establish
the JAAS login and especially also attach the http-client IP principal?

e) we are using Felix RSA/fastbin, I wonder if somebody has experience with
adding instance-level authentication to something like this (and to RMI)?

Gruss
Bernd

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Same for me ;)

So, let me refactor and remove "my" feature.simple bundle to include in 
features.core.

I will create the PR soon.

Regards
JB

> Le 19 mai 2021 à 09:21, Grzegorz Grzybek  a écrit :
> 
> śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre  napisał(a):
> 
>> Yes, both are possible.
>> 
>> Maybe keeping all in org.apache.karaf.features.core with a configuration
>> to use a different deploy/approach is better than a complete new features
>> bundle.
>> It’s not a problem to me to refactor what I did.
>> 
>> Thoughts ?
>> 
> 
> Personally I'm 65% for keeping single features.core + configuration option
> and 35% for features.simple ;)
> 
> regards
> Grzegorz Grzybek
> 
> 
>> 
>> Regards
>> JB
>> 
>>> Le 19 mai 2021 à 08:01, Grzegorz Grzybek  a écrit
>> :
>>> 
>>> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre > j...@nanthrax.net>> napisał(a):
>>> 
 Hi,
 
 Actually, it’s a complete separated bundle.
 
 So, in the Karaf standard distribution, you will have
 org.apache.karaf.features.core in etc/startup.properties: that’s the
 regular/current one with the resolver.
 
 Alternatively, you will have another distribution (I have to think about
 the name), where you will have org.apache.karaf.features.simple in
 etc/startup.properties: it doesn’t use the resolver, just loading the
 features model and executing what’s in there.
 
>>> 
>>> Another, different, "non-canonical" distribution is fine ;)
>>> 
>>> 
 
 Another possible approach is a configuration in
 etc/org.apache.karaf.features.cfg where we use a different/pluggable
 deployer.
 
>>> 
>>> This can still be done in standard, "canonical" distro, but as
>>> commented-out configuration option.
>>> 
>>> regards
>>> Grzegorz Grzybek
>>> 
>>> 
>>> 
 
 Thoughts ?
 
 Regards
 JB
 
> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a
>> écrit
 :
> 
> Hello
> 
> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
 napisał(a):
> 
>> Hi,
>> 
>> Regarding recent comments from users and lot of refresh
>> issues/questions
>> we have in the past, I moved forward with a new simple features
>> service
>> that doesn’t use the resolver. It basically reads the features repo
>> definition and just install what’s define in there statically.
>> 
>> I will prepare a distribution using it by default.
>> 
> 
> Will it be configurable? I know about refresh problems - but the
>> resolver
> did a good job showing you what's wrong with the set of
>> features/bundles
> you're installing.
> Do you plan to switch to resolverless features service in micro release
 of
> Karaf? Or will it be Karaf 4.4 / 5?
> 
> regards
> Grzegorz Grzybek
> 
> 
>> 
>> I will share some details soon.
>> 
>> Regards
>> JB
>> 
>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre  a
>> écrit :
>>> 
>>> Hi,
>>> 
>>> It doesn’t really break, it just don’t use it.
>>> 
>>> It’s up to you to install all feature/bundle requirements.
>>> 
>>> Regards
>>> JB
>>> 
 Le 11 janv. 2021 à 21:09, Markus Rathgeb  a
 écrit
>> :
 
 Hi,
 
> - ignore requirement/capability (no resolver)
 
 did I get it right that this breaks the dependency=true feature that
 installs bundles / features only if a requirement is not fullfilled
 yet?
 
 Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
 patriquelega...@gmail.com>:
 
> Same here,
> 
> This is behaviour that has been expected for some time now,
>> reversing
>> it
> could cause damage to systems that upgrade to the latest Karaf. I
 would
> make it something that users opt into vs having to opt-out of.
> 
> On Fri, 8 Jan 2021 at 08:42, Daniel Las > .invalid>
> wrote:
> 
>> Hi,
>> 
>> It looks like some kind of backward incompatible change introduced
>> within
>> patch version change. I personally would like to keep auto refresh
>> "on"
> by
>> default as this is expected/desired behavior for me.
>> 
>> Regards
>> 
>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre 
> napisał(a):
>> 
>>> Hi everyone,
>>> 
>>> We got several user feedback, complaining about unexpected and
>> cascaded
>>> (unrelated) refresh while installing features.
>>> 
>>> As reminder, a refresh can happen when:
>>> - bundle A imports package foo:1 and a bundle provides newer foo
> package
>>> version. In that case, the features service will refresh A to use
 the
>>> newest package version.
>>> - bundle A has an optional import to package foo and a bundle
>>

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Grzegorz Grzybek]

śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre  napisał(a):

> Yes, both are possible.
>
> Maybe keeping all in org.apache.karaf.features.core with a configuration
> to use a different deploy/approach is better than a complete new features
> bundle.
> It’s not a problem to me to refactor what I did.
>
> Thoughts ?
>

Personally I'm 65% for keeping single features.core + configuration option
and 35% for features.simple ;)

regards
Grzegorz Grzybek


>
> Regards
> JB
>
> > Le 19 mai 2021 à 08:01, Grzegorz Grzybek  a écrit
> :
> >
> > śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre  j...@nanthrax.net>> napisał(a):
> >
> >> Hi,
> >>
> >> Actually, it’s a complete separated bundle.
> >>
> >> So, in the Karaf standard distribution, you will have
> >> org.apache.karaf.features.core in etc/startup.properties: that’s the
> >> regular/current one with the resolver.
> >>
> >> Alternatively, you will have another distribution (I have to think about
> >> the name), where you will have org.apache.karaf.features.simple in
> >> etc/startup.properties: it doesn’t use the resolver, just loading the
> >> features model and executing what’s in there.
> >>
> >
> > Another, different, "non-canonical" distribution is fine ;)
> >
> >
> >>
> >> Another possible approach is a configuration in
> >> etc/org.apache.karaf.features.cfg where we use a different/pluggable
> >> deployer.
> >>
> >
> > This can still be done in standard, "canonical" distro, but as
> > commented-out configuration option.
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >
> >>
> >> Thoughts ?
> >>
> >> Regards
> >> JB
> >>
> >>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a
> écrit
> >> :
> >>>
> >>> Hello
> >>>
> >>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
> >> napisał(a):
> >>>
>  Hi,
> 
>  Regarding recent comments from users and lot of refresh
> issues/questions
>  we have in the past, I moved forward with a new simple features
> service
>  that doesn’t use the resolver. It basically reads the features repo
>  definition and just install what’s define in there statically.
> 
>  I will prepare a distribution using it by default.
> 
> >>>
> >>> Will it be configurable? I know about refresh problems - but the
> resolver
> >>> did a good job showing you what's wrong with the set of
> features/bundles
> >>> you're installing.
> >>> Do you plan to switch to resolverless features service in micro release
> >> of
> >>> Karaf? Or will it be Karaf 4.4 / 5?
> >>>
> >>> regards
> >>> Grzegorz Grzybek
> >>>
> >>>
> 
>  I will share some details soon.
> 
>  Regards
>  JB
> 
> > Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre  a
>  écrit :
> >
> > Hi,
> >
> > It doesn’t really break, it just don’t use it.
> >
> > It’s up to you to install all feature/bundle requirements.
> >
> > Regards
> > JB
> >
> >> Le 11 janv. 2021 à 21:09, Markus Rathgeb  a
> >> écrit
>  :
> >>
> >> Hi,
> >>
> >>> - ignore requirement/capability (no resolver)
> >>
> >> did I get it right that this breaks the dependency=true feature that
> >> installs bundles / features only if a requirement is not fullfilled
> >> yet?
> >>
> >> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
> >> patriquelega...@gmail.com>:
> >>
> >>> Same here,
> >>>
> >>> This is behaviour that has been expected for some time now,
> reversing
>  it
> >>> could cause damage to systems that upgrade to the latest Karaf. I
> >> would
> >>> make it something that users opt into vs having to opt-out of.
> >>>
> >>> On Fri, 8 Jan 2021 at 08:42, Daniel Las   .invalid>
> >>> wrote:
> >>>
>  Hi,
> 
>  It looks like some kind of backward incompatible change introduced
>  within
>  patch version change. I personally would like to keep auto refresh
>  "on"
> >>> by
>  default as this is expected/desired behavior for me.
> 
>  Regards
> 
>  pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre 
> >>> napisał(a):
> 
> > Hi everyone,
> >
> > We got several user feedback, complaining about unexpected and
>  cascaded
> > (unrelated) refresh while installing features.
> >
> > As reminder, a refresh can happen when:
> > - bundle A imports package foo:1 and a bundle provides newer foo
> >>> package
> > version. In that case, the features service will refresh A to use
> >> the
> > newest package version.
> > - bundle A has an optional import to package foo and a bundle
>  provides
> > this package. In that case, the features service will refresh A
> to
>  actually
> > use the import as it’s a "resolved" optional.
> > - bundle A is wired to bundle B (from a package perspective or
> > requirement) and B is refreshed. In that ca