@PostConstruct called twice on @javax.inject.Singleton

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

@PostConstruct called twice on @javax.inject.Singleton

Paul Carter-Brown
Hi,

Please see attached a test project in which a simple singleton is being initialised twice (post construct is called twice). Deploy the ear to TomEE (i'm using 7.0.3) and look at the logs.

I picked up this issue in a large project with an ear containing many wars packaged as "skinny". The injected bean is in one of the shared libraries.

If the pom in the ear project is changed to <skinnyWars>false</skinnyWars> and lines 44-48 are removed then the issue goes away and the init is only called once.

Any ideas?

Paul


This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/

test.zip (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

agumbrecht
Hi Paul,

In the interest of safety first, and benefit second, please create a
ticket here: https://issues.apache.org/jira/projects/TOMEE

Rather than attaching a ZIP here, please consider creating a GitHub
project and sharing it in the ticket.

Thanks,

Andy.

On 09/10/17 15:00, Paul Carter-Brown wrote:

> Hi,
>
> Please see attached a test project in which a simple singleton is
> being initialised twice (post construct is called twice). Deploy the
> ear to TomEE (i'm using 7.0.3) and look at the logs.
>
> I picked up this issue in a large project with an ear containing many
> wars packaged as "skinny". The injected bean is in one of the shared
> libraries.
>
> If the pom in the ear project is changed
> to <skinnyWars>false</skinnyWars> and lines 44-48 are removed then the
> issue goes away and the init is only called once.
>
> Any ideas?
>
> Paul
>
>
> This email is subject to the disclaimer of Smile Communications athttp://www.smilecoms.com/home/email-disclaimer/
> <http://www.smilecoms.com/home/email-disclaimer/>

    --
    Andy Gumbrecht

    http://www.tomitribe.com
    agumbrecht@tomitribe.com
    https://twitter.com/AndyGeeDe

    TomEE treibt Tomitribe ! | http://tomee.apache.org
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Romain Manni-Bucau
Hi Paul,

Did you check the instance - identity hashcode for instance? I wonder if it
is not 2 instances triggered on the same event.

Otherwise Andy is fully right in terms of enabling us to help you.

Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]> a écrit :

> Hi Paul,
>
> In the interest of safety first, and benefit second, please create a
> ticket here: https://issues.apache.org/jira/projects/TOMEE
>
> Rather than attaching a ZIP here, please consider creating a GitHub
> project and sharing it in the ticket.
>
> Thanks,
>
> Andy.
>
> On 09/10/17 15:00, Paul Carter-Brown wrote:
>
>> Hi,
>>
>> Please see attached a test project in which a simple singleton is being
>> initialised twice (post construct is called twice). Deploy the ear to TomEE
>> (i'm using 7.0.3) and look at the logs.
>>
>> I picked up this issue in a large project with an ear containing many
>> wars packaged as "skinny". The injected bean is in one of the shared
>> libraries.
>>
>> If the pom in the ear project is changed to <skinnyWars>false</skinnyWars>
>> and lines 44-48 are removed then the issue goes away and the init is only
>> called once.
>>
>> Any ideas?
>>
>> Paul
>>
>>
>> This email is subject to the disclaimer of Smile Communications athttp://
>> www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/home
>> /email-disclaimer/>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Paul Carter-Brown-2
Hi Andy/Romain,

I'll load on github today and create a ticket.

I have verified that it is a single instance by having a static
initializer: private static final String uuid =
UUID.randomUUID().toString();

The uuid remains the same on both calls to the postconstruct method

Paul

On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <[hidden email]>
wrote:

> Hi Paul,
>
> Did you check the instance - identity hashcode for instance? I wonder if it
> is not 2 instances triggered on the same event.
>
> Otherwise Andy is fully right in terms of enabling us to help you.
>
> Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]> a
> écrit :
>
> > Hi Paul,
> >
> > In the interest of safety first, and benefit second, please create a
> > ticket here: https://issues.apache.org/jira/projects/TOMEE
> >
> > Rather than attaching a ZIP here, please consider creating a GitHub
> > project and sharing it in the ticket.
> >
> > Thanks,
> >
> > Andy.
> >
> > On 09/10/17 15:00, Paul Carter-Brown wrote:
> >
> >> Hi,
> >>
> >> Please see attached a test project in which a simple singleton is being
> >> initialised twice (post construct is called twice). Deploy the ear to
> TomEE
> >> (i'm using 7.0.3) and look at the logs.
> >>
> >> I picked up this issue in a large project with an ear containing many
> >> wars packaged as "skinny". The injected bean is in one of the shared
> >> libraries.
> >>
> >> If the pom in the ear project is changed to
> <skinnyWars>false</skinnyWars>
> >> and lines 44-48 are removed then the issue goes away and the init is
> only
> >> called once.
> >>
> >> Any ideas?
> >>
> >> Paul
> >>
> >>
> >> This email is subject to the disclaimer of Smile Communications
> athttp://
> >> www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/home
> >> /email-disclaimer/>
> >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Paul Carter-Brown
In reply to this post by Romain Manni-Bucau
Hi,

Loaded on github and created ticket:

https://issues.apache.org/jira/browse/TOMEE-2134

On 10 October 2017 at 07:56, Romain Manni-Bucau <[hidden email]>
wrote:

> Hi Paul,
>
> Did you check the instance - identity hashcode for instance? I wonder if it
> is not 2 instances triggered on the same event.
>
> Otherwise Andy is fully right in terms of enabling us to help you.
>
> Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]> a
> écrit :
>
> > Hi Paul,
> >
> > In the interest of safety first, and benefit second, please create a
> > ticket here: https://issues.apache.org/jira/projects/TOMEE
> >
> > Rather than attaching a ZIP here, please consider creating a GitHub
> > project and sharing it in the ticket.
> >
> > Thanks,
> >
> > Andy.
> >
> > On 09/10/17 15:00, Paul Carter-Brown wrote:
> >
> >> Hi,
> >>
> >> Please see attached a test project in which a simple singleton is being
> >> initialised twice (post construct is called twice). Deploy the ear to
> TomEE
> >> (i'm using 7.0.3) and look at the logs.
> >>
> >> I picked up this issue in a large project with an ear containing many
> >> wars packaged as "skinny". The injected bean is in one of the shared
> >> libraries.
> >>
> >> If the pom in the ear project is changed to
> <skinnyWars>false</skinnyWars>
> >> and lines 44-48 are removed then the issue goes away and the init is
> only
> >> called once.
> >>
> >> Any ideas?
> >>
> >> Paul
> >>
> >>
> >> This email is subject to the disclaimer of Smile Communications
> athttp://
> >> www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/home
> >> /email-disclaimer/>
> >>
> >
> >
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>

Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

hwaastad
PS,
are U sure you wanna use javax.inject.Singleton?

Maybe javax.ejb.Singleton?

/hw

ti., 10.10.2017 kl. 08.34 +0200, skrev Paul Carter-Brown:

> Hi,
>
> Loaded on github and created ticket:
>
> https://issues.apache.org/jira/browse/TOMEE-2134
>
> On 10 October 2017 at 07:56, Romain Manni-Bucau
> m>
> wrote:
>
> >
> > Hi Paul,
> >
> > Did you check the instance - identity hashcode for instance? I
> > wonder if it
> > is not 2 instances triggered on the same event.
> >
> > Otherwise Andy is fully right in terms of enabling us to help you.
> >
> > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]>
> > a
> > écrit :
> >
> > >
> > > Hi Paul,
> > >
> > > In the interest of safety first, and benefit second, please
> > > create a
> > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > >
> > > Rather than attaching a ZIP here, please consider creating a
> > > GitHub
> > > project and sharing it in the ticket.
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > Please see attached a test project in which a simple singleton
> > > > is being
> > > > initialised twice (post construct is called twice). Deploy the
> > > > ear to
> > TomEE
> > >
> > > >
> > > > (i'm using 7.0.3) and look at the logs.
> > > >
> > > > I picked up this issue in a large project with an ear
> > > > containing many
> > > > wars packaged as "skinny". The injected bean is in one of the
> > > > shared
> > > > libraries.
> > > >
> > > > If the pom in the ear project is changed to
> > <skinnyWars>false</skinnyWars>
> > >
> > > >
> > > > and lines 44-48 are removed then the issue goes away and the
> > > > init is
> > only
> > >
> > > >
> > > > called once.
> > > >
> > > > Any ideas?
> > > >
> > > > Paul
> > > >
> > > >
> > > > This email is subject to the disclaimer of Smile Communications
> > athttp://
> > >
> > > >
> > > > www.smilecoms.com/home/email-disclaimer/
> > > >
> > > > /email-disclaimer/>
> > > >
> > >
>
>
> -- 
>
> *Paul Carter-Brown*
>
> *Group Chief Information Officer*
>
> *Smile Communications Pty (Ltd)       *
> Smile +234 (0) 702 000 1234
> Mobile +27 (0) 83 4427 179
> Skype PaulC-B
> [hidden email]
> www.smilecoms.com
>
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Paul Carter-Brown
Hi,
The use of plain CDI is intentional in this case. I don't need an EJB.
Interestingly enough I did a test by changing the singleton to a
javax.ejb.Singleton
and using "@EJB" in the servlet. With the EJB packaged with "skinny war"
the injection failed with an NPR when trying to use the EJB:

2017/10/10 09:56:59.273 WARNING
[main][1][org.apache.openejb.config.JndiEncInfoBuilder.buildEjbRefs]
|Unresolved ejb reference
"java:comp/env/com.test.beanmanagerbug.MyServlet/mySingletonInjected" in
bean "test-1.0.0.Comp".  Will attempt resolution again at runtime.
2017/10/10 09:56:59.278 WARNING
[main][1][org.apache.openejb.config.JndiEncInfoBuilder.buildEjbRefs]
|Unresolved ejb reference
"java:comp/env/com.test.beanmanagerbug.MyServlet/mySingletonInjected" in
bean "/opt/tomee/apps/testear-1.0.0/test-1.0.0".  Will attempt resolution
again at runtime.

If I changed to not use skinny wars then the EJB worked fine.

Seems like skinny wars is negatively impacting openejb and openwebbeans

Paul



On 10 October 2017 at 09:30, Helge Waastad <[hidden email]> wrote:

> PS,
> are U sure you wanna use javax.inject.Singleton?
>
> Maybe javax.ejb.Singleton?
>
> /hw
>
> ti., 10.10.2017 kl. 08.34 +0200, skrev Paul Carter-Brown:
> > Hi,
> >
> > Loaded on github and created ticket:
> >
> > https://issues.apache.org/jira/browse/TOMEE-2134
> >
> > On 10 October 2017 at 07:56, Romain Manni-Bucau
> > m>
> > wrote:
> >
> > >
> > > Hi Paul,
> > >
> > > Did you check the instance - identity hashcode for instance? I
> > > wonder if it
> > > is not 2 instances triggered on the same event.
> > >
> > > Otherwise Andy is fully right in terms of enabling us to help you.
> > >
> > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]>
> > > a
> > > écrit :
> > >
> > > >
> > > > Hi Paul,
> > > >
> > > > In the interest of safety first, and benefit second, please
> > > > create a
> > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > >
> > > > Rather than attaching a ZIP here, please consider creating a
> > > > GitHub
> > > > project and sharing it in the ticket.
> > > >
> > > > Thanks,
> > > >
> > > > Andy.
> > > >
> > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > Please see attached a test project in which a simple singleton
> > > > > is being
> > > > > initialised twice (post construct is called twice). Deploy the
> > > > > ear to
> > > TomEE
> > > >
> > > > >
> > > > > (i'm using 7.0.3) and look at the logs.
> > > > >
> > > > > I picked up this issue in a large project with an ear
> > > > > containing many
> > > > > wars packaged as "skinny". The injected bean is in one of the
> > > > > shared
> > > > > libraries.
> > > > >
> > > > > If the pom in the ear project is changed to
> > > <skinnyWars>false</skinnyWars>
> > > >
> > > > >
> > > > > and lines 44-48 are removed then the issue goes away and the
> > > > > init is
> > > only
> > > >
> > > > >
> > > > > called once.
> > > > >
> > > > > Any ideas?
> > > > >
> > > > > Paul
> > > > >
> > > > >
> > > > > This email is subject to the disclaimer of Smile Communications
> > > athttp://
> > > >
> > > > >
> > > > > www.smilecoms.com/home/email-disclaimer/
> > > > >
> > > > > /email-disclaimer/>
> > > > >
> > > >
> >
> >
> > --
> >
> > *Paul Carter-Brown*
> >
> > *Group Chief Information Officer*
> >
> > *Smile Communications Pty (Ltd)       *
> > Smile +234 (0) 702 000 1234
> > Mobile +27 (0) 83 4427 179
> > Skype PaulC-B
> > [hidden email]
> > www.smilecoms.com
> >
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>

Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Romain Manni-Bucau
In reply to this post by Paul Carter-Brown-2
And removing the static?

Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
[hidden email]> a écrit :

> Hi Andy/Romain,
>
> I'll load on github today and create a ticket.
>
> I have verified that it is a single instance by having a static
> initializer: private static final String uuid =
> UUID.randomUUID().toString();
>
> The uuid remains the same on both calls to the postconstruct method
>
> Paul
>
> On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <[hidden email]
> >
> wrote:
>
> > Hi Paul,
> >
> > Did you check the instance - identity hashcode for instance? I wonder if
> it
> > is not 2 instances triggered on the same event.
> >
> > Otherwise Andy is fully right in terms of enabling us to help you.
> >
> > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]> a
> > écrit :
> >
> > > Hi Paul,
> > >
> > > In the interest of safety first, and benefit second, please create a
> > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > >
> > > Rather than attaching a ZIP here, please consider creating a GitHub
> > > project and sharing it in the ticket.
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > >
> > >> Hi,
> > >>
> > >> Please see attached a test project in which a simple singleton is
> being
> > >> initialised twice (post construct is called twice). Deploy the ear to
> > TomEE
> > >> (i'm using 7.0.3) and look at the logs.
> > >>
> > >> I picked up this issue in a large project with an ear containing many
> > >> wars packaged as "skinny". The injected bean is in one of the shared
> > >> libraries.
> > >>
> > >> If the pom in the ear project is changed to
> > <skinnyWars>false</skinnyWars>
> > >> and lines 44-48 are removed then the issue goes away and the init is
> > only
> > >> called once.
> > >>
> > >> Any ideas?
> > >>
> > >> Paul
> > >>
> > >>
> > >> This email is subject to the disclaimer of Smile Communications
> > athttp://
> > >> www.smilecoms.com/home/email-disclaimer/ <
> http://www.smilecoms.com/home
> > >> /email-disclaimer/>
> > >>
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Paul Carter-Brown
Hi Romain,

As a non-static it is different on each call. The singleton is being
constructed twice within the same classloader.

I did some more digging and debugging and can see that 2 singleton contexts
are being created in CDI by two different initialisation flows that both
end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication. These 2
contexts their have their own state as to which beans are instantiated and
hence each calls postconstruct. Here are the stack traces for each case:

2017/10/10 14:13:36.626 WARNING
[main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
constructor
java.lang.Exception
at
org.apache.webbeans.context.SingletonContext.<init>(SingletonContext.java:44)
at
org.apache.webbeans.web.context.WebContextsService.initSingletonContext(WebContextsService.java:643)
at
org.apache.webbeans.web.context.WebContextsService.startContext(WebContextsService.java:329)
at
org.apache.webbeans.web.context.WebContextsService.init(WebContextsService.java:165)
at
org.apache.openejb.cdi.CdiAppContextsService.init(CdiAppContextsService.java:72)
at
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:197)
*at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:189)*
at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:917)
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:721)
at
org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:599)
at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:487)
at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
at org.apache.tomee.catalina.TomcatLoader.initialize(TomcatLoader.java:247)
at
org.apache.tomee.catalina.ServerListener.lifecycleEvent(ServerListener.java:168)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:395)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:108)
at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)


and:

2017/10/10 14:13:37.269 WARNING
[localhost-startStop-1][38][org.apache.webbeans.context.SingletonContext.<init>]
|In constructor
java.lang.Exception
at
org.apache.webbeans.context.SingletonContext.<init>(SingletonContext.java:44)
at
org.apache.webbeans.web.context.WebContextsService.initSingletonContext(WebContextsService.java:643)
at
org.apache.webbeans.web.context.WebContextsService.startContext(WebContextsService.java:329)
at
org.apache.webbeans.web.context.WebContextsService.init(WebContextsService.java:165)
at
org.apache.openejb.cdi.CdiAppContextsService.init(CdiAppContextsService.java:72)
at
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:197)
*at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:189)*
at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1424)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1125)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5105)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
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)


Let me know if you would prefer me to put any further findings on this
forum or on the ticket.

Paul

On 10 October 2017 at 13:15, Romain Manni-Bucau <[hidden email]>
wrote:

> And removing the static?
>
> Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
> [hidden email]> a écrit :
>
> > Hi Andy/Romain,
> >
> > I'll load on github today and create a ticket.
> >
> > I have verified that it is a single instance by having a static
> > initializer: private static final String uuid =
> > UUID.randomUUID().toString();
> >
> > The uuid remains the same on both calls to the postconstruct method
> >
> > Paul
> >
> > On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
> [hidden email]
> > >
> > wrote:
> >
> > > Hi Paul,
> > >
> > > Did you check the instance - identity hashcode for instance? I wonder
> if
> > it
> > > is not 2 instances triggered on the same event.
> > >
> > > Otherwise Andy is fully right in terms of enabling us to help you.
> > >
> > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]> a
> > > écrit :
> > >
> > > > Hi Paul,
> > > >
> > > > In the interest of safety first, and benefit second, please create a
> > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > >
> > > > Rather than attaching a ZIP here, please consider creating a GitHub
> > > > project and sharing it in the ticket.
> > > >
> > > > Thanks,
> > > >
> > > > Andy.
> > > >
> > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Please see attached a test project in which a simple singleton is
> > being
> > > >> initialised twice (post construct is called twice). Deploy the ear
> to
> > > TomEE
> > > >> (i'm using 7.0.3) and look at the logs.
> > > >>
> > > >> I picked up this issue in a large project with an ear containing
> many
> > > >> wars packaged as "skinny". The injected bean is in one of the shared
> > > >> libraries.
> > > >>
> > > >> If the pom in the ear project is changed to
> > > <skinnyWars>false</skinnyWars>
> > > >> and lines 44-48 are removed then the issue goes away and the init is
> > > only
> > > >> called once.
> > > >>
> > > >> Any ideas?
> > > >>
> > > >> Paul
> > > >>
> > > >>
> > > >> This email is subject to the disclaimer of Smile Communications
> > > athttp://
> > > >> www.smilecoms.com/home/email-disclaimer/ <
> > http://www.smilecoms.com/home
> > > >> /email-disclaimer/>
> > > >>
> > > >
> > > >
> > >
> >
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>

Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Romain Manni-Bucau
That is what I had in mind and it matches the classloader model of skinny
wars I think so it looks like it works as intended - as thought I mean.

Side note: you surely meant @ApplicationScoped more than singleton.


Le 10 oct. 2017 13:44, "Paul Carter-Brown" <[hidden email]>
a écrit :

> Hi Romain,
>
> As a non-static it is different on each call. The singleton is being
> constructed twice within the same classloader.
>
> I did some more digging and debugging and can see that 2 singleton contexts
> are being created in CDI by two different initialisation flows that both
> end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication. These
> 2
> contexts their have their own state as to which beans are instantiated and
> hence each calls postconstruct. Here are the stack traces for each case:
>
> 2017/10/10 14:13:36.626 WARNING
> [main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
> constructor
> java.lang.Exception
> at
> org.apache.webbeans.context.SingletonContext.<init>(
> SingletonContext.java:44)
> at
> org.apache.webbeans.web.context.WebContextsService.initSingletonContext(
> WebContextsService.java:643)
> at
> org.apache.webbeans.web.context.WebContextsService.startContext(
> WebContextsService.java:329)
> at
> org.apache.webbeans.web.context.WebContextsService.
> init(WebContextsService.java:165)
> at
> org.apache.openejb.cdi.CdiAppContextsService.init(
> CdiAppContextsService.java:72)
> at
> org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> OpenEJBLifecycle.java:197)
> *at
> org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> ThreadSingletonServiceImpl.java:189)*
> at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> at
> org.apache.openejb.assembler.classic.Assembler.
> createApplication(Assembler.java:917)
> at
> org.apache.openejb.assembler.classic.Assembler.
> createApplication(Assembler.java:721)
> at
> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(
> Assembler.java:599)
> at org.apache.openejb.assembler.classic.Assembler.build(
> Assembler.java:487)
> at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
> at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> at org.apache.tomee.catalina.TomcatLoader.initialize(
> TomcatLoader.java:247)
> at
> org.apache.tomee.catalina.ServerListener.lifecycleEvent(
> ServerListener.java:168)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> LifecycleBase.java:94)
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(
> LifecycleBase.java:395)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:108)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> 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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>
>
> and:
>
> 2017/10/10 14:13:37.269 WARNING
> [localhost-startStop-1][38][org.apache.webbeans.context.
> SingletonContext.<init>]
> |In constructor
> java.lang.Exception
> at
> org.apache.webbeans.context.SingletonContext.<init>(
> SingletonContext.java:44)
> at
> org.apache.webbeans.web.context.WebContextsService.initSingletonContext(
> WebContextsService.java:643)
> at
> org.apache.webbeans.web.context.WebContextsService.startContext(
> WebContextsService.java:329)
> at
> org.apache.webbeans.web.context.WebContextsService.
> init(WebContextsService.java:165)
> at
> org.apache.openejb.cdi.CdiAppContextsService.init(
> CdiAppContextsService.java:72)
> at
> org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> OpenEJBLifecycle.java:197)
> *at
> org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> ThreadSingletonServiceImpl.java:189)*
> at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
> TomcatWebAppBuilder.java:1424)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(
> TomcatWebAppBuilder.java:1125)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(
> GlobalListenerSupport.java:133)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> LifecycleBase.java:94)
> at
> org.apache.catalina.core.StandardContext.startInternal(
> StandardContext.java:5105)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(
> ContainerBase.java:1419)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(
> ContainerBase.java:1409)
> 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)
>
>
> Let me know if you would prefer me to put any further findings on this
> forum or on the ticket.
>
> Paul
>
> On 10 October 2017 at 13:15, Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > And removing the static?
> >
> > Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
> > [hidden email]> a écrit :
> >
> > > Hi Andy/Romain,
> > >
> > > I'll load on github today and create a ticket.
> > >
> > > I have verified that it is a single instance by having a static
> > > initializer: private static final String uuid =
> > > UUID.randomUUID().toString();
> > >
> > > The uuid remains the same on both calls to the postconstruct method
> > >
> > > Paul
> > >
> > > On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
> > [hidden email]
> > > >
> > > wrote:
> > >
> > > > Hi Paul,
> > > >
> > > > Did you check the instance - identity hashcode for instance? I wonder
> > if
> > > it
> > > > is not 2 instances triggered on the same event.
> > > >
> > > > Otherwise Andy is fully right in terms of enabling us to help you.
> > > >
> > > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]> a
> > > > écrit :
> > > >
> > > > > Hi Paul,
> > > > >
> > > > > In the interest of safety first, and benefit second, please create
> a
> > > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > > >
> > > > > Rather than attaching a ZIP here, please consider creating a GitHub
> > > > > project and sharing it in the ticket.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Andy.
> > > > >
> > > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> Please see attached a test project in which a simple singleton is
> > > being
> > > > >> initialised twice (post construct is called twice). Deploy the ear
> > to
> > > > TomEE
> > > > >> (i'm using 7.0.3) and look at the logs.
> > > > >>
> > > > >> I picked up this issue in a large project with an ear containing
> > many
> > > > >> wars packaged as "skinny". The injected bean is in one of the
> shared
> > > > >> libraries.
> > > > >>
> > > > >> If the pom in the ear project is changed to
> > > > <skinnyWars>false</skinnyWars>
> > > > >> and lines 44-48 are removed then the issue goes away and the init
> is
> > > > only
> > > > >> called once.
> > > > >>
> > > > >> Any ideas?
> > > > >>
> > > > >> Paul
> > > > >>
> > > > >>
> > > > >> This email is subject to the disclaimer of Smile Communications
> > > > athttp://
> > > > >> www.smilecoms.com/home/email-disclaimer/ <
> > > http://www.smilecoms.com/home
> > > > >> /email-disclaimer/>
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
>
> *Paul Carter-Brown*
>
> *Group Chief Information Officer*
>
> *Smile Communications Pty (Ltd)       *
> Smile +234 (0) 702 000 1234
> Mobile +27 (0) 83 4427 179
> Skype PaulC-B
> [hidden email]
> www.smilecoms.com
>
> --
>
>
> This email is subject to the disclaimer of Smile Communications at
> http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
> disclaimer>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Paul Carter-Brown
Hi Romain,

Correct me if I'm wrong but my understanding is that an EAR with shared
library jars should be considered as a single application. If a class
exists in a single jar and a single classloader and is marked as a
singleton then is it wrong to expect it to only be constructed once by CDI?
I could understand if the jar was in web-inf/lib of multiple wars but it's
not.

Paul

On 10 October 2017 at 14:55, Romain Manni-Bucau <[hidden email]>
wrote:

> That is what I had in mind and it matches the classloader model of skinny
> wars I think so it looks like it works as intended - as thought I mean.
>
> Side note: you surely meant @ApplicationScoped more than singleton.
>
>
> Le 10 oct. 2017 13:44, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> com>
> a écrit :
>
> > Hi Romain,
> >
> > As a non-static it is different on each call. The singleton is being
> > constructed twice within the same classloader.
> >
> > I did some more digging and debugging and can see that 2 singleton
> contexts
> > are being created in CDI by two different initialisation flows that both
> > end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication.
> These
> > 2
> > contexts their have their own state as to which beans are instantiated
> and
> > hence each calls postconstruct. Here are the stack traces for each case:
> >
> > 2017/10/10 14:13:36.626 WARNING
> > [main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
> > constructor
> > java.lang.Exception
> > at
> > org.apache.webbeans.context.SingletonContext.<init>(
> > SingletonContext.java:44)
> > at
> > org.apache.webbeans.web.context.WebContextsService.initSingletonContext(
> > WebContextsService.java:643)
> > at
> > org.apache.webbeans.web.context.WebContextsService.startContext(
> > WebContextsService.java:329)
> > at
> > org.apache.webbeans.web.context.WebContextsService.
> > init(WebContextsService.java:165)
> > at
> > org.apache.openejb.cdi.CdiAppContextsService.init(
> > CdiAppContextsService.java:72)
> > at
> > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > OpenEJBLifecycle.java:197)
> > *at
> > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > ThreadSingletonServiceImpl.java:189)*
> > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> > at
> > org.apache.openejb.assembler.classic.Assembler.
> > createApplication(Assembler.java:917)
> > at
> > org.apache.openejb.assembler.classic.Assembler.
> > createApplication(Assembler.java:721)
> > at
> > org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(
> > Assembler.java:599)
> > at org.apache.openejb.assembler.classic.Assembler.build(
> > Assembler.java:487)
> > at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
> > at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> > at org.apache.tomee.catalina.TomcatLoader.initialize(
> > TomcatLoader.java:247)
> > at
> > org.apache.tomee.catalina.ServerListener.lifecycleEvent(
> > ServerListener.java:168)
> > at
> > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > LifecycleBase.java:94)
> > at
> > org.apache.catalina.util.LifecycleBase.setStateInternal(
> > LifecycleBase.java:395)
> > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:108)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> > 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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> >
> >
> > and:
> >
> > 2017/10/10 14:13:37.269 WARNING
> > [localhost-startStop-1][38][org.apache.webbeans.context.
> > SingletonContext.<init>]
> > |In constructor
> > java.lang.Exception
> > at
> > org.apache.webbeans.context.SingletonContext.<init>(
> > SingletonContext.java:44)
> > at
> > org.apache.webbeans.web.context.WebContextsService.initSingletonContext(
> > WebContextsService.java:643)
> > at
> > org.apache.webbeans.web.context.WebContextsService.startContext(
> > WebContextsService.java:329)
> > at
> > org.apache.webbeans.web.context.WebContextsService.
> > init(WebContextsService.java:165)
> > at
> > org.apache.openejb.cdi.CdiAppContextsService.init(
> > CdiAppContextsService.java:72)
> > at
> > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > OpenEJBLifecycle.java:197)
> > *at
> > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > ThreadSingletonServiceImpl.java:189)*
> > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
> > at
> > org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
> > TomcatWebAppBuilder.java:1424)
> > at
> > org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(
> > TomcatWebAppBuilder.java:1125)
> > at
> > org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(
> > GlobalListenerSupport.java:133)
> > at
> > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > LifecycleBase.java:94)
> > at
> > org.apache.catalina.core.StandardContext.startInternal(
> > StandardContext.java:5105)
> > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> > at
> > org.apache.catalina.core.ContainerBase$StartChild.call(
> > ContainerBase.java:1419)
> > at
> > org.apache.catalina.core.ContainerBase$StartChild.call(
> > ContainerBase.java:1409)
> > 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)
> >
> >
> > Let me know if you would prefer me to put any further findings on this
> > forum or on the ticket.
> >
> > Paul
> >
> > On 10 October 2017 at 13:15, Romain Manni-Bucau <[hidden email]>
> > wrote:
> >
> > > And removing the static?
> > >
> > > Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
> > > [hidden email]> a écrit :
> > >
> > > > Hi Andy/Romain,
> > > >
> > > > I'll load on github today and create a ticket.
> > > >
> > > > I have verified that it is a single instance by having a static
> > > > initializer: private static final String uuid =
> > > > UUID.randomUUID().toString();
> > > >
> > > > The uuid remains the same on both calls to the postconstruct method
> > > >
> > > > Paul
> > > >
> > > > On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
> > > [hidden email]
> > > > >
> > > > wrote:
> > > >
> > > > > Hi Paul,
> > > > >
> > > > > Did you check the instance - identity hashcode for instance? I
> wonder
> > > if
> > > > it
> > > > > is not 2 instances triggered on the same event.
> > > > >
> > > > > Otherwise Andy is fully right in terms of enabling us to help you.
> > > > >
> > > > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]>
> a
> > > > > écrit :
> > > > >
> > > > > > Hi Paul,
> > > > > >
> > > > > > In the interest of safety first, and benefit second, please
> create
> > a
> > > > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > > > >
> > > > > > Rather than attaching a ZIP here, please consider creating a
> GitHub
> > > > > > project and sharing it in the ticket.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Andy.
> > > > > >
> > > > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> Please see attached a test project in which a simple singleton
> is
> > > > being
> > > > > >> initialised twice (post construct is called twice). Deploy the
> ear
> > > to
> > > > > TomEE
> > > > > >> (i'm using 7.0.3) and look at the logs.
> > > > > >>
> > > > > >> I picked up this issue in a large project with an ear containing
> > > many
> > > > > >> wars packaged as "skinny". The injected bean is in one of the
> > shared
> > > > > >> libraries.
> > > > > >>
> > > > > >> If the pom in the ear project is changed to
> > > > > <skinnyWars>false</skinnyWars>
> > > > > >> and lines 44-48 are removed then the issue goes away and the
> init
> > is
> > > > > only
> > > > > >> called once.
> > > > > >>
> > > > > >> Any ideas?
> > > > > >>
> > > > > >> Paul
> > > > > >>
> > > > > >>
> > > > > >> This email is subject to the disclaimer of Smile Communications
> > > > > athttp://
> > > > > >> www.smilecoms.com/home/email-disclaimer/ <
> > > > http://www.smilecoms.com/home
> > > > > >> /email-disclaimer/>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Paul Carter-Brown*
> >
> > *Group Chief Information Officer*
> >
> > *Smile Communications Pty (Ltd)       *
> > Smile +234 (0) 702 000 1234
> > Mobile +27 (0) 83 4427 179
> > Skype PaulC-B
> > [hidden email]
> > www.smilecoms.com
> >
> > --
> >
> >
> > This email is subject to the disclaimer of Smile Communications at
> > http://www.smilecoms.com/home/email-disclaimer/ <
> http://www.smilecoms.com/
> > disclaimer>
> >
> >
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>

Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Romain Manni-Bucau
But with skinny wars you still get it in the webapp loader and lib part
right ? It is not about physical model but resolved one.

Le 10 oct. 2017 14:11, "Paul Carter-Brown" <[hidden email]>
a écrit :

Hi Romain,

Correct me if I'm wrong but my understanding is that an EAR with shared
library jars should be considered as a single application. If a class
exists in a single jar and a single classloader and is marked as a
singleton then is it wrong to expect it to only be constructed once by CDI?
I could understand if the jar was in web-inf/lib of multiple wars but it's
not.

Paul

On 10 October 2017 at 14:55, Romain Manni-Bucau <[hidden email]>
wrote:

> That is what I had in mind and it matches the classloader model of skinny
> wars I think so it looks like it works as intended - as thought I mean.
>
> Side note: you surely meant @ApplicationScoped more than singleton.
>
>
> Le 10 oct. 2017 13:44, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> com>
> a écrit :
>
> > Hi Romain,
> >
> > As a non-static it is different on each call. The singleton is being
> > constructed twice within the same classloader.
> >
> > I did some more digging and debugging and can see that 2 singleton
> contexts
> > are being created in CDI by two different initialisation flows that both
> > end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication.
> These
> > 2
> > contexts their have their own state as to which beans are instantiated
> and
> > hence each calls postconstruct. Here are the stack traces for each case:
> >
> > 2017/10/10 14:13:36.626 WARNING
> > [main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
> > constructor
> > java.lang.Exception
> > at
> > org.apache.webbeans.context.SingletonContext.<init>(
> > SingletonContext.java:44)
> > at
> > org.apache.webbeans.web.context.WebContextsService.initSingletonContext(
> > WebContextsService.java:643)
> > at
> > org.apache.webbeans.web.context.WebContextsService.startContext(
> > WebContextsService.java:329)
> > at
> > org.apache.webbeans.web.context.WebContextsService.
> > init(WebContextsService.java:165)
> > at
> > org.apache.openejb.cdi.CdiAppContextsService.init(
> > CdiAppContextsService.java:72)
> > at
> > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > OpenEJBLifecycle.java:197)
> > *at
> > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > ThreadSingletonServiceImpl.java:189)*
> > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> > at
> > org.apache.openejb.assembler.classic.Assembler.
> > createApplication(Assembler.java:917)
> > at
> > org.apache.openejb.assembler.classic.Assembler.
> > createApplication(Assembler.java:721)
> > at
> > org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(
> > Assembler.java:599)
> > at org.apache.openejb.assembler.classic.Assembler.build(
> > Assembler.java:487)
> > at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
> > at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> > at org.apache.tomee.catalina.TomcatLoader.initialize(
> > TomcatLoader.java:247)
> > at
> > org.apache.tomee.catalina.ServerListener.lifecycleEvent(
> > ServerListener.java:168)
> > at
> > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > LifecycleBase.java:94)
> > at
> > org.apache.catalina.util.LifecycleBase.setStateInternal(
> > LifecycleBase.java:395)
> > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:108)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> > 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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> >
> >
> > and:
> >
> > 2017/10/10 14:13:37.269 WARNING
> > [localhost-startStop-1][38][org.apache.webbeans.context.
> > SingletonContext.<init>]
> > |In constructor
> > java.lang.Exception
> > at
> > org.apache.webbeans.context.SingletonContext.<init>(
> > SingletonContext.java:44)
> > at
> > org.apache.webbeans.web.context.WebContextsService.initSingletonContext(
> > WebContextsService.java:643)
> > at
> > org.apache.webbeans.web.context.WebContextsService.startContext(
> > WebContextsService.java:329)
> > at
> > org.apache.webbeans.web.context.WebContextsService.
> > init(WebContextsService.java:165)
> > at
> > org.apache.openejb.cdi.CdiAppContextsService.init(
> > CdiAppContextsService.java:72)
> > at
> > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > OpenEJBLifecycle.java:197)
> > *at
> > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > ThreadSingletonServiceImpl.java:189)*
> > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
> > at
> > org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
> > TomcatWebAppBuilder.java:1424)
> > at
> > org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(
> > TomcatWebAppBuilder.java:1125)
> > at
> > org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(
> > GlobalListenerSupport.java:133)
> > at
> > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > LifecycleBase.java:94)
> > at
> > org.apache.catalina.core.StandardContext.startInternal(
> > StandardContext.java:5105)
> > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> > at
> > org.apache.catalina.core.ContainerBase$StartChild.call(
> > ContainerBase.java:1419)
> > at
> > org.apache.catalina.core.ContainerBase$StartChild.call(
> > ContainerBase.java:1409)
> > 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)
> >
> >
> > Let me know if you would prefer me to put any further findings on this
> > forum or on the ticket.
> >
> > Paul
> >
> > On 10 October 2017 at 13:15, Romain Manni-Bucau <[hidden email]>
> > wrote:
> >
> > > And removing the static?
> > >
> > > Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
> > > [hidden email]> a écrit :
> > >
> > > > Hi Andy/Romain,
> > > >
> > > > I'll load on github today and create a ticket.
> > > >
> > > > I have verified that it is a single instance by having a static
> > > > initializer: private static final String uuid =
> > > > UUID.randomUUID().toString();
> > > >
> > > > The uuid remains the same on both calls to the postconstruct method
> > > >
> > > > Paul
> > > >
> > > > On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
> > > [hidden email]
> > > > >
> > > > wrote:
> > > >
> > > > > Hi Paul,
> > > > >
> > > > > Did you check the instance - identity hashcode for instance? I
> wonder
> > > if
> > > > it
> > > > > is not 2 instances triggered on the same event.
> > > > >
> > > > > Otherwise Andy is fully right in terms of enabling us to help you.
> > > > >
> > > > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <[hidden email]>
> a
> > > > > écrit :
> > > > >
> > > > > > Hi Paul,
> > > > > >
> > > > > > In the interest of safety first, and benefit second, please
> create
> > a
> > > > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > > > >
> > > > > > Rather than attaching a ZIP here, please consider creating a
> GitHub
> > > > > > project and sharing it in the ticket.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Andy.
> > > > > >
> > > > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> Please see attached a test project in which a simple singleton
> is
> > > > being
> > > > > >> initialised twice (post construct is called twice). Deploy the
> ear
> > > to
> > > > > TomEE
> > > > > >> (i'm using 7.0.3) and look at the logs.
> > > > > >>
> > > > > >> I picked up this issue in a large project with an ear
containing

> > > many
> > > > > >> wars packaged as "skinny". The injected bean is in one of the
> > shared
> > > > > >> libraries.
> > > > > >>
> > > > > >> If the pom in the ear project is changed to
> > > > > <skinnyWars>false</skinnyWars>
> > > > > >> and lines 44-48 are removed then the issue goes away and the
> init
> > is
> > > > > only
> > > > > >> called once.
> > > > > >>
> > > > > >> Any ideas?
> > > > > >>
> > > > > >> Paul
> > > > > >>
> > > > > >>
> > > > > >> This email is subject to the disclaimer of Smile Communications
> > > > > athttp://
> > > > > >> www.smilecoms.com/home/email-disclaimer/ <
> > > > http://www.smilecoms.com/home
> > > > > >> /email-disclaimer/>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Paul Carter-Brown*
> >
> > *Group Chief Information Officer*
> >
> > *Smile Communications Pty (Ltd)       *
> > Smile +234 (0) 702 000 1234
> > Mobile +27 (0) 83 4427 179
> > Skype PaulC-B
> > [hidden email]
> > www.smilecoms.com
> >
> > --
> >
> >
> > This email is subject to the disclaimer of Smile Communications at
> > http://www.smilecoms.com/home/email-disclaimer/ <
> http://www.smilecoms.com/
> > disclaimer>
> >
> >
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at
http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
disclaimer>
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Paul Carter-Brown
Hi,

I've used @ApplicationScoped and @javax.inject.Singleton and both have the
same behaviour. Seems like webbeans considers both to be Singleton as they
are stored in the singleton context.

In terms of the behaviour of these in an EAR:

https://issues.jboss.org/browse/CDI-129

Doing more research now...

On 10 October 2017 at 15:18, Romain Manni-Bucau <[hidden email]>
wrote:

> But with skinny wars you still get it in the webapp loader and lib part
> right ? It is not about physical model but resolved one.
>
> Le 10 oct. 2017 14:11, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> com>
> a écrit :
>
> Hi Romain,
>
> Correct me if I'm wrong but my understanding is that an EAR with shared
> library jars should be considered as a single application. If a class
> exists in a single jar and a single classloader and is marked as a
> singleton then is it wrong to expect it to only be constructed once by CDI?
> I could understand if the jar was in web-inf/lib of multiple wars but it's
> not.
>
> Paul
>
> On 10 October 2017 at 14:55, Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > That is what I had in mind and it matches the classloader model of skinny
> > wars I think so it looks like it works as intended - as thought I mean.
> >
> > Side note: you surely meant @ApplicationScoped more than singleton.
> >
> >
> > Le 10 oct. 2017 13:44, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> > com>
> > a écrit :
> >
> > > Hi Romain,
> > >
> > > As a non-static it is different on each call. The singleton is being
> > > constructed twice within the same classloader.
> > >
> > > I did some more digging and debugging and can see that 2 singleton
> > contexts
> > > are being created in CDI by two different initialisation flows that
> both
> > > end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication.
> > These
> > > 2
> > > contexts their have their own state as to which beans are instantiated
> > and
> > > hence each calls postconstruct. Here are the stack traces for each
> case:
> > >
> > > 2017/10/10 14:13:36.626 WARNING
> > > [main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
> > > constructor
> > > java.lang.Exception
> > > at
> > > org.apache.webbeans.context.SingletonContext.<init>(
> > > SingletonContext.java:44)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.
> initSingletonContext(
> > > WebContextsService.java:643)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.startContext(
> > > WebContextsService.java:329)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.
> > > init(WebContextsService.java:165)
> > > at
> > > org.apache.openejb.cdi.CdiAppContextsService.init(
> > > CdiAppContextsService.java:72)
> > > at
> > > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > > OpenEJBLifecycle.java:197)
> > > *at
> > > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > > ThreadSingletonServiceImpl.java:189)*
> > > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> > > at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:917)
> > > at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:721)
> > > at
> > > org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(
> > > Assembler.java:599)
> > > at org.apache.openejb.assembler.classic.Assembler.build(
> > > Assembler.java:487)
> > > at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
> > > at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> > > at org.apache.tomee.catalina.TomcatLoader.initialize(
> > > TomcatLoader.java:247)
> > > at
> > > org.apache.tomee.catalina.ServerListener.lifecycleEvent(
> > > ServerListener.java:168)
> > > at
> > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > > LifecycleBase.java:94)
> > > at
> > > org.apache.catalina.util.LifecycleBase.setStateInternal(
> > > LifecycleBase.java:395)
> > > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:108)
> > > at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> > > at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> > > 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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> > > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> > >
> > >
> > > and:
> > >
> > > 2017/10/10 14:13:37.269 WARNING
> > > [localhost-startStop-1][38][org.apache.webbeans.context.
> > > SingletonContext.<init>]
> > > |In constructor
> > > java.lang.Exception
> > > at
> > > org.apache.webbeans.context.SingletonContext.<init>(
> > > SingletonContext.java:44)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.
> initSingletonContext(
> > > WebContextsService.java:643)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.startContext(
> > > WebContextsService.java:329)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.
> > > init(WebContextsService.java:165)
> > > at
> > > org.apache.openejb.cdi.CdiAppContextsService.init(
> > > CdiAppContextsService.java:72)
> > > at
> > > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > > OpenEJBLifecycle.java:197)
> > > *at
> > > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > > ThreadSingletonServiceImpl.java:189)*
> > > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
> > > at
> > > org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
> > > TomcatWebAppBuilder.java:1424)
> > > at
> > > org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(
> > > TomcatWebAppBuilder.java:1125)
> > > at
> > > org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(
> > > GlobalListenerSupport.java:133)
> > > at
> > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > > LifecycleBase.java:94)
> > > at
> > > org.apache.catalina.core.StandardContext.startInternal(
> > > StandardContext.java:5105)
> > > at org.apache.catalina.util.LifecycleBase.start(
> LifecycleBase.java:150)
> > > at
> > > org.apache.catalina.core.ContainerBase$StartChild.call(
> > > ContainerBase.java:1419)
> > > at
> > > org.apache.catalina.core.ContainerBase$StartChild.call(
> > > ContainerBase.java:1409)
> > > 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)
> > >
> > >
> > > Let me know if you would prefer me to put any further findings on this
> > > forum or on the ticket.
> > >
> > > Paul
> > >
> > > On 10 October 2017 at 13:15, Romain Manni-Bucau <[hidden email]
> >
> > > wrote:
> > >
> > > > And removing the static?
> > > >
> > > > Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
> > > > [hidden email]> a écrit :
> > > >
> > > > > Hi Andy/Romain,
> > > > >
> > > > > I'll load on github today and create a ticket.
> > > > >
> > > > > I have verified that it is a single instance by having a static
> > > > > initializer: private static final String uuid =
> > > > > UUID.randomUUID().toString();
> > > > >
> > > > > The uuid remains the same on both calls to the postconstruct method
> > > > >
> > > > > Paul
> > > > >
> > > > > On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
> > > > [hidden email]
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Paul,
> > > > > >
> > > > > > Did you check the instance - identity hashcode for instance? I
> > wonder
> > > > if
> > > > > it
> > > > > > is not 2 instances triggered on the same event.
> > > > > >
> > > > > > Otherwise Andy is fully right in terms of enabling us to help
> you.
> > > > > >
> > > > > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <
> [hidden email]>
> > a
> > > > > > écrit :
> > > > > >
> > > > > > > Hi Paul,
> > > > > > >
> > > > > > > In the interest of safety first, and benefit second, please
> > create
> > > a
> > > > > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > > > > >
> > > > > > > Rather than attaching a ZIP here, please consider creating a
> > GitHub
> > > > > > > project and sharing it in the ticket.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Andy.
> > > > > > >
> > > > > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > > > > >
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> Please see attached a test project in which a simple singleton
> > is
> > > > > being
> > > > > > >> initialised twice (post construct is called twice). Deploy the
> > ear
> > > > to
> > > > > > TomEE
> > > > > > >> (i'm using 7.0.3) and look at the logs.
> > > > > > >>
> > > > > > >> I picked up this issue in a large project with an ear
> containing
> > > > many
> > > > > > >> wars packaged as "skinny". The injected bean is in one of the
> > > shared
> > > > > > >> libraries.
> > > > > > >>
> > > > > > >> If the pom in the ear project is changed to
> > > > > > <skinnyWars>false</skinnyWars>
> > > > > > >> and lines 44-48 are removed then the issue goes away and the
> > init
> > > is
> > > > > > only
> > > > > > >> called once.
> > > > > > >>
> > > > > > >> Any ideas?
> > > > > > >>
> > > > > > >> Paul
> > > > > > >>
> > > > > > >>
> > > > > > >> This email is subject to the disclaimer of Smile
> Communications
> > > > > > athttp://
> > > > > > >> www.smilecoms.com/home/email-disclaimer/ <
> > > > > http://www.smilecoms.com/home
> > > > > > >> /email-disclaimer/>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Paul Carter-Brown*
> > >
> > > *Group Chief Information Officer*
> > >
> > > *Smile Communications Pty (Ltd)       *
> > > Smile +234 (0) 702 000 1234
> > > Mobile +27 (0) 83 4427 179
> > > Skype PaulC-B
> > > [hidden email]
> > > www.smilecoms.com
> > >
> > > --
> > >
> > >
> > > This email is subject to the disclaimer of Smile Communications at
> > > http://www.smilecoms.com/home/email-disclaimer/ <
> > http://www.smilecoms.com/
> > > disclaimer>
> > >
> > >
> >
>
>
>
> --
>
> *Paul Carter-Brown*
>
> *Group Chief Information Officer*
>
> *Smile Communications Pty (Ltd)       *
> Smile +234 (0) 702 000 1234
> Mobile +27 (0) 83 4427 179
> Skype PaulC-B
> [hidden email]
> www.smilecoms.com
>
> --
>
>
> This email is subject to the disclaimer of Smile Communications at
> http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
> disclaimer>
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>

Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Romain Manni-Bucau
Le 10 oct. 2017 14:26, "Paul Carter-Brown" <[hidden email]>
a écrit :

Hi,

I've used @ApplicationScoped and @javax.inject.Singleton and both have the
same behaviour. Seems like webbeans considers both to be Singleton as they
are stored in the singleton context.



Yes, was just a side note for other behaviors.


In terms of the behaviour of these in an EAR:

https://issues.jboss.org/browse/CDI-129

Doing more research now...



This is the ticket. No solution since both impl are wrong (single context
or one per loader) but tomee one is the least worse after 2 years of
experimentations in early EE 6 times.






On 10 October 2017 at 15:18, Romain Manni-Bucau <[hidden email]>
wrote:

> But with skinny wars you still get it in the webapp loader and lib part
> right ? It is not about physical model but resolved one.
>
> Le 10 oct. 2017 14:11, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> com>
> a écrit :
>
> Hi Romain,
>
> Correct me if I'm wrong but my understanding is that an EAR with shared
> library jars should be considered as a single application. If a class
> exists in a single jar and a single classloader and is marked as a
> singleton then is it wrong to expect it to only be constructed once by
CDI?
> I could understand if the jar was in web-inf/lib of multiple wars but it's
> not.
>
> Paul
>
> On 10 October 2017 at 14:55, Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > That is what I had in mind and it matches the classloader model of
skinny

> > wars I think so it looks like it works as intended - as thought I mean.
> >
> > Side note: you surely meant @ApplicationScoped more than singleton.
> >
> >
> > Le 10 oct. 2017 13:44, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> > com>
> > a écrit :
> >
> > > Hi Romain,
> > >
> > > As a non-static it is different on each call. The singleton is being
> > > constructed twice within the same classloader.
> > >
> > > I did some more digging and debugging and can see that 2 singleton
> > contexts
> > > are being created in CDI by two different initialisation flows that
> both
> > > end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication.
> > These
> > > 2
> > > contexts their have their own state as to which beans are instantiated
> > and
> > > hence each calls postconstruct. Here are the stack traces for each
> case:
> > >
> > > 2017/10/10 14:13:36.626 WARNING
> > > [main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
> > > constructor
> > > java.lang.Exception
> > > at
> > > org.apache.webbeans.context.SingletonContext.<init>(
> > > SingletonContext.java:44)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.
> initSingletonContext(
> > > WebContextsService.java:643)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.startContext(
> > > WebContextsService.java:329)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.
> > > init(WebContextsService.java:165)
> > > at
> > > org.apache.openejb.cdi.CdiAppContextsService.init(
> > > CdiAppContextsService.java:72)
> > > at
> > > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > > OpenEJBLifecycle.java:197)
> > > *at
> > > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > > ThreadSingletonServiceImpl.java:189)*
> > > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> > > at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:917)
> > > at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:721)
> > > at
> > > org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(
> > > Assembler.java:599)
> > > at org.apache.openejb.assembler.classic.Assembler.build(
> > > Assembler.java:487)
> > > at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
> > > at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> > > at org.apache.tomee.catalina.TomcatLoader.initialize(
> > > TomcatLoader.java:247)
> > > at
> > > org.apache.tomee.catalina.ServerListener.lifecycleEvent(
> > > ServerListener.java:168)
> > > at
> > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > > LifecycleBase.java:94)
> > > at
> > > org.apache.catalina.util.LifecycleBase.setStateInternal(
> > > LifecycleBase.java:395)
> > > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:108)
> > > at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> > > at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> > > 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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> > > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> > >
> > >
> > > and:
> > >
> > > 2017/10/10 14:13:37.269 WARNING
> > > [localhost-startStop-1][38][org.apache.webbeans.context.
> > > SingletonContext.<init>]
> > > |In constructor
> > > java.lang.Exception
> > > at
> > > org.apache.webbeans.context.SingletonContext.<init>(
> > > SingletonContext.java:44)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.
> initSingletonContext(
> > > WebContextsService.java:643)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.startContext(
> > > WebContextsService.java:329)
> > > at
> > > org.apache.webbeans.web.context.WebContextsService.
> > > init(WebContextsService.java:165)
> > > at
> > > org.apache.openejb.cdi.CdiAppContextsService.init(
> > > CdiAppContextsService.java:72)
> > > at
> > > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > > OpenEJBLifecycle.java:197)
> > > *at
> > > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > > ThreadSingletonServiceImpl.java:189)*
> > > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
> > > at
> > > org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
> > > TomcatWebAppBuilder.java:1424)
> > > at
> > > org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(
> > > TomcatWebAppBuilder.java:1125)
> > > at
> > > org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(
> > > GlobalListenerSupport.java:133)
> > > at
> > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > > LifecycleBase.java:94)
> > > at
> > > org.apache.catalina.core.StandardContext.startInternal(
> > > StandardContext.java:5105)
> > > at org.apache.catalina.util.LifecycleBase.start(
> LifecycleBase.java:150)
> > > at
> > > org.apache.catalina.core.ContainerBase$StartChild.call(
> > > ContainerBase.java:1419)
> > > at
> > > org.apache.catalina.core.ContainerBase$StartChild.call(
> > > ContainerBase.java:1409)
> > > 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)
> > >
> > >
> > > Let me know if you would prefer me to put any further findings on this
> > > forum or on the ticket.
> > >
> > > Paul
> > >
> > > On 10 October 2017 at 13:15, Romain Manni-Bucau <[hidden email]
> >
> > > wrote:
> > >
> > > > And removing the static?
> > > >
> > > > Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
> > > > [hidden email]> a écrit :
> > > >
> > > > > Hi Andy/Romain,
> > > > >
> > > > > I'll load on github today and create a ticket.
> > > > >
> > > > > I have verified that it is a single instance by having a static
> > > > > initializer: private static final String uuid =
> > > > > UUID.randomUUID().toString();
> > > > >
> > > > > The uuid remains the same on both calls to the postconstruct
method

> > > > >
> > > > > Paul
> > > > >
> > > > > On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
> > > > [hidden email]
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Paul,
> > > > > >
> > > > > > Did you check the instance - identity hashcode for instance? I
> > wonder
> > > > if
> > > > > it
> > > > > > is not 2 instances triggered on the same event.
> > > > > >
> > > > > > Otherwise Andy is fully right in terms of enabling us to help
> you.
> > > > > >
> > > > > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <
> [hidden email]>
> > a
> > > > > > écrit :
> > > > > >
> > > > > > > Hi Paul,
> > > > > > >
> > > > > > > In the interest of safety first, and benefit second, please
> > create
> > > a
> > > > > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > > > > >
> > > > > > > Rather than attaching a ZIP here, please consider creating a
> > GitHub
> > > > > > > project and sharing it in the ticket.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Andy.
> > > > > > >
> > > > > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > > > > >
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> Please see attached a test project in which a simple
singleton
> > is
> > > > > being
> > > > > > >> initialised twice (post construct is called twice). Deploy
the

> > ear
> > > > to
> > > > > > TomEE
> > > > > > >> (i'm using 7.0.3) and look at the logs.
> > > > > > >>
> > > > > > >> I picked up this issue in a large project with an ear
> containing
> > > > many
> > > > > > >> wars packaged as "skinny". The injected bean is in one of the
> > > shared
> > > > > > >> libraries.
> > > > > > >>
> > > > > > >> If the pom in the ear project is changed to
> > > > > > <skinnyWars>false</skinnyWars>
> > > > > > >> and lines 44-48 are removed then the issue goes away and the
> > init
> > > is
> > > > > > only
> > > > > > >> called once.
> > > > > > >>
> > > > > > >> Any ideas?
> > > > > > >>
> > > > > > >> Paul
> > > > > > >>
> > > > > > >>
> > > > > > >> This email is subject to the disclaimer of Smile
> Communications
> > > > > > athttp://
> > > > > > >> www.smilecoms.com/home/email-disclaimer/ <
> > > > > http://www.smilecoms.com/home
> > > > > > >> /email-disclaimer/>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Paul Carter-Brown*
> > >
> > > *Group Chief Information Officer*
> > >
> > > *Smile Communications Pty (Ltd)       *
> > > Smile +234 (0) 702 000 1234
> > > Mobile +27 (0) 83 4427 179
> > > Skype PaulC-B
> > > [hidden email]
> > > www.smilecoms.com
> > >
> > > --
> > >
> > >
> > > This email is subject to the disclaimer of Smile Communications at
> > > http://www.smilecoms.com/home/email-disclaimer/ <
> > http://www.smilecoms.com/
> > > disclaimer>
> > >
> > >
> >
>
>
>
> --
>
> *Paul Carter-Brown*
>
> *Group Chief Information Officer*
>
> *Smile Communications Pty (Ltd)       *
> Smile +234 (0) 702 000 1234
> Mobile +27 (0) 83 4427 179
> Skype PaulC-B
> [hidden email]
> www.smilecoms.com
>
> --
>
>
> This email is subject to the disclaimer of Smile Communications at
> http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
> disclaimer>
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at
http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
disclaimer>
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Paul Carter-Brown
Hi Romain,

mmm this really throws a spanner in the works.

So let's say I have an EAR with many WARs and I have a jar which provides
shared functionality to the WARs. In the jar are classes that are expensive
to initialise and consume a lot of memory.

I hoped that putting the jar in EAR/lib and sharing across the WARs, in
combination with @Singleton/@ApplicationScoped and @PostConstruct was the
best way to go about this.

Assuming this now results in an instance per WAR within the EAR, what
workaround would you suggest? Should I drop CDI and use traditional
Singleton pattern with a factory method? Or Use CDI
@Singleton/@ApplicationScoped and store the member data statically and
change @PostConstruct to check if the object has been initialised already
and skip if it has?

This must surely be a common problem I am trying to solve.

Paul



On 10 October 2017 at 15:32, Romain Manni-Bucau <[hidden email]>
wrote:

> Le 10 oct. 2017 14:26, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> com>
> a écrit :
>
> Hi,
>
> I've used @ApplicationScoped and @javax.inject.Singleton and both have the
> same behaviour. Seems like webbeans considers both to be Singleton as they
> are stored in the singleton context.
>
>
>
> Yes, was just a side note for other behaviors.
>
>
> In terms of the behaviour of these in an EAR:
>
> https://issues.jboss.org/browse/CDI-129
>
> Doing more research now...
>
>
>
> This is the ticket. No solution since both impl are wrong (single context
> or one per loader) but tomee one is the least worse after 2 years of
> experimentations in early EE 6 times.
>
>
>
>
>
>
> On 10 October 2017 at 15:18, Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > But with skinny wars you still get it in the webapp loader and lib part
> > right ? It is not about physical model but resolved one.
> >
> > Le 10 oct. 2017 14:11, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> > com>
> > a écrit :
> >
> > Hi Romain,
> >
> > Correct me if I'm wrong but my understanding is that an EAR with shared
> > library jars should be considered as a single application. If a class
> > exists in a single jar and a single classloader and is marked as a
> > singleton then is it wrong to expect it to only be constructed once by
> CDI?
> > I could understand if the jar was in web-inf/lib of multiple wars but
> it's
> > not.
> >
> > Paul
> >
> > On 10 October 2017 at 14:55, Romain Manni-Bucau <[hidden email]>
> > wrote:
> >
> > > That is what I had in mind and it matches the classloader model of
> skinny
> > > wars I think so it looks like it works as intended - as thought I mean.
> > >
> > > Side note: you surely meant @ApplicationScoped more than singleton.
> > >
> > >
> > > Le 10 oct. 2017 13:44, "Paul Carter-Brown"
> <paul.carter-brown@smilecoms.
> > > com>
> > > a écrit :
> > >
> > > > Hi Romain,
> > > >
> > > > As a non-static it is different on each call. The singleton is being
> > > > constructed twice within the same classloader.
> > > >
> > > > I did some more digging and debugging and can see that 2 singleton
> > > contexts
> > > > are being created in CDI by two different initialisation flows that
> > both
> > > > end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication.
> > > These
> > > > 2
> > > > contexts their have their own state as to which beans are
> instantiated
> > > and
> > > > hence each calls postconstruct. Here are the stack traces for each
> > case:
> > > >
> > > > 2017/10/10 14:13:36.626 WARNING
> > > > [main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
> > > > constructor
> > > > java.lang.Exception
> > > > at
> > > > org.apache.webbeans.context.SingletonContext.<init>(
> > > > SingletonContext.java:44)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.
> > initSingletonContext(
> > > > WebContextsService.java:643)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.startContext(
> > > > WebContextsService.java:329)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.
> > > > init(WebContextsService.java:165)
> > > > at
> > > > org.apache.openejb.cdi.CdiAppContextsService.init(
> > > > CdiAppContextsService.java:72)
> > > > at
> > > > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > > > OpenEJBLifecycle.java:197)
> > > > *at
> > > > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > > > ThreadSingletonServiceImpl.java:189)*
> > > > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> > > > at
> > > > org.apache.openejb.assembler.classic.Assembler.
> > > > createApplication(Assembler.java:917)
> > > > at
> > > > org.apache.openejb.assembler.classic.Assembler.
> > > > createApplication(Assembler.java:721)
> > > > at
> > > > org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(
> > > > Assembler.java:599)
> > > > at org.apache.openejb.assembler.classic.Assembler.build(
> > > > Assembler.java:487)
> > > > at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
> > > > at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> > > > at org.apache.tomee.catalina.TomcatLoader.initialize(
> > > > TomcatLoader.java:247)
> > > > at
> > > > org.apache.tomee.catalina.ServerListener.lifecycleEvent(
> > > > ServerListener.java:168)
> > > > at
> > > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > > > LifecycleBase.java:94)
> > > > at
> > > > org.apache.catalina.util.LifecycleBase.setStateInternal(
> > > > LifecycleBase.java:395)
> > > > at org.apache.catalina.util.LifecycleBase.init(
> LifecycleBase.java:108)
> > > > at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> > > > at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> > > > 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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> > > > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> > > >
> > > >
> > > > and:
> > > >
> > > > 2017/10/10 14:13:37.269 WARNING
> > > > [localhost-startStop-1][38][org.apache.webbeans.context.
> > > > SingletonContext.<init>]
> > > > |In constructor
> > > > java.lang.Exception
> > > > at
> > > > org.apache.webbeans.context.SingletonContext.<init>(
> > > > SingletonContext.java:44)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.
> > initSingletonContext(
> > > > WebContextsService.java:643)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.startContext(
> > > > WebContextsService.java:329)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.
> > > > init(WebContextsService.java:165)
> > > > at
> > > > org.apache.openejb.cdi.CdiAppContextsService.init(
> > > > CdiAppContextsService.java:72)
> > > > at
> > > > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > > > OpenEJBLifecycle.java:197)
> > > > *at
> > > > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > > > ThreadSingletonServiceImpl.java:189)*
> > > > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
> > > > at
> > > > org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
> > > > TomcatWebAppBuilder.java:1424)
> > > > at
> > > > org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(
> > > > TomcatWebAppBuilder.java:1125)
> > > > at
> > > > org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(
> > > > GlobalListenerSupport.java:133)
> > > > at
> > > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > > > LifecycleBase.java:94)
> > > > at
> > > > org.apache.catalina.core.StandardContext.startInternal(
> > > > StandardContext.java:5105)
> > > > at org.apache.catalina.util.LifecycleBase.start(
> > LifecycleBase.java:150)
> > > > at
> > > > org.apache.catalina.core.ContainerBase$StartChild.call(
> > > > ContainerBase.java:1419)
> > > > at
> > > > org.apache.catalina.core.ContainerBase$StartChild.call(
> > > > ContainerBase.java:1409)
> > > > 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)
> > > >
> > > >
> > > > Let me know if you would prefer me to put any further findings on
> this
> > > > forum or on the ticket.
> > > >
> > > > Paul
> > > >
> > > > On 10 October 2017 at 13:15, Romain Manni-Bucau <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > And removing the static?
> > > > >
> > > > > Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
> > > > > [hidden email]> a écrit :
> > > > >
> > > > > > Hi Andy/Romain,
> > > > > >
> > > > > > I'll load on github today and create a ticket.
> > > > > >
> > > > > > I have verified that it is a single instance by having a static
> > > > > > initializer: private static final String uuid =
> > > > > > UUID.randomUUID().toString();
> > > > > >
> > > > > > The uuid remains the same on both calls to the postconstruct
> method
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > > On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
> > > > > [hidden email]
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Paul,
> > > > > > >
> > > > > > > Did you check the instance - identity hashcode for instance? I
> > > wonder
> > > > > if
> > > > > > it
> > > > > > > is not 2 instances triggered on the same event.
> > > > > > >
> > > > > > > Otherwise Andy is fully right in terms of enabling us to help
> > you.
> > > > > > >
> > > > > > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <
> > [hidden email]>
> > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Hi Paul,
> > > > > > > >
> > > > > > > > In the interest of safety first, and benefit second, please
> > > create
> > > > a
> > > > > > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > > > > > >
> > > > > > > > Rather than attaching a ZIP here, please consider creating a
> > > GitHub
> > > > > > > > project and sharing it in the ticket.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Andy.
> > > > > > > >
> > > > > > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > > > > > >
> > > > > > > >> Hi,
> > > > > > > >>
> > > > > > > >> Please see attached a test project in which a simple
> singleton
> > > is
> > > > > > being
> > > > > > > >> initialised twice (post construct is called twice). Deploy
> the
> > > ear
> > > > > to
> > > > > > > TomEE
> > > > > > > >> (i'm using 7.0.3) and look at the logs.
> > > > > > > >>
> > > > > > > >> I picked up this issue in a large project with an ear
> > containing
> > > > > many
> > > > > > > >> wars packaged as "skinny". The injected bean is in one of
> the
> > > > shared
> > > > > > > >> libraries.
> > > > > > > >>
> > > > > > > >> If the pom in the ear project is changed to
> > > > > > > <skinnyWars>false</skinnyWars>
> > > > > > > >> and lines 44-48 are removed then the issue goes away and the
> > > init
> > > > is
> > > > > > > only
> > > > > > > >> called once.
> > > > > > > >>
> > > > > > > >> Any ideas?
> > > > > > > >>
> > > > > > > >> Paul
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> This email is subject to the disclaimer of Smile
> > Communications
> > > > > > > athttp://
> > > > > > > >> www.smilecoms.com/home/email-disclaimer/ <
> > > > > > http://www.smilecoms.com/home
> > > > > > > >> /email-disclaimer/>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *Paul Carter-Brown*
> > > >
> > > > *Group Chief Information Officer*
> > > >
> > > > *Smile Communications Pty (Ltd)       *
> > > > Smile +234 (0) 702 000 1234
> > > > Mobile +27 (0) 83 4427 179
> > > > Skype PaulC-B
> > > > [hidden email]
> > > > www.smilecoms.com
> > > >
> > > > --
> > > >
> > > >
> > > > This email is subject to the disclaimer of Smile Communications at
> > > > http://www.smilecoms.com/home/email-disclaimer/ <
> > > http://www.smilecoms.com/
> > > > disclaimer>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Paul Carter-Brown*
> >
> > *Group Chief Information Officer*
> >
> > *Smile Communications Pty (Ltd)       *
> > Smile +234 (0) 702 000 1234
> > Mobile +27 (0) 83 4427 179
> > Skype PaulC-B
> > [hidden email]
> > www.smilecoms.com
> >
> > --
> >
> >
> > This email is subject to the disclaimer of Smile Communications at
> > http://www.smilecoms.com/home/email-disclaimer/ <
> http://www.smilecoms.com/
> > disclaimer>
> >
>
>
>
> --
>
> *Paul Carter-Brown*
>
> *Group Chief Information Officer*
>
> *Smile Communications Pty (Ltd)       *
> Smile +234 (0) 702 000 1234
> Mobile +27 (0) 83 4427 179
> Skype PaulC-B
> [hidden email]
> www.smilecoms.com
>
> --
>
>
> This email is subject to the disclaimer of Smile Communications at
> http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
> disclaimer>
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>

Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

chongma
you could consider using a rest interface to get shared data across
webapps?  i generally deploy the lib per webapp where i have a shared
lib.  the data can be loaded from a single shared rest interface.

On 10/10/2017 16:13, Paul Carter-Brown wrote:

> Hi Romain,
>
> mmm this really throws a spanner in the works.
>
> So let's say I have an EAR with many WARs and I have a jar which provides
> shared functionality to the WARs. In the jar are classes that are expensive
> to initialise and consume a lot of memory.
>
> I hoped that putting the jar in EAR/lib and sharing across the WARs, in
> combination with @Singleton/@ApplicationScoped and @PostConstruct was the
> best way to go about this.
>
> Assuming this now results in an instance per WAR within the EAR, what
> workaround would you suggest? Should I drop CDI and use traditional
> Singleton pattern with a factory method? Or Use CDI
> @Singleton/@ApplicationScoped and store the member data statically and
> change @PostConstruct to check if the object has been initialised already
> and skip if it has?
>
> This must surely be a common problem I am trying to solve.
>
> Paul
>
>
>
> On 10 October 2017 at 15:32, Romain Manni-Bucau <[hidden email]>
> wrote:
>
>> Le 10 oct. 2017 14:26, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
>> com>
>> a écrit :
>>
>> Hi,
>>
>> I've used @ApplicationScoped and @javax.inject.Singleton and both have the
>> same behaviour. Seems like webbeans considers both to be Singleton as they
>> are stored in the singleton context.
>>
>>
>>
>> Yes, was just a side note for other behaviors.
>>
>>
>> In terms of the behaviour of these in an EAR:
>>
>> https://issues.jboss.org/browse/CDI-129
>>
>> Doing more research now...
>>
>>
>>
>> This is the ticket. No solution since both impl are wrong (single context
>> or one per loader) but tomee one is the least worse after 2 years of
>> experimentations in early EE 6 times.
>>
>>
>>
>>
>>
>>
>> On 10 October 2017 at 15:18, Romain Manni-Bucau <[hidden email]>
>> wrote:
>>
>>> But with skinny wars you still get it in the webapp loader and lib part
>>> right ? It is not about physical model but resolved one.
>>>
>>> Le 10 oct. 2017 14:11, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
>>> com>
>>> a écrit :
>>>
>>> Hi Romain,
>>>
>>> Correct me if I'm wrong but my understanding is that an EAR with shared
>>> library jars should be considered as a single application. If a class
>>> exists in a single jar and a single classloader and is marked as a
>>> singleton then is it wrong to expect it to only be constructed once by
>> CDI?
>>> I could understand if the jar was in web-inf/lib of multiple wars but
>> it's
>>> not.
>>>
>>> Paul
>>>
>>> On 10 October 2017 at 14:55, Romain Manni-Bucau <[hidden email]>
>>> wrote:
>>>
>>>> That is what I had in mind and it matches the classloader model of
>> skinny
>>>> wars I think so it looks like it works as intended - as thought I mean.
>>>>
>>>> Side note: you surely meant @ApplicationScoped more than singleton.
>>>>
>>>>
>>>> Le 10 oct. 2017 13:44, "Paul Carter-Brown"
>> <paul.carter-brown@smilecoms.
>>>> com>
>>>> a écrit :
>>>>
>>>>> Hi Romain,
>>>>>
>>>>> As a non-static it is different on each call. The singleton is being
>>>>> constructed twice within the same classloader.
>>>>>
>>>>> I did some more digging and debugging and can see that 2 singleton
>>>> contexts
>>>>> are being created in CDI by two different initialisation flows that
>>> both
>>>>> end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication.
>>>> These
>>>>> 2
>>>>> contexts their have their own state as to which beans are
>> instantiated
>>>> and
>>>>> hence each calls postconstruct. Here are the stack traces for each
>>> case:
>>>>> 2017/10/10 14:13:36.626 WARNING
>>>>> [main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
>>>>> constructor
>>>>> java.lang.Exception
>>>>> at
>>>>> org.apache.webbeans.context.SingletonContext.<init>(
>>>>> SingletonContext.java:44)
>>>>> at
>>>>> org.apache.webbeans.web.context.WebContextsService.
>>> initSingletonContext(
>>>>> WebContextsService.java:643)
>>>>> at
>>>>> org.apache.webbeans.web.context.WebContextsService.startContext(
>>>>> WebContextsService.java:329)
>>>>> at
>>>>> org.apache.webbeans.web.context.WebContextsService.
>>>>> init(WebContextsService.java:165)
>>>>> at
>>>>> org.apache.openejb.cdi.CdiAppContextsService.init(
>>>>> CdiAppContextsService.java:72)
>>>>> at
>>>>> org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
>>>>> OpenEJBLifecycle.java:197)
>>>>> *at
>>>>> org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
>>>>> ThreadSingletonServiceImpl.java:189)*
>>>>> at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
>>>>> at
>>>>> org.apache.openejb.assembler.classic.Assembler.
>>>>> createApplication(Assembler.java:917)
>>>>> at
>>>>> org.apache.openejb.assembler.classic.Assembler.
>>>>> createApplication(Assembler.java:721)
>>>>> at
>>>>> org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(
>>>>> Assembler.java:599)
>>>>> at org.apache.openejb.assembler.classic.Assembler.build(
>>>>> Assembler.java:487)
>>>>> at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
>>>>> at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
>>>>> at org.apache.tomee.catalina.TomcatLoader.initialize(
>>>>> TomcatLoader.java:247)
>>>>> at
>>>>> org.apache.tomee.catalina.ServerListener.lifecycleEvent(
>>>>> ServerListener.java:168)
>>>>> at
>>>>> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
>>>>> LifecycleBase.java:94)
>>>>> at
>>>>> org.apache.catalina.util.LifecycleBase.setStateInternal(
>>>>> LifecycleBase.java:395)
>>>>> at org.apache.catalina.util.LifecycleBase.init(
>> LifecycleBase.java:108)
>>>>> at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
>>>>> at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
>>>>> 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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
>>>>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>>>>>
>>>>>
>>>>> and:
>>>>>
>>>>> 2017/10/10 14:13:37.269 WARNING
>>>>> [localhost-startStop-1][38][org.apache.webbeans.context.
>>>>> SingletonContext.<init>]
>>>>> |In constructor
>>>>> java.lang.Exception
>>>>> at
>>>>> org.apache.webbeans.context.SingletonContext.<init>(
>>>>> SingletonContext.java:44)
>>>>> at
>>>>> org.apache.webbeans.web.context.WebContextsService.
>>> initSingletonContext(
>>>>> WebContextsService.java:643)
>>>>> at
>>>>> org.apache.webbeans.web.context.WebContextsService.startContext(
>>>>> WebContextsService.java:329)
>>>>> at
>>>>> org.apache.webbeans.web.context.WebContextsService.
>>>>> init(WebContextsService.java:165)
>>>>> at
>>>>> org.apache.openejb.cdi.CdiAppContextsService.init(
>>>>> CdiAppContextsService.java:72)
>>>>> at
>>>>> org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
>>>>> OpenEJBLifecycle.java:197)
>>>>> *at
>>>>> org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
>>>>> ThreadSingletonServiceImpl.java:189)*
>>>>> at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
>>>>> at
>>>>> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
>>>>> TomcatWebAppBuilder.java:1424)
>>>>> at
>>>>> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(
>>>>> TomcatWebAppBuilder.java:1125)
>>>>> at
>>>>> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(
>>>>> GlobalListenerSupport.java:133)
>>>>> at
>>>>> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
>>>>> LifecycleBase.java:94)
>>>>> at
>>>>> org.apache.catalina.core.StandardContext.startInternal(
>>>>> StandardContext.java:5105)
>>>>> at org.apache.catalina.util.LifecycleBase.start(
>>> LifecycleBase.java:150)
>>>>> at
>>>>> org.apache.catalina.core.ContainerBase$StartChild.call(
>>>>> ContainerBase.java:1419)
>>>>> at
>>>>> org.apache.catalina.core.ContainerBase$StartChild.call(
>>>>> ContainerBase.java:1409)
>>>>> 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)
>>>>>
>>>>>
>>>>> Let me know if you would prefer me to put any further findings on
>> this
>>>>> forum or on the ticket.
>>>>>
>>>>> Paul
>>>>>
>>>>> On 10 October 2017 at 13:15, Romain Manni-Bucau <
>> [hidden email]
>>>>> wrote:
>>>>>
>>>>>> And removing the static?
>>>>>>
>>>>>> Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
>>>>>> [hidden email]> a écrit :
>>>>>>
>>>>>>> Hi Andy/Romain,
>>>>>>>
>>>>>>> I'll load on github today and create a ticket.
>>>>>>>
>>>>>>> I have verified that it is a single instance by having a static
>>>>>>> initializer: private static final String uuid =
>>>>>>> UUID.randomUUID().toString();
>>>>>>>
>>>>>>> The uuid remains the same on both calls to the postconstruct
>> method
>>>>>>> Paul
>>>>>>>
>>>>>>> On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
>>>>>> [hidden email]
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Paul,
>>>>>>>>
>>>>>>>> Did you check the instance - identity hashcode for instance? I
>>>> wonder
>>>>>> if
>>>>>>> it
>>>>>>>> is not 2 instances triggered on the same event.
>>>>>>>>
>>>>>>>> Otherwise Andy is fully right in terms of enabling us to help
>>> you.
>>>>>>>> Le 10 oct. 2017 01:25, "Andy Gumbrecht" <
>>> [hidden email]>
>>>> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>> Hi Paul,
>>>>>>>>>
>>>>>>>>> In the interest of safety first, and benefit second, please
>>>> create
>>>>> a
>>>>>>>>> ticket here: https://issues.apache.org/jira/projects/TOMEE
>>>>>>>>>
>>>>>>>>> Rather than attaching a ZIP here, please consider creating a
>>>> GitHub
>>>>>>>>> project and sharing it in the ticket.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Andy.
>>>>>>>>>
>>>>>>>>> On 09/10/17 15:00, Paul Carter-Brown wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please see attached a test project in which a simple
>> singleton
>>>> is
>>>>>>> being
>>>>>>>>>> initialised twice (post construct is called twice). Deploy
>> the
>>>> ear
>>>>>> to
>>>>>>>> TomEE
>>>>>>>>>> (i'm using 7.0.3) and look at the logs.
>>>>>>>>>>
>>>>>>>>>> I picked up this issue in a large project with an ear
>>> containing
>>>>>> many
>>>>>>>>>> wars packaged as "skinny". The injected bean is in one of
>> the
>>>>> shared
>>>>>>>>>> libraries.
>>>>>>>>>>
>>>>>>>>>> If the pom in the ear project is changed to
>>>>>>>> <skinnyWars>false</skinnyWars>
>>>>>>>>>> and lines 44-48 are removed then the issue goes away and the
>>>> init
>>>>> is
>>>>>>>> only
>>>>>>>>>> called once.
>>>>>>>>>>
>>>>>>>>>> Any ideas?
>>>>>>>>>>
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This email is subject to the disclaimer of Smile
>>> Communications
>>>>>>>> athttp://
>>>>>>>>>> www.smilecoms.com/home/email-disclaimer/ <
>>>>>>> http://www.smilecoms.com/home
>>>>>>>>>> /email-disclaimer/>
>>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Paul Carter-Brown*
>>>>>
>>>>> *Group Chief Information Officer*
>>>>>
>>>>> *Smile Communications Pty (Ltd)       *
>>>>> Smile +234 (0) 702 000 1234
>>>>> Mobile +27 (0) 83 4427 179
>>>>> Skype PaulC-B
>>>>> [hidden email]
>>>>> www.smilecoms.com
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> This email is subject to the disclaimer of Smile Communications at
>>>>> http://www.smilecoms.com/home/email-disclaimer/ <
>>>> http://www.smilecoms.com/
>>>>> disclaimer>
>>>>>
>>>>>
>>>
>>>
>>> --
>>>
>>> *Paul Carter-Brown*
>>>
>>> *Group Chief Information Officer*
>>>
>>> *Smile Communications Pty (Ltd)       *
>>> Smile +234 (0) 702 000 1234
>>> Mobile +27 (0) 83 4427 179
>>> Skype PaulC-B
>>> [hidden email]
>>> www.smilecoms.com
>>>
>>> --
>>>
>>>
>>> This email is subject to the disclaimer of Smile Communications at
>>> http://www.smilecoms.com/home/email-disclaimer/ <
>> http://www.smilecoms.com/
>>> disclaimer>
>>>
>>
>>
>> --
>>
>> *Paul Carter-Brown*
>>
>> *Group Chief Information Officer*
>>
>> *Smile Communications Pty (Ltd)       *
>> Smile +234 (0) 702 000 1234
>> Mobile +27 (0) 83 4427 179
>> Skype PaulC-B
>> [hidden email]
>> www.smilecoms.com
>>
>> --
>>
>>
>> This email is subject to the disclaimer of Smile Communications at
>> http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
>> disclaimer>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

Romain Manni-Bucau
In reply to this post by Paul Carter-Brown
Le 10 oct. 2017 15:14, "Paul Carter-Brown" <[hidden email]>
a écrit :

Hi Romain,

mmm this really throws a spanner in the works.

So let's say I have an EAR with many WARs and I have a jar which provides
shared functionality to the WARs. In the jar are classes that are expensive
to initialise and consume a lot of memory.

I hoped that putting the jar in EAR/lib and sharing across the WARs, in
combination with @Singleton/@ApplicationScoped and @PostConstruct was the
best way to go about this.

Assuming this now results in an instance per WAR within the EAR, what
workaround would you suggest? Should I drop CDI and use traditional
Singleton pattern with a factory method? Or Use CDI
@Singleton/@ApplicationScoped and store the member data statically and
change @PostConstruct to check if the object has been initialised already
and skip if it has?



EJB singleton does a smooth link here



This must surely be a common problem I am trying to solve.


Requires a new scope yes


Paul



On 10 October 2017 at 15:32, Romain Manni-Bucau <[hidden email]>
wrote:

> Le 10 oct. 2017 14:26, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> com>
> a écrit :
>
> Hi,
>
> I've used @ApplicationScoped and @javax.inject.Singleton and both have the
> same behaviour. Seems like webbeans considers both to be Singleton as they
> are stored in the singleton context.
>
>
>
> Yes, was just a side note for other behaviors.
>
>
> In terms of the behaviour of these in an EAR:
>
> https://issues.jboss.org/browse/CDI-129
>
> Doing more research now...
>
>
>
> This is the ticket. No solution since both impl are wrong (single context
> or one per loader) but tomee one is the least worse after 2 years of
> experimentations in early EE 6 times.
>
>
>
>
>
>
> On 10 October 2017 at 15:18, Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > But with skinny wars you still get it in the webapp loader and lib part
> > right ? It is not about physical model but resolved one.
> >
> > Le 10 oct. 2017 14:11, "Paul Carter-Brown" <paul.carter-brown@smilecoms.
> > com>
> > a écrit :
> >
> > Hi Romain,
> >
> > Correct me if I'm wrong but my understanding is that an EAR with shared
> > library jars should be considered as a single application. If a class
> > exists in a single jar and a single classloader and is marked as a
> > singleton then is it wrong to expect it to only be constructed once by
> CDI?
> > I could understand if the jar was in web-inf/lib of multiple wars but
> it's
> > not.
> >
> > Paul
> >
> > On 10 October 2017 at 14:55, Romain Manni-Bucau <[hidden email]>
> > wrote:
> >
> > > That is what I had in mind and it matches the classloader model of
> skinny
> > > wars I think so it looks like it works as intended - as thought I
mean.

> > >
> > > Side note: you surely meant @ApplicationScoped more than singleton.
> > >
> > >
> > > Le 10 oct. 2017 13:44, "Paul Carter-Brown"
> <paul.carter-brown@smilecoms.
> > > com>
> > > a écrit :
> > >
> > > > Hi Romain,
> > > >
> > > > As a non-static it is different on each call. The singleton is being
> > > > constructed twice within the same classloader.
> > > >
> > > > I did some more digging and debugging and can see that 2 singleton
> > > contexts
> > > > are being created in CDI by two different initialisation flows that
> > both
> > > > end up at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication.
> > > These
> > > > 2
> > > > contexts their have their own state as to which beans are
> instantiated
> > > and
> > > > hence each calls postconstruct. Here are the stack traces for each
> > case:
> > > >
> > > > 2017/10/10 14:13:36.626 WARNING
> > > > [main][1][org.apache.webbeans.context.SingletonContext.<init>] |In
> > > > constructor
> > > > java.lang.Exception
> > > > at
> > > > org.apache.webbeans.context.SingletonContext.<init>(
> > > > SingletonContext.java:44)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.
> > initSingletonContext(
> > > > WebContextsService.java:643)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.startContext(
> > > > WebContextsService.java:329)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.
> > > > init(WebContextsService.java:165)
> > > > at
> > > > org.apache.openejb.cdi.CdiAppContextsService.init(
> > > > CdiAppContextsService.java:72)
> > > > at
> > > > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > > > OpenEJBLifecycle.java:197)
> > > > *at
> > > > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > > > ThreadSingletonServiceImpl.java:189)*
> > > > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> > > > at
> > > > org.apache.openejb.assembler.classic.Assembler.
> > > > createApplication(Assembler.java:917)
> > > > at
> > > > org.apache.openejb.assembler.classic.Assembler.
> > > > createApplication(Assembler.java:721)
> > > > at
> > > > org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(
> > > > Assembler.java:599)
> > > > at org.apache.openejb.assembler.classic.Assembler.build(
> > > > Assembler.java:487)
> > > > at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:150)
> > > > at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> > > > at org.apache.tomee.catalina.TomcatLoader.initialize(
> > > > TomcatLoader.java:247)
> > > > at
> > > > org.apache.tomee.catalina.ServerListener.lifecycleEvent(
> > > > ServerListener.java:168)
> > > > at
> > > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > > > LifecycleBase.java:94)
> > > > at
> > > > org.apache.catalina.util.LifecycleBase.setStateInternal(
> > > > LifecycleBase.java:395)
> > > > at org.apache.catalina.util.LifecycleBase.init(
> LifecycleBase.java:108)
> > > > at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> > > > at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> > > > 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.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> > > > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> > > >
> > > >
> > > > and:
> > > >
> > > > 2017/10/10 14:13:37.269 WARNING
> > > > [localhost-startStop-1][38][org.apache.webbeans.context.
> > > > SingletonContext.<init>]
> > > > |In constructor
> > > > java.lang.Exception
> > > > at
> > > > org.apache.webbeans.context.SingletonContext.<init>(
> > > > SingletonContext.java:44)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.
> > initSingletonContext(
> > > > WebContextsService.java:643)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.startContext(
> > > > WebContextsService.java:329)
> > > > at
> > > > org.apache.webbeans.web.context.WebContextsService.
> > > > init(WebContextsService.java:165)
> > > > at
> > > > org.apache.openejb.cdi.CdiAppContextsService.init(
> > > > CdiAppContextsService.java:72)
> > > > at
> > > > org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(
> > > > OpenEJBLifecycle.java:197)
> > > > *at
> > > > org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(
> > > > ThreadSingletonServiceImpl.java:189)*
> > > > at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:60)
> > > > at
> > > > org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
> > > > TomcatWebAppBuilder.java:1424)
> > > > at
> > > > org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(
> > > > TomcatWebAppBuilder.java:1125)
> > > > at
> > > > org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(
> > > > GlobalListenerSupport.java:133)
> > > > at
> > > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
> > > > LifecycleBase.java:94)
> > > > at
> > > > org.apache.catalina.core.StandardContext.startInternal(
> > > > StandardContext.java:5105)
> > > > at org.apache.catalina.util.LifecycleBase.start(
> > LifecycleBase.java:150)
> > > > at
> > > > org.apache.catalina.core.ContainerBase$StartChild.call(
> > > > ContainerBase.java:1419)
> > > > at
> > > > org.apache.catalina.core.ContainerBase$StartChild.call(
> > > > ContainerBase.java:1409)
> > > > 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)
> > > >
> > > >
> > > > Let me know if you would prefer me to put any further findings on
> this
> > > > forum or on the ticket.
> > > >
> > > > Paul
> > > >
> > > > On 10 October 2017 at 13:15, Romain Manni-Bucau <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > And removing the static?
> > > > >
> > > > > Le 10 oct. 2017 11:45, "Paul Carter-Brown" <
> > > > > [hidden email]> a écrit :
> > > > >
> > > > > > Hi Andy/Romain,
> > > > > >
> > > > > > I'll load on github today and create a ticket.
> > > > > >
> > > > > > I have verified that it is a single instance by having a static
> > > > > > initializer: private static final String uuid =
> > > > > > UUID.randomUUID().toString();
> > > > > >
> > > > > > The uuid remains the same on both calls to the postconstruct
> method
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > > On Tue, Oct 10, 2017 at 7:56 AM, Romain Manni-Bucau <
> > > > > [hidden email]
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Paul,
> > > > > > >
> > > > > > > Did you check the instance - identity hashcode for instance? I
> > > wonder
> > > > > if
> > > > > > it
> > > > > > > is not 2 instances triggered on the same event.
> > > > > > >
> > > > > > > Otherwise Andy is fully right in terms of enabling us to help
> > you.
> > > > > > >
> > > > > > > Le 10 oct. 2017 01:25, "Andy Gumbrecht" <
> > [hidden email]>
> > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Hi Paul,
> > > > > > > >
> > > > > > > > In the interest of safety first, and benefit second, please
> > > create
> > > > a
> > > > > > > > ticket here: https://issues.apache.org/jira/projects/TOMEE
> > > > > > > >
> > > > > > > > Rather than attaching a ZIP here, please consider creating a
> > > GitHub
> > > > > > > > project and sharing it in the ticket.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Andy.
> > > > > > > >
> > > > > > > > On 09/10/17 15:00, Paul Carter-Brown wrote:
> > > > > > > >
> > > > > > > >> Hi,
> > > > > > > >>
> > > > > > > >> Please see attached a test project in which a simple
> singleton
> > > is
> > > > > > being
> > > > > > > >> initialised twice (post construct is called twice). Deploy
> the
> > > ear
> > > > > to
> > > > > > > TomEE
> > > > > > > >> (i'm using 7.0.3) and look at the logs.
> > > > > > > >>
> > > > > > > >> I picked up this issue in a large project with an ear
> > containing
> > > > > many
> > > > > > > >> wars packaged as "skinny". The injected bean is in one of
> the
> > > > shared
> > > > > > > >> libraries.
> > > > > > > >>
> > > > > > > >> If the pom in the ear project is changed to
> > > > > > > <skinnyWars>false</skinnyWars>
> > > > > > > >> and lines 44-48 are removed then the issue goes away and
the

> > > init
> > > > is
> > > > > > > only
> > > > > > > >> called once.
> > > > > > > >>
> > > > > > > >> Any ideas?
> > > > > > > >>
> > > > > > > >> Paul
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> This email is subject to the disclaimer of Smile
> > Communications
> > > > > > > athttp://
> > > > > > > >> www.smilecoms.com/home/email-disclaimer/ <
> > > > > > http://www.smilecoms.com/home
> > > > > > > >> /email-disclaimer/>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *Paul Carter-Brown*
> > > >
> > > > *Group Chief Information Officer*
> > > >
> > > > *Smile Communications Pty (Ltd)       *
> > > > Smile +234 (0) 702 000 1234
> > > > Mobile +27 (0) 83 4427 179
> > > > Skype PaulC-B
> > > > [hidden email]
> > > > www.smilecoms.com
> > > >
> > > > --
> > > >
> > > >
> > > > This email is subject to the disclaimer of Smile Communications at
> > > > http://www.smilecoms.com/home/email-disclaimer/ <
> > > http://www.smilecoms.com/
> > > > disclaimer>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Paul Carter-Brown*
> >
> > *Group Chief Information Officer*
> >
> > *Smile Communications Pty (Ltd)       *
> > Smile +234 (0) 702 000 1234
> > Mobile +27 (0) 83 4427 179
> > Skype PaulC-B
> > [hidden email]
> > www.smilecoms.com
> >
> > --
> >
> >
> > This email is subject to the disclaimer of Smile Communications at
> > http://www.smilecoms.com/home/email-disclaimer/ <
> http://www.smilecoms.com/
> > disclaimer>
> >
>
>
>
> --
>
> *Paul Carter-Brown*
>
> *Group Chief Information Officer*
>
> *Smile Communications Pty (Ltd)       *
> Smile +234 (0) 702 000 1234
> Mobile +27 (0) 83 4427 179
> Skype PaulC-B
> [hidden email]
> www.smilecoms.com
>
> --
>
>
> This email is subject to the disclaimer of Smile Communications at
> http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
> disclaimer>
>



--

*Paul Carter-Brown*

*Group Chief Information Officer*

*Smile Communications Pty (Ltd)       *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
[hidden email]
www.smilecoms.com

--


This email is subject to the disclaimer of Smile Communications at
http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
disclaimer>
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct called twice on @javax.inject.Singleton

agumbrecht
In reply to this post by Paul Carter-Brown
If I understand correctly I think you are trying to share state between
multiple apps in the same runtime. I've always found JMX meets this criteria
nicely.

Andy.



-----
    --
    Andy Gumbrecht

    http://www.tomitribe.com
    [hidden email]
    https://twitter.com/AndyGeeDe

    TomEE treibt Tomitribe ! | http://tomee.apache.org
--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
    --
    Andy Gumbrecht

    http://www.tomitribe.com
    agumbrecht@tomitribe.com
    https://twitter.com/AndyGeeDe

    TomEE treibt Tomitribe ! | http://tomee.apache.org