Re: Experimenting with Karaf 5

[Matteo Rulli]

Thank you JB,

I’ll set up a project in and I’ll open a PR as soon as it is (sort of ☺) 
working.

There are couple of things we usually use in our apps such as weaving hook + 
byte-buddy and ConfigurationPlugins that will be interesting to test as well, 
but let us do one step a time.

Thank you very much,
Matteo

> On 28 Apr 2022, at 19:21, Jean-Baptiste Onofré  wrote:
> 
> Hi Matteo,
> 
> You have two approaches to implement what you propose:
> - Karaf 4 style deployed in Karaf5: K5 OSGi application manager will
> deploy the Karaf4 features service, and so you can use the same thing
> as in K4. You will see K4 distribution in K5 doing that.
> - Karaf 5 style, you implement your own K5 SPI
> - you use another approach like CDI, Spring Boot
> 
> I'm going to push K5 as a branch on the main Karaf repo. Anyway, you
> can submit your example directly on https://github.com/jbonofre/karaf5
> (in an example module for instance)
> 
> If you want, we can have a chat together about that.
> 
> Thanks for your help anyway !
> 
> Regards
> JB
> 
> On Thu, Apr 28, 2022 at 6:59 PM Matteo Rulli  wrote:
>> 
>> Hello,
>> 
>> I would like to start playing with Karaf5, waiting for the official RC... 
>> With the final goal of migrating a few OSGi 3-tier projects (Hibernate, 
>> Declarative Services, Apache CXF REST) to Karaf-5 my idea is:
>> - Put together a very trivial JPA+CXF project using "Karaf-JPA-example" and 
>> "Karaf-rest-example" in Karaf's examples module
>> - Create a feature for the complete "demo application"
>> - Run this application in Karaf-5, deploying the application feature.
>> 
>> The lesson learned will be used in the actual migration process. Before I 
>> start working head-down on this, I would like your advice: is this approach 
>> going to work with Karaf 5? Or is there any evident show-stopper I should be 
>> aware?
>> 
>> Many thanks for your help.
>> 
>> Best regards,
>> Matteo

Experimenting with Karaf 5

[Matteo Rulli]

Hello,

I would like to start playing with Karaf5, waiting for the official RC... With 
the final goal of migrating a few OSGi 3-tier projects (Hibernate, Declarative 
Services, Apache CXF REST) to Karaf-5 my idea is:
- Put together a very trivial JPA+CXF project using "Karaf-JPA-example" and 
"Karaf-rest-example" in Karaf's examples module
- Create a feature for the complete "demo application"
- Run this application in Karaf-5, deploying the application feature.

The lesson learned will be used in the actual migration process. Before I start 
working head-down on this, I would like your advice: is this approach going to 
work with Karaf 5? Or is there any evident show-stopper I should be aware?

Many thanks for your help.

Best regards,
Matteo

Re: OpenAPI and CXF issues with Karaf 4.2.11

[Matteo Rulli]

Hello JB,

II tried the following:

Swagger: force the mvn:io.swagger.core.v3/swagger-jaxrs2/2.1.4 to import 
javax.servlet* in version range javax.servlet*;version="[0,4.1)"
CXF: remove the optional attribute for the osgi.cmpn dependency in the 
/cxf/rt/transports/http/pom.xml
Karaf: getting rid of the throw new UnsupportedOperationException() in the 
uninstall method of 
karaf/features/core/src/main/java/org/apache/karaf/features/internal/service/StaticInstallSupport.java
The third point was necessary as the feature was uninstalling the 
org.ops4j.pax.url.wrap bundle during resolution (why it was I know not). 

Overwriting locally the corresp. artifacts with these three modifications I 
manage to get around the issue. Obviously this is not a solution to the problem.

What would you suggest?

Many thanks,
Matteo


> On 1 Jun 2021, at 06:03, Jean-Baptiste Onofre  wrote:
> 
> Hi Matteo,
> 
> At first glance, it seems to be more an issue with CXF hat should extend the 
> range.
> 
> I will take a look.
> 
> Regards
> JB
> 
>> Le 1 juin 2021 à 00:43, Matteo Rulli > <mailto:matteo.ru...@gmail.com>> a écrit :
>> 
>> Hello,
>> 
>> I recently moved one of our projects from Karaf 4.2.6 to 4.2.11. 
>> Unfortunately I got some errors, primarily due to swagger/openapi 
>> dependencies.
>> 
>> I tried to document and reproduce all the problems here 
>> https://github.com/mrulli/karaf-4211-cxf-swagger%3E%5D(%3Chttps://github.com/mrulli/karaf-4211-cxf-swagger%3E)>
>>  (https://github.com/mrulli/karaf-4211-cxf-swagger 
>> <https://github.com/mrulli/karaf-4211-cxf-swagger>): if you confirm they are 
>> bugs I could raise the corresp. issues but I'm not sure where to open them 
>> (CXF or Karaf).
>> 
>> If you want, I can try to add a couple of integration tests as PR: again, 
>> I'm not sure Karaf is the right place where these tests should be added.
>> 
>> Looking forward to your feedbacks,
>> Matteo
> 

OpenAPI and CXF issues with Karaf 4.2.11

[Matteo Rulli]

Hello,

I recently moved one of our projects from Karaf 4.2.6 to 4.2.11. Unfortunately 
I got some errors, primarily due to swagger/openapi dependencies.

I tried to document and reproduce all the problems here 
https://github.com/mrulli/karaf-4211-cxf-swagger%3E%5D(%3Chttps://github.com/mrulli/karaf-4211-cxf-swagger%3E)>
 (https://github.com/mrulli/karaf-4211-cxf-swagger): if you confirm they are 
bugs I could raise the corresp. issues but I'm not sure where to open them (CXF 
or Karaf).

If you want, I can try to add a couple of integration tests as PR: again, I'm 
not sure Karaf is the right place where these tests should be added.

Looking forward to your feedbacks,
Matteo

Re: [X-Mas Gift] Panel discussion about Karaf 5

[Matteo Rulli]

Hello,

I would like to participate very much indeed.

Thanks,
Matteo

> On 15 Dec 2020, at 18:32, Jean-Baptiste Onofre  wrote:
> 
> Hi guys,
> 
> Maybe some of you know that I started to work on Karaf 5.
> 
> I have something that it’s almost "usable".
> 
> Before sending a global discussion thread on the mailing list, I would like 
> to evaluate the ideas & big changes I did.
> 
> I would like to know if some of you would be interested by a panel discussion 
> call to introduce Karaf 5 (limited audience at first step).
> 
> The agenda of this call would be:
> 1. Pros/Cons about Karaf as it is today
> 2. Concepts in Karaf 5 (module, extension, …)
> 3. Building & running
> 4. Live demo
> 
> It could be recorded/webinar style (not necessary live call) for about 20 
> people at first step (both Karaf developers and users).
> The purpose is to evaluate the direction.
> 
> Thoughts ?
> Who would be interested ?
> 
> Thanks,
> Regards
> JB

Re: Unsupported Operation Exception in feature resolution

[Matteo Rulli]

I see, thank you for the explanation and for adding a more permissive behaviour 
to the karaf-maven-plugin. 

Just to know a little bit better how to control the refreshes, in general my 
understanding is the following
/ directives will install the bundle or the feature, no matter 
what is already installed
dependency=“true" will install the bundle/feature if and only if it is required 
by the resolver and it is not already installed
prerequisite=“true" will guarantee the prerequisite feature will be installed 
before the other stuff in the feature declaration
Is this correct? Is there any other attribute that can be used to control 
feature-based provisioning?

Thank you very much,
Matteo

> On 26 Jul 2019, at 13:12, Jean-Baptiste Onofré  wrote:
> 
> Actually, your features is causing a refresh (the flairkit-alarm-rest
> for instance).
> 
> So, the features resolver tries to uninstall a bundle to reinstall it.
> 
> It happens here:
> 
> https://github.com/apache/karaf/blob/karaf-4.2.x/features/core/src/main/java/org/apache/karaf/features/internal/service/StaticInstallSupport.java#L50
> 
> So, your feature will could work at runtime, but with a refresh.
> 
> I would recommend to fix your bundles to avoid the refresh.
> 
> Anyway, instead of failing, I can log a WARN message with the bundles in
> cause.
> 
> I created KARAF-6370 about that.
> 
> Regards
> JB
> 
> On 26/07/2019 11:40, Matteo Rulli wrote:
>> Hello,
>> 
>> Thanks. Yes we use the verify step of the karat-maven-plugin. Does this mean 
>> that the “verify” step can fail at build-time but the feature will work in a 
>> real deployment? If this is the case, what is the right approach to verify a 
>> feature before it is used or deployed? 
>> 
>> Thanks,
>> Matteo
>> 
>>> On 26 Jul 2019, at 11:31, Jean-Baptiste Onofré  wrote:
>>> 
>>> Hi,
>>> 
>>> I guess you have this with karaf-maven-plugin, right ?
>>> 
>>> The reason is that we use a "simplified" resolver in the plugin, not
>>> implementing all methods. That's why you have UnsupportedOperationException.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 26/07/2019 11:05, Matteo Rulli wrote:
>>>> Hello,
>>>> 
>>>> Karaf feature resolution fails due to
>>>> java.lang.UnsupportedOperationException. It is hard to understand the
>>>> root cause.
>>>> 
>>>> I managed to reproduce the issue in a relatively simple settings, you
>>>> can find it here: 
>>>> https://github.com/mrulli/karaf-426-feature-unsupported-op
>>>> 
>>>> Could you please help me to understand what is it happening here? 
>>>> 
>>>> Thanks,
>>>> Matteo
>>> 
>>> -- 
>>> 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: Unsupported Operation Exception in feature resolution

[Matteo Rulli]

Hello,

Thanks. Yes we use the verify step of the karat-maven-plugin. Does this mean 
that the “verify” step can fail at build-time but the feature will work in a 
real deployment? If this is the case, what is the right approach to verify a 
feature before it is used or deployed? 

Thanks,
Matteo

> On 26 Jul 2019, at 11:31, Jean-Baptiste Onofré  wrote:
> 
> Hi,
> 
> I guess you have this with karaf-maven-plugin, right ?
> 
> The reason is that we use a "simplified" resolver in the plugin, not
> implementing all methods. That's why you have UnsupportedOperationException.
> 
> Regards
> JB
> 
> On 26/07/2019 11:05, Matteo Rulli wrote:
>> Hello,
>> 
>> Karaf feature resolution fails due to
>> java.lang.UnsupportedOperationException. It is hard to understand the
>> root cause.
>> 
>> I managed to reproduce the issue in a relatively simple settings, you
>> can find it here: https://github.com/mrulli/karaf-426-feature-unsupported-op
>> 
>> Could you please help me to understand what is it happening here? 
>> 
>> Thanks,
>> Matteo
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Unsupported Operation Exception in feature resolution

[Matteo Rulli]

Hello,

Karaf feature resolution fails due to java.lang.UnsupportedOperationException. 
It is hard to understand the root cause.

I managed to reproduce the issue in a relatively simple settings, you can find 
it here: https://github.com/mrulli/karaf-426-feature-unsupported-op 


Could you please help me to understand what is it happening here? 

Thanks,
Matteo

Re: TransactionManager problems

[Matteo Rulli]

No luck, even restructuring the features to install JPA stuff only once didn’t 
help. The situation is still the same.

Logs tell nothing, they simply say "Lost DataSource" for all of them until I 
perform the stop and start of 
mvn:org.apache.aries.transaction/org.apache.aries.transaction.blueprint/1.1.1

Matteo

> On 19 Jul 2019, at 18:27, Matteo Rulli  wrote:
> 
> Hi,
> 
> Everything is installed through Karaf features. The features are many (about 
> 15) and three / four of them re-install JPA multiple times through the same 
> steps: 
> 
> osgi.service;objectClass=javax.persistence.EntityManager
> aries-blueprint
> pax-jdbc-postgresql
> mvn:org.apache.xbean/xbean-asm6-shaded/4.10
> 
> jndi
> openjpa3
> pax-jdbc-config
> pax-jdbc
> pax-jdbc-pool-dbcp2
> jpa
> transaction
> 
> This is unnecessary and I suspect it could be the root cause of the problem: 
> I’m trying to refactor the features to only do the steps above once. What do 
> you think?
> 
> Thank you,
> Matteo
>   
>> On 19 Jul 2019, at 06:25, Jean-Baptiste Onofré > <mailto:j...@nanthrax.net>> wrote:
>> 
>> Hi,
>> 
>> do you install the bundles directly or via feature ?
>> 
>> If you install bundle per bundle, if you don't have the right order, you
>> have to perform a refresh.
>> 
>> Regards
>> JB
>> 
>> On 18/07/2019 17:54, Matteo Rulli wrote:
>>> 
>>> Hello,
>>> 
>>> I have a Karaf-based application using JPA and something quite strange
>>> started happening after upgrading to Karaf 4.2.6. 
>>> 
>>> The Karaf bootup process terminates and our application runs OK (in
>>> particular, it can successfully interoperate with the underlying
>>> Postgres database). Nevertheless, the following error condition is
>>> reported by the karaf diag command:
>>> 
>>> karaf@root()> diag
>>> Apache Aries Transaction Blueprint (113)
>>> 
>>> Status: Waiting
>>> Blueprint
>>> 7/18/19 5:24 PM
>>> Missing dependencies:
>>> (objectClass=javax.transaction.TransactionManager)
>>> Declarative Services
>>> 
>>> resulting in the following state (bundle list)
>>> 
>>> 113 │ Waiting │  80 │ 1.1.1  │ Apache Aries Transaction
>>> Blueprint
>>> 114 │ Active  │  80 │ 2.2.0  │ Apache Aries Transaction
>>> Blueprint
>>> ...
>>> 290 │ Active  │  80 │ 0.4.3  │ pax-transx-tm-api
>>> 291 │ Active  │  80 │ 0.4.3  │ pax-transx-tm-geronimo
>>> 
>>> On the other hand the TransactionManager service is there:
>>> 
>>> karaf@root()> service:list TransactionManager
>>> [javax.transaction.TransactionManager,
>>> javax.transaction.TransactionSynchronizationRegistry,
>>> javax.transaction.UserTransaction,
>>> org.apache.geronimo.transaction.manager.RecoverableTransactionManager]
>>> --
>>>  service.bundleid = 291
>>>  service.id <http://service.id/> <http://service.id <http://service.id/>> = 
>>> 352
>>>  service.scope = singleton
>>> Provided by :
>>>  pax-transx-tm-geronimo (291)
>>> Used by:
>>>  OpenJPA Aggregate Jar (213)
>>>  Contoso :: Persistence Provider (57)
>>>  Contoso :: OAuth :: Storage Provider (40)
>>>  Contoso :: Users :: Storage :: Users provider (324)
>>>  Contoso :: Device Management :: Store :: Provider (71)
>>>  OPS4J Pax JDBC Pooling DBCP2 (289)
>>>  Contoso :: Security :: X.509 :: Store :: Provider (314)
>>>  Apache Aries Transaction Blueprint (113)
>>>  Apache Aries JPA support (110)
>>> 
>>> [org.ops4j.pax.transx.tm.TransactionManager]
>>> 
>>>  service.bundleid = 291
>>>  service.id <http://service.id/> <http://service.id <http://service.id/>> = 
>>> 395
>>>  service.scope = singleton
>>> Provided by :
>>>  pax-transx-tm-geronimo (291)
>>> 
>>> karaf@root()> diag
>>> Apache Aries Transaction Blueprint (113)
>>> 
>>> Status: Waiting
>>> Blueprint
>>> 7/18/19 5:24 PM
>>> Missing dependencies:
>>> (objectClass=javax.transaction.TransactionManager)
>>> Declarative Services
>>> 
>>> The strange thing is that if I do
>>> 
>>> karaf@root()> stop 113
>>> karaf@root()> start 113
>>> 
>>> The error disappear:
>>> 
>>> karaf@root()> diag
>>> karaf@root()>
>>> 
>>> Any ideas on what it could be happening here?
>>> 
>>> Thanks,
>>> Matteo
>>> 
>> 
>> -- 
>> Jean-Baptiste Onofré
>> jbono...@apache.org <mailto:jbono...@apache.org>
>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>> Talend - http://www.talend.com <http://www.talend.com/>

Re: TransactionManager problems

[Matteo Rulli]

Hi,

Everything is installed through Karaf features. The features are many (about 
15) and three / four of them re-install JPA multiple times through the same 
steps: 

osgi.service;objectClass=javax.persistence.EntityManager
aries-blueprint
pax-jdbc-postgresql
mvn:org.apache.xbean/xbean-asm6-shaded/4.10

jndi
openjpa3
pax-jdbc-config
pax-jdbc
pax-jdbc-pool-dbcp2
jpa
transaction

This is unnecessary and I suspect it could be the root cause of the problem: 
I’m trying to refactor the features to only do the steps above once. What do 
you think?

Thank you,
Matteo

> On 19 Jul 2019, at 06:25, Jean-Baptiste Onofré  wrote:
> 
> Hi,
> 
> do you install the bundles directly or via feature ?
> 
> If you install bundle per bundle, if you don't have the right order, you
> have to perform a refresh.
> 
> Regards
> JB
> 
> On 18/07/2019 17:54, Matteo Rulli wrote:
>> 
>> Hello,
>> 
>> I have a Karaf-based application using JPA and something quite strange
>> started happening after upgrading to Karaf 4.2.6. 
>> 
>> The Karaf bootup process terminates and our application runs OK (in
>> particular, it can successfully interoperate with the underlying
>> Postgres database). Nevertheless, the following error condition is
>> reported by the karaf diag command:
>> 
>> karaf@root()> diag
>> Apache Aries Transaction Blueprint (113)
>> 
>> Status: Waiting
>> Blueprint
>> 7/18/19 5:24 PM
>> Missing dependencies:
>> (objectClass=javax.transaction.TransactionManager)
>> Declarative Services
>> 
>> resulting in the following state (bundle list)
>> 
>> 113 │ Waiting │  80 │ 1.1.1  │ Apache Aries Transaction
>> Blueprint
>> 114 │ Active  │  80 │ 2.2.0  │ Apache Aries Transaction
>> Blueprint
>> ...
>> 290 │ Active  │  80 │ 0.4.3  │ pax-transx-tm-api
>> 291 │ Active  │  80 │ 0.4.3  │ pax-transx-tm-geronimo
>> 
>> On the other hand the TransactionManager service is there:
>> 
>> karaf@root()> service:list TransactionManager
>> [javax.transaction.TransactionManager,
>> javax.transaction.TransactionSynchronizationRegistry,
>> javax.transaction.UserTransaction,
>> org.apache.geronimo.transaction.manager.RecoverableTransactionManager]
>> --
>>  service.bundleid = 291
>>  service.id <http://service.id/> <http://service.id <http://service.id/>> = 
>> 352
>>  service.scope = singleton
>> Provided by :
>>  pax-transx-tm-geronimo (291)
>> Used by:
>>  OpenJPA Aggregate Jar (213)
>>  Contoso :: Persistence Provider (57)
>>  Contoso :: OAuth :: Storage Provider (40)
>>  Contoso :: Users :: Storage :: Users provider (324)
>>  Contoso :: Device Management :: Store :: Provider (71)
>>  OPS4J Pax JDBC Pooling DBCP2 (289)
>>  Contoso :: Security :: X.509 :: Store :: Provider (314)
>>  Apache Aries Transaction Blueprint (113)
>>  Apache Aries JPA support (110)
>> 
>> [org.ops4j.pax.transx.tm.TransactionManager]
>> 
>>  service.bundleid = 291
>>  service.id <http://service.id/> <http://service.id <http://service.id/>> = 
>> 395
>>  service.scope = singleton
>> Provided by :
>>  pax-transx-tm-geronimo (291)
>> 
>> karaf@root()> diag
>> Apache Aries Transaction Blueprint (113)
>> 
>> Status: Waiting
>> Blueprint
>> 7/18/19 5:24 PM
>> Missing dependencies:
>> (objectClass=javax.transaction.TransactionManager)
>> Declarative Services
>> 
>> The strange thing is that if I do
>> 
>> karaf@root()> stop 113
>> karaf@root()> start 113
>> 
>> The error disappear:
>> 
>> karaf@root()> diag
>> karaf@root()>
>> 
>> Any ideas on what it could be happening here?
>> 
>> Thanks,
>> Matteo
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org <mailto:jbono...@apache.org>
> http://blog.nanthrax.net <http://blog.nanthrax.net/>
> Talend - http://www.talend.com <http://www.talend.com/>

TransactionManager problems

[Matteo Rulli]

Hello,

I have a Karaf-based application using JPA and something quite strange started 
happening after upgrading to Karaf 4.2.6. 

The Karaf bootup process terminates and our application runs OK (in particular, 
it can successfully interoperate with the underlying Postgres database). 
Nevertheless, the following error condition is reported by the karaf diag 
command:

karaf@root()> diag
Apache Aries Transaction Blueprint (113)

Status: Waiting
Blueprint
7/18/19 5:24 PM
Missing dependencies:
(objectClass=javax.transaction.TransactionManager)
Declarative Services

resulting in the following state (bundle list)

113 │ Waiting │  80 │ 1.1.1  │ Apache Aries Transaction Blueprint
114 │ Active  │  80 │ 2.2.0  │ Apache Aries Transaction Blueprint
...
290 │ Active  │  80 │ 0.4.3  │ pax-transx-tm-api
291 │ Active  │  80 │ 0.4.3  │ pax-transx-tm-geronimo

On the other hand the TransactionManager service is there:

karaf@root()> service:list TransactionManager
[javax.transaction.TransactionManager, 
javax.transaction.TransactionSynchronizationRegistry, 
javax.transaction.UserTransaction, 
org.apache.geronimo.transaction.manager.RecoverableTransactionManager]
--
 service.bundleid = 291
 service.id = 352
 service.scope = singleton
Provided by :
 pax-transx-tm-geronimo (291)
Used by:
 OpenJPA Aggregate Jar (213)
 Contoso :: Persistence Provider (57)
 Contoso :: OAuth :: Storage Provider (40)
 Contoso :: Users :: Storage :: Users provider (324)
 Contoso :: Device Management :: Store :: Provider (71)
 OPS4J Pax JDBC Pooling DBCP2 (289)
 Contoso :: Security :: X.509 :: Store :: Provider (314)
 Apache Aries Transaction Blueprint (113)
 Apache Aries JPA support (110)

[org.ops4j.pax.transx.tm.TransactionManager]

 service.bundleid = 291
 service.id = 395
 service.scope = singleton
Provided by :
 pax-transx-tm-geronimo (291)

karaf@root()> diag
Apache Aries Transaction Blueprint (113)

Status: Waiting
Blueprint
7/18/19 5:24 PM
Missing dependencies:
(objectClass=javax.transaction.TransactionManager)
Declarative Services

The strange thing is that if I do

karaf@root()> stop 113
karaf@root()> start 113

The error disappear:

karaf@root()> diag
karaf@root()>

Any ideas on what it could be happening here?

Thanks,
Matteo

Control Karaf boot-up process

[Matteo Rulli]

Hello,

I would like to know if there is a way in Karaf to delay the boot process until 
a specific bundle activator has been executed. In particular, I would like to 
perform some "environment validations” and checks and only if these are OK I 
would like to proceed with the Karaf boot-up.

Thank you for you help,
Matteo

Re: OpenJPA 3 and Karaf 4.2

[Matteo Rulli]

The jndi feature! That did the trick! 

Thank you Francois and Jean-Baptiste for your help and support.

And thanks to the Karaf team for the new 4.2.x line ☺.

Best regards,
Matteo

> On 7 Jan 2019, at 18:43, francois.papon  wrote:
> 
> Hi,
> 
> Did you installed the "jndi" feature?
> 
> Regards,
> 
> Francois
> 
> 
> 
> Envoyé depuis mon smartphone Samsung Galaxy.
> 
>  Message d'origine 
> De : Matteo Rulli 
> Date : 07/01/2019 21:34 (GMT+04:00)
> À : user@karaf.apache.org
> Objet : Re: OpenJPA 3 and Karaf 4.2
> 
> Hi!
> 
> Thank you for the feedback.
> 
> It seems the persistence unit name is ok. The blueprint component is 
> correctly wired with the services:
> 
> karaf@root()> services -u myjpaservice.impl 
> 
> myjpaservice.impl (18) uses:
> 
> [javax.persistence.spi.PersistenceProvider]
> [javax.sql.DataSource]
> [javax.persistence.EntityManagerFactory]
> [javax.transaction.TransactionManager, 
> javax.transaction.TransactionSynchronizationRegistry, 
> javax.transaction.UserTransaction, 
> org.apache.geronimo.transaction.manager.RecoverableTransactionManager]
> 
> And both EntityManager and TransactionManager are available on the service 
> registry:
> 
> karaf@root()> service:list EntityManager
> [javax.persistence.EntityManager]
> -
>  osgi.unit.name = myPersistenceUnit
>  service.bundleid = 18
>  service.id <http://service.id/> = 147
>  service.scope = singleton
> Provided by : 
>  myjpaservice.impl (18)
> 
> karaf@root()> service:list TransactionManager
> [javax.transaction.TransactionManager, 
> javax.transaction.TransactionSynchronizationRegistry, 
> javax.transaction.UserTransaction, 
> org.apache.geronimo.transaction.manager.RecoverableTransactionManager]
> --
>  service.bundleid = 110
>  service.id <http://service.id/> = 124
>  service.scope = singleton
> Provided by : 
>  pax-transx-tm-geronimo (110)
> Used by: 
>  OpenJPA Aggregate Jar (69)
>  OPS4J Pax JDBC Pooling DBCP2 (101)
>  myjpaservice.impl (18)
> 
> [org.ops4j.pax.transx.tm.TransactionManager]
> 
>  service.bundleid = 110
>  service.id <http://service.id/> = 126
>  service.scope = singleton
> Provided by : 
>  pax-transx-tm-geronimo (110)
> 
> Besides, the tables in the postgresqlDB database are correctly created during 
> pax-exam test boot-up: that should be a sign that the pax-jdbc and JPA are 
> running and well configured, right? The test fails as soon as the injected 
> entityManager is used, spitting out the stacktrace below. 
> 
> Could you please suggest what else I can check to identify what the problem 
> could be? The same project works fine with the previous version of Karaf and 
> OpenJPA: could the problem be triggered by some version incompatibilities 
> like the one you mentioned in your previous email?
> 
> Thank you very much,
> Matteo
> 
> 
> Complete stack trace:
> 
> 18:26:02,645 | WARN  | ion(3)-127.0.0.1 | JpaInterceptor   | 
> 29 - org.apache.aries.jpa.blueprint - 2.7.0 | Exception from 
> EmSupplier.preCall
> java.lang.reflect.UndeclaredThrowableException: null
>   at com.sun.proxy.$Proxy70.createEntityManager(Unknown Source) ~[?:?]
>   at 
> org.apache.aries.jpa.support.impl.EMSupplierImpl.createEm(EMSupplierImpl.java:68)
>  ~[?:?]
>   at 
> org.apache.aries.jpa.support.impl.EMSupplierImpl.get(EMSupplierImpl.java:86) 
> ~[?:?]
>   at 
> org.apache.aries.jpa.support.osgi.impl.EmProxy.invoke(EmProxy.java:38) ~[?:?]
>   at com.sun.proxy.$Proxy71.getProperties(Unknown Source) ~[?:?]
>   at Proxy6f73aaf4_20c4_4127_846f_6f5c625740c9.getProperties(Unknown 
> Source) ~[?:?]
>   at 
> org.apache.aries.jpa.blueprint.impl.JpaInterceptor.isResourceLocalInternal(JpaInterceptor.java:109)
>  ~[?:?]
>   at 
> org.apache.aries.jpa.blueprint.impl.JpaInterceptor.isResourceLocal(JpaInterceptor.java:99)
>  ~[?:?]
>   at 
> org.apache.aries.jpa.blueprint.impl.JpaInterceptor.preCall(JpaInterceptor.java:62)
>  ~[?:?]
>   at 
> org.apache.aries.blueprint.proxy.Collaborator.preInvoke(Collaborator.java:73) 
> ~[?:?]
>   at Proxy2b756db4_920f_4f1f_ab3f_93eac79d479c.addEntity(Unknown Source) 
> ~[?:?]
>   at 
> com.flairbit.examples.postgresjpa.TestModule.testCase(TestModule.java:118) 
> ~[?:?]
>   at sun.reflect.NativeMethodAcce

OpenJPA 3 and Karaf 4.2

[Matteo Rulli]

I tried to put together a project (here 
: 
https://github.com/mrulli/myjpaservice) to test how OpenJPA 3 and Karaf 4.2.x 
play together but I get the following error:

 javax.naming.NoInitialContextException: Need to specify class name in 
environment or system property, or as an applet parameter, or in an application 
resource file:  java.naming.factory.initial
at 
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662) ~[?:?]
at 
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) ~[?:?]
at 
javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350) 
~[?:?]
at javax.naming.InitialContext.lookup(InitialContext.java:417) ~[?:?]
at 
org.apache.openjpa.ee.RegistryManagedRuntime.getTransactionManager(RegistryManagedRuntime.java:63)
 ~[?:?]
at 
org.apache.openjpa.ee.AutomaticManagedRuntime.getTransactionManager(AutomaticManagedRuntime.java:171)
 ~[?:?]
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.syncWithManagedTransaction(AbstractBrokerFactory.java:728)
 ~[?:?]
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:399) 
~[?:?]
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:325) 
~[?:?]
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.initializeBroker(AbstractBrokerFactory.java:228)
 ~[?:?]
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:212)
 ~[?:?]
at 
org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:154)
 ~[?:?]
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:246)
 ~[?:?]
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:162)
 ~[?:?]
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:152)
 ~[?:?]
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:58)
 ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:?]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at 
org.apache.aries.jpa.container.impl.AriesEntityManagerFactoryBuilder$2.invoke(AriesEntityManagerFactoryBuilder.java:395)
 ~[?:?]
... 58 more

A similar project works fine with OpenJPA 2.4.1 and Karaf 4.1.

I saw an example project 

 in Karaf repo but the openjpa case seems unsupported/commented out. Is openjpa 
3 supported in Karaf 4.2?

Thank you for your help,

Matteo

Feature verify error with Karaf 4.2.2

[Matteo Rulli]

Hello,
On my to upgrade from Karaf 4.1 to Karaf 4.2 I hit this error:

[ERROR] Message: java.lang.UnsupportedOperationException

Apparently this is triggered by these kind of directives in my feature.xml: 

osgi.service;effective:=active;objectClass=com.flairbit.iot.security.x509.api.X509StoreService
osgi.service;effective:=active;objectClass=com.flairbit.iot.devman.api.SubscriptionStoreService

The same feature passes the verify goal in Karaf 4.1.x.

What do you suggest? What kind of breaking changes where introduced in the 
feature resolution/verify in Karaf 4.2.2?

Many thanks,

Matteo

Re: Openjpa feature resolution error on Karaf 4.2.2

[Matteo Rulli]

The error is this:

feature:install openjpa
org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: 
missing requirement [root] osgi.identity; osgi.identity=openjpa; 
type=karaf.feature; version="[3.0.0,3.0.0]"; 
filter:="(&(osgi.identity=openjpa)(type=karaf.feature)(version>=3.0.0)(version<=3.0.0))"
 [caused by: Unable to resolve openjpa/3.0.0: missing requirement 
[openjpa/3.0.0] osgi.identity; osgi.identity=org.apache.openjpa; 
type=osgi.bundle; version="[3.0.0,3.0.0]"; resolution:=mandatory [caused by: 
Unable to resolve org.apache.openjpa/3.0.0: missing requirement 
[org.apache.openjpa/3.0.0] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.apache.xbean.asm6)(version>=6.1.0)(!(version>=7.0.0)))"]]
at 
org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
at 
org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve 
openjpa/3.0.0: missing requirement [openjpa/3.0.0] osgi.identity; 
osgi.identity=org.apache.openjpa; type=osgi.bundle; version="[3.0.0,3.0.0]"; 
resolution:=mandatory [caused by: Unable to resolve org.apache.openjpa/3.0.0: 
missing requirement [org.apache.openjpa/3.0.0] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.apache.xbean.asm6)(version>=6.1.0)(!(version>=7.0.0)))"]
at 
org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
... 12 more
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve 
org.apache.openjpa/3.0.0: missing requirement [org.apache.openjpa/3.0.0] 
osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.apache.xbean.asm6)(version>=6.1.0)(!(version>=7.0.0)))"
at 
org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
... 13 more
Error executing command: Unable to resolve root: missing requirement [root] 
osgi.identity; osgi.identity=openjpa; type=karaf.feature; 
version="[3.0.0,3.0.0]"; 
filter:="(&(osgi.identity=openjpa)(type=karaf.feature)(version>=3.0.0)(version<=3.0.0))"
 [caused by: Unable to resolve openjpa/3.0.0: missing requirement 
[openjpa/3.0.0] osgi.identity; osgi.identity=org.apache.openjpa; 
type=osgi.bundle; version="[3.0.0,3.0.0]"; resolution:=mandatory [caused by: 
Unable to resolve org.apache.openjpa/3.0.0: missing requirement 
[org.apache.openjpa/3.0.0] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.apache.xbean.asm6)(version>=6.1.0)(!(version>=7.0.0)))"]]

I managed to fix this installing the following bundle

install mvn:org.apache.xbean/xbean-asm6-shaded/4.10

My java version: java version "1.8.0_161"

Thanks,
Matteo


> On 26 Dec 2018, at 19:09, Francois Papon  wrote:
> 
> Hi Matteo,
> 
> We can't see the error on your message.
> 
> Can you re paste it please?
> 
> Regards,
> 
> François Papon
> fpa...@apache.org
> 
> Le 26/12/2018 à 22:03, matteor a écrit :
>> Hello,
>> 
>> I'm trying to upgrade to Karaf 4.2.2 but I get the following error with the
>> openjpa feature:
>> 
>> 
>> 
>> Is this a known issue? Any workaround available?
>> 
>> Thanks,
>> Matteo
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Config feature element used as default

[Matteo Rulli]

Hello,
I would like to know what is the expected behavior of the  feature element when the the.config.pid.cfg file already 
exists in the karaf /etc folder. What properties are injected in the service? 
Those in the file or those in the  element as a default value only when the corresp file in 
etc folder is missing. When the file is already present I’d like to get a 
similar behaviour with respect 

Thank you,
Matteo

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

Hello,
Thank you for your help. Apparently I cannot login or create an issue at the 
https://ops4j1.jira.com/ <https://ops4j1.jira.com/> website. What is the right 
procedure to file a bug there?

By the way, I also tried adding the dynamic import to the probe with:

@ProbeBuilder 
public TestProbeBuilder probeConfiguration(TestProbeBuilder probe) {
probe.setHeader(Constants.DYNAMICIMPORT_PACKAGE, "*"); 
return probe;
}

but it didn’t help.

Thank you again,
Matteo

> On 9 Jul 2018, at 14:44, Jean-Baptiste Onofré  wrote:
> 
> bundle() method comes from the PaxExam probe. A possible issue is that
> PaxExam probe doesn't have the DynamicImport-Package and so it doesn't
> use the URL.
> 
> Can you please create a Jira at OPS4J PaxExam ? I will take a look.
> 
> In the mean time, using the bundle context as workaround is fine.
> 
> Regards
> JB
> 
> On 09/07/2018 14:32, Matteo Rulli wrote:
>> And the reference protocol works also if I install the exploded bundle
>> from the test method with:
>> 
>> @Test
>> *public* *void* testCase() *throws* Exception {
>> /assertNotNull/(/bcontext/);
>> /bcontext/.installBundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/").start();
>> Thread./sleep/(Long.*/MAX_VALUE/*);
>> }
>> 
>> So the only way it gives problem is with the bundle() option. Isn’t this
>> strange? Could it be a timing/race problem? Or a missing pax-exam
>> configuration?
>> 
>> Matteo
>> 
>>> On 9 Jul 2018, at 14:20, Matteo Rulli >> <mailto:matteo.ru...@gmail.com>
>>> <mailto:matteo.ru...@gmail.com <mailto:matteo.ru...@gmail.com>>> wrote:
>>> 
>>> Hi,
>>> I’m using a custom Karaf distro where I modify the framework feature
>>> in order to include the pax-url-reference bundles in the
>>> startup.properties through the karaf-maven-plugin. 
>>> 
>>> Apparently, the pax-url-reference bundles are installed correctly and
>>> they work because if I start the test, I do ssh into the running karaf
>>> and execute the 
>>> 
>>> flairbit@root()>
>>> install 
>>> reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>>> Bundle ID: 131
>>> 
>>> the command works fine. Despite this, when I try to install the
>>> exploded bundle with the 
>>> 
>>> bundle("reference:file:target/classes/“)
>>> 
>>> option, I get the reported error, both using the absolute and relative
>>> path for target folder.
>>> 
>>> Thank you,
>>> Matteo
>>> 
>>> 
>>>> On 9 Jul 2018, at 13:39, Jean-Baptiste Onofré >>> <mailto:j...@nanthrax.net>
>>>> <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>> wrote:
>>>> 
>>>> Hi Matteo,
>>>> 
>>>> it seems you are using in Pax Exam. Do you use your custom dispo in Pax
>>>> Exam ? I suspect that you use the standard Karaf distribution coming
>>>> with Pax Exam, so you will need to install pax-url-reference in
>>>> @Configuration of your test.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> On 09/07/2018 13:00, Matteo Rulli wrote:
>>>>> If I set
>>>>> 
>>>>> bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),
>>>>> 
>>>>> In the test opts (i.e. the absolute path of target folder) I get the
>>>>> same exception reported in the previous email (the data/tmp (Is a
>>>>> directory) one).
>>>>> 
>>>>> Matteo
>>>>> 
>>>>>> On 9 Jul 2018, at 12:52, Francois Papon
>>>>>> mailto:francois.pa...@openobject.fr> 
>>>>>> <mailto:francois.pa...@openobject.fr 
>>>>>> <mailto:francois.pa...@openobject.fr>>
>>>>>> <mailto:francois.pa...@openobject.fr 
>>>>>> <mailto:francois.pa...@openobject.fr>>> wrote:
>>>>>> 
>>>>>> Ok, but I see in your code :
>>>>>> 
>>>>>> bundle("reference:file:target/classes/")
>>>>>> 
>>>>>> Could you try with the full path of the repository ?
>>>>>> 
>>>>>> 
>>>>>> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
>>

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

And the reference protocol works also if I install the exploded bundle from the 
test method with:

@Test
public void testCase() throws Exception {
assertNotNull(bcontext);

bcontext.installBundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/").start();
Thread.sleep(Long.MAX_VALUE);
}

So the only way it gives problem is with the bundle() option. Isn’t this 
strange? Could it be a timing/race problem? Or a missing pax-exam configuration?

Matteo

> On 9 Jul 2018, at 14:20, Matteo Rulli  wrote:
> 
> Hi,
> I’m using a custom Karaf distro where I modify the framework feature in order 
> to include the pax-url-reference bundles in the startup.properties through 
> the karaf-maven-plugin. 
> 
> Apparently, the pax-url-reference bundles are installed correctly and they 
> work because if I start the test, I do ssh into the running karaf and execute 
> the 
> 
> flairbit@root()> install 
> reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
> Bundle ID: 131
> 
> the command works fine. Despite this, when I try to install the exploded 
> bundle with the 
> 
> bundle("reference:file:target/classes/“)
> 
> option, I get the reported error, both using the absolute and relative path 
> for target folder.
> 
> Thank you,
> Matteo
> 
> 
>> On 9 Jul 2018, at 13:39, Jean-Baptiste Onofré > <mailto:j...@nanthrax.net>> wrote:
>> 
>> Hi Matteo,
>> 
>> it seems you are using in Pax Exam. Do you use your custom dispo in Pax
>> Exam ? I suspect that you use the standard Karaf distribution coming
>> with Pax Exam, so you will need to install pax-url-reference in
>> @Configuration of your test.
>> 
>> Regards
>> JB
>> 
>> On 09/07/2018 13:00, Matteo Rulli wrote:
>>> If I set
>>> 
>>> bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),
>>> 
>>> In the test opts (i.e. the absolute path of target folder) I get the
>>> same exception reported in the previous email (the data/tmp (Is a
>>> directory) one).
>>> 
>>> Matteo
>>> 
>>>> On 9 Jul 2018, at 12:52, Francois Papon >>> <mailto:francois.pa...@openobject.fr>
>>>> <mailto:francois.pa...@openobject.fr 
>>>> <mailto:francois.pa...@openobject.fr>>> wrote:
>>>> 
>>>> Ok, but I see in your code :
>>>> 
>>>> bundle("reference:file:target/classes/")
>>>> 
>>>> Could you try with the full path of the repository ?
>>>> 
>>>> 
>>>> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
>>>>> Yes. If I remove the bundle(“reference:….”) line in the test ops and
>>>>> I manually do
>>>>> 
>>>>> installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>>>>> Bundle ID: 131
>>>>> *flairbit*@root()> start131
>>>>> 
>>>>> Everything works just fine.
>>>>> 
>>>>> Matteo
>>>>> 
>>>>> 
>>>>>> On 9 Jul 2018, at 12:24, Francois Papon
>>>>>> mailto:francois.pa...@openobject.fr> 
>>>>>> <mailto:francois.pa...@openobject.fr 
>>>>>> <mailto:francois.pa...@openobject.fr>>>
>>>>>> wrote:
>>>>>> 
>>>>>> Does it work's without bundle("...") ?
>>>>>> 
>>>>>> 
>>>>>> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>>>>>>> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>>>>>>> 
>>>>>>>> On 9 Jul 2018, at 12:07, Francois Papon
>>>>>>>> mailto:francois.pa...@openobject.fr>
>>>>>>>> <mailto:francois.pa...@openobject.fr 
>>>>>>>> <mailto:francois.pa...@openobject.fr>>> wrote:
>>>>>>>> 
>>>>>>>> Which version of Karaf are you using ?
>>>>>>>> 
>>>>>>>> regards
>>>>>>>> 
>>>>>>>> François
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Le 09/07/2018 à 14:05, matteor a écrit :
>>>>>>>>> Sorry. It seems that message formatting in nabble does 

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

Hi,
I’m using a custom Karaf distro where I modify the framework feature in order 
to include the pax-url-reference bundles in the startup.properties through the 
karaf-maven-plugin. 

Apparently, the pax-url-reference bundles are installed correctly and they work 
because if I start the test, I do ssh into the running karaf and execute the 

flairbit@root()> install 
reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
Bundle ID: 131

the command works fine. Despite this, when I try to install the exploded bundle 
with the 

bundle("reference:file:target/classes/“)

option, I get the reported error, both using the absolute and relative path for 
target folder.

Thank you,
Matteo


> On 9 Jul 2018, at 13:39, Jean-Baptiste Onofré  wrote:
> 
> Hi Matteo,
> 
> it seems you are using in Pax Exam. Do you use your custom dispo in Pax
> Exam ? I suspect that you use the standard Karaf distribution coming
> with Pax Exam, so you will need to install pax-url-reference in
> @Configuration of your test.
> 
> Regards
> JB
> 
> On 09/07/2018 13:00, Matteo Rulli wrote:
>> If I set
>> 
>> bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),
>> 
>> In the test opts (i.e. the absolute path of target folder) I get the
>> same exception reported in the previous email (the data/tmp (Is a
>> directory) one).
>> 
>> Matteo
>> 
>>> On 9 Jul 2018, at 12:52, Francois Papon >> <mailto:francois.pa...@openobject.fr>
>>> <mailto:francois.pa...@openobject.fr 
>>> <mailto:francois.pa...@openobject.fr>>> wrote:
>>> 
>>> Ok, but I see in your code :
>>> 
>>> bundle("reference:file:target/classes/")
>>> 
>>> Could you try with the full path of the repository ?
>>> 
>>> 
>>> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
>>>> Yes. If I remove the bundle(“reference:….”) line in the test ops and
>>>> I manually do
>>>> 
>>>> installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>>>> Bundle ID: 131
>>>> *flairbit*@root()> start131
>>>> 
>>>> Everything works just fine.
>>>> 
>>>> Matteo
>>>> 
>>>> 
>>>>> On 9 Jul 2018, at 12:24, Francois Papon
>>>>> mailto:francois.pa...@openobject.fr> 
>>>>> <mailto:francois.pa...@openobject.fr 
>>>>> <mailto:francois.pa...@openobject.fr>>>
>>>>> wrote:
>>>>> 
>>>>> Does it work's without bundle("...") ?
>>>>> 
>>>>> 
>>>>> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>>>>>> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>>>>>> 
>>>>>>> On 9 Jul 2018, at 12:07, Francois Papon
>>>>>>> mailto:francois.pa...@openobject.fr>
>>>>>>> <mailto:francois.pa...@openobject.fr 
>>>>>>> <mailto:francois.pa...@openobject.fr>>> wrote:
>>>>>>> 
>>>>>>> Which version of Karaf are you using ?
>>>>>>> 
>>>>>>> regards
>>>>>>> 
>>>>>>> François
>>>>>>> 
>>>>>>> 
>>>>>>> Le 09/07/2018 à 14:05, matteor a écrit :
>>>>>>>> Sorry. It seems that message formatting in nabble does not work
>>>>>>>> very well...
>>>>>>>> Here is the message with all the details:
>>>>>>>> 
>>>>>>>> I tried to enable the reference protocol in Karaf adding these
>>>>>>>> bundles to
>>>>>>>> the startup.properties:
>>>>>>>> 
>>>>>>>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>>>>>>>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>>>>>>>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>>>>>>>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>>>>>>>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>>>>>>>> 
>>>>>>>> And in fact now I can see the installed bundles in my runtime:
>>>>>>>> 
>>>>>>>> list -t 0 -s | grep pax
>>>>>

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

If I set

bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),

In the test opts (i.e. the absolute path of target folder) I get the same 
exception reported in the previous email (the data/tmp (Is a directory) one).

Matteo

> On 9 Jul 2018, at 12:52, Francois Papon  wrote:
> 
> Ok, but I see in your code :
> 
> bundle("reference:file:target/classes/ <>")
> 
> Could you try with the full path of the repository ?
> 
> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
>> Yes. If I remove the bundle(“reference:….”) line in the test ops and I 
>> manually do
>> 
>> install 
>> reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>>  
>> 
>> Bundle ID: 131
>> flairbit@root()> start 131
>> 
>> Everything works just fine.
>> 
>> Matteo
>> 
>> 
>>> On 9 Jul 2018, at 12:24, Francois Papon >> <mailto:francois.pa...@openobject.fr>> wrote:
>>> 
>>> Does it work's without bundle("...") ?
>>> 
>>> 
>>> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>>>> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>>>> 
>>>>> On 9 Jul 2018, at 12:07, Francois Papon >>>> <mailto:francois.pa...@openobject.fr>> wrote:
>>>>> 
>>>>> Which version of Karaf are you using ?
>>>>> 
>>>>> regards
>>>>> 
>>>>> François
>>>>> 
>>>>> 
>>>>> Le 09/07/2018 à 14:05, matteor a écrit :
>>>>>> Sorry. It seems that message formatting in nabble does not work very 
>>>>>> well...
>>>>>> Here is the message with all the details:
>>>>>> 
>>>>>> I tried to enable the reference protocol in Karaf adding these bundles to
>>>>>> the startup.properties:
>>>>>> 
>>>>>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>>>>>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>>>>>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>>>>>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>>>>>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>>>>>> 
>>>>>> And in fact now I can see the installed bundles in my runtime:
>>>>>> 
>>>>>> list -t 0 -s | grep pax
>>>>>> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>>>>>> 5 │ Active   │   8 │ 1.10.1 │
>>>>>> org.ops4j.pax.logging.pax-logging-api
>>>>>> 6 │ Active   │   8 │ 1.10.1 │
>>>>>> org.ops4j.pax.logging.pax-logging-log4j2
>>>>>> 15 │ Active   │  11 │ 1.8.3  │ 
>>>>>> org.ops4j.pax.swissbox.property
>>>>>> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
>>>>>> 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
>>>>>> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>>>>>> 
>>>>>> But when in my test I try to use the protocol like this:
>>>>>> 
>>>>>> Option[] options = new Option[] {
>>>>>>  systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
>>>>>>  features(testUtils.getStandardRepo(), "aries-blueprint"),
>>>>>>  features(testUtils.getStandardRepo(), "http"),
>>>>>>  features(testUtils.getStandardRepo(), "http-whiteboard"),
>>>>>>  bundle("reference:file:target/classes/ 
>>>>>> ")
>>>>>> };
>>>>>> 
>>>>>> I get quite a strange error:
>>>>>> 
>>>>>> org.apache.karaf.features.internal.util.MultiException: Error:
>>>>>> 
>>>>>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>>>>>> (Is a directory)
>>>>>>  at
>>>>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
>>>>>> ~[?:?]
>>>>>>  at
>>>>>> org.apache.karaf.features.in

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

Yes. If I remove the bundle(“reference:….”) line in the test ops and I manually 
do

install 
reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
Bundle ID: 131
flairbit@root()> start 131

Everything works just fine.

Matteo


> On 9 Jul 2018, at 12:24, Francois Papon  wrote:
> 
> Does it work's without bundle("...") ?
> 
> 
> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>> 
>>> On 9 Jul 2018, at 12:07, Francois Papon >> <mailto:francois.pa...@openobject.fr>> wrote:
>>> 
>>> Which version of Karaf are you using ?
>>> 
>>> regards
>>> 
>>> François
>>> 
>>> 
>>> Le 09/07/2018 à 14:05, matteor a écrit :
>>>> Sorry. It seems that message formatting in nabble does not work very 
>>>> well...
>>>> Here is the message with all the details:
>>>> 
>>>> I tried to enable the reference protocol in Karaf adding these bundles to
>>>> the startup.properties:
>>>> 
>>>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>>>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>>>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>>>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>>>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>>>> 
>>>> And in fact now I can see the installed bundles in my runtime:
>>>> 
>>>> list -t 0 -s | grep pax
>>>> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>>>> 5 │ Active   │   8 │ 1.10.1 │
>>>> org.ops4j.pax.logging.pax-logging-api
>>>> 6 │ Active   │   8 │ 1.10.1 │
>>>> org.ops4j.pax.logging.pax-logging-log4j2
>>>> 15 │ Active   │  11 │ 1.8.3  │ org.ops4j.pax.swissbox.property
>>>> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
>>>> 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
>>>> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>>>> 
>>>> But when in my test I try to use the protocol like this:
>>>> 
>>>> Option[] options = new Option[] {
>>>>systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
>>>>features(testUtils.getStandardRepo(), "aries-blueprint"),
>>>>features(testUtils.getStandardRepo(), "http"),
>>>>features(testUtils.getStandardRepo(), "http-whiteboard"),
>>>>bundle("reference:file:target/classes/ 
>>>> ")
>>>> };
>>>> 
>>>> I get quite a strange error:
>>>> 
>>>> org.apache.karaf.features.internal.util.MultiException: Error:
>>>> 
>>>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>>>> (Is a directory)
>>>>at
>>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
>>>> ~[?:?]
>>>>at
>>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
>>>> ~[?:?]
>>>>at
>>>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
>>>> ~[?:?]
>>>>at
>>>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
>>>> ~[?:?]
>>>>at
>>>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
>>>> ~[?:?]
>>>>at
>>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
>>>> ~[?:?]
>>>>at
>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
>>>> ~[?:?]
>>>>at
>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
>>>> ~[?:?]
>>>>at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>>>at
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>> 

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.

> On 9 Jul 2018, at 12:07, Francois Papon  wrote:
> 
> Which version of Karaf are you using ?
> 
> regards
> 
> François
> 
> 
> Le 09/07/2018 à 14:05, matteor a écrit :
>> Sorry. It seems that message formatting in nabble does not work very well...
>> Here is the message with all the details:
>> 
>> I tried to enable the reference protocol in Karaf adding these bundles to
>> the startup.properties:
>> 
>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>> 
>> And in fact now I can see the installed bundles in my runtime:
>> 
>> list -t 0 -s | grep pax
>> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>> 5 │ Active   │   8 │ 1.10.1 │
>> org.ops4j.pax.logging.pax-logging-api
>> 6 │ Active   │   8 │ 1.10.1 │
>> org.ops4j.pax.logging.pax-logging-log4j2
>> 15 │ Active   │  11 │ 1.8.3  │ org.ops4j.pax.swissbox.property
>> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
>> 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
>> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>> 
>> But when in my test I try to use the protocol like this:
>> 
>> Option[] options = new Option[] {
>>  systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
>>  features(testUtils.getStandardRepo(), "aries-blueprint"),
>>  features(testUtils.getStandardRepo(), "http"),
>>  features(testUtils.getStandardRepo(), "http-whiteboard"),
>>  bundle("reference:file:target/classes/")
>> };
>> 
>> I get quite a strange error:
>> 
>> org.apache.karaf.features.internal.util.MultiException: Error:
>> 
>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>> (Is a directory)
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
>> ~[?:?]
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>  at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> [?:?]
>>  at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> [?:?]
>>  at java.lang.Thread.run(Thread.java:748) [?:?]
>>  Suppressed: java.io.FileNotFoundException:
>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>> (Is a directory)
>>  at java.io.FileInputStream.open0(Native Method) ~[?:?]
>>  at java.io.FileInputStream.open(FileInputStream.java:195) [?:?]
>>  at java.io.FileInputStream.(FileInputStream.java:138) 
>> [?:?]
>>  at
>> org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.open(AbstractDownloadTask.java:54)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem.getMetadata(Subsystem.java:535)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem$1.downloaded(Subsystem.java:402)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:133)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:127)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:350)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> 

Custom file install in Karaf assembly

[Matteo Rulli]

Hello,
I'm trying to replace the default Felix fileinstall with my custom 
implementation. 

To do that I built an alternative framework feature and I generated a KAR out 
of it. 

After that I replaced the 


org.apache.karaf.features
framework
kar


dependency in my karaf assembly project with the custom KAR (this is exacltly 
the same as the original one except that it contains my custom fileinstall). 
Unfortunately when I try to generate the assembly I get this stacktrace:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.karaf.tooling:karaf-maven-plugin:4.1.2:assembly (default-assembly) 
on project flairkit.assembly: Unable to build assembly
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to build 
assembly
at org.apache.karaf.tooling.AssemblyMojo.execute(AssemblyMojo.java:268)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: java.lang.NullPointerException
at org.apache.karaf.tooling.AssemblyMojo.doExecute(AssemblyMojo.java:463)
at org.apache.karaf.tooling.AssemblyMojo.execute(AssemblyMojo.java:262)
... 22 more

Looking at the AssemblyMojo code, it seams that this is not the right way to 
achieve what I want to do. Could you suggest the right way to replace 
fileinstall with a custom implementation in my custom karaf (karaf v. 4.1.2) 
assembly?

Thank you very much,
Matteo

Re: Fileinstall, feature config and pax-exam

[Matteo Rulli]

Thank you Christian. Yes you are right, we could simply avoid to embed the 
config placeholders in the feature file. 

But there is also another way that just came to my mind:

Option[] options = new Option[] {
editConfigurationFilePut( "etc/config.properties", 
"felix.fileinstall.poll", String.valueOf(Integer.MAX_VALUE)),
features(biepiRepo,"my-feature-to-test")
};

as this prevents fileinstall to trigger bundle updates. 

Thanks,
Matteo

> On 20 Apr 2017, at 15:41, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> I think there is or was an issue with loading factory configs as defaults in 
> a feature.
> 
> As your database config normally contains secret information I propose to not 
> install it in the feature. Instead you can deploy the config as part of your 
> pax exam setup.
> 
> Christian
> 
> On 20.04.2017 12:09, Matteo Rulli wrote:
>> Hello,
>> We are running a couple of integration tests using pax-exam 4.10.0 and Karaf 
>> 4.0.8. In the test's @Configuration method we install a feature that 
>> contains both the bundle under test and the corresp. configuration files.
>> 
>> The tests work fine on most dev machines except one where the test fails. As 
>> far as I understood the test failure is triggered by fileinstall that 
>> restarts some bundles while the tests are running:
>> 
>> ... test already started...
>> 
>> 2017-04-20 09:30:48,638 | INFO  | 3952a6dd0975/etc | fileinstall | 4 - 
>> org.apache.felix.fileinstall - 3.5.6 | Updating configuration from 
>> org.apache.aries.transaction.cfg
>> 2017-04-20 09:30:48,642 | INFO  | 3952a6dd0975/etc | fileinstall | 4 - 
>> org.apache.felix.fileinstall - 3.5.6 | Creating configuration from 
>> org.ops4j.datasource-dsone-postgres.cfg
>> 2017-04-20 09:30:48,645 | INFO  | 3952a6dd0975/etc | fileinstall | 4 - 
>> org.apache.felix.fileinstall - 3.5.6 | Creating configuration from 
>> org.ops4j.datasource-dsone-postgres-plain.cfg
>> 2
>> 
>> ... test fails with:
>>  
>> org.apache.openjpa.persistence.InvalidStateException: This operation failed 
>> for some instances.  See the nested exceptions array for details.
>> Caused by:  
>> org.apache.openjpa.persistence.InvalidStateException: This operation cannot 
>> be performed while a Transaction is active.
>> FailedObject: org.apache.openjpa.persistence.EntityManagerImpl@28c1622b
>>  at 
>> org.apache.openjpa.kernel.AbstractBrokerFactory.assertNoActiveTransaction(AbstractBrokerFactory.java:708)[87:org.apache.openjpa:2.4.1]
>>  ... 63 more
>> 
>> And if I query the ConfigAdmin, it reports the "duplicated" configuration 
>> entries for the DataSource:
>> 
>> databaseName: dsone
>> dataSourceName: xa-com.example.dsone.persistence
>> org.apache.karaf.features.configKey: org.ops4j.datasource-dsone-postgres
>> osgi.jdbc.driver.name: PostgreSQL JDBC Driver-pool-xa
>> password: **
>> portNumber: 5432
>> serverName: localhost
>> service.factoryPid: org.ops4j.datasource
>> service.pid: org.ops4j.datasource.211f5de1-8c00-4eaa-b501-b35ac6e9b6c4
>> user: **
>> 
>> databaseName: dsone
>> dataSourceName: com.example.dsone.persistence
>> org.apache.karaf.features.configKey: 
>> org.ops4j.datasource-dsone-postgres-plain
>> osgi.jdbc.driver.name: PostgreSQL JDBC Driver-pool
>> password: **
>> portNumber: 5432
>> serverName: localhost
>> service.factoryPid: org.ops4j.datasource
>> service.pid: org.ops4j.datasource.15452283-8188-4761-b134-f1d987eb3302
>> user: **
>> 
>> databaseName: dsone
>> dataSourceName: com.example.dsone.persistence
>> 
>> felix.fileinstall.filenamefile:/Users/roberto/Documents/git/example/com.example.osgi.dsone/com.example.dsone.storage.provider/target/exam/b157e12e-78cc-4138-9be3-8841da76b972/etc/org.ops4j.datasource-dsone-postgres-plain.cfg
>> osgi.jdbc.driver.name: PostgreSQL JDBC Driver-pool
>> password: **
>> portNumber: 5432
>> serverName: localhost
>> service.factoryPid: org.ops4j.datasource
>> service.pid: org.ops4j.datasource.78917eb8-051b-454d-905b-758b125ab631
>> user: **
>> 
>> databaseName: dsone
>> dataSourceName: xa-com.example.dsone.persistence
>> 
>> felix.fileinstall.filenamefile:/Users/roberto/Documents/git/example/com.example.osgi.dsone/com.example.dsone.storage.provider/target/exam/b157e12e-78cc-4138-9be3-8841da76b972/etc/org.ops4j.datasource-dsone-postgres.cfg
>> 

Fileinstall, feature config and pax-exam

[Matteo Rulli]

Hello,
We are running a couple of integration tests using pax-exam 4.10.0 and Karaf 
4.0.8. In the test's @Configuration method we install a feature that contains 
both the bundle under test and the corresp. configuration files.

The tests work fine on most dev machines except one where the test fails. As 
far as I understood the test failure is triggered by fileinstall that restarts 
some bundles while the tests are running:

... test already started...

2017-04-20 09:30:48,638 | INFO  | 3952a6dd0975/etc | fileinstall | 4 - 
org.apache.felix.fileinstall - 3.5.6 | Updating configuration from 
org.apache.aries.transaction.cfg
2017-04-20 09:30:48,642 | INFO  | 3952a6dd0975/etc | fileinstall | 4 - 
org.apache.felix.fileinstall - 3.5.6 | Creating configuration from 
org.ops4j.datasource-dsone-postgres.cfg
2017-04-20 09:30:48,645 | INFO  | 3952a6dd0975/etc | fileinstall | 4 - 
org.apache.felix.fileinstall - 3.5.6 | Creating configuration from 
org.ops4j.datasource-dsone-postgres-plain.cfg
2

... test fails with:
 
org.apache.openjpa.persistence.InvalidStateException: This operation failed for 
some instances.  See the nested exceptions array for details.
Caused by:  
org.apache.openjpa.persistence.InvalidStateException: This operation cannot be 
performed while a Transaction is active.
FailedObject: org.apache.openjpa.persistence.EntityManagerImpl@28c1622b
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.assertNoActiveTransaction(AbstractBrokerFactory.java:708)[87:org.apache.openjpa:2.4.1]
... 63 more

And if I query the ConfigAdmin, it reports the "duplicated" configuration 
entries for the DataSource:

databaseName: dsone
dataSourceName: xa-com.example.dsone.persistence
org.apache.karaf.features.configKey: org.ops4j.datasource-dsone-postgres
osgi.jdbc.driver.name: PostgreSQL JDBC Driver-pool-xa
password: **
portNumber: 5432
serverName: localhost
service.factoryPid: org.ops4j.datasource
service.pid: org.ops4j.datasource.211f5de1-8c00-4eaa-b501-b35ac6e9b6c4
user: **

databaseName: dsone
dataSourceName: com.example.dsone.persistence
org.apache.karaf.features.configKey: 
org.ops4j.datasource-dsone-postgres-plain
osgi.jdbc.driver.name: PostgreSQL JDBC Driver-pool
password: **
portNumber: 5432
serverName: localhost
service.factoryPid: org.ops4j.datasource
service.pid: org.ops4j.datasource.15452283-8188-4761-b134-f1d987eb3302
user: **

databaseName: dsone
dataSourceName: com.example.dsone.persistence

felix.fileinstall.filenamefile:/Users/roberto/Documents/git/example/com.example.osgi.dsone/com.example.dsone.storage.provider/target/exam/b157e12e-78cc-4138-9be3-8841da76b972/etc/org.ops4j.datasource-dsone-postgres-plain.cfg
osgi.jdbc.driver.name: PostgreSQL JDBC Driver-pool
password: **
portNumber: 5432
serverName: localhost
service.factoryPid: org.ops4j.datasource
service.pid: org.ops4j.datasource.78917eb8-051b-454d-905b-758b125ab631
user: **

databaseName: dsone
dataSourceName: xa-com.example.dsone.persistence

felix.fileinstall.filenamefile:/Users/roberto/Documents/git/example/com.example.osgi.dsone/com.example.dsone.storage.provider/target/exam/b157e12e-78cc-4138-9be3-8841da76b972/etc/org.ops4j.datasource-dsone-postgres.cfg
osgi.jdbc.driver.name: PostgreSQL JDBC Driver-pool-xa
password: **
portNumber: 5432
serverName: localhost
service.factoryPid: org.ops4j.datasource
service.pid: org.ops4j.datasource.0dfef597-9c1c-4cfc-864c-1a50c73b7350
user: **

So my question is:

1. Is this plausible? I mean: is it true that fileinstall could interpret 
config files that are installed by the feature service as new config files, 
triggering the problem above?
1. Is installing the config files along with the karaf feature the right way to 
go in this kind of scenarios?
2. What is the best way to solve this problem? I could wait in @Before method 
until I see all the config entries but this seems a little bit ugly to me...

Thank you,
matteo