Re: Karaf and SpringBoot

2022-02-02 Thread Oleg Cohen 
Hi JB,

Thank you for the info!

So, the best course of action is to wait for K5? There is an early
release available right?

Best
Oleg

Sent from my iPhone

> On Jan 18, 2022, at 2:25 PM, Jean-Baptiste Onofré  wrote:
>
> Hi Oleg,
>
> Yes, it's always possible to wrap spring-boot app as a uber bundle and
> use the controller from K5.
>
> Before starting K5, I added a spring-boot deployer doing that.
>
> Not sure it makes sense to have it in K4 while K5 is coming.
>
> Regards
> JB
>
>> On 18/01/2022 19:24, Oleg Cohen wrote:
>> Greetings,
>>
>> I have a general question. I know that Karaf 5 is coming with a
>> capability to host SpringBoot based services. Are there any capabilities
>> to deploy such services exist in Karaf 4?
>>
>> Thank you!
>> Oleg
>>
>> --
>> *Oleg Cohen | Principal | **A S S U R E B R I D G E*
>> *Office: +1 617 564 0737  |  Mobile: +1 617 455 7927  |  Fax: +1 888 409
>> 6995**
>> Email: _oleg.co...@assurebridge.com
>> _ **| www.assurebridge.com
>> *

Re: Activation related stack traces after upgrading to 4.2.15

2022-02-02 Thread Łukasz Dywicki 

Hey Greg,
Looking at the stack trace it originates from an system dependency we 
have and not Karaf itself. Are you able to reproduce issue without Karaf 
(ie. running stock CXF), or it happens only when you deploy your service 
within our runtime?


BTW would your organization be interested in providing a story for 
https://karaf.apache.org/stories.html ?


Best,
Łukasz
--
Apache Karaf committer & PMC member
http://code-house.org

On 2.02.2022 17:15, Greg Logan wrote:

Hi all,

We are seeing null pointer exceptions[1] on requests after upgrading 
from 4.2.9 to 4.2.15.  The requests look like this (these are testing 
instances, passwords are public, feel free to copy and paste these 
commands):


curl -vvv 'https://stable.opencast.org/api/series/ 
' \

   -u admin:opencast \
   -F 'metadata=[{"label":"Opencast Series 
Dublincore","flavor":"dublincore\/series","fields":[{"id":"title","value":"Test"}]}]' 
\
   -F 
'acl=[{"allow":true,"action":"write","role":"ROLE_ADMIN"},{"allow":true,"action":"read","role":"ROLE_ADMIN"}]'


A corrected request adds mimetypes to the acl and metadata fields:

curl -vvv 'https://stable.opencast.org/api/series/ 
' \

   -u admin:opencast \
   -F 'metadata=[{"label":"Opencast Series 
Dublincore","flavor":"dublincore\/series","fields":[{"id":"title","value":"Test"}]}]; 
type=application/json' \
   -F 
'acl=[{"allow":true,"action":"write","role":"ROLE_ADMIN"},{"allow":true,"action":"read","role":"ROLE_ADMIN"}]; 
type=application/json'


Looking through the Karaf jira, 
https://issues.apache.org/jira/browse/KARAF-6703 
 caught one of our 
developer's eye, notably the comment with the same stack trace linking 
to https://issues.apache.org/jira/browse/CXF-8380 
.  Looking at the jars 
in our assemblies, it looks like we have CXF 3.4.3, but this behaviour 
is supposed to be resolved by 3.4.2.  Am I confused and this is still a 
known issue, or am I just unfamiliar with the inner workings of Karaf 
and CXF?


Thanks,
G

1: Caused by:java.lang.NullPointerException: mimeType
         at 
java.datatransfer/java.awt.datatransfer.DataFlavor.init(DataFlavor.java:427)
         at 
javax.activation.ActivationDataFlavor.init(ActivationDataFlavor.java:113)

         at javax.activation.DataHandler.init(DataHandler.java:41)
         at 
org.apache.cxf.attachment.AttachmentUtil.createAttachment(AttachmentUtil.java:420)
         at 
org.apache.cxf.jaxrs.ext.MessageContextImpl.createAttachments(MessageContextImpl.java:291)
         at 
org.apache.cxf.jaxrs.ext.MessageContextImpl.get(MessageContextImpl.java:79)
         at 
org.apache.cxf.jaxrs.utils.multipart.AttachmentUtils.getMultipartBody(AttachmentUtils.java:84)
         at 
org.apache.cxf.jaxrs.utils.JAXRSUtils.processFormParam(JAXRSUtils.java:1044)
         at 
org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:967)
         at 
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:927)
         at 
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:842)

...

Activation related stack traces after upgrading to 4.2.15

2022-02-02 Thread Greg Logan 
Hi all,

We are seeing null pointer exceptions[1] on requests after upgrading from
4.2.9 to 4.2.15.  The requests look like this (these are testing instances,
passwords are public, feel free to copy and paste these commands):

curl -vvv 'https://stable.opencast.org/api/series/' \
  -u admin:opencast \
  -F 'metadata=[{"label":"Opencast Series
Dublincore","flavor":"dublincore\/series","fields":[{"id":"title","value":"Test"}]}]'
\
  -F
'acl=[{"allow":true,"action":"write","role":"ROLE_ADMIN"},{"allow":true,"action":"read","role":"ROLE_ADMIN"}]'

A corrected request adds mimetypes to the acl and metadata fields:

curl -vvv 'https://stable.opencast.org/api/series/' \
  -u admin:opencast \
  -F 'metadata=[{"label":"Opencast Series
Dublincore","flavor":"dublincore\/series","fields":[{"id":"title","value":"Test"}]}];
type=application/json' \
  -F
'acl=[{"allow":true,"action":"write","role":"ROLE_ADMIN"},{"allow":true,"action":"read","role":"ROLE_ADMIN"}];
type=application/json'

Looking through the Karaf jira,
https://issues.apache.org/jira/browse/KARAF-6703 caught one of our
developer's eye, notably the comment with the same stack trace linking to
https://issues.apache.org/jira/browse/CXF-8380.  Looking at the jars in our
assemblies, it looks like we have CXF 3.4.3, but this behaviour is supposed
to be resolved by 3.4.2.  Am I confused and this is still a known issue, or
am I just unfamiliar with the inner workings of Karaf and CXF?

Thanks,
G

1: Caused by:java.lang.NullPointerException: mimeType
at
java.datatransfer/java.awt.datatransfer.DataFlavor.init(DataFlavor.java:427)
at
javax.activation.ActivationDataFlavor.init(ActivationDataFlavor.java:113)
at javax.activation.DataHandler.init(DataHandler.java:41)
at
org.apache.cxf.attachment.AttachmentUtil.createAttachment(AttachmentUtil.java:420)
at
org.apache.cxf.jaxrs.ext.MessageContextImpl.createAttachments(MessageContextImpl.java:291)
at
org.apache.cxf.jaxrs.ext.MessageContextImpl.get(MessageContextImpl.java:79)
at
org.apache.cxf.jaxrs.utils.multipart.AttachmentUtils.getMultipartBody(AttachmentUtils.java:84)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processFormParam(JAXRSUtils.java:1044)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:967)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:927)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:842)
...

Re: getting camel-azure-storage-queue component to work on Karaf

2022-02-02 Thread Jean-Baptiste Onofré 

Hi,

OK, I will do an update on the bundle then.

Regards
JB

On 01/02/2022 23:56, Ivan Tam wrote:

Hi JB,

We saw there is a dependency with 2 security issues with this bundle.  
They are both in "com.google.guava:guava". If "guava" was updated to 
31.0.1-jre it would fix this issue.


https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.azure-storage/8.6.6_1 



Thanks,

Ivan

-Original Message-
From: Jean-Baptiste Onofré 
Sent: Thursday, January 13, 2022 12:12 AM
To: user@karaf.apache.org
Subject: Re: getting camel-azure-storage-queue component to work on Karaf

EXTERNAL EMAIL - Use caution opening attachments and links.

Hi,

Any reason why not using SMX azure bundles ? I created them for Camel 
components.


If you need additional bundles or updated versions, please let me know.

Regards

JB

On 13/01/2022 05:59, Ivan Tam wrote:

 > Hi,

 >

 > We were trying to use camel-azure-storage-queue component in a

 > blueprint xml and get it to work on Karaf AKS.

 >

 > Karaf 4.3.3 and Camel 3.11.4 is used.

 >

 > _Blueprint xml snippet:_

 >

 >  uri="azure-storage-queue://{{account_name}}/{{queue_name}}?accessKey={

 > {key}}"/>

 >

 > For some reason, to get it to work we need to both feature install a

 > camel project and Karaf commands, although we saw some of the bundles

 > are duplicated.

 >

 > _feature.xml installed_:

 >

 >  

 >

 >      camel

 >

 >      camel-blueprint

 >

 >      camel-azure-storage-queue

 >

 >

 > mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bu

 > ndle/1.2.4

 >

 >

 > wrap:mvn:com.azure/azure-core-http-netty/1.11.1$Require-Capabi

 > lity=osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registra

 > r)"Provide-Capability=osgi.serviceloader;osgi.serviceloader=com.a

 > zure.core.implementation.http.HttpClientProvider

 >

 >

 > wrap:mvn:com.azure/azure-core/1.21.0$Require-Capability=osgi.e

 > xtender;filter:="(osgi.extender=osgi.serviceloader.processor)",osgi.se

 > rviceloader;filter:="(osgi.serviceloader=com.azure.core.implementation

 > .http.HttpClientProvider)";cardinality:=multiple

 >

 >

 > mvn:io.projectreactor.netty/reactor-netty-http/1.0.12

 >

 >

 > mvn:io.netty/netty-transport-native-unix-common/4.1.68.Final bundle>

 >

 >

 > mvn:io.projectreactor.netty/reactor-netty-core/1.0.12

 >

 >

 > mvn:io.netty/netty-transport-native-epoll/4.1.68.Final >

 >

 >      mvn:io.netty/netty-resolver-dns/4.1.68.Final

 >

 >      mvn:io.netty/netty-codec-dns/4.1.68.Final

 >

 >      mvn:io.netty/netty-buffer/4.1.68.Final

 >

 >      mvn:io.netty/netty-common/4.1.68.Final

 >

 >      mvn:io.netty/netty-transport/4.1.68.Final

 >

 >      mvn:io.netty/netty-resolver/4.1.68.Final

 >

 >      mvn:io.netty/netty-handler/4.1.68.Final

 >

 >      mvn:io.netty/netty-codec/4.1.68.Final

 >

 >      mvn:io.netty/netty-codec-http/4.1.68.Final

 >

 >      mvn:io.netty/netty-codec-http2/4.1.68.Final

 >

 >

 > mvn:io.netty/netty-handler-proxy/4.1.68.Final

 >

 >      mvn:io.netty/netty-codec-socks/4.1.68.Final

 >

 >      mvn:com.my.project/my-poc/1.0-SNAPSHOT

 >

 >      

 >

 > _karaf commands needed_:

 >

 > karaf@root()> bundle:install -s

 > wrap:mvn:com.azure/azure-core-http-netty/1.11.1\$Require-Capability=os

 > gi.extender\;filter:=\"(osgi.extender=osgi.serviceloader.registrar)\"\

 > =osgi.serviceloader\;osgi.serviceloader=com.azure.c

 > ore.http.HttpClientProvider

 >

 > karaf@root()> bundle:install -s

 > wrap:mvn:com.azure/azure-core/1.21.0\$Require-Capability=osgi.extender

 > \;filter:=\"(osgi.extender=osgi.serviceloader.processor)\",osgi.servic

 > eloader\;filter:=\"(osgi.serviceloader=com.azure.core.http.HttpClientP

 > rovider)\"\;cardinality:=multiple

 >

 >

 > karaf@root()> bundle:install -s

 > mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.2

 > .4

 >

 > if we just apply either one, say if we only feature install the camel

 > project but not run the Karaf commands above, it won’t work. (Even if

 > we know the bundles are already included in feature.xml)

 >

 > Is it because of how wrap scheme is handled?

 >

 > Or is it related to service loader mediator using apache.aries.spifly

 > on Karaf?

 >

 > Is there any rule of thumb resolving bundles in OSGI env? How can we

 > get this to work easier?

 >

 > Many thanks,

 >

 > Ivan

 >

 >

 >

 > *Ivan Tam*

 > /Engr 2, Software Eng/

 > /Software Engineering/

 >

 > ivan@bd.com 

 >

 > 10020 Pacific Mesa Blvd

 > San Diego, California, 92121

 > US

 > *t: *(858)617.1556

 >

 > *bd.com* >

 >

 > ***

 > IMPORTANT MESSAGE FOR RECIPIENTS IN THE U.S.A.:

 > This message