Re: FileInstaller with 4.3.3

[Paul Fraser]

Yes, running without clean works OK in my case.

Paul Fraser

On 23/9/21 6:45 pm, Jean-Baptiste Onofré wrote:

I guess it works fine without the clean arg right ?

Regards
JB

On 22/09/2021 13:15, Jesse White wrote:
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: Listening for bundle event

[Jean-Baptiste Onofré]

Hi,

Why not using Cellar for remote notification ?

Else, a simple possibility is to implement a bundle listener and use 
eventadmin to broadcast the events.


Regards
JB

On 23/09/2021 15:15, Andrei Petru Mura wrote:
I want to remotely manage my karaf instance, programatically. I think a 
good option for this is the JMX service which karaf already provides. Is 
there a way to simply add a listener for a bundle which I know follows 
to be installed and then to wait for notifications on this bundle state 
changes? Or any type of events related to it?


Thanks,
Andrei

Listening for bundle event

[Andrei Petru Mura]

I want to remotely manage my karaf instance, programatically. I think a
good option for this is the JMX service which karaf already provides. Is
there a way to simply add a listener for a bundle which I know follows to
be installed and then to wait for notifications on this bundle state
changes? Or any type of events related to it?

Thanks,
Andrei

Re: Shutdown issue ActiveMq

[Łukasz Dywicki]

Hey Jorg,
I am not too familiar with pax-jms, I do recall some of spring-jms 
troubles in the past (especially camel).
The big question is if your components actually do have an option for 
graceful shutdown. What you observe might be a very basic.


Looking at the sequence of actions you can see two paths of execution:
1. Container shutdown announced
2. Pool shutdown
3. Connection shutdown

1. Container shutdown announced
2. Component shutdown
3. Last will message
4. Connection close

If your only link between pool and component is connection itself you 
will observe a lot of such troubles. In order to do such you need to 
bind state of pool and client so they work together.
While shutdown of client should not cause shutdown of pool the reversed 
scenario is true. Also blueprint references might not be "up" at the 
time camel context is still awake.


A very basic workaround for that is building up a set of listeners ie. 
listening if connection factory is up in your client and vice versa.
Reverse listening (pool for clients) will help you to make graceful 
shutdown.


Hope that above puts some light on topic.

Best,
Łukasz
--
Code-House
http://code-house.org


On 22.09.2021 20:29, Jörg Jansen wrote:

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:

jms
spring
activemq-broker-noweb
activemq-client
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 

Re: FileInstaller with 4.3.3

[Jean-Baptiste Onofré]

I guess it works fine without the clean arg right ?

Regards
JB

On 22/09/2021 13:15, Jesse White wrote:
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.