Re: Karaf 4.4.2 bin/client -> Failed (IllegalArgumentException) to execute: Invalid UINT32 value: -1

Hi, This is a known bug. It will be fixed in the next release. Regards JB On Mon, Nov 14, 2022 at 4:53 PM Paul Spencer wrote: > > Karaf version 4.4.2 > Java Virtual MachineJava HotSpot(TM) 64-Bit Server VM version > 25.172-b11 > Version

Re: [DISCUSS] Adopt new Karaf logo

-1 (non-binding) My $0.02 — 1. The cloud logo is not friendly to be turned into a font 2. I prefer the alternative hexagon logo is simpler (even if similar to others) and better suited for the things logos are used for — stickers, font, ascii art, etc. Thanks, Matt Pavlovich > On Nov 13,

AW: cxf / camel-blueprint stax2 classloading issue

Upgrading the stax2-api-bundle-version in https://github.com/apache/camel-karaf to 4.2.1 fixes the issue, I made a pull request which is hopefully accepted by the dev team Von: Björn Konrad Gesendet: Montag, 7.

Re: Karaf 4.4.2 bin/client -> Failed (IllegalArgumentException) to execute: Invalid UINT32 value: -1

Just found https://issues.apache.org/jira/browse/KARAF-7607, so this is a known bug. Paul Spencer On 2022/11/14 15:53:03 Paul Spencer wrote: > Karaf version 4.4.2 > Java Virtual MachineJava HotSpot(TM) 64-Bit Server VM version > 25.172-b11 > Version

Karaf 4.4.2 bin/client -> Failed (IllegalArgumentException) to execute: Invalid UINT32 value: -1

Karaf version 4.4.2 Java Virtual MachineJava HotSpot(TM) 64-Bit Server VM version 25.172-b11 Version 1.8.0_172 Vendor Oracle Corporation bin/karaf works, but bin/client fails with the following error:

Re: Unable to create default RequestDispatcher

Prashanth - just one thing - what's the method you're using to register ExampleServlet? Because according to HttpService and Whiteboard specifications, there's no "default" servlet registered. See - in Karaf 4.4.2, I've installed hawtio application (mvn:io.hawt/hawtio-osgi/2.15.0/war) and this

Re: Unable to create default RequestDispatcher

Hello There were a lot of changes in Pax Web 8 and in previous versions, getNamedDispatch() was simply delegated to underlying web server. Now the servlet context is always OSGi-specific and there indeed may be something missing. I've created