ApacheCon is now less than a month away!

[Rich Bowen]

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 Data, are the official gatherings of the
Apache Software Foundation, and one of the best places in the world to
meet other members of your project community, gain deeper knowledge
about your favorite Apache projects, learn about the ASF. Your project
doesn't live in a vacuum - it's part of a larger family of projects that
have a shared set of values, as well as a shared governance model. And
many of our project have an overlap in developers, in communities, and
in subject matter, making ApacheCon a great place for cross-pollination
of ideas and of communities.

Some highlights of these events will be:

* Many of our board members and project chairs will be present
* The lightning talks are a great place to hear, and give, short
presentations about what you and other members of the community are
working on
* The key signing gets you linked into the web of trust, and better
able to verify our software releases
* Evening receptions and parties where you can meet community
members in a less formal setting
* The State of the Feather, where you can learn what the ASF has
done in the last year, and what's coming next year
* BarCampApache, an informal unconference-style event, is another
venue for discussing your projects at the ASF

We have a great schedule lined up, covering the wide range of ASF
projects, including:

* CI and CD at Scale: Scaling Jenkins with Docker and Apache Mesos -
Carlos Sanchez
* Inner sourcing 101 - Jim Jagielski
* Java Memory Leaks in Modular Environments - Mark Thomas

ApacheCon/Apache Big Data will be held in Sevilla, Spain, at the Melia
Sevilla, November 14th through 18th. You can find out more at
http://apachecon.com/  Other ways to stay up to date with ApacheCon are:

* Follow us on Twitter at @apachecon
* Join us on IRC, at #apachecon on the Freenode IRC network
* Join the apachecon-discuss mailing list by sending email to
apachecon-discuss-subscr...@apache.org
* Or contact me directly at rbo...@apache.org with questions,
comments, or to volunteer to help

See you in Sevilla!

-- 
Rich Bowen: VP, Conferences
rbo...@apache.org
http://apachecon.com/
@apachecon

Re: Decanter log collector: flooding OSGI event bus?

[Jean-Baptiste Onofré]

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 causes the delivery.

Christian

Hello Christian,

I’ll try to perform this kind of test as soon as I can.

Hi,

what’s the Decanter version ?

Can you share the Decanter collectors you installed ?

By the way, I plan to release Decanter 1.3.0 later this week, so, if
it’s a bug, I would like to fix it for this release.

Thanks !
Regards
JB

Hello JB,

I’m using decanter-1.2.0 and I’ve deployed the log collector and the
socket appender in the same karaf instance, to send logs to a remote
host (which uses the decanter socket-collector).

Alan Alberghini
IOOOTA - a...@iooota.com 
https://www.iooota.com
https://www.facebook.com/IOOOTA





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-collector-flooding-OSGI-event-bus-tp4048415p4048434.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: Unable to resolve 'org.osgi.service.component.annotations'

[Toni Menzel]

"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
 | @rebazeio *

On Wed, Oct 19, 2016 at 8:36 AM, Jens Reimann  wrote:

> 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 development, try to migrate to Bndtools.
>> If you want to keep PDE and use DS, check out this tutorial from Lars
>> Vogel (always good for eclipse specific stuff): http://www.vogella.com
>> /tutorials/OSGiServices/article.html
>>
>>
>> *Toni Menzel*
>>
>>
>> *Developer Advocates - The Rebaze Way *
>>
>> *www.rebaze.de  | www.rebaze.com
>>  | @rebazeio *
>>
>> On Tue, Oct 18, 2016 at 9:57 AM, Markus Rathgeb 
>> wrote:
>>
>>> Hi Jens,
>>>
>>> > So as I understood it the annotations should not be imported.
>>>
>>> Yes, there is no need to import the component service annotations.
>>> As already written, this annotations are used a compile time to
>>> generate the XML files for DS.
>>>
>>> Best regards,
>>> Markus
>>>
>>
>>
>
>
> --
> Jens Reimann
> Senior Software Engineer / EMEA ENG Middleware
> Werner-von-Siemens-Ring 14
> 85630 Grasbrunn
> Germany
> phone: +49 89 2050 71286
> 
> _
>
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
> 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> Michael O'Neill
>

Re: Decanter log collector: flooding OSGI event bus?

[414n]

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,

what’s the Decanter version ?

Can you share the Decanter collectors you installed ?

By the way, I plan to release Decanter 1.3.0 later this week, so, if
it’s a bug, I would like to fix it for this release.

Thanks !
Regards
JB

Hello JB,

I’m using decanter-1.2.0 and I’ve deployed the log collector and the 
socket appender in the same karaf instance, to send logs to a remote 
host (which uses the decanter socket-collector).

Alan Alberghini
IOOOTA - a...@iooota.com 
https://www.iooota.com
https://www.facebook.com/IOOOTA





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-collector-flooding-OSGI-event-bus-tp4048415p4048434.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: See root exception cause in log?

[Jean-Baptiste Onofré]

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 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
missing the
"cause" stack traces.

Is there a way to enable this. Google did not turn up anything
useful.

Thanks

Jens

--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286 

_

Red Hat GmbH, www.de.redhat.com 
,
Registered seat: Grasbrunn, Commercial register: Amtsgericht
Muenchen,
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael
Cunningham,
Michael O'Neill


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




--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_

Red Hat GmbH, www.de.redhat.com ,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill


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

Re: See root exception cause in log?

[Jens Reimann]

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 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 missing the
>> "cause" stack traces.
>>
>> Is there a way to enable this. Google did not turn up anything useful.
>>
>> Thanks
>>
>> Jens
>>
>> --
>> Jens Reimann
>> Senior Software Engineer / EMEA ENG Middleware
>> Werner-von-Siemens-Ring 14
>> 85630 Grasbrunn
>> Germany
>> phone: +49 89 2050 71286
>> 
>> _
>>
>> Red Hat GmbH, www.de.redhat.com ,
>> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
>> HRB 153243,
>> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
>> Michael O'Neill
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

Re: Best practice for context-specific service instances?

[cniehues]

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?

[Timothy Ward]

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 that you want for that service. Resource providers already exist for 
JDBC and JPA, which may give you what you want out of the box already.


> On 19 Oct 2016, at 09:41, cniehues  wrote:
> 
> 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 that
> will be used multiple times that has a longer running initiation process
> depending on the request content.
> Is there maybe a factory I can extend?
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048427.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Best practice for context-specific service instances?

[Christian Schneider]

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 you use the same thread you get the same 
EntityManager through one call.

This might suit what you need but it is only working for the EntityManager.

Christian

On 19.10.2016 10:41, cniehues wrote:

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 that
will be used multiple times that has a longer running initiation process
depending on the request content.
Is there maybe a factory I can extend?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048427.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Best practice for context-specific service instances?

[cniehues]

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 that
will be used multiple times that has a longer running initiation process
depending on the request content.
Is there maybe a factory I can extend?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048427.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: See root exception cause in log?

[Jean-Baptiste Onofré]

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 missing the
"cause" stack traces.

Is there a way to enable this. Google did not turn up anything useful.

Thanks

Jens

--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_

Red Hat GmbH, www.de.redhat.com ,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill


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

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

[Jens Reimann]

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 development, try to migrate to Bndtools.
> If you want to keep PDE and use DS, check out this tutorial from Lars
> Vogel (always good for eclipse specific stuff): http://www.vogella.
> com/tutorials/OSGiServices/article.html
>
>
> *Toni Menzel*
>
>
> *Developer Advocates - The Rebaze Way *
>
> *www.rebaze.de  | www.rebaze.com
>  | @rebazeio *
>
> On Tue, Oct 18, 2016 at 9:57 AM, Markus Rathgeb 
> wrote:
>
>> Hi Jens,
>>
>> > So as I understood it the annotations should not be imported.
>>
>> Yes, there is no need to import the component service annotations.
>> As already written, this annotations are used a compile time to
>> generate the XML files for DS.
>>
>> Best regards,
>> Markus
>>
>
>


-- 
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill