Re: new shell behavior regarding the threads pooling with Karaf 4.1

[Guillaume Nodet]

It has changed due to support for redirections and jobs in the console.
However, the assumption was already wrong with 4.0.x, for example:

*karaf*@root()> thread-name = { ((($.context bundle) loadClass
java.lang.Thread) currentThread) name }

((($.context bundle) loadClass java.lang.Thread) currentThread) name

*karaf*@root()> echo $(thread-name)

Karaf local console user karaf

*karaf*@root()> echo foo | echo $(thread-name)

pipe-[echo, $(thread-name)]

As you can see, in the second case, the thread is not the main one.
In Karaf 4.1.x, you can launch jobs in the background using the & operator,
or move them in the background at a later time using ^Z + fg.  So jobs have
to be launched in a separate thread.

On the security side, the way to obtain the karaf user is to use the jaas
subject.  It should be propagated throughout the session (though I just
found KARAF-5183).  I think if you're using a InheritableThreadLocal, it
should almost work (though you'll have the same problems as described in
KARAF-5183 I suppose).

2017-06-07 16:45 GMT+02:00 Nicolas Brasey :

> Hi guys!
>
> We are currently migrating from karaf 4.0.8 to 4.1.1 and discovered a new
> behavior in the shell. The new karaf does not dedicate a thread to the
> shell session, that means different commands in the same shell session
> might run in a different thread, which break our authentication mechanism
> which is maintained in a threadlocal.
>
> In the past, we never experienced karaf using different threads for
> executing different commands in the same shell session.
>
> So the question is: Is this change intentional from the Karaf team, or our
> assumption to have a single threaded session is wrong ?
>
> Thanks a lot!
>
> Nicolas
>



-- 

Guillaume Nodet

Re: Hibernate ORM with PostgresSql with Karaf 4.1.0

[smunro]

Hello Jack,

I don't see anything in your example about creating a data source on karaf. 
Have you defined a org.ops4j.datasource-.cfg for karaf?

Take a look at https://github.com/desolate-planet/osgi-jpa-demo this is just
a simple demo I created to get past my issue.

A few things to try, once you've deployed your data source and your bundle,
try the following in karaf:

service:list DataSourceFactory
service:list DataSource

The above will confirm you have a data source factory and a data source with
the desired name (store).

If you can verify the data source is available on karaf with the store name,
then the problem lies in your dependencies.

I don't have your code at hand to compare, but check my feature file to see
the repositories used as well as the versions of each feature.

Stephen






--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-ORM-with-PostgresSql-with-Karaf-4-1-0-tp4050582p4050606.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate, JPA and Karaf 4

[smunro]

Hello Jack,

I've commented on one your previous posts as this thread is growing arms and
legs now...

The repo was posted previously in the above comments.

Stephen



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-JPA-and-Karaf-4-tp4050569p4050607.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: new shell behavior regarding the threads pooling with Karaf 4.1

[Nicolas Brasey]

Hi Guillaume,

Thanks for your detailed answer, I was not aware the possibility to have
background jobs in the karaf shell, it makes sense now. This shell is a
really powerful tool :-)

Okay, I'll give a try with a InheritableThreadLocal as you proposed and let
you know. Thanks a lot for your help!

Nicolas







On Thu, Jun 8, 2017 at 9:17 AM, Guillaume Nodet  wrote:

> It has changed due to support for redirections and jobs in the console.
> However, the assumption was already wrong with 4.0.x, for example:
>
> *karaf*@root()> thread-name = { ((($.context bundle) loadClass
> java.lang.Thread) currentThread) name }
>
> ((($.context bundle) loadClass java.lang.Thread) currentThread) name
>
> *karaf*@root()> echo $(thread-name)
>
> Karaf local console user karaf
>
> *karaf*@root()> echo foo | echo $(thread-name)
>
> pipe-[echo, $(thread-name)]
>
> As you can see, in the second case, the thread is not the main one.
> In Karaf 4.1.x, you can launch jobs in the background using the & operator,
> or move them in the background at a later time using ^Z + fg.  So jobs have
> to be launched in a separate thread.
>
> On the security side, the way to obtain the karaf user is to use the jaas
> subject.  It should be propagated throughout the session (though I just
> found KARAF-5183).  I think if you're using a InheritableThreadLocal, it
> should almost work (though you'll have the same problems as described in
> KARAF-5183 I suppose).
>
> 2017-06-07 16:45 GMT+02:00 Nicolas Brasey :
>
>> Hi guys!
>>
>> We are currently migrating from karaf 4.0.8 to 4.1.1 and discovered a new
>> behavior in the shell. The new karaf does not dedicate a thread to the
>> shell session, that means different commands in the same shell session
>> might run in a different thread, which break our authentication mechanism
>> which is maintained in a threadlocal.
>>
>> In the past, we never experienced karaf using different threads for
>> executing different commands in the same shell session.
>>
>> So the question is: Is this change intentional from the Karaf team, or
>> our assumption to have a single threaded session is wrong ?
>>
>> Thanks a lot!
>>
>> Nicolas
>>
>
>
>
> --
> 
> Guillaume Nodet
>
>

Re: Hibernate ORM with PostgresSql with Karaf 4.1.0

[Timothy Ward]

Hi Jack,

As I posted in response to Stephen in another thread, Aries Transaction Control 
makes sorting out JPA quite a lot simpler. You end up with just one 
configuration to manage. I’m including that post below. The significant 
difference for you is that obviously you’ll want a Postgres driver rather than 
H2, and a Postgres Driver name/URL in the configuration.

Regards,

Tim

——

Hi,

Have you considered using OSGi Transaction Control rather than blueprint’s 
integration? Apache Aries has an implementation of this pre-release OSGi R7 
specification, and there are fewer moving parts. You can avoid deploying the 
blueprint/PAX JDBC pieces, and just use:

A JPA provider (OpenJPA 2.4, Hibernate 5.x, EclipseLink 2.6), 
Aries JPA Container 2.6.0 (none of the rest of Aries JPA will be needed)
Aries Transaction Control Service Local 

 (0.0.2 is available in Maven Central)
Aries Transaction Control JPA Local 

 (0.0.2 is available in Maven Central)
H2 (your database of choice?) which is already a fully paid up OSGi 
implementation 

If you then cut down your persistence unit to the bare essentials:

http://xmlns.jcp.org/xml/ns/persistence 
"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance 
"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 

http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd 
">
 

   org.hibernate.ejb.HibernatePersistence
 


And create a factory configuration for pid 
org.apache.aries.tx.control.jpa.local containing:

osgi.unit.name=authentication
osgi.jdbc.driver.class=org.h2.Driver
url=

You should then be able to inject the Transaction Control service and the 
JPAEntityManagerProvider, just like in this example 


I hope this helps,

Regards,

Tim 

——

> On 8 Jun 2017, at 09:09, smunro  wrote:
> 
> Hello Jack,
> 
> I don't see anything in your example about creating a data source on karaf. 
> Have you defined a org.ops4j.datasource-.cfg for karaf?
> 
> Take a look at https://github.com/desolate-planet/osgi-jpa-demo this is just
> a simple demo I created to get past my issue.
> 
> A few things to try, once you've deployed your data source and your bundle,
> try the following in karaf:
> 
> service:list DataSourceFactory
> service:list DataSource
> 
> The above will confirm you have a data source factory and a data source with
> the desired name (store).
> 
> If you can verify the data source is available on karaf with the store name,
> then the problem lies in your dependencies.
> 
> I don't have your code at hand to compare, but check my feature file to see
> the repositories used as well as the versions of each feature.
> 
> Stephen
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Hibernate-ORM-with-PostgresSql-with-Karaf-4-1-0-tp4050582p4050606.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

Aries JPA annotationless mappings

[smunro]

Hello,

I have another small obstacle regarding a requirement for avoiding
annotations :(

I have a bundle which contains model classes, but I'm not allowed to use
annotations as they are to be left agnostic. The obviously way round this is
to go back to the old mappings.xml.  I have an orm.xml in my META-INF, which
karaf picks up ok, but I am getting the following error:

  org.hibernate.AnnotationException: No identifier specified for entity:


I have an  attribute in my orm.xml file, so I'm guessing the .xml file
is being ignored. 

The only other option I can see round this is to wrap each model with an
annotated equivalent, but I'd like to try and cut the amount of code needed.
Is there an approach to disable annotations and ensure the mapping.xml is
the only source used?

I remember reading something about aries jpa2 always needing annotations,
but I can't find that comment anymore, so I dunno if it's still valid.

Stephen



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Aries-JPA-annotationless-mappings-tp4050610.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Aries JPA annotationless mappings

[smunro]

I came across this: https://issues.apache.org/jira/browse/ARIES-1711, so I
guess I need to create those wrappers :)



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Aries-JPA-annotationless-mappings-tp4050610p4050611.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate, JPA and Karaf 4

[Jack]

Hi Stephen,

I have took your code and modified my code inline with yours, but my bundles
status showing "Grace Period".

If I remove below two line then, bundles will start properly

  






--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-JPA-and-Karaf-4-tp4050569p4050612.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate, JPA and Karaf 4

[smunro]

Sounds like your using another version of JPA. Look at the xml schema in the
persistence.xml and check your using the jpa 2.0 namespace. If your using
jpa 1, then the code below won't work, you'll need to use the jpa 1.0
solution:

  
  
  


What errors are shown in karaf.log?

Warm Regards,
Stephen Munro



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-JPA-and-Karaf-4-tp4050569p4050613.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate, JPA and Karaf 4

[Jack]

No error in the logs, but the status of the bundle shows "Grace Period"

Below is my blueprint file


http://www.osgi.org/xmlns/blueprint/v1.0.0";
   xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0";
   xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
   http://aries.apache.org/xmlns/jpa/v2.0.0
   http://aries.apache.org/xmlns/transactions/v2.0.0";>
   





 









--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-JPA-and-Karaf-4-tp4050569p4050614.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate ORM with PostgresSql with Karaf 4.1.0

[Jack]

Hi,

I have placed my datasource in deploy folder. 

 

 

You can see the details




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-ORM-with-PostgresSql-with-Karaf-4-1-0-tp4050582p4050615.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate, JPA and Karaf 4

[Allan C.]

I've encountered something similar to what you're facing now. I'm not quite
certain what caused the bundle not starting but IIRC I think the Dao bundle
in grace period is resolved after trying with several different hibernate
versions.

I wish I could be more of help.

Regards, Allan.

Sent from Gmail mobile.

On 8 Jun 2017 18:40, "Jack"  wrote:

No error in the logs, but the status of the bundle shows "Grace Period"

Below is my blueprint file


http://www.osgi.org/xmlns/blueprint/v1.0.0";
   xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0";
   xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
   http://aries.apache.org/xmlns/jpa/v2.0.0
   http://aries.apache.org/xmlns/transactions/v2.0.0";>






 









--
View this message in context: http://karaf.922171.n3.nabble.
com/Hibernate-JPA-and-Karaf-4-tp4050569p4050614.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate, JPA and Karaf 4

[Jean-Baptiste Onofré]

You should have the cause of the grace period in the log.

I bet on the namespace. Can you check that ?

Regards
JB

On 06/08/2017 01:04 PM, Allan C. wrote:
I've encountered something similar to what you're facing now. I'm not quite 
certain what caused the bundle not starting but IIRC I think the Dao bundle in 
grace period is resolved after trying with several different hibernate versions.


I wish I could be more of help.

Regards, Allan.

Sent from Gmail mobile.

On 8 Jun 2017 18:40, "Jack" mailto:sshett...@gmail.com>> 
wrote:


No error in the logs, but the status of the bundle shows "Grace Period"

Below is my blueprint file


http://www.osgi.org/xmlns/blueprint/v1.0.0
"
xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0
"
xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0
"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
"
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0

https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd

http://aries.apache.org/xmlns/jpa/v2.0.0

http://aries.apache.org/xmlns/transactions/v2.0.0
">


 
 

 
  
 
 

 





--
View this message in context:

http://karaf.922171.n3.nabble.com/Hibernate-JPA-and-Karaf-4-tp4050569p4050614.html


Sent from the Karaf - User mailing list archive at Nabble.com.




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Hibernate, JPA and Karaf 4

[Allan C.]

It was kind of an early setup + POC. The log files have been deleted but I
can try to reproduce this issue with 4.0.5. No promise though. Will get
back to you.

Regards, Allan.

Sent from Gmail mobile.

On 8 Jun 2017 19:36, "Jean-Baptiste Onofré"  wrote:

> You should have the cause of the grace period in the log.
>
> I bet on the namespace. Can you check that ?
>
> Regards
> JB
>
> On 06/08/2017 01:04 PM, Allan C. wrote:
>
>> I've encountered something similar to what you're facing now. I'm not
>> quite certain what caused the bundle not starting but IIRC I think the Dao
>> bundle in grace period is resolved after trying with several different
>> hibernate versions.
>>
>> I wish I could be more of help.
>>
>> Regards, Allan.
>>
>> Sent from Gmail mobile.
>>
>> On 8 Jun 2017 18:40, "Jack" > sshett...@gmail.com>> wrote:
>>
>> No error in the logs, but the status of the bundle shows "Grace
>> Period"
>>
>> Below is my blueprint file
>>
>> 
>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>> "
>> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0
>> "
>> xmlns:tx="http://aries.apache.
>> org/xmlns/transactions/v2.0.0
>> "
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>> "
>> xsi:schemaLocation="http://www
>> .osgi.org/xmlns/blueprint/v1.0.0
>> 
>> https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>> 
>> http://aries.apache.org/xmlns/jpa/v2.0.0
>> 
>> http://aries.apache.org/xmlns/transactions/v2.0.0
>> ">
>>
>>
>>  
>>  
>>
>>  > >
>>   > unitname="toshibarma"/>
>>  
>>  
>>
>>  > interface="com.rma.data.dao.StoreDao" />
>>
>> 
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Hibernate-JPA-and-Karaf-4-
>> tp4050569p4050614.html
>> > 4-tp4050569p4050614.html>
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Hibernate, JPA and Karaf 4

[Jean-Baptiste Onofré]

Hi Allan,

that would be great if you can reproduce and share your project. Then, I will 
take a look.


Thanks !
Regards
JB

On 06/08/2017 01:55 PM, Allan C. wrote:
It was kind of an early setup + POC. The log files have been deleted but I can 
try to reproduce this issue with 4.0.5. No promise though. Will get back to you.


Regards, Allan.

Sent from Gmail mobile.

On 8 Jun 2017 19:36, "Jean-Baptiste Onofré" > wrote:


You should have the cause of the grace period in the log.

I bet on the namespace. Can you check that ?

Regards
JB

On 06/08/2017 01:04 PM, Allan C. wrote:

I've encountered something similar to what you're facing now. I'm not
quite certain what caused the bundle not starting but IIRC I think the
Dao bundle in grace period is resolved after trying with several
different hibernate versions.

I wish I could be more of help.

Regards, Allan.

Sent from Gmail mobile.

On 8 Jun 2017 18:40, "Jack" mailto:sshett...@gmail.com> >> wrote:

 No error in the logs, but the status of the bundle shows "Grace 
Period"

 Below is my blueprint file

 
 http://www.osgi.org/xmlns/blueprint/v1.0.0

 >"
 xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0

 >"

xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0


 >"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance

 >"

xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0


 >
https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd

 >
http://aries.apache.org/xmlns/jpa/v2.0.0

 >
http://aries.apache.org/xmlns/transactions/v2.0.0

 >">


  
  

  
   
  
  

  http://com.rma.data.dao.St>oreDao" 
/>

 



 --
 View this message in context:

http://karaf.922171.n3.nabble.com/Hibernate-JPA-and-Karaf-4-tp4050569p4050614.html



>
 Sent from the Karaf - User mailing list archive at Nabble.com.



-- 
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

HotswapAgent and Karaf

[Castor]

Hello! 

Since i'm losing some time with redeploys ( Yes, bundle:watch helps a lot,
but my bundle takes quite sometime to clean/install everytime ) i'm trying
to find a faster way to develop. One of the options is to use a hot code
swapper like JRebel or DCEVM + HotSwap agent. 

It seems that HotSpot agent supports Equinox
http://hotswapagent.org/mydoc_plugin_osgiequinox.html , so i created a
equinox standalone bundle to test, and it works quite ok! So i changed the
karaf framework to Equinox and added the following config to karaf.bat, as
told in the guide. 

-XXaltjvm=dcevm -Dosgi.frameworkParentClassloader=app
-javaagent:C:\hotswap\hotswap-agent.jar

With that, it seems that Karaf itself starts with Hotswap Agent, but the
hotswap classloader is not propagated to the underlying bundles, it seems to
me that Karaf is initializing with HotSwap, but not the underlying Equinox,
how can i fix that?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/HotswapAgent-and-Karaf-tp4050620.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Feature install runs 30 minutes finishes wiith out of memory error in Felix resolver code

[jholloway]

We are currently using Karaf 4.0.9.  We have a feature file that has worked
for us for over a year.  We have noticed a slight degradation during the
feature install in the past few months as we have added bundles and
sub-features to our feature file.  Recently, we added numerous new
sub-features and bundles to our one feature file.  Currently, the feature
install hangs between 15 and 45 minutes until we get a Java heap space out
of memory error.  The print stack trace shows that it is in the Felix
resolver the entire time.  However, when we downloaded, setup and configured
Karaf 4.1.1, the same feature file installed with no problem and very
quickly.  Is there something we can do within Karaf 4.0.9 to make it process
our feature file more efficiently without hanging?  Officially upgrading to
Karaf 4.1.1 is out of our control. 



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Feature-install-runs-30-minutes-finishes-wiith-out-of-memory-error-in-Felix-resolver-code-tp4050625.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate ORM with PostgresSql with Karaf 4.1.0

[Jack]

Hi added my project in below location

https://github.com/JackMic/hibernate---postgres--karaf.4.1.0

If some can download the project and solve my problem.

I'm almost trying from two weeks to resolve this issue.

Note : i'm using karaf 4.1.0





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-ORM-with-PostgresSql-with-Karaf-4-1-0-tp4050582p4050628.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hibernate, JPA and Karaf 4

[Jack]

Hi added my project in below location

https://github.com/JackMic/hibernate---postgres--karaf.4.1.0

If some can download the project and solve my problem.

I'm almost trying from two weeks to resolve this issue.

Note : i'm using karaf 4.1.0




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-JPA-and-Karaf-4-tp4050569p4050629.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Feature install runs 30 minutes finishes wiith out of memory error in Felix resolver code

[Guillaume Nodet]

What about just the following command in the karaf console ?
  update org.apache.karaf.features.core
mvn:org.apache.karaf.features/org.apache.karaf.features.core/4.1.1

2017-06-08 19:59 GMT+02:00 jholloway :

> We are currently using Karaf 4.0.9.  We have a feature file that has worked
> for us for over a year.  We have noticed a slight degradation during the
> feature install in the past few months as we have added bundles and
> sub-features to our feature file.  Recently, we added numerous new
> sub-features and bundles to our one feature file.  Currently, the feature
> install hangs between 15 and 45 minutes until we get a Java heap space out
> of memory error.  The print stack trace shows that it is in the Felix
> resolver the entire time.  However, when we downloaded, setup and
> configured
> Karaf 4.1.1, the same feature file installed with no problem and very
> quickly.  Is there something we can do within Karaf 4.0.9 to make it
> process
> our feature file more efficiently without hanging?  Officially upgrading to
> Karaf 4.1.1 is out of our control.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Feature-install-runs-30-minutes-finishes-wiith-out-of-
> memory-error-in-Felix-resolver-code-tp4050625.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 

Guillaume Nodet