Re: How to provide a transactional entity manager to a third party

[Tim Ward]

Hi,

If you want to use a managed EntityManager (rather than one that you create and 
destroy yourself) then you need to do so within managed scope.

In Transaction Control (which you may have seen emails about on this list in 
the last few days) this would be by creating a scoped EntityManager from a 
JPAEntityManagerProvider, and then setting up a scope whenever you access the 
EntityManager. For example as the integration tests do here 
.

For a managed EntityManager obtained in another way you will still need to set 
up the appropriate context to access it. This may be using the Coordinator 
service (if coordinations are being used for lifecycle management), or it may 
be by setting up a JTA transaction in some way. 

As you haven’t provided many details about how the EntityManager is set up or 
maintained it’s hard to be more specific, but I hope this helps to point you in 
the correct direction.

Tim

> On 8 Feb 2019, at 07:06, cobusstroebel  wrote:
> 
> I am trying to use the Axon Framework inside Apache Karaf.
> During the configuration of the Axon Framework I want to setup a
> JpaTokenStore which requires an EntityManager.
> 
> Configurer configurer = DefaultConfigurer.defaultConfiguration()
>.configureAggregate(MyAggregate.class)
>.eventProcessing(eventProcessingConfigurer -> {
>eventProcessingConfigurer.registerTokenStore(configuration -> 
>JpaTokenStore.builder()
>.entityManagerProvider(new
> SimpleEntityManagerProvider(*entityManager*))
>.serializer(configuration.serializer())
>.build()
>);
>}
> );
> 
> Whenever I provide an EntityManager I keep getting this error:
> java.lang.IllegalStateException: Need active coordination. I know it is
> because the injected entity manager is used outside of the class it is
> injected into.
> 
> One of the guys from Axon suggested that I use a TransactionManager similar
> to this one
> (https://github.com/AxonFramework/AxonFramework/blob/master/spring/src/main/java/org/axonframework/spring/messaging/unitofwork/SpringTransactionManager.java)
> but I don't know how to go about this in Karaf.
> 
> Can anyone please nudge me in the right direction?
> 
> Kindest Regards
> Cobus
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

How to provide a transactional entity manager to a third party

[cobusstroebel]

I am trying to use the Axon Framework inside Apache Karaf.
During the configuration of the Axon Framework I want to setup a
JpaTokenStore which requires an EntityManager.

Configurer configurer = DefaultConfigurer.defaultConfiguration()
.configureAggregate(MyAggregate.class)
.eventProcessing(eventProcessingConfigurer -> {
eventProcessingConfigurer.registerTokenStore(configuration -> 
JpaTokenStore.builder()
.entityManagerProvider(new
SimpleEntityManagerProvider(*entityManager*))
.serializer(configuration.serializer())
.build()
);
}
);

Whenever I provide an EntityManager I keep getting this error:
java.lang.IllegalStateException: Need active coordination. I know it is
because the injected entity manager is used outside of the class it is
injected into.

One of the guys from Axon suggested that I use a TransactionManager similar
to this one
(https://github.com/AxonFramework/AxonFramework/blob/master/spring/src/main/java/org/axonframework/spring/messaging/unitofwork/SpringTransactionManager.java)
but I don't know how to go about this in Karaf.

Can anyone please nudge me in the right direction?

Kindest Regards
Cobus



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Interactive Console/Shell Command

[Oleg Cohen]

Hello,

I was wondering if anybody successfully developed and ran an interactive Karaf 
shell command, i.e. one that prompts the user for input.

I tried to use java.util.Scanner and when it prompts not all characters I type 
are input and when I hit enter it seems the submission happens twice and I get 
Command not found: [my input string]

I would appreciate suggestions!

Regards,
Oleg

Re: Microkernel Karaf fit...

[Ranx]

This is a little dated but it means someone was taking a swing at this back
with Karaf 3.x. I did see where Onos has moved on to using Karaf 4.x
although I don't know if they are still using OSv. Being able to boot Karaf
into unikernel means start up would be fast, there's little attack surface,
and it won't have the overhead of VMs/Docker on top. Although I gather OSv
could run in that environment as well as could other unikernels. Has anyone
had any experience attempting to use Karaf with any unikernels good, bad or
indifferent. I'm certainly for pursuing this farther but if it's already out
there then there isn't any point in reinventing the wheel. 

One complaint or problem with unikernels  is there is only one allowed
process running. You can't log into it as user. That's also part of its
inherent security as well. That's why Karaf in that environment interests me
so much as I don't need a user login to the operating system if I can log
into Karaf itself. 

Unfortunately my knowledge is somewhat limited here that's why I though I'd
ask if anyone had worked with it. Ideally I'd get a server with Xen running
on it so I could compile this and test it. 

https://github.com/cloudius-systems/osv-apps/blob/master/onos/Capstanfile

base: cloudius/osv-openjdk

cmdline: >
  /java.so
  -Xms128M
  -Xmx512M
  -XX:+UnlockDiagnosticVMOptions
  -XX:+UnsyncloadClass
  -Dcom.sun.management.jmxremote
 
-Djava.endorsed.dirs=/usr/lib/jvm/java/jre/lib/endorsed:/usr/lib/jvm/java/lib/endorsed:/onos/apache-karaf-3.0.3/lib/endorsed
 
-Djava.ext.dirs=/usr/lib/jvm/java/jre/lib/ext:/usr/lib/jvm/java/lib/ext:/onos/apache-karaf-3.0.3/lib/ext
  -Dkaraf.instances=/onos/apache-karaf-3.0.3/instances
  -Dkaraf.home=/onos/apache-karaf-3.0.3
  -Dkaraf.base=/onos/apache-karaf-3.0.3
  -Dkaraf.data=/onos/apache-karaf-3.0.3/data
  -Dkaraf.etc=/onos/apache-karaf-3.0.3/etc
  -Djava.io.tmpdir=/onos/apache-karaf-3.0.3/data/tmp
 
-Djava.util.logging.config.file=/onos/apache-karaf-3.0.3/etc/java.util.logging.properties
  -Dkaraf.startLocalConsole=true
  -Dkaraf.startRemoteShell=true
  -classpath
/onos/apache-karaf-3.0.3/lib/karaf-jaas-boot.jar:/onos/apache-karaf-3.0.3/lib/karaf.jar:/onos/apache-karaf-3.0.3/lib/karaf-jmx-boot.jar:/onos/apache-karaf-3.0.3/lib/karaf-org.osgi.core.jar
  org.apache.karaf.main.Main

build: make



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf and Transaction Control Service Specification

[Tim Ward]

Not a problem - registering the resource as a service is a simple idea that 
sounds good. I even advocated it in my book! I then spent 3 years helping 
people fix the same persistence problems over and over which definitely changed 
my mind… 

That’s why I (and a bunch of other OSGi Alliance members) have spent the last 
3-4 years advocating people do transactions and resources differently. The 
small amount of boilerplate code is annoying, but it completely eliminates the 
lifecycle and service linking issues that we used to have with the invisible 
“joining up” of the old transaction behaviour. The whole thing is much more 
reliable.

Totally worth it :)

Tim



> On 7 Feb 2019, at 15:42, Alex Soto  wrote:
> 
> Thank you Tim,  I am glad I asked. 
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On Feb 7, 2019, at 9:26 AM, Tim Ward > > wrote:
>> 
>> Hi,
>> 
>> The model is the way it is quite deliberately, and there are several usage 
>> issues with doing what you’re suggesting:
>> 
>> It is unclear whether the EntityManager service is a scoped resource (and 
>> therefore managed) or not to external users
>> It is unclear which Transaction Control service implementation the scoped 
>> resource is attached to (the getResource(txControl) call creates an 
>> important link). If you use the wrong Transaction Control implementation 
>> (there may be several) then it won’t work properly.
>> It becomes harder to debug what’s going on because there are more “non 
>> obvious" links between services
>> 
>> These issues (and a few others) are problems that people hit repeatedly when 
>> trying to use DataSources and Transactions together in OSGi. I have seen 
>> *many* applications where people did not realise that their carefully set up 
>> transactions didn’t roll back because they were using the wrong datasource 
>> service, or it had been bound to a different transaction manager than the 
>> one they were using to start the transaction.
>> 
>> Therefore, while it is possible to do what you’re suggesting I would 
>> *strongly* encourage you not to do it. We’ve been there before and it sucked 
>> so hard that it resulted in us creating a whole new specification to fix the 
>> problems (namely the Transaction Control specification!).
>> 
>> If you’re able to use Declarative Services 1.4 (you possibly aren’t) then 
>> you could simplify your example a little using constructor injection:
>> 
>>  private final EntityManager em;
>>  private final TransactionControl txControl;
>> 
>>  @Activate
>>  public MyServiceImpl(@Reference(target = 
>> "(osgi.unit.name=myPersistenUnit)”) 
>>  JPAEntityManagerProvider provider, @Reference 
>> TransactionControl txControl) {
>>  
>>  this.txControl = txControl;
>>  em = provider.getResource(txControl);
>> 
>>  }
>> 
>> Best Regards,
>> 
>> Tim
>> 
>>> On 7 Feb 2019, at 15:02, Alex Soto >> > wrote:
>>> 
>>> I am wondering if it makes sense to create the scoped EntityManager as a 
>>> singleton service to be then @Referenced by the various repositories.   I 
>>> have various repository classes that need the EntityManager, all would need 
>>> to have some code like this:
>>> 
>>> @Reference(target = "(osgi.unit.name=myPersistenUnit)")
>>> private JPAEntityManagerProvider provider;
>>> 
>>> private EntityManager em;
>>> 
>>> @Activate
>>> void init() {
>>>   em = provider.getResource(txControl);
>>> }
>>> 
>>> 
>>> So each Repository component creates its own Scoped EntityManager. Does it 
>>> make sense to have one component in the application that creates a single 
>>> EM and have the various repositories use that one from the Service Registry?
>>> 
>>> Best regards,
>>> Alex soto
>>> 
>>> 
>>> 
>>> 
 On Feb 6, 2019, at 4:40 PM, Tim Ward >>> > wrote:
 
 The relevant specification for learning about scoped resources (which is 
 what the ResourceProvider gives you) is the Transaction Control 
 Specification. In this case your question is covered by Section 147.2.5 
 Multi Threading 
 .
  
 
 Scoped resources are always thread safe and designed to be singleton 
 objects used across multiple scopes. The underlying scoped resource 
 implementation then delegates to a real resource instance that is bound to 
 the current scope. The result is that the real resource never sees 
 multi-threaded access (a scope is bound to a single thread) and that you 
 never need to worry about creating/closing the resource because the “real 
 resource” is automatically created (or retrieved from a pool) on first use 
 within a scope and then closed (or returned to the pool) when the scope 
 finishes. 
 
 Best Regards,
 
 Tim
 
> On 6 Feb 2019, 

Re: Karaf and Transaction Control Service Specification

[Alex Soto]

Thank you Tim,  I am glad I asked. 

Best regards,
Alex soto




> On Feb 7, 2019, at 9:26 AM, Tim Ward  wrote:
> 
> Hi,
> 
> The model is the way it is quite deliberately, and there are several usage 
> issues with doing what you’re suggesting:
> 
> It is unclear whether the EntityManager service is a scoped resource (and 
> therefore managed) or not to external users
> It is unclear which Transaction Control service implementation the scoped 
> resource is attached to (the getResource(txControl) call creates an important 
> link). If you use the wrong Transaction Control implementation (there may be 
> several) then it won’t work properly.
> It becomes harder to debug what’s going on because there are more “non 
> obvious" links between services
> 
> These issues (and a few others) are problems that people hit repeatedly when 
> trying to use DataSources and Transactions together in OSGi. I have seen 
> *many* applications where people did not realise that their carefully set up 
> transactions didn’t roll back because they were using the wrong datasource 
> service, or it had been bound to a different transaction manager than the one 
> they were using to start the transaction.
> 
> Therefore, while it is possible to do what you’re suggesting I would 
> *strongly* encourage you not to do it. We’ve been there before and it sucked 
> so hard that it resulted in us creating a whole new specification to fix the 
> problems (namely the Transaction Control specification!).
> 
> If you’re able to use Declarative Services 1.4 (you possibly aren’t) then you 
> could simplify your example a little using constructor injection:
> 
>   private final EntityManager em;
>   private final TransactionControl txControl;
> 
>   @Activate
>   public MyServiceImpl(@Reference(target = 
> "(osgi.unit.name=myPersistenUnit)”) 
>   JPAEntityManagerProvider provider, @Reference 
> TransactionControl txControl) {
>   
>   this.txControl = txControl;
>   em = provider.getResource(txControl);
> 
>   }
> 
> Best Regards,
> 
> Tim
> 
>> On 7 Feb 2019, at 15:02, Alex Soto > > wrote:
>> 
>> I am wondering if it makes sense to create the scoped EntityManager as a 
>> singleton service to be then @Referenced by the various repositories.   I 
>> have various repository classes that need the EntityManager, all would need 
>> to have some code like this:
>> 
>>  @Reference(target = "(osgi.unit.name=myPersistenUnit)")
>>  private JPAEntityManagerProvider provider;
>> 
>>  private EntityManager em;
>> 
>>  @Activate
>>  void init() {
>>em = provider.getResource(txControl);
>>  }
>> 
>> 
>> So each Repository component creates its own Scoped EntityManager. Does it 
>> make sense to have one component in the application that creates a single EM 
>> and have the various repositories use that one from the Service Registry?
>> 
>> Best regards,
>> Alex soto
>> 
>> 
>> 
>> 
>>> On Feb 6, 2019, at 4:40 PM, Tim Ward >> > wrote:
>>> 
>>> The relevant specification for learning about scoped resources (which is 
>>> what the ResourceProvider gives you) is the Transaction Control 
>>> Specification. In this case your question is covered by Section 147.2.5 
>>> Multi Threading 
>>> .
>>>  
>>> 
>>> Scoped resources are always thread safe and designed to be singleton 
>>> objects used across multiple scopes. The underlying scoped resource 
>>> implementation then delegates to a real resource instance that is bound to 
>>> the current scope. The result is that the real resource never sees 
>>> multi-threaded access (a scope is bound to a single thread) and that you 
>>> never need to worry about creating/closing the resource because the “real 
>>> resource” is automatically created (or retrieved from a pool) on first use 
>>> within a scope and then closed (or returned to the pool) when the scope 
>>> finishes. 
>>> 
>>> Best Regards,
>>> 
>>> Tim
>>> 
 On 6 Feb 2019, at 22:14, Alex Soto >>> > wrote:
 
 Actually, I took a stab at this again since I had some spare time now.  I 
 am almost done. It looks promising.
 
 The only question I have is about the entity manager.  In the examples, I 
 see an entity manager is obtained in the activate method, and used for the 
 rest of the life of the component:
 
private EntityManager em;
 
@Activate
void init() {
em = provider.getResource(txControl);
}
 
 
 Is this safe in a multi threaded environment? I expect the component to be 
 called concurrently. 
 Section 127.3.3 of OSGi Companion states that "An Entity Manager is 
 intended to be used by a single session, it is not thread safe.” So I am 
 confused since all examples seem 

Re: Karaf and Transaction Control Service Specification

[Tim Ward]

Hi,

The model is the way it is quite deliberately, and there are several usage 
issues with doing what you’re suggesting:

It is unclear whether the EntityManager service is a scoped resource (and 
therefore managed) or not to external users
It is unclear which Transaction Control service implementation the scoped 
resource is attached to (the getResource(txControl) call creates an important 
link). If you use the wrong Transaction Control implementation (there may be 
several) then it won’t work properly.
It becomes harder to debug what’s going on because there are more “non obvious" 
links between services

These issues (and a few others) are problems that people hit repeatedly when 
trying to use DataSources and Transactions together in OSGi. I have seen *many* 
applications where people did not realise that their carefully set up 
transactions didn’t roll back because they were using the wrong datasource 
service, or it had been bound to a different transaction manager than the one 
they were using to start the transaction.

Therefore, while it is possible to do what you’re suggesting I would *strongly* 
encourage you not to do it. We’ve been there before and it sucked so hard that 
it resulted in us creating a whole new specification to fix the problems 
(namely the Transaction Control specification!).

If you’re able to use Declarative Services 1.4 (you possibly aren’t) then you 
could simplify your example a little using constructor injection:

private final EntityManager em;
private final TransactionControl txControl;

@Activate
public MyServiceImpl(@Reference(target = 
"(osgi.unit.name=myPersistenUnit)”) 
JPAEntityManagerProvider provider, @Reference 
TransactionControl txControl) {

this.txControl = txControl;
em = provider.getResource(txControl);

}

Best Regards,

Tim

> On 7 Feb 2019, at 15:02, Alex Soto  wrote:
> 
> I am wondering if it makes sense to create the scoped EntityManager as a 
> singleton service to be then @Referenced by the various repositories.   I 
> have various repository classes that need the EntityManager, all would need 
> to have some code like this:
> 
>   @Reference(target = "(osgi.unit.name=myPersistenUnit)")
>   private JPAEntityManagerProvider provider;
> 
>   private EntityManager em;
> 
>   @Activate
>   void init() {
> em = provider.getResource(txControl);
>   }
> 
> 
> So each Repository component creates its own Scoped EntityManager. Does it 
> make sense to have one component in the application that creates a single EM 
> and have the various repositories use that one from the Service Registry?
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On Feb 6, 2019, at 4:40 PM, Tim Ward > > wrote:
>> 
>> The relevant specification for learning about scoped resources (which is 
>> what the ResourceProvider gives you) is the Transaction Control 
>> Specification. In this case your question is covered by Section 147.2.5 
>> Multi Threading 
>> .
>>  
>> 
>> Scoped resources are always thread safe and designed to be singleton objects 
>> used across multiple scopes. The underlying scoped resource implementation 
>> then delegates to a real resource instance that is bound to the current 
>> scope. The result is that the real resource never sees multi-threaded access 
>> (a scope is bound to a single thread) and that you never need to worry about 
>> creating/closing the resource because the “real resource” is automatically 
>> created (or retrieved from a pool) on first use within a scope and then 
>> closed (or returned to the pool) when the scope finishes. 
>> 
>> Best Regards,
>> 
>> Tim
>> 
>>> On 6 Feb 2019, at 22:14, Alex Soto >> > wrote:
>>> 
>>> Actually, I took a stab at this again since I had some spare time now.  I 
>>> am almost done. It looks promising.
>>> 
>>> The only question I have is about the entity manager.  In the examples, I 
>>> see an entity manager is obtained in the activate method, and used for the 
>>> rest of the life of the component:
>>> 
>>> private EntityManager em;
>>> 
>>> @Activate
>>> void init() {
>>> em = provider.getResource(txControl);
>>> }
>>> 
>>> 
>>> Is this safe in a multi threaded environment? I expect the component to be 
>>> called concurrently. 
>>> Section 127.3.3 of OSGi Companion states that "An Entity Manager is 
>>> intended to be used by a single session, it is not thread safe.” So I am 
>>> confused since all examples seem to be ignoring this.
>>> 
>>> 
>>> Best regards,
>>> Alex soto
>>> 
>>> 
>>> 
>>> 
 On Feb 6, 2019, at 3:16 PM, Tim Jones >>> > wrote:
 
 Hi Alex,
 
 yes it is possible to use tx-control with Karaf, we have been using it on
 v4.0.5 in our 

Re: Karaf and Transaction Control Service Specification

[Alex Soto]

I am wondering if it makes sense to create the scoped EntityManager as a 
singleton service to be then @Referenced by the various repositories.   I have 
various repository classes that need the EntityManager, all would need to have 
some code like this:

@Reference(target = "(osgi.unit.name=myPersistenUnit)")
private JPAEntityManagerProvider provider;

private EntityManager em;

@Activate
void init() {
  em = provider.getResource(txControl);
}


So each Repository component creates its own Scoped EntityManager. Does it make 
sense to have one component in the application that creates a single EM and 
have the various repositories use that one from the Service Registry?

Best regards,
Alex soto




> On Feb 6, 2019, at 4:40 PM, Tim Ward  wrote:
> 
> The relevant specification for learning about scoped resources (which is what 
> the ResourceProvider gives you) is the Transaction Control Specification. In 
> this case your question is covered by Section 147.2.5 Multi Threading 
> .
>  
> 
> Scoped resources are always thread safe and designed to be singleton objects 
> used across multiple scopes. The underlying scoped resource implementation 
> then delegates to a real resource instance that is bound to the current 
> scope. The result is that the real resource never sees multi-threaded access 
> (a scope is bound to a single thread) and that you never need to worry about 
> creating/closing the resource because the “real resource” is automatically 
> created (or retrieved from a pool) on first use within a scope and then 
> closed (or returned to the pool) when the scope finishes. 
> 
> Best Regards,
> 
> Tim
> 
>> On 6 Feb 2019, at 22:14, Alex Soto > > wrote:
>> 
>> Actually, I took a stab at this again since I had some spare time now.  I am 
>> almost done. It looks promising.
>> 
>> The only question I have is about the entity manager.  In the examples, I 
>> see an entity manager is obtained in the activate method, and used for the 
>> rest of the life of the component:
>> 
>>  private EntityManager em;
>> 
>>  @Activate
>>  void init() {
>>  em = provider.getResource(txControl);
>>  }
>> 
>> 
>> Is this safe in a multi threaded environment? I expect the component to be 
>> called concurrently. 
>> Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended 
>> to be used by a single session, it is not thread safe.” So I am confused 
>> since all examples seem to be ignoring this.
>> 
>> 
>> Best regards,
>> Alex soto
>> 
>> 
>> 
>> 
>>> On Feb 6, 2019, at 3:16 PM, Tim Jones >> > wrote:
>>> 
>>> Hi Alex,
>>> 
>>> yes it is possible to use tx-control with Karaf, we have been using it on
>>> v4.0.5 in our production system for about 18 months with no issues. One of
>>> the main reasons we use tx-control is that is it 'backed' by a standard.
>>> Rightly or wrongly we also didn't have confidence in Aries JPA Template at
>>> the time we were considering transaction managment solutions to manage our
>>> transactions in a production environment (perhaps this was misguided) but we
>>> were concerned that there were few integrated tests for that project where
>>> as there are over 2000 lines of test code for tx-control which demonstrate
>>> sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
>>> commit, rollback depending upon exception type and much more.
>>> 
>>> I think the enRoute project has some examples
>>> https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html 
>>>  and
>>> the tx-control test code is worth looking at.
>>> 
>>> Tim
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html 
>>> 
>> 
> 

Re: Error Creating XA DataSource

[Tim Ward]

Hi,

I don’t know the specifics of what is going on here, but it is not recommended 
to use a pooled datasource factory wrapper with Transaction Control (which does 
its own pooling). You would be better off using the vanilla DataSourceFactory 
service for mysql.

Also, you may wish to update to use version 1.0.0 of Transaction Control, it is 
newer and builds against the released OSGi API.

Best Regards,

Tim

> On 7 Feb 2019, at 11:34, cobusstroebel  wrote:
> 
> I am using Karaf 4.0.3 with the following features enabled:
> 
>jndi
>transaction-api
>transaction
>jpa
>eclipselink
>pax-jdbc-config
>pax-jdbc-mysql
>pax-jdbc-pool-aries
> start-level="80">mvn:javax.validation/validation-api/1.1.0.Final
> 
> mvn:org.apache.aries.tx-control/tx-control-service-xa/0.0.3
> 
> mvn:org.apache.aries.tx-control/tx-control-provider-jpa-xa/0.0.3
> 
> Whenever I drop in my org.apache.aries.tx.controljpa.xa-example.cfg in etc,
> I get the following error:
> 
> An error occured creating the Resource provider for pid
> org.apache.aries.tx.control.jpa.xa.9bc35a19-cd58-43fe-bb73-146cfb846f2f
> org.osgi.service.transaction.control.TransactionException: Unable to create
> the JDBC resource provider
>at
> org.apache.aries.tx.control.jpa.xa.impl.XAJPADataSourceSetup.decorateJPAProperties(XAJPADataSourceSetup.java:60)[173:tx-control-provider-jpa-xa:0.0.3]
>at
> org.apache.aries.tx.control.jpa.common.impl.AbstractManagedJPADataSourceSetup.addingService(AbstractManagedJPADataSourceSetup.java:111)[173:tx-control-provider-jpa-xa:0.0.3]
>at
> org.apache.aries.tx.control.jpa.common.impl.AbstractManagedJPADataSourceSetup.addingService(AbstractManagedJPADataSourceSetup.java:57)[173:tx-control-provider-jpa-xa:0.0.3]
>at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)[org.osgi.core-6.0.0.jar:]
>at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)[org.osgi.core-6.0.0.jar:]
>at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[org.osgi.core-6.0.0.jar:]
>at
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)[org.osgi.core-6.0.0.jar:]
>at
> org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)[org.osgi.core-6.0.0.jar:]
>at
> org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)[org.osgi.core-6.0.0.jar:]
>at
> org.apache.aries.tx.control.jpa.common.impl.AbstractManagedJPADataSourceSetup.start(AbstractManagedJPADataSourceSetup.java:99)[173:tx-control-provider-jpa-xa:0.0.3]
>at
> org.apache.aries.tx.control.resource.common.impl.ConfigurationDefinedResourceFactory.updated(ConfigurationDefinedResourceFactory.java:82)[173:tx-control-provider-jpa-xa:0.0.3]
>at
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)[7:org.apache.felix.configadmin:1.8.8]
>at
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)[7:org.apache.felix.configadmin:1.8.8]
>at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)[7:org.apache.felix.configadmin:1.8.8]
>at
> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
>at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
>at java.lang.Thread.run(Thread.java:745)[:1.8.0_101]
> Caused by: java.sql.SQLException: Not supported
>at
> org.ops4j.pax.jdbc.pool.aries.impl.ds.AriesPooledDataSourceFactory.createXADataSource(AriesPooledDataSourceFactory.java:113)[165:org.ops4j.pax.jdbc.pool.aries:0.7.0]
>at
> org.apache.aries.tx.control.jpa.xa.impl.XAJPADataSourceSetup.decorateJPAProperties(XAJPADataSourceSetup.java:57)[173:tx-control-provider-jpa-xa:0.0.3]
>...
> 
> Here is what my org.apache.aries.tx.controljpa.xa-example.cfg looks like:
> 
> osgi.unit.name=ExamplePU
> osgi.jdbc.driver.class=com.mysql.jdbc.Driver-pool-xa
> url=jdbc:mysql://localhost:3306/myexample
> databaseName=myexample
> user=whatever
> password=whatever
> 
> 
> Can anyone explain to me why I am getting a not supported exception?
> 
> Kind Regards
> Cobus
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Error Creating XA DataSource

[cobusstroebel]

I am using Karaf 4.0.3 with the following features enabled:

jndi
transaction-api
transaction
jpa
eclipselink
pax-jdbc-config
pax-jdbc-mysql
pax-jdbc-pool-aries
mvn:javax.validation/validation-api/1.1.0.Final

mvn:org.apache.aries.tx-control/tx-control-service-xa/0.0.3

mvn:org.apache.aries.tx-control/tx-control-provider-jpa-xa/0.0.3

Whenever I drop in my org.apache.aries.tx.controljpa.xa-example.cfg in etc,
I get the following error:

An error occured creating the Resource provider for pid
org.apache.aries.tx.control.jpa.xa.9bc35a19-cd58-43fe-bb73-146cfb846f2f
org.osgi.service.transaction.control.TransactionException: Unable to create
the JDBC resource provider
at
org.apache.aries.tx.control.jpa.xa.impl.XAJPADataSourceSetup.decorateJPAProperties(XAJPADataSourceSetup.java:60)[173:tx-control-provider-jpa-xa:0.0.3]
at
org.apache.aries.tx.control.jpa.common.impl.AbstractManagedJPADataSourceSetup.addingService(AbstractManagedJPADataSourceSetup.java:111)[173:tx-control-provider-jpa-xa:0.0.3]
at
org.apache.aries.tx.control.jpa.common.impl.AbstractManagedJPADataSourceSetup.addingService(AbstractManagedJPADataSourceSetup.java:57)[173:tx-control-provider-jpa-xa:0.0.3]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)[org.osgi.core-6.0.0.jar:]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)[org.osgi.core-6.0.0.jar:]
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[org.osgi.core-6.0.0.jar:]
at
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)[org.osgi.core-6.0.0.jar:]
at
org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)[org.osgi.core-6.0.0.jar:]
at
org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)[org.osgi.core-6.0.0.jar:]
at
org.apache.aries.tx.control.jpa.common.impl.AbstractManagedJPADataSourceSetup.start(AbstractManagedJPADataSourceSetup.java:99)[173:tx-control-provider-jpa-xa:0.0.3]
at
org.apache.aries.tx.control.resource.common.impl.ConfigurationDefinedResourceFactory.updated(ConfigurationDefinedResourceFactory.java:82)[173:tx-control-provider-jpa-xa:0.0.3]
at
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_101]
Caused by: java.sql.SQLException: Not supported
at
org.ops4j.pax.jdbc.pool.aries.impl.ds.AriesPooledDataSourceFactory.createXADataSource(AriesPooledDataSourceFactory.java:113)[165:org.ops4j.pax.jdbc.pool.aries:0.7.0]
at
org.apache.aries.tx.control.jpa.xa.impl.XAJPADataSourceSetup.decorateJPAProperties(XAJPADataSourceSetup.java:57)[173:tx-control-provider-jpa-xa:0.0.3]
...

Here is what my org.apache.aries.tx.controljpa.xa-example.cfg looks like:

osgi.unit.name=ExamplePU
osgi.jdbc.driver.class=com.mysql.jdbc.Driver-pool-xa
url=jdbc:mysql://localhost:3306/myexample
databaseName=myexample
user=whatever
password=whatever


Can anyone explain to me why I am getting a not supported exception?

Kind Regards
Cobus



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: FeaturesProcessor and JDK11

[J . Brebec]

I have created KARAF-6142

It's related to the package-info class who is not visible on jdk11 by the 
plugin, but I didn't found a fix for now.

Regards,
Jérémie

On 2019/02/06 20:57:06, Jean-Baptiste Onofré  wrote: 
> Hi Jérémie,
> 
> can you please create a Jira (or I can do it for you) ?
> 
> I will fix that but for 4.2.4/4.3.0 as Karaf 4.2.3 release is in progress.
> 
> Regards
> JB
> 
> On 06/02/2019 20:59, J. Brebec wrote:
> > Hello,
> > 
> > I am using Karaf 4.2.2 and the karaf-maven-plugin to build a custom 
> > distribution. This distribution uses a features-processor xml files in 
> > order to blacklist/replaces some bundles.
> > 
> > This works fine under JDK8, however, it fails under JDK11. With this JDK, 
> > the features-processor files is unmarshalled without any elements.
> > 
> > For example, If I use this file :
> > 
> >  > xmlns="http://karaf.apache.org/xmlns/features-processing/v1.0.0;
> > xmlns:f="http://karaf.apache.org/xmlns/features/v1.5.0;>
> > 
> > 
> > 
> > with JDK8, the xsd validation of this file is successful. However, in 
> > JDK11, it fails because "blacklistedRepositories" should'nt have a 
> > namespace (and jaxb doesn't see any child elements)
> > 
> > Is it a know issues ? I didn't find anything about it on github.
> > 
> > Regards,
> > Jérémie
> > 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

Re: Connecting via jaas module results in FileNotFoundException

[abdelb]

Hi, sshRole was set to ssh. I changed it to admin and that has done the
trick! 

Really appreciate the assistance, thanks again.  



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html