think of it as internal design documentation
when you revisit this code 8 months from now:
- based on nothing but your well-chosen ;) package/class/method/variable names, will you recall all of your current design intentions and rationale? likely not
- when you hand-off this code to another software engineer, how easy will it be to mostly rtfm? will you have to waste time preparing design/implementation notes specifically for the hand-off? if this is the case because the code is unreadable and not self-guiding and there's not already at least high level design notes in a wiki, you're doing it wrong!
If a method is overridden in a subclass, Javadoc should only be present
if it says something distinct to the original definition of the method
this at least makes the paragraph breaks wysiwygísh and somewhat easier to read
Use a single <li> tag for items in a list
place a single <li> tag at the start of the line and no closing tag
Define a punchy first sentence
it has the responsibility of summing up the method or class to readers scanning
the class or package
the first sentence should be
clear and punchy, and generally short
use the third person form at the start
Avoid the second person form, such as "Get the foo"
Use "this" to refer to an instance of the class
When referring to an instance of the class being documented, use "this" to reference it.
Aim for short single line sentences
Wherever possible, make Javadoc sentences fit on a single line
favouring between 80 and 120 characters
Use @link and @code wisely
@link feature creates a visible hyperlink in generated Javadoc to the target
@code feature provides a section of fixed-width font, ideal for references to
methods and class names
Only use @link on the first reference to a specific class or method
Use @code for subsequent references.
This avoids excessive hyperlinks cluttering up the Javadoc
Never use @link in the first sentence
Always use @code in the first sentence if necessary
Adding a hyperlink in that first sentence makes the higher level documentation more confusing
Do not use @code for null, true or false
Adding @code for every occurrence is a burden to both the reader and writer of the
Javadoc and adds no real value.
Use @param, @return and @throws
@param entries should be specified in the same order as the parameters
@return should be after the @param entries
followed by @throws.
Use @param for generics
correct approach is an @param tag with the parameter name of <T> where T
is the type parameter name.
Use one blank line before @param
This aids readability in source code.
Treat @param and @return as a phrase
They should start with a lower case letter, typically using the word "the".
They should not end with a dot.
This aids readability in source code and when generated.
treated as phrases rather than complete sentences
Treat @throws as an if clause
phrase describing the condition
Define null-handling for all parameters and return types
ideally, if the method in question has any specified/required pre and/or post conditions, they should be noted in the javadoc, not *just* null handling
also, there are cleaner ways to design around this type of old school null handling hackage
methods should define their null-tolerance in the @param or @return
likewise with javadoc on things like default constructors
/**
* Creates an instance of SomeClass
*/
public SomeClass() {}
is equally useless and unnecessarily clutters up the source code
free and more feature rich alternative to BlazeDS, but also outranks LCDS’ out-of-the-box features when it comes to data management, streaming media and integrating with mobile devices and Cloud computing
developer tools like code generation, invocation test drive and interoperability with multiple IDEs and frameworks
supporting integration with mobile clients (Android, Windows Phone 7, RIM Playbook and soon iOS) and the Java service layer, which includes support for Java POJOs, EJBs, Spring Beans, Grails controllers, Hibernate Objects and XML Web Services
Spring is controlled by ONE COMPANY. It is not an independent open source organization like Apache. At least with Java EE there are multiple OPEN SOURCE implementations. How long before VMWare decides its $500 million investment needs to be recouped and they start charging for Spring in a big way? Don’t think it can happen? Think again…VMWare is in the same poor position BEA/WLS was against JBoss with Red Hat’s VM/Cloud tech eating away at VMWare’s margins. There is a much higher chance of them scrambling for revenue sources than Red hat ever being acquired by Oracle.
Core JavaServer Faces
JSF 2.0 Cookbook
JavaServer Faces 2.0, The Complete Reference
EJB 3.1 Cookbook
Enterprise JavaBeans 3.1
Beginning Java EE 6 with GlassFish 3
Java EE 6 with GlassFish 3 Application Server
Java EE 6 Development With NetBeans 7
Real World Java EE Patterns Rethinking Best Practices
Real World Java EE Night Hacks Dissecting the Business Tier
if you’ve heard Rod Johnson speak he is always adamant that Spring has replaced Java EE. Its good to see that his rhetoric is utter BS!
Sorry, even Spring MVC sucks as much balls as JSF does.
Java EE wins over Spring
CDI closed API hole
Application server started to get their act together with regards to boot time. It started with Glassfish and ended with JBoss 7. Both of which can boot in a matter of seconds.
Arquillian allows you to run your unit tests in a real environment with real transactions, etc. Personally I always despised mocks because they didn’t test in the environment you were going to run in. I thought they were pointless and to this day, I refuse to use this testing pattern.
I’m glad Rod and company were able to cash out with the VMWare acquisition before Java EE was able to regain its dominance
SpringSource pushed Java EE to innovate and for that I’m very grateful. For Java EE, it was either evolve or die. They evolved, now its time for Spring to die.
MDG Technologies allow users to extend Enterprise Architect's modeling capabilities to specific domains and notations. MDG Technologies seamlessly plug into Enterprise Architect to provide additional toolboxes, UML profiles, patterns, templates and other modeling resources.
Free MDG Technology downloads for Enterprise Architect:
EJB
MDG Technology for Enterprise Java Beans allows the user to model EJB entities and EJB sessions, complete with UML profiles for modeling EJB, EJB patterns and Code Management.
(requires Enterprise Architect 4.1 or later)
ICONIX AGILE DDT
ICONIX Agile Developer - Design-Driven Testing (DDT) streamlines the ICONIX modeling process, providing:
Convenient modeling of robustness diagrams
Automatic generation of sequence diagram structures from robustness diagrams
Transformation of robustness control elements to test diagrams
Transformation of sequence diagram elements to test diagrams
Transformation of requirement diagrams to test diagrams
Transformation between test cases and test classes. (JUnit & NUnit)
Built-in model validation rules for ICONIX robustness diagrams
(requires Enterprise Architect 7.5 or later)
Testing
MDG Technology for Testing helps users to rapidly model a wide range of testing procedures including component testing, SUT, Test Cases and more.
(requires Enterprise Architect 4.1 or later)
Instructions for loading an MDG Technology
EXE file:
Download and run the .exe file to install the MDG technology.
Open Enterprise Architect.
Select from the Main Menu Add-Ins | XYZ Technology | Load.
Built-in MDG Technologies:
Most of the MDG Technologies provided by Sparx Systems are built into Enterprise Architect directly. Depending on your edition of Enterprise Architect, some or all of the following MDG Technologies will be available:
Baseline Diagram Compare feature is a quick and easy way to visually compare a current diagram with an earlier version
Access Any of the following:
•Project Browser diagram context menu | Compare to Baseline | <select baseline>: Show Differences•Project Browser package context menu | Package Control | Manage Baselines: Show Differences | Selected diagram context menu | Open Visual Diagram Diff •Diagram context menu | Compare to Baseline: Show Differences, or•Select Package | Project | Baselines: Show Differences | Selected diagram context menu | Open Visual Diagram Diff
displayed using JSF views, business logic is encapsulated in CDI beans, information is persisted using JPA, and transactions can be controlled manually or using EJB
deploy the example by right clicking on the jboss-as-login project, and choosing Run As -> Run On Server
src/main/webapp directory
beans.xml and face-config.xml tell JBoss AS to enable CDI and JSF for the application
don't need a web.xml
src/main/resources
persistence.xml, which sets up JPA, and import.sql which Hibernate, the JPA provider in JBoss AS, will use to load the initial users into the application when the application starts
CDI managed beans. The @EJB annotation is removed and @Inject is used instead
Annotating the boundary (Cart) with the @Named annotation makes the Cart immediately visible for expression language (EL) expressions in JSP and JSF
@Named annotation takes the simple name of the annotated class, puts the first character in lowercase, and exposes it directly to the JSF pages (or JSP). The Cart bean can be accessed directly, without any backed or managed beans, by the JSF pages: <h:commandButton value="Check out!" action="#{cart.checkout}" />
If there is a need for abstraction, the class can be turned into an interface (or abstract class)
local implementation (with CDI events
@Inject
Event<String> event;
event.fire("Order proceeded!");
remote implementation:
javax.enterprise.event.Event belongs to the CDI-implementation
class Event can be considered to be a lightweight alternative to the java.beans.PropertyChangeSupport class
@Inject
Event<String> event;
event.fire("Order proceeded!");
event can be received by any managed bean and also by EJB beans
provide a method with a single @Observes annotated parameter
@Observes String event
there is no real event, just the payload:
The during attribute in the @Observes annotation allows you to select in which transactional phase the event gets delivered. The default setting is IN_PROGRESS, which causes an immediate event delivery regardless of the transaction outcome. The AFTER_SUCCESS configuration causes the delivery to occur only after successful transaction completion
Although CDI events work only inside a single process (in the default case, CDI is extensible), they are perfectly suitable for decoupling packages from modules
The method checkout() starts a transaction that gets "reused" by the OrderSystem and CustomerNotification session beans
jboss-as-maven-plugin to deploy the webapp. Unfortunately, this plugin does not allow me to start and stop the server and it seems redundant to require a local install if the Arquillian tests already download an AS instance (yes, I could run the test against the local instance as well, but think for example continuous integration where I want to manage/control the WHOLE ENVIRONMENT).
cargo plugin another go. A lot has happened there and it supports not only JBoss 7.x, but it also offers a so called artifact installer which allows to download the app server as a managed maven dependency.
cargo:install in the initialize phase to install the app server into the target directory. This way I can install a custom module (via the gmaven plugin) before the tests get executed and/or before I start the application
AuthorizationInfo represents a single Subject's stored authorization data (roles, permissions, etc)
used during authorization (access control) checks only
Roles are represented as a Collection of Strings
(Collection<String>)
Permissions are provided in two ways:
A Collection of Strings, where each String can usually be converted into Permission
objects by a Realm's
PermissionResolver
A Collection of Permission objects
most Realms store both sets of data for a Subject
a Realm implementation to utilize an implementation of the
Account interface instead, which is a convenience interface that combines both
AuthenticationInfo and AuthorizationInfo
Arquillian recognizes three container interaction styles:
A remote container resides in a separate JVM from the test runner. Arquillian binds to the container to deploy the test archive and invokes tests via a remote protocol (e.g., Servlet, JMX).
A managed container is similar to a remote container, except its lifecycle (startup/shutdown) is also managed by Arquillian.
An embedded container resides in the same JVM and is mostly likely managed by Arquillian. Tests are executed via a local protocol for containers without a web component and via a remote protocol for containers with a web component. No need to fiddle with those Maven plugins!
Arquillian can control a variety of containers out of the box
Domain object instance security: In many applications
it's desirable to define Access Control Lists (ACLs) for individual
domain object instances. We provide a comprehensive ACL package with
features including integer bit masking, permission inheritance
(including blocking), an optimized JDBC-backed ACL repository, caching
and a pluggable, interface-driven design.
OpenID Support: the web's emerging single sign-on standard
(supported by Google, IBM, Sun, Yahoo and others) is also supported in Spring
Security
Easy integration with existing databases: Our implementations
have been designed to make it easy to use your existing authentication schema
and data (without modification). Of course, you can also provide your own Data
Access Object if you wish.
Password encoding: Of course, passwords in your authentication
repository need not be in plain text. We support both SHA and MD5 encoding, and
also pluggable "salt" providers to maximise password security.
Caching: Spring Security optionally integrates with Spring's Ehcache factory. This flexibility
means your database (or other authentication repository) is not repeatedly queried
for authentication information when using Spring Security with stateless
applications.
Run-as replacement: The system fully supports temporarily
replacing the authenticated principal for the duration of the web request or
bean invocation. This enables you to build public-facing object tiers with
different security configurations than your backend objects.
Tag library support: Your JSP files can use our taglib to ensure
that protected content like links and messages are only displayed to users
holding the appropriate granted authorities. The taglib also fully integrates
with Spring Security's ACL services, and obtaining extra information about the
logged-in principal.
User Provisioning APIs: Support for groups, hierarchical roles
and a user management API, which all combine to reduce development time and
significantly improve system administration.
Enterprise-wide single sign on using CAS 3: Spring Security
integrates with JA-SIG's open source Central Authentication
Service (CAS)
'Subject' can mean a human being, but also a 3rd party process, daemon account, or anything similar. It simply means 'the thing that is currently interacting with the software'
Subject currentUser = SecurityUtils.getSubject();
SecurityManager
SecurityManager manages security operations for all users
Realms
Realm acts as the ‘bridge’ or ‘connector’ between Shiro and your application’s security data. That is, when it comes time to actually interact with security-related data like user accounts to perform authentication (login) and authorization (access control), Shiro looks up many of these things from one or more Realms configured for an application.
Realm is essentially a security-specific DAO
Shiro provides out-of-the-box Realms to connect to a number of security data sources (aka directories) such as LDAP, relational databases (JDBC), text configuration sources like INI and properties files, and more
Authorization
A permission is a raw statement of functionality, for example ‘open a door’, ‘create a blog entry’, ‘delete the ‘jsmith’ user’, etc. By having permissions reflect your application’s raw functionality, you only need to change permission checks when you change your application’s functionality. In turn, you can assign permissions to roles or to users as necessary at runtime.
“Run As” support for assuming the identity of another Subject