Bug 1310908 - [GSS](6.4.z) EJBs accessible too early (spec violation)
Summary: [GSS](6.4.z) EJBs accessible too early (spec violation)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: EJB
Version: 6.4.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: CR1
: EAP 6.4.9
Assignee: Fedor Gavrilov
QA Contact: Jan Martiska
URL:
Whiteboard:
Depends On:
Blocks: eap649-payload 1350355 1366526
TreeView+ depends on / blocked
 
Reported: 2016-02-22 23:43 UTC by dereed
Modified: 2020-06-11 12:48 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1350355 (view as bug list)
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
test.zip (3.37 KB, application/octet-stream)
2016-02-22 23:50 UTC, dereed
no flags Details
auto-test-reproducer.zip - just deploy jars and it will log an error and stacktrace if issue occurs (5.47 KB, application/zip)
2016-03-17 16:32 UTC, Brad Maxwell
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBEAP-19447 0 Major New [GSS](7.3.z) Application does not fail when @Singleton @PostConstruct throws exception 2020-05-25 09:46:32 UTC
Red Hat Issue Tracker JBEAP-3871 0 Critical Verified [GSS](7.0.z) EJBs accessible too early (spec violation) 2020-05-25 09:46:32 UTC
Red Hat Issue Tracker WFLY-6402 0 Major Closed EJBs accessible too early (spec violation) 2020-05-25 09:46:32 UTC

Description dereed 2016-02-22 23:43:22 UTC
EJB 3.1 spec, section 4.8.1:
    "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.

EAP does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call.

Comment 1 dereed 2016-02-22 23:50:12 UTC
Attached test case, test.zip.

Deploy both singleton.jar and client.war.
Start EAP.

The @Singleton's @PostConstruct will log to stdout "starting pause" and sleep.
Hit client.war -- http://localhost:8080/client/ which accesses another bean in single
ton.war.

Expected: EJB call waits until @PostConstruct finishes.
Actual: EJB call completes immediately (logs to stdout "Singleton TestBean").

Comment 2 dereed 2016-02-22 23:50:55 UTC
Created attachment 1129567 [details]
test.zip

Comment 7 dereed 2016-02-23 21:42:21 UTC
Workaround: Add @DependsOn("SingletonEJBName"), or @DependsOn("ejb.jar#SingletonEJBName") for separate modules in an ear, to each EJB for each singleton it needs to wait on.

Comment 9 Brad Maxwell 2016-03-17 16:32:58 UTC
Created attachment 1137443 [details]
auto-test-reproducer.zip - just deploy jars and it will log an error and stacktrace if issue occurs

Comment 13 JBoss JIRA Server 2016-04-05 03:56:21 UTC
Fedor Gavrilov <fgavrilo> updated the status of jira WFLY-6402 to Coding In Progress

Comment 19 JBoss JIRA Server 2016-06-08 09:24:57 UTC
Fedor Gavrilov <fgavrilo> updated the status of jira WFLY-6402 to Coding In Progress

Comment 20 JBoss JIRA Server 2016-06-08 09:25:06 UTC
Fedor Gavrilov <fgavrilo> updated the status of jira WFLY-6402 to Open

Comment 21 JBoss JIRA Server 2016-06-08 09:25:52 UTC
Fedor Gavrilov <fgavrilo> updated the status of jira WFLY-6402 to Resolved

Comment 29 JBoss JIRA Server 2016-06-24 15:38:13 UTC
Fedor Gavrilov <fgavrilo> updated the status of jira WFLY-6402 to Reopened

Comment 31 Jiří Bílek 2016-06-29 08:52:56 UTC
test.zip works
auto-test-reproducer.zip does not work (https://bugzilla.redhat.com/show_bug.cgi?id=1350355)
Verified with EAP 6.4.9.CP.CR2

Comment 32 Petr Penicka 2017-01-17 12:58:57 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Comment 33 Petr Penicka 2017-01-17 12:58:59 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Comment 34 Petr Penicka 2017-01-17 13:00:52 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.


Note You need to log in before you can comment on or make changes to this bug.