Bug 1310908 - [GSS](6.4.z) EJBs accessible too early (spec violation)
[GSS](6.4.z) EJBs accessible too early (spec violation)
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: EJB (Show other bugs)
6.4.6
Unspecified Unspecified
unspecified Severity unspecified
: CR1
: EAP 6.4.9
Assigned To: Fedor Gavrilov
Jan Martiska
:
Depends On:
Blocks: eap649-payload 1350355 1366526
  Show dependency treegraph
 
Reported: 2016-02-22 18:43 EST by dereed
Modified: 2017-01-17 08:00 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1350355 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test.zip (3.37 KB, application/octet-stream)
2016-02-22 18:50 EST, 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 12:32 EDT, Brad Maxwell
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBEAP-3871 Critical Verified [GSS](7.0.z) EJBs accessible too early (spec violation) 2017-03-22 06:53 EDT
JBoss Issue Tracker WFLY-6402 Major Resolved EJBs accessible too early (spec violation) 2017-03-22 06:53 EDT

  None (edit)
Description dereed 2016-02-22 18:43:22 EST
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 18:50:12 EST
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 18:50 EST
Created attachment 1129567 [details]
test.zip
Comment 7 dereed 2016-02-23 16:42:21 EST
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 12:32 EDT
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-04 23:56:21 EDT
Fedor Gavrilov <fgavrilo@redhat.com> updated the status of jira WFLY-6402 to Coding In Progress
Comment 19 JBoss JIRA Server 2016-06-08 05:24:57 EDT
Fedor Gavrilov <fgavrilo@redhat.com> updated the status of jira WFLY-6402 to Coding In Progress
Comment 20 JBoss JIRA Server 2016-06-08 05:25:06 EDT
Fedor Gavrilov <fgavrilo@redhat.com> updated the status of jira WFLY-6402 to Open
Comment 21 JBoss JIRA Server 2016-06-08 05:25:52 EDT
Fedor Gavrilov <fgavrilo@redhat.com> updated the status of jira WFLY-6402 to Resolved
Comment 29 JBoss JIRA Server 2016-06-24 11:38:13 EDT
Fedor Gavrilov <fgavrilo@redhat.com> updated the status of jira WFLY-6402 to Reopened
Comment 31 Jiří Bílek 2016-06-29 04:52:56 EDT
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 07:58:57 EST
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.
Comment 33 Petr Penicka 2017-01-17 07:58:59 EST
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.
Comment 34 Petr Penicka 2017-01-17 08:00:52 EST
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.