Group items tagged

describing its parameter object and is therefore not type-safe and its use is subject to many syntax errors.

GraniteDS provides a Java-like reflection API that encapsulates describeType calls and offers a type-safe, object-oriented, set of reflection classes and methods

caches its results for better performance

supports advanced features such as ApplicationDomain and namespaces

Stateless beans must have a dependent scope while a stateful session bean can have any scope. By default they are transactional, but you can use the transaction attribute annotation.

CDI beans can be injected into EJBs and EJBs can be injected into CDI beans

When to use which bean How do you know when to use which bean? Simple.

In general, you should use CDI beans unless you need the advanced functionality available in the EJBs such as transactional functions. You can write your own interceptor to make CDI beans transactional, but for now, its simpler to use an EJB until CDI gets transactional CDI beans which is just around the corner

Comparing JSF Beans, CDI Beans and EJBs

JSF Managed Beans

In short, don’t use them if you are developing for Java EE 6 and using CDI. They provide a simple mechanism for dependency injection and defining backing beans for web pages, but they are far less powerful than CDI beans.

JSF beans cannot be mixed with other kinds of beans without some kind of manual coding.

CDI Beans

includes a complete, comprehensive managed bean facility

interceptors, conversation scope, Events, type safe injection, decorators, stereotypes and producer methods

JSF-like features, you can define the scope of the CDI bean using one of the scopes defined in the javax.enterprise.context package (namely, request, conversation, session and application scopes). If you want to use the CDI bean from a JSF page, you can give it a name using the javax.inject.Named annotation

Comparing JSF Beans, CDI Beans and EJBs

Comparing JSF Beans, CDI Beans and EJBs

JSF Managed Beans

All managed entity instances are unique in a Tide context

Tide keeps the classic three layers web architecture, when LCDS removes the service layer, and is some kind of remote JPA provider for Flex applications

Tide approach is to minimize the amount of code needed to make things work between the client and the server

principles are very similar to the ones of JBoss Seam, which is the main reason why the first integration of Tide has been done with this framework. Integrations with Spring, EJB 3 and CDI are also available

need to compile your MXML/AS sources with the granite-essentials.swc and granite.swc libraries

org.granite.gravity.tomcat.GravityTomcatServlet

/gravityamf/*

6.3.1. Supported Application Servers

GraniteDS provides a generic servlet implementation that can work in any compliant servlet container

blocking IO and thus will provide relatively limited scalability

GraniteDS thus provides implementations of non blocking messaging for the most popular application servers.

asynchronous non blocking servlets

JBoss 5+org.granite.gravity.jbossweb.GravityJBossWebServletOnly with APR/NIO enabled (APR highly recommended)

GlassFish 3.xorg.granite.gravity.async.GravityAsyncServletUsing Servlet 3.0

Tomcat 7.x / Jetty 8.xorg.granite.gravity.async.GravityAsyncServletUsing Servlet 3.0

"strong" password policy

Secure Password Recovery Mechanism

Require re-authentication for Sensitive Features

Authentication and Error Messages

can be used for the purposes of user ID and password enumeration

Incorrectly implemented error messages

generic manner

respond with a generic error message regardless if the user ID or password was incorrect

give no indication to the status of an existing account

Authentication responses

Invalid user ID or password"

does not indicate if the user ID or password is the incorrect parameter

Transmit Passwords Only Over TLS

must be exclusively accessed over TLS

unencrypted session ID

credentials

Implement Account Lockout

lock out an account if more than a preset number of unsuccessful login attempts are made

can produce a result that locks out entire blocks of application users accounts

is to lockout accounts for a number of hours

Session Management General Guidelines

Application-created persistence units

Native Hibernate applications

native (i.e. non-JPA)

JPA applications that create an EntityManagerFactory on their own, either using the PersistenceProvider SPI directly or through an intermediary mechanism such as Spring's LocalContainerEntityManagerFactoryBean

standard Java EE-applications may ignore the provider implementation and rely on the standard features provided by the container - JBoss AS7 supporting standard JPA 1.0 and 2.0

future versions of JBoss AS7 it will be possible to use alternative persistence provider implementations

Due to the limited capabilities of the ActionScript 3 reflection API than cannot access private fields, it is necessary to create an externalizable AS3 class (implementing flash.utils.IExternalizable and its corresponding externalizable Java class

In both classes you have to implement two methods

the Gas3 generator can automatically generate the writeExternal and readExternal methods.

With GraniteDS automated externalization and without any modification made to our bean, we may serialize all properties of the Person class, private or not

In order to externalize the Person.java entity bean, we must tell GraniteDS which classes we want to externalize with a

externalize all classes named com.myapp.entity.Person by using the org.granite.hibernate.HibernateExternalizer

you could use this declaration, but note that type in the example above is replaced by

            <include annotated-with="javax.persistence.Entity"/>             <include annotated-with="javax.persistence.MappedSuperclass"/>             <include annotated-with="javax.persistence.Embeddable"/>

: type

annotated-with

Instead of configuring externalizers with the above method, you may use the

feature:

precedence rules for these three configuration options:

asks the user for multiple pieces of hard data that should have been

send the password reset information to some

such as a (possibly different) email address or an SMS text number, etc. to be used in Step 3.

Step 2) Verify Security Questions

application verifies that each piece of data is correct for the given username

If anything is incorrect, or if the username is not recognized, the second page displays a generic error message such as “Sorry, invalid data”. If all submitted data is correct, Step 2 should display at least two of the user’s pre-established personal security questions, along with input fields for the answers.

Avoid sending the username as a parameter

Do not provide a drop-down list

server-side session

user's email account may have already been compromised

William Drai

Honestly I don't see any value in switching to CDI if it is

please not this Dao/Template mess

Gavin King

to reproduce the same awful patterns

please not this Dao/Template mess

Because, of course, there are no other well-known patterns for dealing with boiler-plate cleanup code and connection leaks.

This is exactly the kind of

It gives people a

and somehow shuts down their brains so they

It's a very impressive magic trick, and I wish I knew how to do it myself. But then, I'm just not like that. I'm always trying to poke holes in things - whether they were Invented Here or Not.

but that might be too high-level for your taste. Their are other, less-abstract options.

exception handling, this is one area where Spring does a good job: "The Spring Framework's handling of SQLException is one of its most useful features in terms of enabling easier JDBC development and maintenance. The Spring Framework provides JDBC support that abstracts SQLException and provides a DAO-friendly, unchecked exception hierarchy."

Automatic connection closing (and other boiler-plate code) is obviously a hard requirement to be handled by the fwk.

Gavin King

there are a bunch of people

They don't understand, or see the value of, using managed objects to represent their persistent data.

Um. Why? Why would that be a bad thing? I imagine that any app with 1000 queries has tens of thousands of classes already. What's the problem? Why is defining a class worse than writing a method?