Enterprise Java Development@TOPIC@

Chapter 29. Project 3 Grading

Your project will be graded on completeness and quality of product. In order for you to receive full credit in each area, it must be a) complete, b) done well, and c) tested. The breakdown of grading will be as follows:

The following table contains examples of where projects have lost points in the past. Of course, each project submitted can introduce new issues or different severity levels of the same issues. Do not treat this as a complete list.

Table 29.1. Sample Lost Points

README   
The WebUI is hard to navigate (fine) but README offered no assistance5  
Projects cleanly builds with Maven   
Using rogue users that are not part of the standard class setup in your end-to-end. 3  
Initial build fails. Looks to depend on DB schema bleedover between unit and IT tests. 2  
Project 1 and 2 functionality   
Second application being deployed as EAR and not WAR 2  
Relying on persistence unit to create schema -- thus blowing away all DB data on deployment 2  
Missing scenario feature (e.g., wrong data) from project 2 end-to-end scenario. 1  
Attempting to set the state of a @Stateless EJB. What do you think will happen to that state when you get a different bean instance the next time you call? 2  
Not self managing schema. With the end-to-end having resetAll() in place, why did you rely on the JPA provider to initialize your schema? 1  
Client Security Login   
Fine, but too many fine-grain logins. 0  
EJB Security   
Using credential logins for the JMS Connection from EJBs -- versus leveraging the @RunAs role 1  
Not relying on declaritive security to perform the role checks. You are also having the caller authorized for the role supply instance-specific information. For example, any division coordinator is allowed to report the score for any division. 2  
Not constraining authorized caller to manage only their information. Caller is passing references to information using identifiers that could be associated with any user versus "manage my stuff". By relying on those identifiers you are allowing them to "manage that stuff which may or may not be my stuff". 3  
EJB module not being associated with a specific security-domain. Relying on defaults. 2  
@RunAs takes a role -- not a principal 1  
WAR Security   
Requiring login to pages that should allow anonymous access. 1  
WAR is not properly locked down. 2  
Mixed use of BASIC and FORM. When signing in to perform action a Basic authentication popup appears and logout no longer functions, need to close browser to log out.    
EJB JMS Publisher   
Copied provided example wholesale and did not adjust to be your solution (e.g., features specific to the example are not required for project, comments specific to example are not appropriate for a project solution). 2  
Not closing resources (JMS 1.1) This eventually exhausts resources over time. 2  
Could not find testing of this anywhere to makeup for the fact that the end-to-end was not implemented 2  
EJB MDB Subscriber   
Not implemented 10  
Using System.out versus logging framework or better error reporting 1  
Java SE JMS Listener   
Did not provide your subscriber any credentials to interact with the server. 2  
Didn't work out of box. JMS topic mis-named 1  
EJB Timers   
It would be a better design to treat the timer() callback as an interface facade and not the triggering implementation mechanism. You have combined EJB Timer, JMS publishing, and business logic within a single method. 0  
End-to-end Integration Test   
Your configuration made it hard to run the end-to-end scenario in a debugger. All JNDI names and properties were solely expressed in the pom.xml rather than having suitable defaults in the IT test and overrides from the pom.xml. With that type of setup you did not have your pom.xml and surefire setup to allow remote debugging. 2  
Poluted, hard to follow, too much extra stuff2  
Missing resetAll and populate at start of scenarios5  
Missing step X1  
No. I want different functionality in this step1