ApacheCon is now less than a month away!

Dear Apache Enthusiast, ApacheCon Sevilla is now less than a month out, and we need your help getting the word out. Please tell your colleagues, your friends, and members of related technical communities, about this event. Rates go up November 3rd, so register today! ApacheCon, and Apache Big

Re: Decanter log collector: flooding OSGI event bus?

Thanks for the update. I will try to reproduce locally. I keep you posted. Regards JB On 10/19/2016 11:51 AM, 414n wrote: Sounds like maybe an EventListener of decanter was blocking for too long. Can you try to stop the decanter bundles individually and check which bundle

Re: Unable to resolve 'org.osgi.service.component.annotations'

"It's a poor craftsman that blames his tools." - Therefor, use what you want to use ;) And as said, that article i linked should help with your problem. *Toni Menzel* *Developer Advocates - The Rebaze Way * *www.rebaze.de | www.rebaze.com |

Re: Decanter log collector: flooding OSGI event bus?

Sounds like maybe an EventListener of decanter was blocking for too long. Can you try to stop the decanter bundles individually and check which bundle causes the delivery. Christian Hello Christian, I’ll try to perform this kind of test as soon as I can. Hi,

Re: See root exception cause in log?

It's a command. Regards JB On 10/19/2016 11:09 AM, Jens Reimann wrote: Thanks for the help. Is this a command? Or a configuration option in some file? On Wed, Oct 19, 2016 at 10:02 AM, Jean-Baptiste Onofré > wrote: stack-traces-print is useful

Re: See root exception cause in log?

Thanks for the help. Is this a command? Or a configuration option in some file? On Wed, Oct 19, 2016 at 10:02 AM, Jean-Baptiste Onofré wrote: > stack-traces-print is useful in dev mode to get the whole stack trace > directly on the shell console. > > Regards > JB > > On

Re: Best practice for context-specific service instances?

Thanks for the help, i will have a closer look to the tx-control -- View this message in context: http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048430.html Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Best practice for context-specific service instances?

Again - I would suggest that what you want is provided by the Transaction Control specification - you can begin a scope and then all work done within that scope remains isolated until the scope finishes. It’s trivial to provide a resource provider for a service, which gives you the scoping

Re: Best practice for context-specific service instances?

I dont think this is possible with OSGi services in general. As far as I know a service can have a singleton or prototype scope. Prototype means the service is instantiated once per requesting bundle. In tx control as well as in Aries JPA the entitymanager instance is bound to a thread. So if

Re: Best practice for context-specific service instances?

I want to ensure that changes in the database/persistence-unit that have not been committed are only visible to the instances handling the same request. But the EntityManager is only an example, I am looking for something like a context singleton scope for service instances. Think about a service

Re: See root exception cause in log?

stack-traces-print is useful in dev mode to get the whole stack trace directly on the shell console. Regards JB On 10/19/2016 09:59 AM, Jens Reimann wrote: This may be a "noob" question, but to me it looks like that in the karaf log file and this "log:display" command all exception are

Re: Unable to resolve 'org.osgi.service.component.annotations'

Hi Toni, ... I think you can argue about "the right" tool for ages ... I just use what is already there. And I do think that continuing arguing about that will probably kill this thread. On Tue, Oct 18, 2016 at 11:56 AM, Toni Menzel wrote: > If you are serious about OSGi