RE: Shutdown issue ActiveMq

[Jörg Jansen]

Hi JB,

any update?

Thanks,
Joerg

-Original Message-
From: JB Onofré  
Sent: Montag, 16. August 2021 08:27
To: user@karaf.apache.org
Subject: Re: Shutdown issue ActiveMq

Hi

I will take a look with the resources you sent on your last email. 
No need a jira for now, we will create one if the issue is confirmed. 

Regards
JB

> Le 16 août 2021 à 08:25, Jörg Jansen  a 
> écrit :
> 
> Good morning,
> 
> I would like to bring up this point once again and kindly ask if anybody has 
> an idea, of a possible cause of this issue?
> Should I raise a JIRA ticket?
> 
> Kind regards,
> Joerg
> 
> -Original Message-
> From: Jörg Jansen
> Sent: Montag, 5. Juli 2021 10:47
> To: 'user@karaf.apache.org' 
> Subject: RE: Shutdown issue ActiveMq
> 
> Hi JB,
> 
> I just pushed an example to github, which shows the configuration and 
> a reproduction guide: https://github.com/jojansen/jms-shutdown.git
> Maybe you have time to look into it? 
> 
> Regards,
> Joerg
> 
> -Original Message-
> From: Jörg Jansen
> Sent: Freitag, 2. Juli 2021 15:02
> To: user@karaf.apache.org
> Subject: RE: Shutdown issue ActiveMq
> 
> Sure,
> 
> the feature looks like: 
>  description="Provide JMS connection factory and ActiveMqBroker">
>jms
>spring
>activemq-broker-noweb
>activemq-client
> version="${ops4j.pax.jms.version}">pax-jms-pool-pooledjms
>pax-jms-activemq
>camel-jms
> 
>
>  name = lisa-amq
>  osgi.jndi.service.name = jms/lisa-amq
>  password = ${activemq.jms.password}
>  connectionFactoryType = ConnectionFactory
>  type = activemq
>  url = ${activemq.url}
>  user = ${activemq.jms.user}
> 
>  # hints for pax-jms-config to use selected 
> org.ops4j.pax.jms.service.PooledConnectionFactoryFactory
>  pool = pooledjms
>  xa = false
> 
>  # pooled-jms specific configuration of 
> org.messaginghub.pooled.jms.JmsPoolConnectionFactory
>  pool.idleTimeout = 10
>  pool.maxConnections = 10
>  pool.blockIfSessionPoolIsFull = true
>  pax.jms.managed = true
>
>  
> 
> Thanks and regards
> Joerg
> 
> -Original Message-
> From: Jean-Baptiste Onofre 
> Sent: Freitag, 2. Juli 2021 14:53
> To: user@karaf.apache.org
> Subject: Re: Shutdown issue ActiveMq
> 
> It should be fine if your feature installed pax-jms config has prerequisite.
> 
> Can you share snippet of your feature referencing activemq-broker ?
> 
> Regards
> JB
> 
>> Le 2 juil. 2021 à 14:21, Jörg Jansen  a 
>> écrit :
>> 
>> It's installed as a prerequisite feature (which is referenced by my 
>> customized boot feature). 
>> 
>> Regards,
>> Joerg
>> 
>> -Original Message-
>> From: Jean-Baptiste Onofre 
>> Sent: Freitag, 2. Juli 2021 14:07
>> To: user@karaf.apache.org
>> Subject: Re: Shutdown issue ActiveMq
>> 
>> Ah the broker is installed as a feature in Karaf ? I thought your broker was 
>> outside of Karaf (standalone).
>> 
>> Does activemq-broker feature installed as boot feature ? Or do you install 
>> after startup using feature:install ?
>> 
>> Regards
>> JB
>> 
 Le 2 juil. 2021 à 11:14, Jörg Jansen  a 
 écrit :
>>> 
>>> Hi JB,
>>> 
>>> I'm using the AUTO ack, but switching to CLIENT doesn't make any 
>>> difference. 
>>> How can I change the AMQ pool?
>>> From my understanding it should be the preferred way to use pooledjms.
>>> 
>>> This behavior sounds to me, that it may be be a ordering problem in my 
>>> assembly. 
>>> The broker should be shutdown after all cliens. 
>>> 
>>> Regards,
>>> Joerg
>>> 
>>> -Original Message-
>>> From: Jean-Baptiste Onofre 
>>> Sent: Freitag, 2. Juli 2021 09:52
>>> To: user 
>>> Subject: Re: Shutdown issue ActiveMq
>>> 
>>> Hi,
>>> 
>>> Did you try with another kind of pooler ? Like "native" ActiveMQ pool 
>>> instead of wrapped pooledjms ?
>>> 
>>> What kind of ack do you use in your Camel route ? AUTO (default) or CLIENT ?
>>> 
>>> Regards
>>> JB
>>> 
 Le 2 juil. 2021 à 08:05, Jörg Jansen  a 
 écrit :
 
 Hi everybody,
 
 I'm facing a problem with our JMS connection, when shutting down the karaf 
 container. 
 The JMS connectionFactory is provided/configured via ops4j-jms.
 When shutting down karaf, I receive the message: "Caught exception trying 
 rollback() when putting session back into the pool, will invalidate. 
 javax.jms.IllegalStateException: The Session is closed".
 
 Does anybody have an idea how to fix it? 
 Seaching for a workaround brings up to set the idleTimeout to 0, but this 
 has no effect. 
 
 The currently used versions are: 
 Karaf: 4.3.2
 ActiveMq: 5.16.0
 Camel: 3.7.4
 
 Any help would be really appreciated.
 
 Additional details are available below.
 
 Thanks in advance,
 Joerg
 
 
 ***
 *
 Stacktrace
 
 2021-07-02T07:4

Re: Decanter and JMX

[Steven Huypens]

Thanks, that would be great !

Steven

On Wed, Sep 22, 2021 at 4:21 PM JB Onofré  wrote:

> Oh yes. It just has to be exposed. I will do that.
>
> I forgot, sorry for the inconvenience.
>
> Regards
> JB
>
> Le 22 sept. 2021 à 15:50, Steven Huypens  a
> écrit :
>
> 
> Hi JB,
>
> While trying to expose a micrometer  Gauge, I
> noticed that its Double value is not shown by the PrometheusServlet.
> Apparently only Integers and Longs are. Any reason for this ? Looks like an
> easy fix to handle Doubles as well.
>
> Best regards,
> Steven
>
> On Sun, Sep 19, 2021 at 3:33 PM Steven Huypens 
> wrote:
>
>>
>> Great !
>>
>> Anyway, thanks for the 2.8.0 release. Decanter now offers a prometheus
>> endpoint with the properties we need out-of-the-box.
>>
>> Steven
>>
>> On Sun, Sep 19, 2021 at 1:58 PM JB Onofré  wrote:
>>
>>> Ah that’s on the jmx collector then not Prometheus appender: the
>>> Prometheus appender just use property names provided by the collectors.
>>>
>>> I think it makes sense to use full object name and collector prefix to
>>> differentiate the properties name.
>>>
>>> I will do that for next decanter release.
>>>
>>> Thanks for pointing this.
>>>
>>> Regards
>>> JB
>>>
>>> Le 19 sept. 2021 à 12:53, Steven Huypens  a
>>> écrit :
>>>
>>> 
>>> Hi JB,
>>>
>>> Thanks for the clarification, it works for me as described now.
>>>
>>> However, the problem I wanted to address was that if two different
>>> MBeans would contain the exact same property, I see no way of
>>> differentiating between them. In fact I think only one of the properties
>>> will be shown by the Prometheus servlet.
>>>
>>> At the moment that's not a real problem for me, just wanted to let you
>>> know and suggest the possibility of a prefix eg.
>>>
>>> java_lang_Memory_HeapMemoryUsage_committed
>>> java_lang_Memory_HeapMemoryUsage_init
>>> java_lang_Memory_HeapMemoryUsage_max
>>> java_lang_Memory_HeapMemoryUsage_used
>>>
>>> Best regards,
>>> Steven
>>>
>>> On Sun, Sep 19, 2021 at 11:30 AM Jean-Baptiste Onofre 
>>> wrote:
>>>
 Hi Steven,

 I’m about to write a quick blog post to give some highlights about this
 change.

 Basically, I did these two other changes:

 1. For « descendent » properties (the properties inside a Map for
 instance), the property is now named [MAP_PROPERTY]_[ENTRY_PROPERTY]:


 https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java#L74

 2. You can specify the property you want to « render » in the
 Prometheus servlet using prometheus.key.foo in
 etc/org.apache.karaf.decanter.appender.prometheus.cfg:


 https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java#L69

 I hope it helps.

 Regards
 JB

 > Le 19 sept. 2021 à 10:16, Steven Huypens 
 a écrit :
 >
 > Hi JB,
 >
 > I've tested the new 2.8.0 decanter release and I'm pleased to say
 your fix for https://issues.apache.org/jira/browse/KARAF-7154 works
 great. Thanks for that !
 >
 > However I couldn't figure out from the pull request what changes you
 made related to my second suggestion, to better identify from which MBean
 the properties are (or as you put it 'allow user to define the "exported"
 event properties by configuration'). Can you please explain how I can
 achieve this ?
 >
 > Kind regards,
 > Steven
 >
 > On Wed, May 12, 2021 at 6:57 PM Steven Huypens <
 steven.huyp...@gmail.com> wrote:
 > Hi Jean-Baptist,
 >
 > 1) You mention the Prometheus appender only exposes the numeric
 metrics. I believe it would be a minor but very useful addition to also
 expose the Objects in a CompositeDataSupport. For example java.lang.memory
 has a HeapMemoryUsage-object which contains 4 values (committed, init, max
 & used) that could easily be exposed as well.
 >
 > 2) I also would like to suggest to prefix the outputted name of a
 property with something that really identifies the MBean, eg. :
 >
 > java_lang_Memory_HeapMemoryUsage_committed
 > java_lang_Memory_HeapMemoryUsage_init
 > java_lang_Memory_HeapMemoryUsage_max
 > java_lang_Memory_HeapMemoryUsage_used
 >
 > Currently MBeans having the same properties will have their values
 overridden in the output.
 >
 > Kind regards,
 > Steven
 >
 > On Mon, May 3, 2021 at 6:14 AM Jean-Baptiste Onofre 
 wrote:
 > Hi Daniel,
 >
 > JMX collector polls all MBeans attributes. However Prometheus
 appender only expose metrics (numeric) on the Prometheus servlet:
 >
 > http://localhost:8181/decanter/prometheus
 >
 > As the generated JMX JSON is "more" than just numeric, it’s possible
 that you don’t have the

Re: FileInstaller with 4.3.3

[Jesse White]

We're hitting a similar problem with the deploy/ folder and can reproduce with 
a vanilla distribution of Karaf 4.3.3.

On Mac OS w/ JDK 11:

  tar zxvf apache-karaf-4.3.3.tar.gz && cd apache-karaf-4.3.3
  cp /tmp/confd-telemetry-feature.xml deploy/
  ./bin/karaf clean

  karaf@root()> feature:info confd-telemetry-auto
  Feature not found

Similar test with Karaf 4.3.2 shows:

  karaf@root()> feature:info  confd-telemetry-auto
  Feature confd-telemetry-auto 1.0.0
  Feature configuration:
org.opennms.features.telemetry.listeners-single-port-flows
org.opennms.features.telemetry.listeners-JTI-Listener
org.opennms.features.telemetry.listeners-NXOS-Listener
  ...

Here's a reference to the feature file in question:
   https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b

Thanks for all the effort in maintaining the distribution - looking forward to 
getting R7 up and running with JDK 17!

Best,
Jesse

From: Jean-Baptiste Onofre 
Sent: Tuesday, September 21, 2021 9:39 AM
To: user@karaf.apache.org 
Subject: Re: FileInstaller with 4.3.3

WARNING: This email originated outside of NantHealth.
DO NOT CLICK links or attachments unless you recognize the sender and are 
expecting this email.


Yes, I tried both, no clean, clean as argument, clean in config.properties.

All works fine.

Can you share some details about your test case and environment (especially if 
you are on Windows or Unix) ?

Regards
JB

> Le 21 sept. 2021 à 15:00, Matthias Leinweber  a 
> écrit :
>
> For me it's a custom dist. Did you do a clean start?
>
> Am Di., 21. Sept. 2021 um 14:28 Uhr schrieb Jean-Baptiste Onofre 
> :
> Hi,
>
> I did several test and it works fine for me.
>
> Here’s the very simplest test:
>
> - Starting from Karaf 4.3.3 vanilla
> - I put commons-lang-2.6.jar in the deploy folder (while Karaf is stopped)
> - then, I’m starting Karaf with bin/karaf
> - When I checked the bundle:list:
>
> 54 │ Active   │  10 │ 2.6.7  │ OPS4J Pax Url - wrap:
> 55 │ Active   │  80 │ 2.6│ Commons Lang
>
> So, you can see commons-lang installed and active, meaning the deployers 
> deployed it from the deploy folder.
>
> It works for me.
>
> Can you elaborate a bit your test case ?
> Is it a custom distribution ?
>
> Regards
> JB
>
> > Le 20 sept. 2021 à 08:29, Paul Fraser  a écrit :
> >
> > Hi JB,
> >
> > Any result on this check?
> >
> > Paul Fraser
> >
> > On 17/9/21 9:55 pm, JB Onofré wrote:
> >> I checked etc I will check deploy now.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 17 sept. 2021 à 12:29, Paul Fraser  a écrit :
> >>>
> >>> Hi JB,
> >>>
> >>> In my case the problem occurs using the deploy folder.
> >>>
> >>> Exact same code in 4.3.2 works, 4.3.3 does not install the deploy folder 
> >>> files.
> >>>
> >>> Paul
> >>>
>  On 17/9/21 7:04 pm, Jean-Baptiste Onofré wrote:
>  Hi,
> 
>  did you updated the etc location in etc/config.properties (in the 
>  felix.fileinstall.dir property) ?
> 
>  I just tried and it works fine for me. Here's my test case:
> 
>  1. I created etc/my.config.cfg containing foo=bar
>  2. I'm starting karaf
>  3. I can see the config loaded:
> 
>  karaf@root()> config:list "(service.pid=my.config)"
> 
> 
> 
> 
>  
>  Pid:my.config
>  BundleLocation: ?
>  Properties:
> felix.fileinstall.filename = 
>  file:/home/jbonofre/Workspace/karaf/assemblies/apache-karaf/target/apache-karaf-4.3.4-SNAPSHOT/etc/my.config.cfg
> foo = bar
> service.pid = my.config
> 
>  Can you share your test case ?
> 
>  Regards
>  JB
> 
> 
> 
> > On 16/09/2021 14:31, Matthias Leinweber wrote:
> > Hello,
> >
> > I am having a strange issue after I updated my assembly to 4.3.3. I am 
> > using a custom file installer location which I deploy with a feature.
> >
> > The strange thing is that the folder is not processed automatically at 
> > startup, but if I touch a single file in the folder all others files 
> > get processed as well.
> >
> > Any ideas?
> >
> > br,
> > Matthias
>
>
>
>

CONFIDENTIALITY NOTICE
This e-mail message and any attachments are only for the use of the intended 
recipient and may contain information that is privileged, confidential or 
exempt from disclosure under applicable law. If you are not the intended 
recipient, any disclosure, distribution or other use of this e-mail message or 
attachments is prohibited. If you have received this e-mail message in error, 
please delete and notify the sender immediately. Thank you.

Re: Decanter and JMX

[JB Onofré]

Oh yes. It just has to be exposed. I will do that. 

I forgot, sorry for the inconvenience. 

Regards 
JB

> Le 22 sept. 2021 à 15:50, Steven Huypens  a écrit :
> 
> 
> Hi JB,
> 
> While trying to expose a micrometer Gauge, I noticed that its Double value is 
> not shown by the PrometheusServlet. Apparently only Integers and Longs are. 
> Any reason for this ? Looks like an easy fix to handle Doubles as well.
> 
> Best regards,
> Steven
> 
>> On Sun, Sep 19, 2021 at 3:33 PM Steven Huypens  
>> wrote:
>> 
>> Great !
>> 
>> Anyway, thanks for the 2.8.0 release. Decanter now offers a prometheus 
>> endpoint with the properties we need out-of-the-box.
>> 
>> Steven
>> 
>>> On Sun, Sep 19, 2021 at 1:58 PM JB Onofré  wrote:
>>> Ah that’s on the jmx collector then not Prometheus appender: the Prometheus 
>>> appender just use property names provided by the collectors. 
>>> 
>>> I think it makes sense to use full object name and collector prefix to 
>>> differentiate the properties name. 
>>> 
>>> I will do that for next decanter release. 
>>> 
>>> Thanks for pointing this. 
>>> 
>>> Regards 
>>> JB
>>> 
> Le 19 sept. 2021 à 12:53, Steven Huypens  a 
> écrit :
> 
 
 Hi JB,
 
 Thanks for the clarification, it works for me as described now. 
 
 However, the problem I wanted to address was that if two different MBeans 
 would contain the exact same property, I see no way of differentiating 
 between them. In fact I think only one of the properties will be shown by 
 the Prometheus servlet.
 
 At the moment that's not a real problem for me, just wanted to let you 
 know and suggest the possibility of a prefix eg.
 
 java_lang_Memory_HeapMemoryUsage_committed
 java_lang_Memory_HeapMemoryUsage_init 
 java_lang_Memory_HeapMemoryUsage_max
 java_lang_Memory_HeapMemoryUsage_used
 
 Best regards,
 Steven
 
> On Sun, Sep 19, 2021 at 11:30 AM Jean-Baptiste Onofre  
> wrote:
> Hi Steven,
> 
> I’m about to write a quick blog post to give some highlights about this 
> change.
> 
> Basically, I did these two other changes:
> 
> 1. For « descendent » properties (the properties inside a Map for 
> instance), the property is now named [MAP_PROPERTY]_[ENTRY_PROPERTY]:
> 
> https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java#L74
> 
> 2. You can specify the property you want to « render » in the Prometheus 
> servlet using prometheus.key.foo in 
> etc/org.apache.karaf.decanter.appender.prometheus.cfg:
> 
> https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java#L69
> 
> I hope it helps.
> 
> Regards
> JB
> 
> > Le 19 sept. 2021 à 10:16, Steven Huypens  a 
> > écrit :
> > 
> > Hi JB,
> > 
> > I've tested the new 2.8.0 decanter release and I'm pleased to say your 
> > fix for https://issues.apache.org/jira/browse/KARAF-7154 works great. 
> > Thanks for that !
> > 
> > However I couldn't figure out from the pull request what changes you 
> > made related to my second suggestion, to better identify from which 
> > MBean the properties are (or as you put it 'allow user to define the 
> > "exported" event properties by configuration'). Can you please explain 
> > how I can achieve this ?
> > 
> > Kind regards,
> > Steven
> > 
> > On Wed, May 12, 2021 at 6:57 PM Steven Huypens 
> >  wrote:
> > Hi Jean-Baptist,
> > 
> > 1) You mention the Prometheus appender only exposes the numeric 
> > metrics. I believe it would be a minor but very useful addition to also 
> > expose the Objects in a CompositeDataSupport. For example 
> > java.lang.memory has a HeapMemoryUsage-object which contains 4 values 
> > (committed, init, max & used) that could easily be exposed as well.
> > 
> > 2) I also would like to suggest to prefix the outputted name of a 
> > property with something that really identifies the MBean, eg. :
> > 
> > java_lang_Memory_HeapMemoryUsage_committed
> > java_lang_Memory_HeapMemoryUsage_init 
> > java_lang_Memory_HeapMemoryUsage_max
> > java_lang_Memory_HeapMemoryUsage_used
> > 
> > Currently MBeans having the same properties will have their values 
> > overridden in the output.
> > 
> > Kind regards,
> > Steven
> > 
> > On Mon, May 3, 2021 at 6:14 AM Jean-Baptiste Onofre  
> > wrote:
> > Hi Daniel,
> > 
> > JMX collector polls all MBeans attributes. However Prometheus appender 
> > only expose metrics (numeric) on the Prometheus servlet:
> > 
> > http://localhost:8181/decanter/prometheus
> > 
> > As the generated JMX JSON is "more" than just 

Re: Decanter and JMX

[Steven Huypens]

Hi JB,

While trying to expose a micrometer  Gauge, I
noticed that its Double value is not shown by the PrometheusServlet.
Apparently only Integers and Longs are. Any reason for this ? Looks like an
easy fix to handle Doubles as well.

Best regards,
Steven

On Sun, Sep 19, 2021 at 3:33 PM Steven Huypens 
wrote:

>
> Great !
>
> Anyway, thanks for the 2.8.0 release. Decanter now offers a prometheus
> endpoint with the properties we need out-of-the-box.
>
> Steven
>
> On Sun, Sep 19, 2021 at 1:58 PM JB Onofré  wrote:
>
>> Ah that’s on the jmx collector then not Prometheus appender: the
>> Prometheus appender just use property names provided by the collectors.
>>
>> I think it makes sense to use full object name and collector prefix to
>> differentiate the properties name.
>>
>> I will do that for next decanter release.
>>
>> Thanks for pointing this.
>>
>> Regards
>> JB
>>
>> Le 19 sept. 2021 à 12:53, Steven Huypens  a
>> écrit :
>>
>> 
>> Hi JB,
>>
>> Thanks for the clarification, it works for me as described now.
>>
>> However, the problem I wanted to address was that if two different MBeans
>> would contain the exact same property, I see no way of differentiating
>> between them. In fact I think only one of the properties will be shown by
>> the Prometheus servlet.
>>
>> At the moment that's not a real problem for me, just wanted to let you
>> know and suggest the possibility of a prefix eg.
>>
>> java_lang_Memory_HeapMemoryUsage_committed
>> java_lang_Memory_HeapMemoryUsage_init
>> java_lang_Memory_HeapMemoryUsage_max
>> java_lang_Memory_HeapMemoryUsage_used
>>
>> Best regards,
>> Steven
>>
>> On Sun, Sep 19, 2021 at 11:30 AM Jean-Baptiste Onofre 
>> wrote:
>>
>>> Hi Steven,
>>>
>>> I’m about to write a quick blog post to give some highlights about this
>>> change.
>>>
>>> Basically, I did these two other changes:
>>>
>>> 1. For « descendent » properties (the properties inside a Map for
>>> instance), the property is now named [MAP_PROPERTY]_[ENTRY_PROPERTY]:
>>>
>>>
>>> https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java#L74
>>>
>>> 2. You can specify the property you want to « render » in the Prometheus
>>> servlet using prometheus.key.foo in
>>> etc/org.apache.karaf.decanter.appender.prometheus.cfg:
>>>
>>>
>>> https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java#L69
>>>
>>> I hope it helps.
>>>
>>> Regards
>>> JB
>>>
>>> > Le 19 sept. 2021 à 10:16, Steven Huypens  a
>>> écrit :
>>> >
>>> > Hi JB,
>>> >
>>> > I've tested the new 2.8.0 decanter release and I'm pleased to say your
>>> fix for https://issues.apache.org/jira/browse/KARAF-7154 works great.
>>> Thanks for that !
>>> >
>>> > However I couldn't figure out from the pull request what changes you
>>> made related to my second suggestion, to better identify from which MBean
>>> the properties are (or as you put it 'allow user to define the "exported"
>>> event properties by configuration'). Can you please explain how I can
>>> achieve this ?
>>> >
>>> > Kind regards,
>>> > Steven
>>> >
>>> > On Wed, May 12, 2021 at 6:57 PM Steven Huypens <
>>> steven.huyp...@gmail.com> wrote:
>>> > Hi Jean-Baptist,
>>> >
>>> > 1) You mention the Prometheus appender only exposes the numeric
>>> metrics. I believe it would be a minor but very useful addition to also
>>> expose the Objects in a CompositeDataSupport. For example java.lang.memory
>>> has a HeapMemoryUsage-object which contains 4 values (committed, init, max
>>> & used) that could easily be exposed as well.
>>> >
>>> > 2) I also would like to suggest to prefix the outputted name of a
>>> property with something that really identifies the MBean, eg. :
>>> >
>>> > java_lang_Memory_HeapMemoryUsage_committed
>>> > java_lang_Memory_HeapMemoryUsage_init
>>> > java_lang_Memory_HeapMemoryUsage_max
>>> > java_lang_Memory_HeapMemoryUsage_used
>>> >
>>> > Currently MBeans having the same properties will have their values
>>> overridden in the output.
>>> >
>>> > Kind regards,
>>> > Steven
>>> >
>>> > On Mon, May 3, 2021 at 6:14 AM Jean-Baptiste Onofre 
>>> wrote:
>>> > Hi Daniel,
>>> >
>>> > JMX collector polls all MBeans attributes. However Prometheus appender
>>> only expose metrics (numeric) on the Prometheus servlet:
>>> >
>>> > http://localhost:8181/decanter/prometheus
>>> >
>>> > As the generated JMX JSON is "more" than just numeric, it’s possible
>>> that you don’t have the metrics.
>>> >
>>> > You can check the JMX JSON using another kind of appender (like log
>>> appender or elasticsearch).
>>> > I can add kind of "json introspection" on the Prometheus appender to
>>> "force" some JSON fields as metrics (gauge).
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > > Le 2 mai 2021 à 22:24, Daniel Las  a écrit :
>>> > >
>>> > > Hi,
>>> > >
>>> > > I installed Decanter 2.7.0 on Karaf 4.2.11 with

Re: Karaf feature update without internet connection

[Andre Schlegel-Tylla]

Tried with the following




org.apache.maven.wagon
wagon-ssh
3.4.3



Also tried wagon-http. The error doesn't change.

Regards
Andre

Am Mi., 22. Sept. 2021 um 10:20 Uhr schrieb Jean-Baptiste Onofre <
j...@nanthrax.net>:

> Hi,
>
> I guess you should add wagon as dependency of the karaf-maven-plugin
> execution.
>
> Regards
> JB
>
> > Le 22 sept. 2021 à 09:45, Andre Schlegel-Tylla <
> andre.schle...@virtimo.de> a écrit :
> >
> > Hi JB,
> >
> > I tried this:
> >
> > 
> > 4.0.0
> > test
> > de.virtimo.bpc
> > 1.0.0-SNAPSHOT
> > 
> > 
> > 
> > org.apache.karaf.tooling
> > features-maven-plugin
> > 2.4.4
> >
> > 
> > 
> > add-features-to-repo
> > generate-resources
> > 
> > add-features-to-repo
> > 
> > 
> > 
> >
>  
> mvn:org.apache.cxf.karaf/apache-cxf/3.3.11/xml/feature
> > 
> > 
> > cxf
> > 
> > target/features-repo
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > But when I get this error:
> >
> > [ERROR] Failed to execute goal
> org.apache.karaf.tooling:features-maven-plugin:2.4.4:add-features-to-repo
> (add-features-to-repo) on project test: Can't resolve bundle
> org.apache.cxf.karaf:apache-cxf:xml:feature:3.3.11: Could not transfer
> artifact org.apache.cxf.karaf:apache-cxf:xml:feature:3.3.11 from/to central
> (https://repo.maven.apache.org/maven2): Cannot access
> https://repo.maven.apache.org/maven2 with type default using the
> available connector factories: BasicRepositoryConnectorFactory
> > [ERROR]   org.apache.cxf.karaf:apache-cxf:xml:3.3.11
> > [ERROR]
> > [ERROR] from the specified remote repositories:
> > [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true,
> snapshots=true),
> > [ERROR]   virtimo-central (
> https://virtimo.jfrog.io/artifactory/libs-release, releases=true,
> snapshots=false),
> > [ERROR]   virtimo-snapshots (
> https://virtimo.jfrog.io/artifactory/libs-snapshot, releases=true,
> snapshots=true): Cannot access https://repo.maven.apache.org/maven2 using
> the registered transporter factories: WagonTransporterFactory: Unsupported
> transport protocol https: com.google.inject.ProvisionException: Unable to
> provision, see the following errors:
> > [ERROR]
> > [ERROR] 1) Error in custom provider, java.lang.TypeNotPresentException:
> Type org.apache.maven.wagon.providers.http.HttpWagon$__sisu33 not present
> > [ERROR]   at
> ClassRealm[plugin>org.apache.karaf.tooling:features-maven-plugin:2.4.4,
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@4b85612c] (via
> modules: org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> > [ERROR]   while locating org.apache.maven.wagon.Wagon annotated with
> @com.google.inject.name.Named(value="https")
> > [ERROR]
> > [ERROR] 1 error
> > [ERROR]   role: org.apache.maven.wagon.Wagon
> > [ERROR]   roleHint: https:
> org/apache/maven/wagon/providers/http/HttpWagon
> > [ERROR] -> [Help 1]
> >
> > The maven repo config is fine. He loaded the plugin from maven (the
> 2.4.5-SNAPSHOT which is mentioned in the documentation is not available).
> >
> > Regards
> > Andre
> >
> > Am Di., 21. Sept. 2021 um 08:36 Uhr schrieb Jean-Baptiste Onofre <
> j...@nanthrax.net>:
> > Hi Andre,
> >
> > You can populate the system maven repository using add-features-to-repo
> goal of the Karaf-maven-plugin.
> >
> > Regards
> > JB
> >
> > > Le 21 sept. 2021 à 08:25, Andre Schlegel-Tylla <
> andre.schlegel-ty...@virtimo.de> a écrit :
> > >
> > > Hello,
> > >
> > > we want to update CXF on some customer systems. This is no problem
> with an internet connection. We also now how to install a single jar file
> into the local maven repository. But in this case CXF is based on many
> features.
> > >
> > > How can we update all the used CXF features? A Karaf update is
> currently no option.
> > >
> > > Kind regards
> > > Andre
> >
>
>

Re: Karaf feature update without internet connection

[Jean-Baptiste Onofre]

Hi,

I guess you should add wagon as dependency of the karaf-maven-plugin execution.

Regards
JB

> Le 22 sept. 2021 à 09:45, Andre Schlegel-Tylla  a 
> écrit :
> 
> Hi JB,
> 
> I tried this:
> 
> 
> 4.0.0
> test
> de.virtimo.bpc
> 1.0.0-SNAPSHOT
> 
> 
> 
> org.apache.karaf.tooling
> features-maven-plugin
> 2.4.4
> 
> 
> 
> add-features-to-repo
> generate-resources
> 
> add-features-to-repo
> 
> 
> 
> 
> mvn:org.apache.cxf.karaf/apache-cxf/3.3.11/xml/feature
> 
> 
> cxf
> 
> target/features-repo
> 
> 
> 
> 
> 
> 
> 
> But when I get this error:
> 
> [ERROR] Failed to execute goal 
> org.apache.karaf.tooling:features-maven-plugin:2.4.4:add-features-to-repo 
> (add-features-to-repo) on project test: Can't resolve bundle 
> org.apache.cxf.karaf:apache-cxf:xml:feature:3.3.11: Could not transfer 
> artifact org.apache.cxf.karaf:apache-cxf:xml:feature:3.3.11 from/to central 
> (https://repo.maven.apache.org/maven2): Cannot access 
> https://repo.maven.apache.org/maven2 with type default using the available 
> connector factories: BasicRepositoryConnectorFactory
> [ERROR]   org.apache.cxf.karaf:apache-cxf:xml:3.3.11
> [ERROR] 
> [ERROR] from the specified remote repositories:
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=true),
> [ERROR]   virtimo-central (https://virtimo.jfrog.io/artifactory/libs-release, 
> releases=true, snapshots=false),
> [ERROR]   virtimo-snapshots 
> (https://virtimo.jfrog.io/artifactory/libs-snapshot, releases=true, 
> snapshots=true): Cannot access https://repo.maven.apache.org/maven2 using the 
> registered transporter factories: WagonTransporterFactory: Unsupported 
> transport protocol https: com.google.inject.ProvisionException: Unable to 
> provision, see the following errors:
> [ERROR] 
> [ERROR] 1) Error in custom provider, java.lang.TypeNotPresentException: Type 
> org.apache.maven.wagon.providers.http.HttpWagon$__sisu33 not present
> [ERROR]   at 
> ClassRealm[plugin>org.apache.karaf.tooling:features-maven-plugin:2.4.4, 
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@4b85612c] (via 
> modules: org.eclipse.sisu.wire.WireModule -> 
> org.eclipse.sisu.plexus.PlexusBindingModule)
> [ERROR]   while locating org.apache.maven.wagon.Wagon annotated with 
> @com.google.inject.name.Named(value="https")
> [ERROR] 
> [ERROR] 1 error
> [ERROR]   role: org.apache.maven.wagon.Wagon
> [ERROR]   roleHint: https: org/apache/maven/wagon/providers/http/HttpWagon
> [ERROR] -> [Help 1]
> 
> The maven repo config is fine. He loaded the plugin from maven (the 
> 2.4.5-SNAPSHOT which is mentioned in the documentation is not available).
> 
> Regards
> Andre
> 
> Am Di., 21. Sept. 2021 um 08:36 Uhr schrieb Jean-Baptiste Onofre 
> :
> Hi Andre,
> 
> You can populate the system maven repository using add-features-to-repo goal 
> of the Karaf-maven-plugin.
> 
> Regards
> JB
> 
> > Le 21 sept. 2021 à 08:25, Andre Schlegel-Tylla 
> >  a écrit :
> > 
> > Hello,
> > 
> > we want to update CXF on some customer systems. This is no problem with an 
> > internet connection. We also now how to install a single jar file into the 
> > local maven repository. But in this case CXF is based on many features.
> > 
> > How can we update all the used CXF features? A Karaf update is currently no 
> > option.
> > 
> > Kind regards
> > Andre
> 

Re: Karaf feature update without internet connection

[Andre Schlegel-Tylla]

Hi JB,

I tried this:


4.0.0
test
de.virtimo.bpc
1.0.0-SNAPSHOT



org.apache.karaf.tooling
features-maven-plugin
2.4.4



add-features-to-repo
generate-resources

add-features-to-repo




mvn:org.apache.cxf.karaf/apache-cxf/3.3.11/xml/feature


cxf

target/features-repo








But when I get this error:

[ERROR] Failed to execute goal
org.apache.karaf.tooling:features-maven-plugin:2.4.4:add-features-to-repo
(add-features-to-repo) on project test: Can't resolve bundle
org.apache.cxf.karaf:apache-cxf:xml:feature:3.3.11: Could not transfer
artifact org.apache.cxf.karaf:apache-cxf:xml:feature:3.3.11 from/to central
(https://repo.maven.apache.org/maven2): Cannot access
https://repo.maven.apache.org/maven2 with type default using the available
connector factories: BasicRepositoryConnectorFactory
[ERROR]   org.apache.cxf.karaf:apache-cxf:xml:3.3.11
[ERROR]
[ERROR] from the specified remote repositories:
[ERROR]   central (https://repo.maven.apache.org/maven2, releases=true,
snapshots=true),
[ERROR]   virtimo-central (https://virtimo.jfrog.io/artifactory/libs-release,
releases=true, snapshots=false),
[ERROR]   virtimo-snapshots (
https://virtimo.jfrog.io/artifactory/libs-snapshot, releases=true,
snapshots=true): Cannot access https://repo.maven.apache.org/maven2 using
the registered transporter factories: WagonTransporterFactory: Unsupported
transport protocol https: com.google.inject.ProvisionException: Unable to
provision, see the following errors:
[ERROR]
[ERROR] 1) Error in custom provider, java.lang.TypeNotPresentException:
Type org.apache.maven.wagon.providers.http.HttpWagon$__sisu33 not present
[ERROR]   at
ClassRealm[plugin>org.apache.karaf.tooling:features-maven-plugin:2.4.4,
parent: jdk.internal.loader.ClassLoaders$AppClassLoader@4b85612c] (via
modules: org.eclipse.sisu.wire.WireModule ->
org.eclipse.sisu.plexus.PlexusBindingModule)
[ERROR]   while locating org.apache.maven.wagon.Wagon annotated with
@com.google.inject.name.Named(value="https")
[ERROR]
[ERROR] 1 error
[ERROR]   role: org.apache.maven.wagon.Wagon
[ERROR]   roleHint: https: org/apache/maven/wagon/providers/http/HttpWagon
[ERROR] -> [Help 1]

The maven repo config is fine. He loaded the plugin from maven (the
2.4.5-SNAPSHOT which is mentioned in the documentation is not available).

Regards
Andre

Am Di., 21. Sept. 2021 um 08:36 Uhr schrieb Jean-Baptiste Onofre <
j...@nanthrax.net>:

> Hi Andre,
>
> You can populate the system maven repository using add-features-to-repo
> goal of the Karaf-maven-plugin.
>
> Regards
> JB
>
> > Le 21 sept. 2021 à 08:25, Andre Schlegel-Tylla <
> andre.schlegel-ty...@virtimo.de> a écrit :
> >
> > Hello,
> >
> > we want to update CXF on some customer systems. This is no problem with
> an internet connection. We also now how to install a single jar file into
> the local maven repository. But in this case CXF is based on many features.
> >
> > How can we update all the used CXF features? A Karaf update is currently
> no option.
> >
> > Kind regards
> > Andre
>
>