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

2021-05-22 Thread Benjamin Graf 

Hi,

a short note. It works up to Felix 6.0.3 on JDK11 and fails from version 
6.0.4+ beginning.


Some bug fix from:

Changes from 6.0.3 to 6.0.4
---

** Bug
    * [FELIX-6178] - org.osgi.framework.Bundle#getServicesInUse returns 
services with usage count = 0
    * [FELIX-6222] - Support for os.name Capability is missing for 
Windows Server 2019

    * [FELIX-6297] - unclosed InputStream on Bundle.start
    * [FELIX-6318] - Tiny thread-safety bug in BundleWiringImpl
    * [FELIX-6326] - Cannot read bundled resources with hash in the 
filename

    * [FELIX-6331] - Race condition in unget service from service factory

Should be the cause IMHO. Any Felix expert on the list?

Regards,

Benjamin

On 20.05.2021 19:00, Benjamin Graf wrote:

Hi,

just tried to run pax-transx-tm-narayana in plain Felix 7 on JDK11 and 
still the same Exception trace.


Regards

Benjamin

On 20.05.2021 18:16, Benjamin Graf wrote:

Hi Grzegorz,

Of course do I remember issue #50. And I think it's not a bug in 
pax-transx because everything is fine with Karaf 4.2.11 on JDK11. The 
error occurs on Karaf 4.3.2 maybe 4.3.x at all. So it might be a bug 
in either newer Karaf or newer Felix?!


Regards

Benjamin

On 20.05.2021 18:07, Grzegorz Grzybek wrote:

Hmm, but your remember this
https://github.com/ops4j/org.ops4j.pax.transx/issues/50 issue? I 
ensured
that pax-transx can run, build and test using JDK11... I'll check it 
again.
Could you file a bug to 
https://github.com/ops4j/org.ops4j.pax.transx/issues

?

regards
Grzegorz Grzybek

czw., 20 maj 2021 o 18:00 Benjamin Graf  
napisał(a):



Hi Grzegorz,

the same error with pax-transx 0.5.1

    - feature:repo-add pax-transx 0.5.1
    - feature:repo-add pax-transx 0.5.1

Regards

Benjamin
On 20.05.2021 17:43, Grzegorz Grzybek wrote:

Hi

Did you try `mvn clean install` latest pax-transx release?

regards
Grzegorz Grzybek

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



Hi JB,

I use JDK 11 as runtime environment. There is no code to compile to
reproduce this bug just plain Karaf and pax-trans-tm-narayana from 
Maven

central.

Regards

Benjamin

On 20.05.2021 10:32, Jean-Baptiste Onofre wrote:

Hi Ben,

Are you using JDK 11 (for both compile and runtime) ?

Regards
JB


Le 20 mai 2021 à 08:17, Benjamin Graf  
 a écrit :


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

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

2021-05-20 Thread Benjamin Graf 

Hi,

just tried to run pax-transx-tm-narayana in plain Felix 7 on JDK11 and 
still the same Exception trace.


Regards

Benjamin

On 20.05.2021 18:16, Benjamin Graf wrote:

Hi Grzegorz,

Of course do I remember issue #50. And I think it's not a bug in 
pax-transx because everything is fine with Karaf 4.2.11 on JDK11. The 
error occurs on Karaf 4.3.2 maybe 4.3.x at all. So it might be a bug 
in either newer Karaf or newer Felix?!


Regards

Benjamin

On 20.05.2021 18:07, Grzegorz Grzybek wrote:

Hmm, but your remember this
https://github.com/ops4j/org.ops4j.pax.transx/issues/50 issue? I ensured
that pax-transx can run, build and test using JDK11... I'll check it 
again.
Could you file a bug to 
https://github.com/ops4j/org.ops4j.pax.transx/issues

?

regards
Grzegorz Grzybek

czw., 20 maj 2021 o 18:00 Benjamin Graf  
napisał(a):



Hi Grzegorz,

the same error with pax-transx 0.5.1

    - feature:repo-add pax-transx 0.5.1
    - feature:repo-add pax-transx 0.5.1

Regards

Benjamin
On 20.05.2021 17:43, Grzegorz Grzybek wrote:

Hi

Did you try `mvn clean install` latest pax-transx release?

regards
Grzegorz Grzybek

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



Hi JB,

I use JDK 11 as runtime environment. There is no code to compile to
reproduce this bug just plain Karaf and pax-trans-tm-narayana from 
Maven

central.

Regards

Benjamin

On 20.05.2021 10:32, Jean-Baptiste Onofre wrote:

Hi Ben,

Are you using JDK 11 (for both compile and runtime) ?

Regards
JB


Le 20 mai 2021 à 08:17, Benjamin Graf  
 a écrit :


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

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

2021-05-20 Thread Benjamin Graf 

Hi Grzegorz,

Of course do I remember issue #50. And I think it's not a bug in 
pax-transx because everything is fine with Karaf 4.2.11 on JDK11. The 
error occurs on Karaf 4.3.2 maybe 4.3.x at all. So it might be a bug in 
either newer Karaf or newer Felix?!


Regards

Benjamin

On 20.05.2021 18:07, Grzegorz Grzybek wrote:

Hmm, but your remember this
https://github.com/ops4j/org.ops4j.pax.transx/issues/50 issue? I ensured
that pax-transx can run, build and test using JDK11... I'll check it again.
Could you file a bug to https://github.com/ops4j/org.ops4j.pax.transx/issues
?

regards
Grzegorz Grzybek

czw., 20 maj 2021 o 18:00 Benjamin Graf  napisał(a):


Hi Grzegorz,

the same error with pax-transx 0.5.1

- feature:repo-add pax-transx 0.5.1
- feature:repo-add pax-transx 0.5.1

Regards

Benjamin
On 20.05.2021 17:43, Grzegorz Grzybek wrote:

Hi

Did you try `mvn clean install` latest pax-transx release?

regards
Grzegorz Grzybek

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


Hi JB,

I use JDK 11 as runtime environment. There is no code to compile to
reproduce this bug just plain Karaf and pax-trans-tm-narayana from Maven
central.

Regards

Benjamin

On 20.05.2021 10:32, Jean-Baptiste Onofre wrote:

Hi Ben,

Are you using JDK 11 (for both compile and runtime) ?

Regards
JB


Le 20 mai 2021 à 08:17, Benjamin Graf  
 a écrit :

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

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

2021-05-20 Thread Benjamin Graf 

Hi Grzegorz,

the same error with pax-transx 0.5.1

 * feature:repo-add pax-transx 0.5.1
 * feature:repo-add pax-transx 0.5.1

Regards

Benjamin

On 20.05.2021 17:43, Grzegorz Grzybek wrote:

Hi

Did you try `mvn clean install` latest pax-transx release?

regards
Grzegorz Grzybek

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


Hi JB,

I use JDK 11 as runtime environment. There is no code to compile to
reproduce this bug just plain Karaf and pax-trans-tm-narayana from Maven
central.

Regards

Benjamin

On 20.05.2021 10:32, Jean-Baptiste Onofre wrote:

Hi Ben,

Are you using JDK 11 (for both compile and runtime) ?

Regards
JB


Le 20 mai 2021 à 08:17, Benjamin Graf  a écrit :

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

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

2021-05-20 Thread Benjamin Graf 

Hi JB,

I use JDK 11 as runtime environment. There is no code to compile to 
reproduce this bug just plain Karaf and pax-trans-tm-narayana from Maven 
central.


Regards

Benjamin

On 20.05.2021 10:32, Jean-Baptiste Onofre wrote:

Hi Ben,

Are you using JDK 11 (for both compile and runtime) ?

Regards
JB


Le 20 mai 2021 à 08:17, Benjamin Graf  a écrit :

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

Re: [RESULT][VOTE] Apache Karaf (runtime) 4.3.0 release

2020-11-02 Thread Benjamin Graf 

Hi JB,

it seems we have an issue in latest 4.3.0 with aries-proxy which does 
not use ASM 9.0, yet. Feature and bundle are unfortunately not in sync.


Regards,

Benjamin

On 30.10.2020 08:16, Jean-Baptiste Onofre wrote:

Hi everyone,

This vote passed with the following result:

+1 (binding): Grzegorz Grzybek, Jamie Goodyear, François Papon, JB Onofré
+1 (non binding): Robert Varga, Eric Lilja

I’m promoting the artifacts on Maven Central and dist, update Jira and website 
and I will announce the release.

Thanks all for your vote.

Regards
JB


Le 26 oct. 2020 à 17:22, Jean-Baptiste Onofre  a écrit :

Hi guys,

After several weeks of work, I’m happy to submit Apache Karaf (runtime) 4.3.0 
release to your vote.

I’m preparing a blog post for some details. Here’s a highlight of some key 
points:

- OSGi R7
- JDK 11+
- JSON configuration format support
- Better features definition (using requirements/capabilities)
- BoM to simplify your dependencies
- and bunch of dependencies updates and bug fixes

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12343304
 


Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1149/ 


Staging Dist:
https://dist.apache.org/repos/dist/dev/karaf/4.3.0 


Git tag:
karaf-4.3.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB


OpenPGP_0x522CCBD38B66CF02.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.2.9 (take #2)

2020-06-05 Thread Benjamin Graf 
+1 (non-binding)

Regards

Benjamin

On 05.06.2020 14:48, Jean-Baptiste Onofre wrote:
> Hi everyone,
>
> I submit Apache Karaf runtime 4.2.9 release to your vote (take #2 where we 
> fixed the ASM update).
>
> This is a maintenance release on the 4.2.x series bringing fixes, updates and 
> improvements.
> It especially fixes the issues related to the shell (paste didn’t work 
> properly, some commands caused exception, …).
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346465
>  
> 
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1143/ 
> 
>
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.9/ 
> 
>
> Git Tag:
> karaf-4.2.9
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf 4.2.9 release

2020-05-19 Thread Benjamin Graf 
-1

Update to ASM 8 has negativ impact to aries-proxy

org.objectweb.asm;resolution:=optional;version="[5,8)",org.objectweb.asm.commons;resolution:=optional;version="[5,8)"

On 19.05.2020 18:39, Jean-Baptiste Onofre wrote:
> Hi everyone,
>
> I submit Apache Karaf runtime 4.2.9 release to your vote.
>
> This is a maintenance release on the 4.2.x series bringing fixes, updates and 
> improvements.
> It especially fixes the issues related to the shell (paste didn’t work 
> properly, some commands caused exception, …).
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346465
>  
> 
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1142/ 
> 
>
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.9/ 
> 
>
> Git Tag:
> karaf-4.2.9
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB



signature.asc
Description: OpenPGP digital signature

Re: Setting security provider for Karaf 4.3.0-SNAPSHOT

2020-02-02 Thread Benjamin Graf 
Hi together,

how going on with this topic. Actually bouncastle is the defacto
standard security library for karaf and bundled by default. So taking
the approach explained by Robert sounds reasonable to upstream to Karaf
itself and moving libs to from system to boot and maybe even register
org.apache.karaf.security.providers =
org.bouncycastle.jce.provider.BouncyCastleProvider. Something to be
solved before 4.3RC2?

Regards,

Benjamin

On 15.01.2020 17:00, Robert Varga wrote:
> On 15/01/2020 16:25, Benjamin Graf wrote:
>> Hi,
>>
>> I'm actually playing around with the latest 4.3.0-SNAPSHOT. I recognize
>> that the ssh bundle is using bouncycastle for reading pem files right
>> now (KARAF-6383). The "issue" I'm facing is that if I like to set
>> bouncycastle as the security provider via
>> "org.apache.karaf.security.providers =
>> org.bouncycastle.jce.provider.BouncyCastleProvider" I have to distribute
>> the same bundle twice or otherwise have to remove it from system and add
>> needed packages to "org.osgi.framework.bootdelegation".
>>
>> Anybody seeing a better solution? 
> Not sure, but in OpenDaylight we have two fragment bundles which attach
> to framework bundle and expose all of BouncyCastle to OSGi:
>
> https://github.com/opendaylight/odlparent/tree/master/karaf/bcpkix-framework-ext
> https://github.com/opendaylight/odlparent/tree/master/karaf/bcprov-framework-ext
>
> perhaps these should be upstreamed (but then we upgrade BC much more
> quickly than we upgrade Karaf).
>
> Regards,
> Robert
>



signature.asc
Description: OpenPGP digital signature

Setting security provider for Karaf 4.3.0-SNAPSHOT

2020-01-15 Thread Benjamin Graf 
Hi,

I'm actually playing around with the latest 4.3.0-SNAPSHOT. I recognize
that the ssh bundle is using bouncycastle for reading pem files right
now (KARAF-6383). The "issue" I'm facing is that if I like to set
bouncycastle as the security provider via
"org.apache.karaf.security.providers =
org.bouncycastle.jce.provider.BouncyCastleProvider" I have to distribute
the same bundle twice or otherwise have to remove it from system and add
needed packages to "org.osgi.framework.bootdelegation".

Anybody seeing a better solution? Maybe an enhancement needed?

Regards

Benjamin




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.2.8 release

2020-01-14 Thread Benjamin Graf 
Hi JB,

changing line ending from unix to windows seems to solve the issue.
Maybe some strange interpreter problem of the windows shell itself. I
would suggest to change line ending for all bat-files in the karaf
distribution.

What do you think?

Regards

Benjamin

On 15.01.2020 08:47, Benjamin Graf wrote:
> Hi JB,
>
> it's fine with JDK8. That's why I found the issue quite late.
>
> Regards
>
> Benjamin
>
> On 15.01.2020 08:42, Jean-Baptiste Onofré wrote:
>> Hi Benjamin,
>>
>> does it happen with JDK8 ?
>>
>> I will fix for Karaf 4.2.9 and provide a workaround in the mean time.
>>
>> Regards
>> JB
>>
>> On 15/01/2020 08:26, Benjamin Graf wrote:
>>> Hi,
>>>
>>> I'm facing a issue while starting under Windows 10 and JDK 11:
>>>
>>> It seems there is a strange issue added in karaf.bat between 4.2.7 and
>>> 4.2.8. Some error also on actual 4.3 SNAPSHOTS.
>>>
>>> Regards,
>>>
>>> Benjamin
>>>
>>> On 12.01.2020 12:34, Jean-Baptiste Onofré wrote:
>>>> Hi all,
>>>>
>>>> I submit Apache Karaf runtime 4.2.8 to your vote. This is a
>>>> maintenance release on the 4.2.x series, bringing updates, improvements
>>>> and fixes.
>>>>
>>>> Release Notes:
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346100
>>>>
>>>> Staging Repository:
>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1137
>>>>
>>>> Staging Dist:
>>>> https://dist.apache.org/repos/dist/dev/karaf/4.2.8/
>>>>
>>>> Git Tag:
>>>> karaf-4.2.8
>>>>
>>>> Please vote to approve this release:
>>>>
>>>> [ ] +1 Approve the release
>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>>
>>>> This vote will be open for at least 72 hours.
>>>>
>>>> Thanks,
>>>> Regards
>>>> JB



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.2.8 release

2020-01-14 Thread Benjamin Graf 
Hi JB,

it's fine with JDK8. That's why I found the issue quite late.

Regards

Benjamin

On 15.01.2020 08:42, Jean-Baptiste Onofré wrote:
> Hi Benjamin,
>
> does it happen with JDK8 ?
>
> I will fix for Karaf 4.2.9 and provide a workaround in the mean time.
>
> Regards
> JB
>
> On 15/01/2020 08:26, Benjamin Graf wrote:
>> Hi,
>>
>> I'm facing a issue while starting under Windows 10 and JDK 11:
>>
>> It seems there is a strange issue added in karaf.bat between 4.2.7 and
>> 4.2.8. Some error also on actual 4.3 SNAPSHOTS.
>>
>> Regards,
>>
>> Benjamin
>>
>> On 12.01.2020 12:34, Jean-Baptiste Onofré wrote:
>>> Hi all,
>>>
>>> I submit Apache Karaf runtime 4.2.8 to your vote. This is a
>>> maintenance release on the 4.2.x series, bringing updates, improvements
>>> and fixes.
>>>
>>> Release Notes:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346100
>>>
>>> Staging Repository:
>>> https://repository.apache.org/content/repositories/orgapachekaraf-1137
>>>
>>> Staging Dist:
>>> https://dist.apache.org/repos/dist/dev/karaf/4.2.8/
>>>
>>> Git Tag:
>>> karaf-4.2.8
>>>
>>> Please vote to approve this release:
>>>
>>> [ ] +1 Approve the release
>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>
>>> This vote will be open for at least 72 hours.
>>>
>>> Thanks,
>>> Regards
>>> JB



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.2.8 release

2020-01-14 Thread Benjamin Graf 
Hi,

I'm facing a issue while starting under Windows 10 and JDK 11:

It seems there is a strange issue added in karaf.bat between 4.2.7 and
4.2.8. Some error also on actual 4.3 SNAPSHOTS.

Regards,

Benjamin

On 12.01.2020 12:34, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I submit Apache Karaf runtime 4.2.8 to your vote. This is a
> maintenance release on the 4.2.x series, bringing updates, improvements
> and fixes.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346100
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1137
>
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.8/
>
> Git Tag:
> karaf-4.2.8
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB


signature.asc
Description: OpenPGP digital signature

Aw: Re: [HEADS UP] Preparing Karaf 4.2.6 and 4.3.0.RC1

2019-06-04 Thread Benjamin Graf 
Hi JB,
 
do I understand right that pax-logging 1.11 or 2.0 won't be OSGi R6 for karaf 
4.2.x anymore? Or does Grzegorz and you plan a next "small" release for 4.2 
branch, too? Most improvements done in the near past are not in den 1.10.x 
branch of pax-logging.
 
Regards
Benjamin
 
Gesendet: Dienstag, 04. Juni 2019 um 12:56 Uhr
Von: "Jean-Baptiste Onofré" 
An: dev@karaf.apache.org
Betreff: Re: [HEADS UP] Preparing Karaf 4.2.6 and 4.3.0.RC1
Hi guys,

I would like to provide a quick update and those releases.

I created pax-logging-1.10.x branch and released pax-logging 1.10.2 with
the improvements to avoid the refreshes. With Grzegorz, we also started
bunch of improvements on master and we also already started the OSGi R7
support in Pax Logging.

I'm completing the latest minor updates on karaf-4.2.x: I will submit
Karaf 4.2.6 to vote tonight or tomorrow early morning.

Once done, I will focus on 4.3.0.RC1 with OSGi R7 support.

Stay tuned !

Regards
JB

On 20/05/2019 07:47, Jean-Baptiste Onofré wrote:
> Hi guys,
>
> FYI, I'm completing the preparation of Karaf 4.2.6 today. I hope to
> submit this release to vote tomorrow or Wednesday.
>
> In the mean time, we are moving forward on third party projects
> (especially Pax*) to be OSGi R7 compliant.
> I'm also doing some preparation steps on Karaf master to prepare the
> OSGi R7 upgrade.
> I think I will be able to cut a RC1 beginning of next week.
>
> Stay tuned !
>
> Regards
> JB
>

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

Re: Version alignment report for Karaf 4.2.3-SNAPSHOT - 1/2

2019-01-08 Thread Benjamin Graf 
Hi Grzegorz,

is there a reason why the plugin goal for generateConsistencyReport does
not filter the features that were chosen in custom distributions? Using
the report that way generates many "false friends" that are actually not
needed to resolve. Maybe it should also interact with more than only
blacklisted features/bundles for example replacements in
org.apache.karaf.features.xml. This way you can iterative tune your
distribution by adding more and more items to replacement list and
checking consistency report.

What do you think?

Regards

Benjamin

Am 08.01.2019 um 13:28 schrieb Grzegorz Grzybek:
> Hello
>
> For any custom Karaf distro we can enable generation of "consistency
> report" - check sample here:
> http://people.apache.org/~ggrzybek/bundle-report-full-karaf.xml (requires
> browser that can do XSLT transformation using )
>
> it can be configured using:
>
> 
> org.apache.karaf.tooling
> karaf-maven-plugin
> 
>
> ${project.build.directory}/assembly
> 
>
> karaf-maven-plugin:assembly then generates:
>  - bundle-report.xslt - stylesheet to transform XMLs
>  - bundle-report-full.xml - full report, including blacklisted
> repos/features/bundles
>  - bundle-report.xml - a report without blacklisted items
>
> The idea behind this report is to show _duplicates_ - bundles that appear
> with the same groupId and artifactId (maven) but with different version.
> The report also shows the features the bundles are declared in and feature
> repositories the features come from.
>
> Entire closure of bundles → features → repositories is taken into account.
>
> It's most important when creating custom Karaf distribution - we can check
> if some features declare conflicting bundles - we (usually) don't want to
> have two versions of servlet-api JAR installed (though it's not a problem
> with guava - it's even a must).
>
> When a _duplicate_ is found or even duplicate repositories are referenced
> (directly or transitively) usually there's a need to _blacklist_ something.
>
> With https://issues.apache.org/jira/browse/KARAF-5376 I've introduced a way
> (documentation is still being written...) to blacklist
> bundles/features/repositories or override bundles/features/repositories.
>
> Blacklisting/overriding is done using etc/org.apache.karaf.features.xml
> file. Short summary of the mechanism is here:
> https://issues.apache.org/jira/browse/KARAF-5376?focusedCommentId=16431939=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16431939
>
> In next email, I'll show what should/could be aligned in master branch for
> Karaf 4.2.3-SNAPSHOT.
>
> regards
> Grzegorz Grzybek
>



signature.asc
Description: OpenPGP digital signature

Re: Enterprise Feature Repository Causing Invalid Custom Distribution...

2019-01-07 Thread Benjamin Graf 
Hi JB,

that's the error of the ActiveMQ feature file I reported last year. The 
corrected feature file is not releases yet. It may also be a problem in the 
resolvement algorithm used by involved components mainly outside Karaf I think 
pax-url if I remember right.

Regards
Benjamin 

Am 8. Januar 2019 06:09:10 MEZ schrieb "Jean-Baptiste Onofré" 
:
>By the way, the enterprise features repo is used in the standard Karaf
>distribution, so it's weird that it works here. It's maybe a
>combination
>of features.
>
>For the tracking I created:
>https://issues.apache.org/jira/browse/KARAF-6075
>
>Regards
>JB
>
>On 07/01/2019 22:16, James Carman wrote:
>> We are trying to build our own custom Karaf 4.2.2 distribution and
>> when we include the enterprise feature repository along with the
>> ActiveMQ 5.15.8 feature repository, we get an invalid
>> org.apache.karaf.features.cfg file which includes 4.2.3-SNAPSHOT
>> versions of some of the boot features.  I have created an example
>> project here:
>> 
>> https://github.com/jwcarman/custom-karaf-example
>> 
>> If you build it as-is, you'll see the problem. If you comment out the
>> enterprise feature repo, the problem goes away.
>> 
>> Thanks,
>> 
>> James
>> 
>
>-- 
>Jean-Baptiste Onofré
>jbono...@apache.org
>http://blog.nanthrax.net
>Talend - http://www.talend.com

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

signature.asc
Description: PGP signature

[DISCUSS] Add jms-spec feature to enterprise feature

2016-10-07 Thread Benjamin Graf 
Hi,

Actually it is hard getting messaging systems working with Karaf if they
are using different version of the jms API (1.1 vs 2.0) like ActiveMQ
Artemis or IBM WebsphereMQ > 8. Therefor I would suggest to add a
jms-spec feature for either 1.1 version and 2.0 version. This allows to
add it for example to the corresponding spring-jms features (3.x -> JMS
1.1, 4.x -> JMS 2.0) If you need a specific JMS version to get resolved
you can using override feature or explicitly declare it in
org.apache.karaf.features.cfg.

What do you think? Better suggestions?

Regards,

Benjamin




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Karaf 2.3.7

2014-09-05 Thread Benjamin Graf 
Hi,

but it has been done in the past from Karaf 2.3.3 to 2.3.4 for cm version 1.0.1
to 1.0.3. Since it is only a minor bug fix it's worth thinking about for 2.3.7
or 2.3.8.

Benjamin

On 03.09.2014 19:55, Jean-Baptiste Onofré wrote:
 Unfortunately, no, Karaf 2.3.x is a maintenance release, and we avoid such
 major update.

 Regards
 JB

 On 09/03/2014 03:07 PM, SvS wrote:
 Hi,

 Is it possible to update org.apache.aries.blueprint.cm to version 1.0.4  in
 karaf 2.3.7? It solves many issues with the managed factory services.

 Regards,
 SvS



 -- 
 View this message in context:
 http://karaf.922171.n3.nabble.com/VOTE-Release-Apache-Karaf-2-3-7-tp4035022p4035038.html
 Sent from the Karaf - Dev mailing list archive at Nabble.com.






signature.asc
Description: OpenPGP digital signature

Re: karaf-3.0.2 Problem with console

2014-08-10 Thread Benjamin Graf 

Hi JB,

any news about this?

Regards
Benjamin

On 04.08.2014 21:54, Jean-Baptiste Onofré wrote:

Catcha, thanks for the update.

Anyway, the jline 2.12 update causes the input issue on the local 
console.

I'm testing a fix in jline.

Regards
JB

On 08/04/2014 09:34 PM, Kevin Carr wrote:

Jean-Baptiste,

Sorry for the multiple posts earlier.  I had an older version of
3.0.2-SNAPSHOT, that didn't have the jline fixed.  I have since 
updated to

the latest version and everything is going good.

I have it installed on our dev system with a team of 8 other devs.
Hopefully we can put it through some paces, and get back to the karaf 
team

with issues.  (If we have any.  )


On Mon, Aug 4, 2014 at 2:30 PM, Jean-Baptiste Onofré j...@nanthrax.net
wrote:


Hi Kevin,

Jline 2.12 is already used (that's the source of the local console 
issue).

So I guess that you use a Karaf custom distribution, right ?

Regards
JB


On 08/04/2014 07:42 PM, Kevin Carr wrote:

I found that sshd is failing because jline 2.11 is in the system 
folder,
and sshd is looking for 2.12.  I put jline 2.12 in the system area 
and it

is running now.


On Mon, Aug 4, 2014 at 7:42 AM, Jean-Baptiste Onofré j...@nanthrax.net
wrote:

  It's another use case. Anyway, the local console should work as 
the SSHd

is optional.

More over, I think the ssh console has issues too (as it leverages
jline).

Regards
JB


On 08/04/2014 02:38 PM, Kevin Carr wrote:

  Is it possible to open putty and connect?  I am on windows 7, 
and start

karaf in cmd for windows then open connection in putty.

Maybe that will at least get you going till the fix is in place.
On Aug 4, 2014 7:33 AM, Jean-Baptiste Onofré j...@nanthrax.net 
wrote:


   Hi guys,



FYI, as I suspected, the issue on Windows is related to the 
JLine 2.12

update:

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

I'm working on it. I will send an update on the mailing list as 
soon

as I
have details (and eventually a new quick release to fix that).

Regards
JB

On 08/03/2014 08:45 PM, Benjamin Graf wrote:

   Hi together,



I actually face the same problem with the just released 2.3.6 
version

on
Win7x64 JDK7u65. 2.3.5 does still work so there must be a 
change done

which causes this issue.

Regards
Benjamin

On 30.07.2014 20:30, nseb wrote:

   Hi Jean Baptiste,



Have you found the problem?

Best Regards,
Sébastien.



-
CTO , JeetConsulting.

Analyze now your Maven Java projects' dependencies , here
--
View this message in context:
http://karaf.922171.n3.nabble.com/karaf-3-0-2-Problem-with-
console-tp4034304p4034502.html

Sent from the Karaf - Dev mailing list archive at Nabble.com.




   --


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




  --

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







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

Re: karaf-3.0.2 Problem with console

2014-08-03 Thread Benjamin Graf 

Hi together,

I actually face the same problem with the just released 2.3.6 version on 
Win7x64 JDK7u65. 2.3.5 does still work so there must be a change done 
which causes this issue.


Regards
Benjamin

On 30.07.2014 20:30, nseb wrote:

Hi Jean Baptiste,

Have you found the problem?

Best Regards,
Sébastien.



-
CTO , JeetConsulting.

Analyze now your Maven Java projects' dependencies , here
--
View this message in context: 
http://karaf.922171.n3.nabble.com/karaf-3-0-2-Problem-with-console-tp4034304p4034502.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Release Karaf 2.4.0

2014-07-14 Thread Benjamin Graf 

What about upgrading to Felix 4.4.1 first before releasing 2.4.0?

Benjamin

On 09.07.2014 17:24, Guillaume Nodet wrote:

Now that Aries releases are done, I'd like to discuss a 2.4.0 release asap.
I think it's in a good shape, but i'll do a bit more testing and I would
welcome any additional volunteers.

Anyway, does anyone as any urgent stuff to put in before we release ?
I'd like to start the release friday or monday if nothing requires a delay.

Thoughts ?

Guillaume

Aw: [INFO] Apache Karaf 3.0.2 will be OSGi r4.3

2014-06-30 Thread Benjamin Graf 

Hi,
maybe create another branch (3.1.x) for r5? It's a bit odd that 2.4 will 
be r5 ready but no 3.x version. :-)

Regards
Benjamin
*Gesendet:* Montag, 30. Juni 2014 um 13:47 Uhr
*Von:* Jean-Baptiste Onofré j...@nanthrax.net
*An:* Karaf Dev dev@karaf.apache.org
*Betreff:* [INFO] Apache Karaf 3.0.2 will be OSGi r4.3
Hi all,

just an important note.

We upgraded karaf-3.0.x branch to Felix 4.4.0/Equinox 3.9.1, so OSGi r5
in 3.0.2-SNAPSHOT.

I think it wasn't a good upgrade for two reasons:
1/ we changed the OSGi release support in a minor version of a branch
2/ we potentially break dependency projects, it's the case for Pax Web
3.1 for instance.

So, I will do the following:
- master branch (Karaf 4.0.0-SNAPSHOT) will be OSGi r5, with Felix 4.4.0
and Equinox 3.9.1 (as it's the case right now)
- karaf-3.0.x branch (Karaf 3.0.2-SNAPSHOT) will be OSGi r4.3, with
Felix 4.2.1 and Equinox 3.8 (as it was in Karaf 3.0.1)

I will update the schedule plan on the website too.

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

Re: Karaf 3,4 plans?

2014-06-20 Thread Benjamin Graf 
Hi,

I think this discussion shows that karaf needs an actual release and 
maintenance plan. Don't forget we still have 2.3.x and 2.x branch used and 
developed. 2.4 will be an OSGi r5 release too. Well, that's really confusing. 
;-)

Regards
Benjamin

On 19. Juni 2014 21:24:53 MESZ, Jean-Baptiste Onofré j...@nanthrax.net 
wrote:
Hi Scott,

to be clear, this is the current situation:

Karaf 3.0.1 (latest release): Felix 4.2.1/Equinox 3.8.2, OSGi r4.3 (and

partial r5 support)
Karaf 3.0.2 (next release, planned in a couple of weeks): Felix 
4.4.0/Equinox 3.9.1, OSGi r5
Karaf 4.0.0 (future): Felix 4.4.0/Equinox 3.9.1, OSGi r5

Regards
JB

On 06/19/2014 08:27 PM, Scott Lewis wrote:
 On 6/19/2014 1:59 AM, Jean-Baptiste Onofré wrote:
 Yes, it is but not yet released (it will be included in 3.0.2). I
 talked about the current version in 3.0.1 (latest release).

 I'm a little confused about framework versions and Karaf version.

 Is the conclusion that 3.0.1 (latest release) does not have the Felix
 version that supports OSGi R5?   But some version of Felix that
supports
 R5 will be included in Karaf 3.0.2?

 If that's right:

 1) When is Karaf 3.0.2 to be expected?
 2) Which version of Felix will be included in 3.0.2?

 Thanksinadvance,

 Scott



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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Karaf 3,4 plans?

2014-06-19 Thread Benjamin Graf 

Just to clarify even the 3.0.x branch is one r5 yet (since KARAF-2860). :-)

Regards
Benjamin

On 18.06.2014 20:06, Jean-Baptiste Onofré wrote:

It sounds good to me.

Regards
JB

On 06/18/2014 08:02 PM, Guillaume Nodet wrote:

I'd like to have a release or karaf 2.4 and a 4.0 beta during july.
I think we should aim for a 4.0 soon in september maybe.


2014-06-18 19:45 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net:


Hi Scott,

Karaf 3 uses:
- Felix Framework 4.2.1
- Equinox 3.8.2

So it means full OSGi r4.3 support, and partial r5 support.

I upgraded Karaf 4 to use Felix Framework 4.4.0 and Equinox 3.9.1,
providing a full OSGi r5 support.

In term of release plan, I schedule Karaf 3.0.2 at least for end of 
next
week (we need some update of transitive projects for full Java8 
support).

No plan for Karaf 4 for now.

I would propose to prepare to r5 framework update for Karaf 3.0.3 (or
maybe on a 3.1.x branch, it would be better).

Regards
JB


On 06/18/2014 06:47 PM, Scott Lewis wrote:


Hi Folks,

I'm working on producing karaf features for ECF's upcoming Luna 
release
(next week), and I'm wondering:  should I target Karaf 3.0.1 or 
Karaf 4?


I've seen discussion of Karaf 4 on this mailing list, but I couldn't
find details of it on the karaf roadmap [1].  e.g. which OSGi 
framework

version is going to be supported in 4 (i.e. which versions of Felix or
Equinox are going to be used), as well as other new/added/changed
features in karaf itself.   It would also be nice to know some general
release plans/schedule for 3.X and 4...if it's available.

If possible, I would prefer to target both current and upcoming 
releases
of karaf for the ECF R5 OSGi Remote Services impl being released 
June 25
[2], but there are some spec-imposed dependencies on framework 
versions
(wiring API, etc), so it's helpful to know what the karaf 4 
dependencies

are going to be.

Thanksinadvance for any info or plans pointers,

Scott

[1] https://cwiki.apache.org/confluence/display/KARAF/Roadmap
[2] https://wiki.eclipse.org/Simultaneous_Release



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

Re: JDBC Feature

2014-01-18 Thread Benjamin Graf 

Hi JB,

what I'm missing is a link to aries transaction jdbc which is in my 
opinion the better template to provide out of the box. I think it's 
worth thinking about a closer integration of this feature rather than 
doing dbcp stuff for example. Well, of course that is a personally point 
of view if you prefer to go with geronimo stuff providing jee APIs and 
implementations or any other lib out there. :) May be it also worth 
looking to integrate aries transaction jms for the karaf jms enterprise 
feature. (Karaf vs. ServiceMix ?)


Regards
Benjamin

On 18.01.2014 10:52, Jean-Baptiste Onofré wrote:

Hi Benjamin,

if you take a deeper look, you will see that Karaf JDBC uses Aries 
(blueprint and transaction).


Template files uses blueprint. The generic template uses DBCP, the 
other templates use specific database/JDBC driver capability. But it's 
only template, you can deploy your own datasource definition.


The Karaf JDBC module provides what is not in Aries: management of 
datasource, JDBC service, MBean and shell commands.


So it's not different, it's a complement.

Regards
JB

On 01/18/2014 09:40 AM, Benjamin Graf wrote:

Hi,

actually a lot of JDBC stuff has been done for karaf. I'm just wondering
why it is done so heterogeneously in different apache projects. Karaf
uses blueprint and (not all the time!) dbcp for pooling and creating
datasources. Aries uses blueprint as well (:-)) but using
geronimo/tranql for pooling and creating. Since aries is part of karaf
enterprise, why using yet another enterprise abstraction? By the way. I
think aries has done a lot of good work to make working with JDBC quite
handy.

Just my 0.02€

What do you think?

Regards
Benjamin

Re: JDBC Feature

2014-01-18 Thread Benjamin Graf 

Hi JB,

well, I'm looking into which features/bundles gets installed how the 
templates for specific providers does initialize the datasources (export 
blueprint service) Take a look how they can be enhanced 
(http://search.maven.org/#search|ga|1|aries.transaction.jdbc) by using 
aries transaction jdbc.


Regards
Benjamin

On 18.01.2014 15:06, Jean-Baptiste Onofré wrote:

Hi Benjamin,

I'm not sure to follow you.

Did you really take a look in the Karaf JDBC or JMS feature. It's 
mostly commands and MBean (not really any runtime providing). We 
completely leverage Aries Transaction for instance.
It's the same for JNDI: we complete Aries JNDI (which doesn't provide 
any initial context) with a very simple XBean naming context.


I'm not sure to see your point. Maybe you think that Karaf JDBC or JMS 
is more than that you think it is actually ;)


Regards
JB

On 01/18/2014 03:02 PM, Benjamin Graf wrote:

Hi JB,

what I'm missing is a link to aries transaction jdbc which is in my
opinion the better template to provide out of the box. I think it's
worth thinking about a closer integration of this feature rather than
doing dbcp stuff for example. Well, of course that is a personally point
of view if you prefer to go with geronimo stuff providing jee APIs and
implementations or any other lib out there. :) May be it also worth
looking to integrate aries transaction jms for the karaf jms enterprise
feature. (Karaf vs. ServiceMix ?)

Regards
Benjamin

On 18.01.2014 10:52, Jean-Baptiste Onofré wrote:

Hi Benjamin,

if you take a deeper look, you will see that Karaf JDBC uses Aries
(blueprint and transaction).

Template files uses blueprint. The generic template uses DBCP, the
other templates use specific database/JDBC driver capability. But it's
only template, you can deploy your own datasource definition.

The Karaf JDBC module provides what is not in Aries: management of
datasource, JDBC service, MBean and shell commands.

So it's not different, it's a complement.

Regards
JB

On 01/18/2014 09:40 AM, Benjamin Graf wrote:

Hi,

actually a lot of JDBC stuff has been done for karaf. I'm just 
wondering

why it is done so heterogeneously in different apache projects. Karaf
uses blueprint and (not all the time!) dbcp for pooling and creating
datasources. Aries uses blueprint as well (:-)) but using
geronimo/tranql for pooling and creating. Since aries is part of karaf
enterprise, why using yet another enterprise abstraction? By the 
way. I
think aries has done a lot of good work to make working with JDBC 
quite

handy.

Just my 0.02€

What do you think?

Regards
Benjamin

Re: JDBC Feature

2014-01-18 Thread Benjamin Graf 
You right I missed the point that this is focused on xa only. There 
should maybe be opened a ticket at aries to also support non xa 
datasources as input. Not every jdbc driver has pooling capabilities itself.


Regards
Benjamin

On 18.01.2014 15:30, Jean-Baptiste Onofré wrote:
This is different: aries.transaction.jdbc allows you to create a 
standard datasource using a xadatasource.


It doesn't provide any datasource (you have to provide at least a XA 
Datasource).


It's not the same usage.

Where we can see an overlap it's in term of pooling as the Aries 
RecoverableDataSource provide a pooling (using the Aries 
ConnectionManagerFactory). That's true. But again, we can add a 
template Aries DataSource that wrap a XADataSource to create a 
pooled datasource. But you need the XADataSource ;)


Regards
JB

On 01/18/2014 03:22 PM, Benjamin Graf wrote:

Hi JB,

well, I'm looking into which features/bundles gets installed how the
templates for specific providers does initialize the datasources (export
blueprint service) Take a look how they can be enhanced
(http://search.maven.org/#search|ga|1|aries.transaction.jdbc) by using
aries transaction jdbc.

Regards
Benjamin

On 18.01.2014 15:06, Jean-Baptiste Onofré wrote:

Hi Benjamin,

I'm not sure to follow you.

Did you really take a look in the Karaf JDBC or JMS feature. It's
mostly commands and MBean (not really any runtime providing). We
completely leverage Aries Transaction for instance.
It's the same for JNDI: we complete Aries JNDI (which doesn't provide
any initial context) with a very simple XBean naming context.

I'm not sure to see your point. Maybe you think that Karaf JDBC or JMS
is more than that you think it is actually ;)

Regards
JB

On 01/18/2014 03:02 PM, Benjamin Graf wrote:

Hi JB,

what I'm missing is a link to aries transaction jdbc which is in my
opinion the better template to provide out of the box. I think it's
worth thinking about a closer integration of this feature rather than
doing dbcp stuff for example. Well, of course that is a personally 
point

of view if you prefer to go with geronimo stuff providing jee APIs and
implementations or any other lib out there. :) May be it also worth
looking to integrate aries transaction jms for the karaf jms 
enterprise

feature. (Karaf vs. ServiceMix ?)

Regards
Benjamin

On 18.01.2014 10:52, Jean-Baptiste Onofré wrote:

Hi Benjamin,

if you take a deeper look, you will see that Karaf JDBC uses Aries
(blueprint and transaction).

Template files uses blueprint. The generic template uses DBCP, the
other templates use specific database/JDBC driver capability. But 
it's

only template, you can deploy your own datasource definition.

The Karaf JDBC module provides what is not in Aries: management of
datasource, JDBC service, MBean and shell commands.

So it's not different, it's a complement.

Regards
JB

On 01/18/2014 09:40 AM, Benjamin Graf wrote:

Hi,

actually a lot of JDBC stuff has been done for karaf. I'm just
wondering
why it is done so heterogeneously in different apache projects. 
Karaf

uses blueprint and (not all the time!) dbcp for pooling and creating
datasources. Aries uses blueprint as well (:-)) but using
geronimo/tranql for pooling and creating. Since aries is part of 
karaf

enterprise, why using yet another enterprise abstraction? By the
way. I
think aries has done a lot of good work to make working with JDBC
quite
handy.

Just my 0.02€

What do you think?

Regards
Benjamin