type-safe message handling with bean-validation

nine years ago i implemented ExtValMessageInterpolatorAdapter. back then it allowed to combine the MessageInterpolator (bv) and the MessageResolver (extval). with that it was easy to load violation-messages from a custom message-source. it was needed because there was no agreement in the eg about it. from my first presentation about bv (in 2009) until now i always hear the same (valid) feedback (that there is a gap). the result (back then) was BVAL-217, but besides that nothing changed. four years ago there was the last (official) extval-release. the main reason was that most projects limited themselves to std. bv, because jsf as well as some component libs filled the most important gaps. years later there are still extval features which aren't part of the spec. (message-resolving is just one of them). as a "replacement" projects drop the corresponding requirement/s, use weird workarounds, "copy" parts of frameworks like extval or they moved away from bv and/or jsf anyway.

recently i was asked if it is possible to load bv-violation-messages from a database. furthermore, it would be beneficial to re-use custom concepts for type-safe messages. in such cases apache codi and later on deltaspike helped a lot to benefit from (or implement) such features easily. however, adding such frameworks isn't always an option (although they would help a lot) and in some cases there are still some limits.

so i extracted some parts from extval, codi and deltaspike and combined it with new ideas.

without type-safe messages available with deltaspike, i usually use something like the following pragmatic approach for type-safe messages:

	public interface MessageId {
	String getId();
	}

view raw MessageId.java hosted with ❤ by GitHub

	public enum MyMessage implements MessageId {
	MSG_01(),
	MSG_02();
	@Override
	public String getId() {
	return name();
	}
	}

view raw MyMessage.java hosted with ❤ by GitHub

that's easy to use, refactor and it's even possible to create an extension which autom. detects all enums implementing that interface and check for message-id clashes. however, when it comes to bean-validation we have the issue that we can't reference the message-id in a type-safe manner (due to the limited capability of java-annotations in combination with the fact that bv specifies that the message-attribute of constraint-annotations needs to be a string).

to allow at least one enum-type per bv-constraint we can benefit from the composite-constraint feature which is available since v1.0. with that we can define e.g.:

	@ReportAsSingleViolation
	@Size
	@Constraint(validatedBy = {})
	@Target({FIELD, METHOD, PARAMETER})
	@Retention(RUNTIME)
	public @interface Length {
	String message() default "{}"; //triggers the delegation to #messageId
	Class<?>[] groups() default {};
	Class<? extends Payload>[] payload() default {};
	MyMessage messageId();
	MyLabel propertyLabel();
	@OverridesAttribute(constraint = Size.class, name = "min")
	int min() default 0;
	@OverridesAttribute(constraint = Size.class, name = "max")
	int max() default Integer.MAX_VALUE;
	//...
	}

view raw Length.java hosted with ❤ by GitHub

furthermore, in some cases it's useful to use information about the property in the violation message. in the listing above it's realized with the constraint-attribute propertyLabel. with std. bv you can hardcode that info. the main issue here is that there is no i18n support for the constraint-attribute value. instead of (manually) post-processing the violation-messages, it would be better to use the std. key-syntax to reference a different value in the message-source.

to summarize it, we would like e.g. to store the violation-text:
The length of '{propertyLabel}' should be between '{min}' and '{max}'
in a database, create a custom enum which implements a custom interface like MessageId and optionally (type-safe) labels which support i18n (the label-texts are stored in message-sources as well).
for the property-label we also create the corresponding entries in the database.
using those parts with @Length would e.g. look like:

	public class Person {
	@Length(min = 1, max = 50, messageId = MY_LENGTH_MSG, propertyLabel = FIRST_NAME)
	private String fName;
	@Length(min = 2, max = 50, messageId = MY_LENGTH_MSG, propertyLabel = LAST_NAME)
	private String lName;
	}

view raw Person.java hosted with ❤ by GitHub

and the resulting message is e.g.:
The length of 'Surname' should be between '2' and '50'

the propertyLabel attribute can be a string following the std. key-format to support i18n. alternatively it can be also a custom enum (implementing a custom interface). it isn't the same, but similar to the type-safe message-enum itself. due to the autom. interpolation the label-enum needs to be slightly different - e.g.:

	public enum MyLabel implements LabelId {
	FIRST_NAME("firstName"), LAST_NAME("lastName");
	private final String key;
	MyLabel(String key) {
	this.key = "{" + key + "}";
	}
	@Override
	public String getId() {
	return key;
	}
	@Override
	public String toString() {
	return key;
	}
	}

view raw MyLabel.java hosted with ❤ by GitHub

the (custom) LabelId interface is just used to distinguish labels from the message itself. since the label is a constraint-attribute it gets interpolated by bv itself and therefore we need to force the key-format to identify the parts which need to be resolved in an own step.

to realize all that you just need to add the ds-bv-label-addon e.g. by adding https://rawgit.com/os890/ds-bv-label-addon/public as maven-repository and afterwards the maven-dependency as well as the custom message-interpolator:

	<dependency>
	<groupId>org.os890.bv.addon</groupId>
	<artifactId>cdi-bv-label-addon</artifactId>
	<version>1.0.0</version>
	</dependency>

view raw pom.xml hosted with ❤ by GitHub

	<validation-config
	xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.1.xsd"
	version="1.1">
	<message-interpolator>org.os890.bv.addon.label.impl.AdvancedMessageInterpolator</message-interpolator>
	</validation-config>

view raw validation.xml hosted with ❤ by GitHub

to resolve violation-messages e.g. from a database you can add one or more beans like:

	@ApplicationScoped
	public class DbMessageSourceAdapter implements MessageSourceAdapter {
	@Inject
	private ViolationMessageDao violationMessageDao;
	@Override
	public String resolveMessage(String key, Locale locale) {
	return violationMessageDao.findByKey(key);
	}
	}

view raw DbMessageSourceAdapter.java hosted with ❤ by GitHub

if you like to use message- and/or label-enums you can implement one or more beans like:

	@ApplicationScoped
	public class EnumLabelsResolver implements LabelResolver {
	@Override
	public List<String> resolveLabelsFor(ConstraintDescriptor<?> constraintDescriptor) {
	List<String> result = new ArrayList<>();
	for (Method annotationMethod : constraintDescriptor.getAnnotation().annotationType().getDeclaredMethods()) {
	if (LabelId.class.isAssignableFrom(annotationMethod.getReturnType())) {
	try {
	LabelId labelId = (LabelId) annotationMethod.invoke(constraintDescriptor.getAnnotation());
	result.add(labelId.getId());
	} catch (Exception e) {
	throw ExceptionUtils.throwAsRuntimeException(e);
	}
	}
	}
	return result;
	}
	}

view raw EnumLabelsResolver.java hosted with ❤ by GitHub

	@ApplicationScoped
	public class EnumMessageTemplateResolver implements MessageTemplateResolver {
	@Override
	public String resolveMessageTemplateFor(ConstraintDescriptor<?> constraintDescriptor) {
	for (Method annotationMethod : constraintDescriptor.getAnnotation().annotationType().getDeclaredMethods()) {
	if (MessageId.class.isAssignableFrom(annotationMethod.getReturnType())) {
	try {
	MessageId messageId = (MessageId) annotationMethod.invoke(constraintDescriptor.getAnnotation());
	return "{" + messageId.getId() + "}";
	} catch (Exception e) {
	throw ExceptionUtils.throwAsRuntimeException(e);
	}
	}
	}
	return null;
	}
	}

view raw EnumMessageTemplateResolver.java hosted with ❤ by GitHub

the git-repository illustrates different use-cases including one which shows how to share one constraint between different modules without using a shared message-enum (but still keep the type-safe approach) by using a shared composite-constraint in combination with a composite-constraint per module (which delegate to the shared composite-constraint).

[add-on] no flush with org.apache.deltaspike.jpa.api.transaction.Transactional #readOnly and hibernate

jpa supports FlushModeType COMMIT and AUTO. for some use-cases that isn't enough. in case of org.apache.deltaspike.jpa.api.transaction.Transactional#readOnly(true) you will get a #rollback instead of a #commit at the end of the transaction. however, with some other frameworks you can get special behavior. e.g. some use org.hibernate.FlushMode#MANUAL once they detect hibernate as the jpa-provider. deltaspike only provides portable features and therefore you won't get such a special behavior out-of-the-box. however, deltaspike provides a rich set of extension-points. with a custom org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy it's a matter of less than 100 loc to integrate org.hibernate.FlushMode#MANUAL as mentioned above. you can find a corresponding prototype here.

[add-on] javax.annotation.security.* with deltaspike

intro/background:
recently DELTASPIKE-1345 was reported. since i checked the available integration of javax.annotation.security.* as well as JSR-375 just recently, it was clear that there isn't a well-established CDI extension which integrates with the servlet- and ejb-api (at least at this point).

in the past few years we usually used @Secured (or @Secures) to integrate with those and other authentication (and authorization) mechanisms. in most cases that allowed a type-safe and more CDI-like approach in combination with solid security-frameworks like http://shiro.apache.org

however, (currently) projects like keycloak are integrated e.g. with wildfly (and therefore with javax.annotation.security.*), but only for servlet based artifacts and EJBs.

since JSR-375 is integrated with CDI out-of-the-box, only EE6 and EE7 still have a gap in view of those annotations for authentication (in combination with CDI). in most cases it's enough to use @Secures in combination with the std. EE-APIs (like it's illustrated for JSF in one of the wildfly-demos). however, it's for sure inconsistent that those annotations can be used with different EE-APIs, but out-of-the-box not with CDI beans. therefore, i prototyped https://github.com/os890/ds-role-bridge-addon
it's a bridge which supports @DenyAll, @PermitAll, @RolesAllowed and @RunAs. i skipped the support for @DeclareRoles in combination with @RunAs, because a full support with EJBs wouldn't be portable anyway. the remaining annotations are also integrated with EJBs and therefore in most cases it should just work as it would be supported out-of-the-box.

the short story:
as shown in the demo-applications it's just needed to add the bridge as a runtime-dependency and use the javax.annotation.security.* annotations directly at the CDI beans. behind the scenes the final-role check is delegated to the servlet-api or if it isn't available (or there is no active servlet-request), a fallback gets triggered which delegates the check to the EJBContext. only @RunAs required a custom role-evaluation (including an explicit approach for the integration with EJBs).

the result:
https://github.com/os890/ds-role-bridge-addon should allow the same overall usage of @DenyAll, @PermitAll, @RolesAllowed and @RunAs (please report an issue if there is a difference). the main (known) difference is that you need to use annotations like @RolesAllowed explicitly (there is no "default/implicit" protection). furthermore, the result of a violation is a java.lang.SecurityException. however, the bridge also provides a rich set of SPIs which allows to customize the default behavior (in this case e.g. with an @Alternative implementation of AccessDeniedHandler).

btw. since cdi is really powerful it took longer to create the examples then the bridge itself.

multi-profiles in one minute

2012 spring added bean-profiles which is similar to project-stages added in myfaces-codi 2010. deltaspike improved and unified the project-stage concept. for the average case it's (imo) easier to handle than bean-profiles. however, from time to time users come up with some very special edge-cases which can be done with (custom) expressions supported by @Exclude. per definition such cases can get quite complex and usually there is an easier approach with deltaspike. in all the years (on the mailing-lists and in projects) i just saw one case which would really benefit a bit from the (imo) more complex bean-profiles approach. even in that case the result wasn't just "bad luck" and a questionable workaround as a result. instead it is possible to implements bean-profiles as a deltaspike-addon with less than 30 lines of code.

	public class MultiProfileExtension implements Extension {
	private Set<String> activeProfileNames = new HashSet<>();
	protected void determineActiveProfiles(@Observes BeforeBeanDiscovery beforeBeanDiscovery) {
	String activeProfileString =
	ConfigResolver.getPropertyValue("active-profiles", "Production");
	Collections.addAll(activeProfileNames, activeProfileString.split(","));
	}
	protected void matchActiveProfiles(@Observes ProcessAnnotatedType pat, BeanManager bm) {
	Set<Annotation> annotations = pat.getAnnotatedType().getAnnotations();
	Profile profile = AnnotationUtils.findAnnotation(
	bm, annotations.toArray(new Annotation[annotations.size()]), Profile.class);
	if (profile == null) {
	return;
	}
	for (String supportedProfile : profile.value()) {
	if (activeProfileNames.contains(supportedProfile)) {
	return;
	}
	}
	pat.veto();
	}
	}

view raw MultiProfileExtension.java hosted with ❤ by GitHub

the usage is quite simple.

	@Profile("X")
	//further cdi annotation/s
	public class BeanProfileX {
	}

view raw ProfileBeanX.java hosted with ❤ by GitHub

a type-safe approach based on cdi-stereotypes is supported as well. the usage of the type-safe approach is also straightforward:

	@ProfileA
	//further cdi-annotation/s
	public class BeanProfileA {
	}

view raw BeanProfileA.java hosted with ❤ by GitHub

	//...
	@Stereotype
	@Profile("A")
	public @interface ProfileA {
	}

view raw ProfileA.java hosted with ❤ by GitHub

enabling 1-n profiles can be done with any active config-source.
the implementation including tests are available at ds-multi-profile-addon.

type-safe configs the second minute

in my first post about this topic i explained how to create a type-safe config based on interfaces and the partial-bean-module provided by deltaspike.

this second part is about a new possibility which is available since deltaspike v1.5.1.


until deltaspike v1.5.1, you needed to create and inject the type-safe config for accessing configured values. one part of the example shown in the first post looked like:

	@TypeSafeConfig
	public interface AppConfig {
	String name();
	ApplicationVersion version();
	}

view raw AppConfig.java hosted with ❤ by GitHub

	@Scheduled(cronExpression = "0 0/10 * * * ?")
	public class CustomBatchStarter implements org.quartz.Job {
	@Inject
	private LogService logService;
	@Inject
	private AppConfig appConfig;
	@Inject
	private BatchConfig batchConfig;
	@Inject
	private CustomBatchService batchService;
	@Override
	public void execute(JobExecutionContext context) throws JobExecutionException {
	logService.log(appConfig.name(), appConfig.version(),
	getClass().getName() + " started");
	batchService.start(batchConfig.batchSize());
	}
	}

view raw CustomBatchStarter.java hosted with ❤ by GitHub

since deltaspike v1.5.1, you can use @Produces in your type-safe config. with that you can directly inject the result instead of the config-class.

	@TypeSafeConfig
	public interface AppConfig2 {
	String name();
	@Produces //since ds v1.5.1
	ApplicationVersion version();
	}

view raw AppConfig2.java hosted with ❤ by GitHub

	//example for injecting and using type-safe configs
	@Scheduled(cronExpression = "0 0/10 * * * ?")
	public class CustomBatchStarter2 implements org.quartz.Job {
	@Inject
	private LogService logService;
	@Inject
	private ApplicationVersion version;
	@Inject
	private BatchConfig batchConfig;
	@Inject
	private CustomBatchService batchService;
	@Override
	public void execute(JobExecutionContext context) throws JobExecutionException {
	logService.log(appConfig.name(), version, getClass().getName() + " started");
	batchService.start(batchConfig.batchSize());
	}
	}

view raw CustomBatchStarter2.java hosted with ❤ by GitHub

type-safe configs in one minute

within the last months i heard about more and more projects which move to cdi.
an important aspect of cdi is the type-safe injection including type-safe qualifiers and many other concepts based on type-safety.

"surprisingly" type-safe concepts get ignored quite often when it comes to accessing config-values.
however, there is no technical limitation here. in fact creating even generic approaches for type-safe configs can be easy once the implementation is based on deltaspike.

-> like with many other topics my answer is something like:
"use deltaspike and it's way easier."

in case of config-approaches, deltaspike provides several flexible and extensible concepts.
e.g. the upcoming chapter of http://cdiatwork.irian.at will also describe some of them in detail.

beyond that it's easy to implement your own concepts based on mechanisms provided by deltaspike.
the following listing illustrates how to implement your own type-safe config.

	@PartialBeanBinding
	@Retention(RUNTIME)
	@Target(TYPE)
	public @interface TypeSafeConfig {
	}

view raw TypeSafeConfig.java hosted with ❤ by GitHub

	@TypeSafeConfig
	public class TypeSafeConfigHandler implements java.lang.reflect.InvocationHandler {
	public Object invoke(Object o, Method method, Object[] args) throws Throwable {
	String key = method.getName();
	String value = ConfigResolver.getProjectStageAwarePropertyValue(key);
	return parseValue(method.getReturnType(), value);
	}
	private Object parseValue(Class<?> type, String value) {
	//...
	}
	}

view raw TypeSafeConfigHandler.java hosted with ❤ by GitHub

this implementation is based on the partial-bean module of http://deltaspike.apache.org (@TypeSafeConfig is annotated with @org.apache.deltaspike.partialbean.api.PartialBeanBinding). in a second step it's required to annotate an implementation of java.lang.reflect.InvocationHandler with our own binding-annotation (see @TypeSafeConfig) and implement the logic to load and parse the config-values. in our example we delegate the lookup of the config-values to ConfigResolver#getProjectStageAwarePropertyValue. ConfigResolver is provided by deltaspike and allows to integrate even custom config-sources easily.

with those two simple classes, we can create custom type-safe configs by just creating interfaces and annotating them with our own binding-annotation (see @TypeSafeConfig). the following listings show two examples how to define and use such a custom config (see AppConfig and BatchConfig).

the last snippet shows how to inject and use both configs in any cdi-bean. in the illustrated example we use them in CustomBatchStarter, which is a cdi-enabled implementation of org.quartz.Job (see @org.apache.deltaspike.scheduler.api.Scheduled).

	//example #1 for a custom type-safe config
	@TypeSafeConfig
	public interface AppConfig {
	String name();
	ApplicationVersion version();
	}

view raw AppConfig.java hosted with ❤ by GitHub

	//example #2 for a custom type-safe config
	@TypeSafeConfig
	public interface BatchConfig {
	Integer numberOfRetries();
	Long batchSize();
	}

view raw BatchConfig.java hosted with ❤ by GitHub

	//example for injecting and using type-safe configs
	@Scheduled(cronExpression = "0 0/10 * * * ?")
	public class CustomBatchStarter implements org.quartz.Job {
	@Inject
	private LogService logService;
	@Inject
	private AppConfig appConfig;
	@Inject
	private BatchConfig batchConfig;
	@Inject
	private CustomBatchService batchService;
	@Override
	public void execute(JobExecutionContext context) throws JobExecutionException {
	logService.log(appConfig.name(), appConfig.version(),
	getClass().getName() + " started");
	batchService.start(batchConfig.batchSize());
	}
	}

view raw CustomBatchStarter.java hosted with ❤ by GitHub

openwebbeans custom resources

cdi itself allows to add beans to integrate other frameworks and containers.
so it's possible to inject them via @Inject.
however, sometimes you need to use other annotations like @EJB or @Autowired.
in an ee-server ee-annotations like @EJB work out-of-the-box. however, in case of a manual setup e.g. in combination with a servlet-container like tomcat, you might not be able to inject references to remote-ejbs. in any case you can't use non-ee annotations like @Autowired in cdi-beans out-of-the-box.

as mentioned in previous posts apache openwebbeans is very flexible.

owb is based on a simple plugin architecture which allows to customize parts easily.

some years ago i published an add-on for owb which allows to inject remote-ejbs via @EJB into cdi-beans in non-ee environments.

the add-on injects references resolved by a custom ejb-resolver into injection-points annotated with @EJB.

with the same approach it's possible to use 3rd party annotations in cdi-beans.

today i prototyped a similar add-on for owb, which allows to use @Autowired in cdi-beans to inject spring-beans based on the (field-)name or type. compared to the cdi-spring bridge i described here, it allows a simpler implementation which delegates to a started spring-container (instead of bootstrapping it). the major downside is that it isn't a portable cdi-extension (per definition) and therefore you can only use it with owb. furthermore, there is no validation of those injection-points during the startup you (might) know from cdi and injection of cdi-beans into spring-beans isn't supported as well.

[deltaspike] restricting the amount of windows

with codi it was possible to restrict the number of windows and old windows are dropped if the maximum was reached and a new window should get created.
deltaspike doesn't allow that before v1.1.0, however, it's very easy to implement it manually:

	@SessionScoped
	@JsfPhaseListener
	public class WindowQuotaHandler implements PhaseListener
	{
	@Inject
	private WindowContext windowContext;
	private Stack<String> windowIdStack = new Stack<String>();
	@Override
	public synchronized /*no issue due to session-scoped instance*/
	void afterPhase(PhaseEvent event)
	{
	String currentWindowId = windowContext.getCurrentWindowId();
	if (currentWindowId == null)
	{
	return;
	}
	if (windowIdStack.contains(currentWindowId))
	{
	windowIdStack.remove(currentWindowId);
	windowIdStack.push(currentWindowId);
	}
	else
	{
	windowIdStack.push(currentWindowId);
	if (windowIdStack.size() > 30) //restricted to 30 windows
	{
	String windowIdToRemove = windowIdStack.remove(0);
	windowContext.closeWindow(windowIdToRemove);
	}
	}
	}
	@Override
	public void beforePhase(PhaseEvent event)
	{
	}
	@Override
	public PhaseId getPhaseId()
	{
	return PhaseId.RENDER_RESPONSE;
	}
	}

view raw WindowQuotaHandler.java hosted with ❤ by GitHub

duke arrived!

today duke arrived - thx to the whole community!

[slides] apache deltaspike

8th release of deltaspike -> v1

The Apache DeltaSpike team is pleased to announce the 8th release of DeltaSpike. It's v1.0.0!

openwebbeans on wls

some time ago, i described how to run openwebbeans on glassfish and wls.
the described approach works pretty well. however, once deltaspike added an optional ee7-support (esp. for jsf 2.2+), wls fails during the startup, because v12.1.2 doesn't support optional classes which contain imports of unknown classes (ee7 classes unknown to an ee6-server) like the other ee6 servers do.
therefore i created a new branch for ds-owb-bundle which filters those optional ee7 classes.
with that deltaspike works on wls without issues.

openwebbeans on glassfish

some time ago, i described how to run openwebbeans on glassfish3 and wls12.
in my previous post i described how to run openwebbeans on wildfly8 (and as7).
with the latest commit for ds-owb-bundle and the trunk of owb add-on,
the demo-application also works on glassfish4.

openwebbeans on wildfly8

recently i showed how to run owb on as7. the same owb add-on works with wildfly8 as well. however, wildfly8 ships a version of weld which implements cdi 1.1. therefore, i had to update the repackaged version of deltaspike. with the latest commit for ds-owb-bundle, the demo-application also works on wildfly8.

openwebbeans on as7

some time ago, i described how to run openwebbeans on a weld based ee6 server.
i mentioned that the used classpath-scanner doesn't support the virtual-file-system.
however, today i rewrote the scanner-service.
now it uses the "Corn Classpath Scanner" lib, which supports the vfs.
therefore, i tested the result with as7 (v7.2.0) and owb works fine as expected.
you can have a look at the result at the as7-branch of the same repository.

apache deltaspike pmc chair

now it's official - i'm the new pmc chair of deltaspike for this year.
i'll try to continue the great work of the previous chair!

furthermore, i would like to thank mark for being such a great chair!

in my first blog-post as new pmc chair i would like to mention:
everybody is welcome to join our awesome community!

[add-on] fast event processing with disruptor + deltaspike

cdi offers synchronous events. they are more like a decoupled method call. that's fine for a lot of use-cases.

in some cases the processing can take some time (in the observer method). a common trick is to use an ejb + @Asynchronous for the observer-method. with that the event-source can continue and the observer operates in a new thread.

however, that isn't enough if there is a huge amount of such events. for use-cases like that i've prototyped an add-on for apache deltaspike which allows to use disruptor for firing and observing events. it includes a simple qualifier support, however, it doesn't provide an 1:1 implementation of the cdi event rules. it can be used the same way as cdi events:

 

	public class DefaultEventBroadcastingTest
	{
	@Inject
	private AsynchronousEvent<MyEvent> myAsyncEvent;
	public void fireAsyncEvent()
	{
	this.myAsyncEvent.fire(new MyEvent(/*...*/));
	}
	}

view raw AsyncEventBroadcaster.java hosted with ❤ by GitHub

and

	@ApplicationScoped
	public class AsyncObserver
	{
	public void onEvent(@ObservesAsynchronous MyEvent event)
	{
	//...
	}
	}

view raw AsyncObserver.java hosted with ❤ by GitHub

the add-on creates a disruptor-processor for every observer methods. the method gets invoked on the cdi-bean itself. the cdictrl-module provided by deltaspike is used for starting the cdi request- and session-scope before an observer method gets called (and to stop it afterwards). with that the application-, session- and request-scope (as well as all scopes based on them which start autom.) can be used for such beans.
since the observer methods are invoked on the contextual-instance, cdi features like dependency-injection can be used as expected. the result is really nice. there is a huge difference in view of the pure event-processing performance of the events:

the result might look strange at the first view. however, the effects are quite clear. since the observer-logic in the demo is fast, the benefit of using @Asynchronous is lost. here the pure invocation of observers in ejbs is slower (than observers in a cdi-bean), because the container has to handle additional ejb features like transactions. the cdi bean as well as the stateful ejb is application-scoped and therefore only one (cached) instance is needed.

in the charts above it's hard to see, but the numbers show that tomee is faster in case of the deltaspike/disruptor add-on (due to the highly optimized proxies of openwebbeans 1.2.x) and as7 is a bit faster with dispatching standard cdi events.

currently the add-on works with tomee and as7 (tested with v7.2) and is available here. the repository also contains several tests, which illustrate the supported use-cases.

[add-on] mock cdi-beans with deltaspike

i've prototyped an add-on for apache deltaspike which allows to mock cdi-beans manually or with a mocking-framework.

an example for a simple cdi-bean:

	@RequestScoped
	public class MyCdiBean
	{
	private int count = 0;
	public int getCount()
	{
	return count;
	}
	public void increaseCount()
	{
	count++;
	}
	}

view raw MyCdiBean.java hosted with ❤ by GitHub

an example for a simple manual-mock for the cdi-bean:

	@RunWith(CdiTestRunner.class)
	public class ManuallyMockedCdiBeanTest
	{
	@Inject
	private MyCdiBean myCdiBean;
	@Inject
	private DynamicMockContext mockContext;
	@Test
	public void manualMock()
	{
	mockContext.addMock(new MyCdiBean() {
	@Override
	public int getCount() {
	return 14;
	}
	});
	Assert.assertEquals(14, myCdiBean.getCount());
	myCdiBean.increaseCount(); //no effect due to the mock
	Assert.assertEquals(14, myCdiBean.getCount());
	}
	}

view raw ManuallyMockedCdiBeanTest.java hosted with ❤ by GitHub

an example for a simple mockito-mock for the cdi-bean:

	@RunWith(CdiTestRunner.class)
	public class MockitoMockedCdiBeanTest
	{
	@Inject
	private MyCdiBean myCdiBean;
	@Inject
	private DynamicMockContext mockContext;
	@Test
	public void mockitoMock()
	{
	MyCdiBean mockedCdiBean = mock(MyCdiBean.class);
	when(mockedCdiBean.getCount()).thenReturn(14);
	mockContext.addMock(mockedCdiBean);
	Assert.assertEquals(14, this.myCdiBean.getCount());
	myCdiBean.increaseCount(); //no effect due to the mock
	Assert.assertEquals(14, this.myCdiBean.getCount());
	}
	}

view raw MockitoMockedCdiBeanTest.java hosted with ❤ by GitHub

the same is possible in combination with qualifiers as well as with producers and @Typed beans.

the add-on is available here. the repository also contains several tests, which illustrate the supported use-cases. the tests use manual-mocks as well as mockito-mocks. however, you can provide any object as mock which is a subclass of the original implementation.

[add-on] monitoring lite with deltaspike

there are quite a lot of different use-cases for monitoring and auditing. for more advanced use-cases projects like apache sirona are reasonable. however, in several cases it's enough to have a simple interceptor which collects information (which can get processed at the end of a request). since a lot of projects implemented it on their own and end up with similar solutions, i've created an add-on for apache deltaspike which supports several common use-cases like exception monitoring, performance monitoring (via execution time) and auditing (with or without method-parameter values).

after adding the add-on to a project based on deltaspike the usage is simple, just annotate a method or the whole class with @InvocationMonitored and create a cdi-observer for MonitoredMethodInvocationsEvent. the add-on will collect information about the monitored method-invocations during a request and you can process the entries based on your requirements. the following example illustrates a sample usage. it's up to you which information you use and how you process it (e.g. logging it, storing it in a persistent store,...).

	public class MonitoredMethodInvocationProcessor
	{
	//...
	public void onMonitoredMethodInvocations(@Observes MonitoredMethodInvocationsEvent methodInvocationsEvent)
	{
	String userId = this.userHolder.getCurrentUserId();
	for (MethodInvocationDescriptor methodInvocation : methodInvocationsEvent.getMethodInvocationDescriptors())
	{
	if (methodInvocation.getException() != null)
	{
	error(userId + "@" + methodInvocation + ":L" + methodInvocation.getException().getStackTrace()[0].getLineNumber());
	}
	else
	{
	trace(userId + "@" + methodInvocation);
	}
	if (methodInvocation.getExecutionTime() > this.maxThreshold)
	{
	warn("slow method-invocation detected: " + methodInvocation.getMethodDetails());
	}
	}
	}
	//...
	}

view raw MonitoredMethodInvocationProcessor.java hosted with ❤ by GitHub

asynchronous processing is also supported via an @Asynchronous observer in an ejb.

the optional jsf module allows to record the current view-id per entry and the processing after the rendering-phase.

the add-on is available here.

simple cdi and ejb tests with deltaspike

apache deltaspike v0.6+ provides an easy to use, but quite powerful junit test-runner. it's based on the container-control api of deltaspike. deltaspike itself currently provides implementations for openwebeans, weld and openejb (tomee).

the last one is important, if you need to test a cdi+ejb based application. just by using a different container-control implementation (deltaspike-cdictrl-openejb) in your build config and adding openejb (/tomee) via org.apache.openejb:openejb-core, you can test cdi-beans as well as ejbs. just inject them as usual via @Inject (also @EJB works as expected).

	@RunWith(CdiTestRunner.class)
	public class InjectionTest
	{
	@Inject
	private MyCdiBean bean1;
	@EJB //or @Inject
	private MyEjb bean2;
	@Test
	public void injection()
	{
	Assert.assertNotNull(this.bean1);
	Assert.assertNotNull(this.bean2);
	//...
	}
	}

view raw InjectionTest.java hosted with ❤ by GitHub

an example can be found here.

[slides] flexibility with cdi and deltaspike

welcome cdiatwork.irian.at

today we announced a german book about cdi and apache deltaspike.
it's available at http://cdiatwork.irian.at

instead of publishing it at once, we do it step by step.
readers have the chance to provide feedback of any kind. therefore a github issue-tracker is linked in the menu. if you don't like to do it there, you can also contact me directly. every feedback is very welcome.

migrate codi 1.x to deltaspike 0.6

the myfaces-stack demo at https://github.com/os890/tomee_mf_stack_001 (later added to the tomee examples) is a codi-feature-demo which includes the most important features of codi compacted in few jsf pages and classes. a second branch (https://github.com/os890/tomee_mf_stack_001/tree/codi2ds) in the same repository shows the needed changes to migrate such a codi application to deltaspike (currently v0.6).

update: for upgrading to v0.7, just upgrade the version number of deltaspike (the demo was upgraded already)

deltaspike in 2013

here a short overview about the progress of deltaspike in 2013:

first of all the project graduated (apache incubator -> apache top-level-project).

multiple modules have been added:

• bean-validation
• data
• partial-bean
• scheduler
• servlet
• test-control

existing modules have been improved (e.g. optional support for jsf 2.2 specific parts).

the documentation has been improved (but there is still room for further improvements).

almost all myfaces-codi features have been ported to deltaspike and most of them have been improved.

two versions have been released and the next one will follow soon.

cdi and spring-mvc

based on http://os890.blogspot.co.at/2013/12/add-on-spring-bridge-with-deltaspike.html it's possible to write e.g. a cdi bridge for spring-mvc. with that it's possible to use cdi-beans as spring-mvc controllers. please notice that it is just a feasibility study.

https://github.com/os890/cdi-spring-mvc-showcase/tree/cdi-managed is the current state of the official demo with cdi-beans as controllers (instead of spring-beans).

[add-on] spring-bridge with deltaspike

cdi and deltaspike are very powerful and in several cases all you need. some might argue that other containers like spring have a richer ecosystem. integrating 3rd party frameworks is usually not a big deal and several even provide a nice api (which doesn't require an additional wrapper or api-layer). however, if there is a good reason why one of the additional spring-projects would be nice to use, it's usually also possible to integrate/use it in a cdi-based application via a cdi-spring bridge. in combination with deltaspike it's easy to implement it.

ds-spring-bridge-addon is one of such two-way bridges. it allows to inject spring-beans into cdi-beans as well as cdi-beans into spring-beans as long as the used concepts (like qualifiers,... are compatible).

per default the bridge will bootstrap the spring-container as soon as it is needed. in case of web-applications, it's possible to use WebappAwareSpringContainerManager (which also delegates to the context-loader of spring). as shown in the tests and examples, it's possible to use it with plain java-se, servlet-containers like tomcat as well as ee-containers like tomee.

[deltaspike] validate view-config

apache deltaspike provides an improved version of the view-config known from apache myfaces codi. one of many big advantages is the type-safety (even for navigation). the only missing part is the validation against real files and folders. however, if your view-ids correspond with the real file-names (which is good practice anyway), it's easy to do it manually:

	public class ViewConfigValidator implements ServletContextListener
	{
	@Override
	public void contextInitialized(ServletContextEvent sce)
	{
	ViewConfigResolver viewConfigResolver =
	BeanProvider.getContextualReference(ViewConfigResolver.class);
	for (ConfigDescriptor configDescriptor :
	viewConfigResolver.getConfigDescriptors())
	{
	try
	{
	if (!isInternal(configDescriptor.getConfigClass()) &&
	sce.getServletContext()
	.getResource(configDescriptor.getPath()) == null)
	{
	throw new IllegalStateException("path " +
	configDescriptor.getPath() +
	" doesn't exist, but it's mapped by " +
	configDescriptor.getConfigClass().getName());
	}
	}
	catch (MalformedURLException e)
	{
	throw ExceptionUtils.throwAsRuntimeException(e);
	}
	}
	}
	//needed with deltaspike 0.5
	private boolean isInternal(Class configClass)
	{
	return ViewConfig.class.equals(configClass) ||
	DefaultErrorView.class.equals(configClass) ||
	ViewRef.class.equals(configClass) ||
	ViewRef.Manual.class.equals(configClass);
	}
	@Override
	public void contextDestroyed(ServletContextEvent sce)
	{
	}
	}

view raw ViewConfigValidator.java hosted with ❤ by GitHub

in an ee6+ application-server it's possible to annotate this class with @WebListener (-> no further config is needed). in case of a manual cdi-setup (e.g. with tomcat), it's needed to configure the listener after the listener of the cdi-implementation (because cdi needs to be bootstrapped before this listener gets called).

with all versions after v0.5, deltaspike will do this check out-of-the-box.

[add-on] simple quartz integration with deltaspike 0.5

the container-control module provided by deltaspike is very powerful. recently i created a simple cdi integration for junit based on this module. integrating a scheduler like quartz is even easer. therefore i prototyped a very simple (= only cron-expressions are supported) deltaspike scheduler add-on. the default-implementation delegates to quartz, however, it's possible to integrate it with any scheduler (if cron-expressions are supported).

the major use-case is simple. just annotate your job-implementations (in case of quartz: org.quartz.Job) with @Scheduled(cronExpression = "[your expression]") and it will be scheduled/installed automatically at the end of the bootstrapping process.

it's possible to use cdi based injection:

	@Scheduled(cronExpression = "0 0/10 * * * ?")
	public class CdiAwareQuartzJob implements org.quartz.Job
	{
	@Inject
	private MyService service;
	@Override
	public void execute(JobExecutionContext context)
	throws JobExecutionException
	{
	//...
	}
	}

view raw CdiAwareQuartzJob.java hosted with ❤ by GitHub

furthermore, the request- and session-scope get started (and stopped) per job-execution. however, it can be controlled via @Scheduled#startScopes and it's possible to provide a description as well as a type-safe job-group.

beyond that it's also possible to inject the scheduler and control (scheduleJob, interruptJob, startJobManually,...) it manually - e.g.:

	@ApplicationScoped
	public class SchedulerController
	{
	@Inject
	private Scheduler<Job> jobScheduler;
	public void onPause(@Observes PauseJobEvent /*custom event*/ jobEvent)
	{
	//using it with events is optional
	this.jobScheduler.pauseJob(jobEvent.getJobClass());
	}
	public void onResume(@Observes ResumeJobEvent /*custom event*/ jobEvent)
	{
	//using it with events is optional
	this.jobScheduler.resumeJob(jobEvent.getJobClass());
	}
	}

view raw SchedulerController.java hosted with ❤ by GitHub

With 'false' for @Scheduled#onStartup it's even possible to schedule/install jobs dynamically - e.g.:

	@ApplicationScoped
	public class ProjectStageAwareSchedulerController
	{
	@Inject
	private Scheduler<Job> jobScheduler;
	@Inject
	private ProjectStage projectStage;
	public void registerJobs()
	{
	if (ProjectStage.Production.equals(this.projectStage))
	{
	//see 'false' for @Scheduled#onStartup
	this.jobScheduler.scheduleJob(ManualCdiAwareQuartzJob.class);
	}
	}
	@Scheduled(cronExpression = "0 0/10 * * * ?", onStartup = false)
	public class ManualCdiAwareQuartzJob implements org.quartz.Job
	{
	@Inject
	private MyService service;
	@Override
	public void execute(JobExecutionContext context)
	throws JobExecutionException
	{
	//...
	}
	}
	}

view raw ProjectStageAwareSchedulerController.java hosted with ❤ by GitHub

Update:
This add-on is part of all versions of DeltaSpike after v0.5

[add-on] cdi tests with deltaspike 0.5

arquillian is nice, however, several projects don't need/use it.

several of them implemented a custom approach to control the cdi-container, start/stop scopes and check invalid state (esp. after a failed test). usually the basic tasks are the same or very similar. therefore i prototyped a deltaspike test-ctrl add-on based on some use-cases:

	//starts the container once and one session + request per test-method
	@RunWith(CdiTestRunner.class)
	public class ContainerAndInjectionControl
	{
	@Inject
	private ApplicationScopedBean applicationScopedBean;
	@Inject
	private SessionScopedBean sessionScopedBean;
	@Inject
	private RequestScopedBean requestScopedBean;
	//test the injected beans
	}

view raw ContainerAndInjectionControl.java hosted with ❤ by GitHub

	//starts the container and session once and one request per test-method
	@RunWith(CdiTestRunner.class)
	@TestControl(startScopes = SessionScoped.class)
	public class CustomizedScopeHandling
	{
	//inject beans and test them
	}

view raw CustomizedScopeHandling.java hosted with ❤ by GitHub

	//starts the container once (for the whole suite)
	@RunWith(CdiTestSuiteRunner.class)
	@Suite.SuiteClasses({
	SimpleTest.class,
	SimpleTestControlTest.class
	})
	public class SuiteLevelContainerControl
	{
	}

view raw SuiteLevelContainerControl.java hosted with ❤ by GitHub

	//fine-grained project-stage control
	@RunWith(CdiTestRunner.class)
	@TestControl(projectStage = CustomTestStage.class) //default: ProjectStage.UnitTest.class
	public class TestStageControl
	{
	//tests here will see project-stage CustomTestStage.class
	@Test
	@TestControl(projectStage = ProjectStage.Development.class)
	public void checkDevEnv()
	{
	}
	//tests here will see project-stage CustomTestStage.class
	}

view raw TestStageControl.java hosted with ❤ by GitHub

Update:
This add-on is part of all versions of DeltaSpike after v0.5

migrate codi 1.x to deltaspike 0.5

the myfaces-stack demo at https://github.com/os890/tomee_mf_stack_001 (later added to the tomee examples) is a codi-feature-demo which includes the most important features of codi compacted in few jsf pages and classes. a second branch (https://github.com/os890/tomee_mf_stack_001/tree/codi2ds) in the same repository shows the needed changes to migrate such a codi application to deltaspike (currently v0.5).

the face of deltaspike 0913

the progess of creating deltaspike:

boost myfaces codi scopes with owb v1.2

as described in a previous post, it's possible to boost the performance of custom cdi-scopes with apache openwebbeans. owb 1.2 provides a lot of improvements which makes it even more solid and faster.
therefore a new version of the boost-addon is needed.

openwebbeans to the rescue

there are several application-servers which use weld as cdi implementation. however, several of them work at least slightly different in the integration layer. e.g. some issues lead to a broken cross-module handling. one of many examples is CDI-18. some parts are fixed in cdi 1.1, but that doesn't help you with servers which use cdi 1.0. furthermore, weld2 based servers have to prove that they fixed the integration layer correctly.

the effect is that such servers have issues with supporting more complex use-cases and some even with well tested cdi extensions like apache deltaspike. e.g. wls12 (at least until 12.1.2) has issues with the bda-rules which leads to a failed deployment of applications using apache deltaspike. the only way it can be done is to use some build-tricks (to copy the classes to WEB-INF/classes instead of including the jar-files and to merge the config-files to provide the content via WEB-INF/beans.xml and META-INF/services/javax.enterprise.inject.spi.Extension).

openwebbeans to the rescue:
per default owb doesn't follow the broken bda rules. that saves you from a lot of headache.
as described here it's possible to use openwebbeans instead of weld. if you just have custom cdi extensions, it's easy to use those hints. however, using pre-packaged extensions like apache deltaspike is a bit tricky, because you can't add filters to the affected parts within deltaspike (without patching ds).
anyway, with two small helper libraries it's easy to bypass weld at all.
i wrote the first one some months ago. it's called custom-cdi-owb-addon and uses the plugin infrastructure of owb to provide a custom classpath-scanner and service-loader. the only purpose of the add-on is to change the name of the marker/config files (owb_beans.xml instead of beans.xml and OwbExtension instead of javax.enterprise.inject.spi.Extension). with those two changes only owb will see your custom-cdi configs and beans.
since libraries like apache deltaspike use the standard configs, it's required to repackage them. that's the purpose of the second library called ds-owb-bundle. as you can see in the example, you just have to change the group-id in your maven build and the rest is the same. also your application has to use the new names (owb_beans.xml and OwbExtension).

(the demo-application was tested on wls12 and glassfish3. with as7 it won't work, because the classpath-scanner doesn't support the virtual-file-system.)

for sure it doesn't provide a full integration, but for a jsf application it's good enough (and the same you will get with other 3rd party dependency-injection containers). since owb is very flexible, it's even possible to inject ejbs (a plugin can be found here).

improve apache wink - part 2

today i added an as7-adapter to my apache-wink cdi-add-on . the new cdi integration is also available with wink 1.4+ and 2+. the adapter can be used with both code-bases. it's just needed to disable the scanning of resteasy and add the listener of the adapter to the web.xml

apache wink meets bean-validation

today i did my first commit at apache-wink. it's the first draft of the bean-validation integration as specified in the jax-rs 2.0 specification.

[add-on] codi scopes for deltaspike

a lot of users use the cdi/jsf scopes provided by myfaces codi (apache myfaces extcdi). 2011/2012 codi merged with some other projects and the result is apache deltaspike.

apache deltaspike is not just a merged code-base. it's nearly a full re-implementation with a similar api, but it contains a lot of cleanups and improvements based on the some lessons learned. that's on of the reasons why the progress slowed down (esp. compared to the development speed of codi). codi was driven and tested by real and large applications (in some cases of early adopters). it didn't contain a huge amount of tests, but it was very well tested (by those applications). apache deltaspike faces a slower adoption rate, because not everybody gets time for a migration (from an already solid stack) and some just wait for v1+ which will provide the final/stable api. however, deltaspike is also very well tested, since there are way more automated tests (compared to codi) and they get executed on a regular basis with different versions of cdi.

one effect of the current development speed is that scopes like grouped-conversations (@ConversationScoped from codi), window-scope (@WindowScoped) and view-access-scope (@ViewAccessScoped) as well as the powerful spi for managing them are still not available and/or not that well tested (in real applications).

since most other parts of codi are already part of deltaspike, it's easy to create a lib based on deltaspike which provides the missing parts. the source-code can be found at os890-cdi-ext and for using it as a dependency (in a maven based build), it's deployed to os890-m2-repository.

for using it just drop the dependencies for codi, add deltaspike (at least core and the jsf-module as well as their dependencies), add os890-cdi-ext (org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-api and org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-impl) and change the imported packages in your application (from org.apache.myfaces.extensions.cdi.[...] to org.apache.deltaspike.[...] and org.os890.cdi.ext.[...]).

improve apache wink - part 1

today i added two new features to wink-cdi-addon.

with using WinkAutoConfigCdiRestServlet (in combination with OptionalWinkAutoConfigExtension), it is not needed to list jax-rs provider- and static-resource-classes manually (if they are provided in a cdi enabled archive). beyond that you can use any cdi feature (e.g. for disabling them depending on a condition like the project-stage) you would use for a front-controller.

furthermore, with the new init-param os890.eagerInit, all wink handlers get initialized during the startup. so it's easier to find some basic issues early.

apache wink meets cdi (again)

apache wink is a jax-rs implementation which left the apache-incubator some months ago.

it offers a cdi integration already. however, as mentioned in WINK-388, this part of wink isn't that nice. therefore, i've created a wink/cdi add-on which can be used for existing versions of wink.

in addition it contains an optional (cdi-)extension which upgrades the scopes of jax-rs beans, which are also cdi beans (if they are dependent-scoped implicitly).

async cdi

today i implemented a small lib (~100 lines of code) which allows to use asynchronous cdi beans (including asynchronous observer methods).

if you don't use ejbs (for whatever reason), you can't use javax.ejb.Asynchronous.

however, sometimes you might need some asynchronous calls. as i illustrated in 'akka-and-cdi-are-good-friends', you can use actor-frameworks for doing it. however, sometimes that's just not needed and a simple asynchronous call is enough (which in addition doesn't have to follow the rules introduced by actor-frameworks).

in such cases you can use @Async.

	//...
	public class AsyncObserver
	{
	@Async
	public void observeAsync(@Observes MyEvent myEvent)
	{
	//...
	}
	}

view raw AsyncObserver.java hosted with ❤ by GitHub

	@Async
	//...
	public class MyAsyncService1
	{
	public void processIt1(/*...*/)
	{
	//...
	}
	public java.util.concurrent.Future processIt2(/*...*/)
	{
	//...
	}
	}

view raw MyAsyncService1.java hosted with ❤ by GitHub

	//...
	public class MyAsyncService2
	{
	@Async
	public void processIt1(/*...*/)
	{
	//...
	}
	@Async
	public java.util.concurrent.Future processIt2(/*...*/)
	{
	//...
	}
	}

view raw MyAsyncService2.java hosted with ❤ by GitHub

a working example (with owb as well as tomee with owb 1.2.x) can be found here. currently it doesn't work with weld.

akka and cdi are good friends

today i implemented a small lib (less than 100 lines of code) which integrates akka and cdi.

it supports injection of akka artifacts (ActorRef and ActorSystem) in cdi-beans as well injection of cdi-beans in actors.

examples:

	public class MyActor extends UntypedActor
	{
	@Inject
	private MyService myService;
	@Override
	public void onReceive(Object o) throws Exception
	{
	myService.process(/*...*/);
	}
	}

view raw AdvancedActor.java hosted with ❤ by GitHub

	//...
	public class MyBean
	{
	@Inject
	@Actor(type = MyActor.class)
	private ActorRef standardActor;
	@Inject
	@Actor(type = MyActor.class, systemName = "alternativeActorSystem")
	private ActorRef alternativeActor;
	@Inject
	private ActorSystem defaultSystem;
	@Inject
	@ActorSystemName("mainActorSystem")
	private ActorSystem namedSystem;
	//...
	}

view raw MyBean.java hosted with ❤ by GitHub

this lib doesn't intend to provide a full integration. it should just illustrate how easy it is to use akka in combination with cdi (and to integrate both).

(parts of it are done with deltaspike, however, it's easy to replace (copy) the needed parts to avoid a dependency.)

you just need to be aware of some basic rules given by actor-frameworks (some details are mentioned here).

the migration to tomee is easy

recently i created an example for tomee.

its origin is an example which used the same java-ee parts you find in tomee out-of-the-box, but configured manually for a servlet container like tomcat. the biggest change i had to do was to drop most dependencies. i just had to keep myfaces codi and extval. besides adding org.apache.openejb:javaee-api as provided dependency, i also added org.apache.openejb.maven:tomee-maven-plugin to start tomee and deploy the example with:

mvn tomee:run.

in the code i could keep everything as it was (the cleanup i did wasn't a required step to get it up and running with tomee). in case of the config i just had to drop some parts in web.xml and persistence.xml.

the rest worked immediately!

one container everywhere

based on the title you might think that this post is about spring. but it's about cdi with some references to spring/guice/... . however, it is not about spring vs cdi. it's just about wrong myths about cdi (compared to other containers like spring-core/guice/...)

esp. spring and cdi are so close that you can do almost everything with cdi what you can do with spring and the other way round. your project won't fail because you used one of it instead of the other one. if you have spring(-core) know-how already, it will take you about 2-3 days to know the same about cdi and the other way round. however, if you are in favour of the spring-framework, a lot of config options, one vendor,... , you should go with it. once you have the right dependency- and config-setup, the productivity with spring will be similar as long as you are aware of some topics like explicit proxy-configs in case of injection of beans with a narrow scope into beans with a wider scope. (that shouldn't be an offence - for sure also cdi has its pitfalls.)

let's have a look at some myths:

myth #1

statement:
with spring/guice/... everything is more flexible, since you just need to replace some jar-files for using a new version.

reality:
the same integration points to run spring/guice/... in your application-server are also available for a custom version of cdi (added in WEB-INF/lib).

myth #2

statement:
you can't upgrade the cdi container in your ee6 server.

reality:

technically you can do it. i did it already with tomee, glassfish3 and as7. the main question here is, if you are allowed to do it and/or you have the needed access to do it.

myth #3

statement:
once you picked an ee6 server, you have to use what you have in there.

reality:

a lot of specifications and/or the server itself allow/s to use other implementations. however, in case of cdi the container is integrated very deeply. using an other cdi implementation has the same restrictions as you will face with spring/guice/... . so you can do it, but not with keeping the full (cross-)integration like injecting cdi beans in ejbs. however, you can still use the cdi container to do a (bean-)lookup manually (as you would do with spring/guice/...). (preview: cdi 1.1 offers new SPIs which enable servers to provide even more out-of-the-box.)

myth #4

statement:
you can't use owb in an ee6 server which ships weld per default.

reality:

as mentioned in myth #3 you can do it with the same restrictions you would face with spring/guice/... concerning (cross-)integration. the following part is tested with glassfish (for as7 you would need a custom WebScannerService which supports the jboss vfs). there are different approaches:

approach 1:
in some cases it's enough just to add owb in WEB-INF/lib. e.g. in combination with jsf the el-resolver of owb will be called before the internal el-resolvers (like it is with spring/guice/...). however, you might face issues with some more restrictive checks done by weld (e.g. bda-rules). -> continue with:

approach 2:
2.1
exclude all packages via the scan-tag of the http://jboss.org/schema/weld/beans namespace (in beans.xml) -> only owb will find your beans.
2.2
owb is very pluggable. with a custom WebScannerService you can just use a different file-name for the marker file (e.g. owb_beans.xml instead of beans.xml). you just have to copy the default implementation, replace some strings and enable it in openwebbeans.properties. that means weld won't find your beans, but owb will find them (or the other way round for servers which ship owb per default). however, you might have implementations of javax.enterprise.inject.spi.Extension. -> continue with:

approach 3:
this approach can be combined with approach 2. you can veto beans for weld. just inject the bean-manager in your ProcessAnnotatedType observer and veto the bean if the bean-manager class is from weld: https://gist.github.com/os890/5427764

however, you might use a cdi-extension like codi or deltaspike and there it isn't enough to rename the marker-files or filter beans, because e.g. BeanManagerProvider will find the BeanManager of weld or of owb. since there is no rule (if both are in the classpath), the behaviour would be random. so you have to patch such cdi-extensions. e.g.: https://gist.github.com/os890/5427831

myth #5

statement:
cdi is hard(er) to use, because you don't get a reference to the container.

reality:
that's an easy task with owb as well as with weld. you can do it on your own or just use the CDI-Ctrl module provided by DeltaSpike. (with cdi 1.1 it will be possible out-of-the-box.)

deltaspike is now an apache top level project

it's done! deltaspike moved out of the apache incubator!

the initial project-team is listed in http://s.apache.org/QGq

[add-on] owb and actors

actor-frameworks for the jvm gain more popularity every day. even with actor-frameworks you have to be careful with shared state. however, if you have a java-ee application, you can (re-)use stateless services in your actors easily. one use-case is to resolve transactional beans (ejbs, cdi-beans which are annotated e.g. with @Transactional, ...) in an actor and invoke methods on them to access a database.

with an ee-application-server like tomee that works out-of-the-box. you just have to bootstrap an actor-framework (like akka, jetlang,...) and use the std. java-ee api to lookup the bean/s.

if you are interested in using transactional cdi beans, you can use the jpa-module provided by apache deltaspike v0.4+ (note: those transactions don't span across actors). for using @Transactional, you just have to follow the documentation and you are done. that's usually a short story. but...

if you would like to use @Singleton or @ApplicationScoped beans and you are using the openwebbeans-web module of owb v1.1.x, you need an additional plugin (due to OWB-785). in such cases just get https://github.com/os890/owb-contexts_service-addon.git, build it and add it as runtime dependency to your project.
-> you are done (there is no additional api you have to use).

additional hint:
apache deltaspike provides some nice helpers (like BeanProvider#getContextualReference to resolve cdi-beans), interceptors (like @Transactional), scopes (like @TransactionScoped) and much more...

mint 14

usually i don't blog about operating systems.
however, have you thought linux or esp. mint doesn't look awesome?

if you invest about 1 hour to adjust the default theme, a custom dock (docky) and some other fine-tunings, you get a really nice user-experience!

one picture doesn't show the whole story, but here is a basic impression:

[slides] apache myfaces universe

Apache MyFaces Universe @ ApacheCon

[slides] cdi @ apache

CDI @ Apache

[slides] myfaces codi and seam3 become apache deltaspike

MyFaces CODI and JBoss Seam3 become Apache DeltaSpike

speedup the tomee startup

apache tomee is based on apache tomcat and adds the java-ee web-profile on top of it (based on apache projects like myfaces, openwebbeans, bval,...). the runtime performance is great and also the startup time is nice. esp. during the development phase every second hurts (at least a bit). with a simple change it's easy to remove some overhead! the following part shows the difference.

tomee just adds some libs to tomcat. that means you can also use a different version of tomcat easily - so it's easy to get tweaks and bugfixes of the latest version of tomcat also for tomee and you can use the std. tomcat plugin for your ide. however, that also means you (can) get some overhead - currently the demo apps shipped with tomcat cause such an overhead during the server startup. just by removing the demo web-apps you can reduce the startup time of tomcat itself by about 50 percent (here from ~1.4 seconds to ~0.7 seconds). for tomee you can do the same, but you have to keep a webapp called "tomee" (it's needed to use remote-ejbs - so it isn't a demo). if you don't need remote-ejbs, you can remove all webapps shipped by tomee to improve the startup performance even further.

the following chart shows the differences of the mentioned constellations. the value for jboss as7 is just a reference value.

the following chart shows the overhead introduced by tomee (compared to a standalone tomcat).

please note:
1)
all those values depend on the machine, operating-system,... - in addition the values are rounded and should just give a basic impression about the differences (please don't see it e.g. as a tomee vs as7 comparison).

2)
there are 2 values printed during the tomcat/tomee startup. the first one is listed as "Initialization processed in ..." and  the second one as "Server startup in ...". the values in the charts always show the sum of both ( "Server startup in ..." sounds like the sum but it is not the sum of the full startup process).

3)
as7 is also based on tomcat but the integration is way deeper and therefore it isn't given that the startup of tomcat itself takes the same time as with tomcat standalone or tomee (that's the reason why there is no separation for as7 in the second chart).

2nd release of apache deltaspike

the apache deltaspike team is pleased to announce the 2nd release (v0.2-incubating).

we release early and often. so take the chance and test the new features provided by this release. in the next release we will add further deltaspike-core features and we will start with further modules.

we would be happy to receive your feedback to improve apache deltaspike step by step.

release notes:
http://s.apache.org/DeltaSpike_02incubating

12th release of myfaces-extensions-cdi

The Apache MyFaces team is pleased to announce the 12th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.5!

openwebbeans on glassfish3 for jsf-applications

several users would like to use owb on glassfish3. if a full integration isn't needed and the only problem is an exception in jersey during the bootstrapping process, it's quite easy to work around it.

	//for a partial integration in GlassFish3 in case of:
	//java.lang.NullPointerException at com.sun.jersey.server.impl.cdi.CDIExtension.processAnnotatedField
	public class JerseyAwareLoaderService extends DefaultLoaderService
	{
	@Override
	public <T> List<T> load(Class<T> serviceType, ClassLoader classLoader)
	{
	List<T> result = super.load(serviceType, classLoader);
	Iterator<T> resultIterator = result.iterator();
	while (resultIterator.hasNext())
	{
	if (resultIterator.next().getClass().getName().startsWith("com.sun.jersey.server"))
	{
	resultIterator.remove();
	}
	}
	return result;
	}
	}
	//and in /MEAT-INF/openwebbeans/openwebbeans.properties activate it via:
	configuration.ordinal=100
	org.apache.webbeans.spi.LoaderService=org.os890.codi.addon.cdibridge.JerseyAwareLoaderService

view raw JerseyAwareLoaderService hosted with ❤ by GitHub

you need the following owb modules:

- openwebbeans-impl
- openwebbeans-spi
- openwebbeans-web
- openwebbeans-jsf

attention: that isn't a full integration. as you see e.g. jersey can't be used with this workaround.

11th release of myfaces-extensions-cdi

The Apache MyFaces team is pleased to announce the 11th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.4!

1st release of apache deltaspike

the apache deltaspike team is pleased to announce the first release (v0.1-incubating).

with this first step we started to merge apache myfaces codi-core and jboss solder. we will release early and often. so take the chance and test the first features provided by this release. in the next release we will add further deltaspike-core features and we will start with further modules.

we would be happy to receive your feedback to improve apache deltaspike step by step.

release notes:
http://s.apache.org/DeltaSpike_01incubating

[slides] make jsf more type-safe with cdi and myfaces-codi

Make JSF more type-safe with CDI and MyFaces-CODI

codi meets tomee

recently the open-ejb team released beta2 of tomee v1.

tomee is already optimized a lot. today we saw an issue during the deployment of a codi demo to tomee. thx to romain manni-bucau we found the issue pretty quickly. due to an optimization tomee filters myfaces-* jar files to improve the scanning performance. so you just have to rename the jar file(s) of codi until the issue gets fixed.
(or manually patch org\apache\openejb\config\NewLoaderLogic.class in webapps\openejb\lib\openejb-core-4.0.0-beta-2.jar)

furthermore, we will add an integration test to tomee to avoid that it happens again.

so have fun with myfaces codi on tomee!

10th release of myfaces-extensions-cdi

The Apache MyFaces team is pleased to announce the 10th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.3!

deltaspike repository

today we got our git repository for deltaspike: https://git-wip-us.apache.org/repos/asf/incubator-deltaspike.git

5th release of myfaces-extensions-validator

The Apache MyFaces team is pleased to announce the 5th release of Apache MyFaces Extensions Validator (aka ExtVal).

deltaspike mailing lists

today matt benson created our mailing lists and the first tests were successful: http://goo.gl/oRFtU and http://goo.gl/DZix0

thx matt!

deltaspike joins the asf incubator

the vote to join the incubator was closed. there were 8 binding +1 votes, 3 non-binding +1 votes and no -1 votes. in parallel several other folks showed up and told us that they are interested to join the effort.

9th release of myfaces-extensions-cdi

The Apache MyFaces team is pleased to announce the 9th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.2!

deltaspike - the future of myfaces codi (is bright)

today we announced the future of myfaces codi.

that means: codi goes apache tlp (top level project) together with others (esp. the seam3 team and the cdi-source team). as mentioned in the announcement: we will continue with codi. several features will be promoted to deltaspike and codi v2 will be based on deltaspike and will provide all features which won't be available in deltaspike itself. codi v1 will continue (it will be improved and maintained as it is and won't migrate to deltaspike).

[scopes] render-scope vs flash-scoped vs codi scopes

frameworks like seam provide a so called render-scope e.g. to use beans after a redirect for rendering the next page. that's very often not enough because beans are usually also needed on a subsequent request to the same page. the flash scope is also not the best solution because it's usually also used to overcome the redirect issue of request scoped beans. therefore, myfaces codi introduced the view-access-scope which keeps beans as long as they are accessed by a view (also supports any kind of ajax scenarios). however, if you really need the behaviour of @RenderScoped, you can use e.g. the @PostRenderView callback to terminate beans (which have one of the codi scopes) manually or you can provide a custom marker and you terminate all beans with this marker automatically in a phase-listener. the needed information is available in the wiki (or just contact the myfaces mailing list, if you need further information about it).

[myfaces] setup of codi and extval

in the last weeks i saw a lot of users looking for information about setting up and/or configuring extval and/or codi.

the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)

information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.

8th release of myfaces-extensions-cdi

The Apache MyFaces team is pleased to announce the 8th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.1!

[scopes] view-scope vs view-access-scope

a lot of people were looking for this information.
you can find the information in the wiki of codi.

however, the short answer is:
the view-scope of jsf2+ is bound to a concrete jsf page. that means: as soon as you navigate to a different page, the state gets lost. that's better than nothing, but not useful for a lot of use-cases. the main use-case which needs it are ajax-requests on a page and the data used by them aren't needed on other pages, but it's pretty easy to break it e.g. with a browser-refresh on a page which stores the data in a view-scoped bean and has no form with input components. (in a previous blog post i described how to use the infrastructure provided by codi to create a session based view-scope to overcome such disadvantages cause by storing view scoped beans as part of the tree-state.)

like with the view-scope view-access-scoped beans are available on a page, but they also exist for the next page. that means: they are forwarded to the next page and get destroyed autom. if they don't get used during the first request of the next page. that's e.g. useful for wizards. if you have a wizard page which doesn't use the bean or you have to support the possibility to interrupt a wizard, you can use the grouped-conversation scope (and even the window-scope) provided by codi. however, due to the powerful api of codi you can also destroy the scope manually at any time (if needed).

[benchmark] boost myfaces codi scopes with owb v1.1.1

this is my last blog-entry about the performance of cdi implementations and codi scopes which is planned for the next months. why? you will see it in a minute.

within the last weeks we gave the weld team some hints how they can tweak the performance of their scopes. as you can see in the following benchmark, they improved the performance of std. scopes in weld a lot. the performance of the std. scopes is now pretty much the same as with owb. all differences are within the tolerance. however, the owb team (special thx to mark) is again one step ahead. the next release of owb (v1.1.1) will allow to use a very fast instance cache for custom scopes. based on this feature, i implemented the scope-boost add-on for codi. the result/s you can see in the chart: codi scopes are as fast as the request scope of owb. a nice detail about that: since owb v1.1.1 is faster than v1.1.0, codi scopes (+ add-on) in combination with owb v1.1.1 are faster than the (already very fast) request scope of owb v1.1.0 (you might remember the awesome results of the previous benchmarks).

as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results (tolerance: <0,25ms). all application servers were started without changes in the configuration. for producing the other results i used again tomcat v7.0.19. in this benchmark the servers aren't that important, because there is no class of those servers between the method call and the final method of the bean (just the proxies used by the cdi implementation). that means jboss as7 as well as glassfish v3 are just slower because they don't ship the latest version of weld. for sure - if you upgrade your server, you will get a better performance with those servers.

the result:
as mentioned before std. scopes in weld (the currently latest release) and owb have about the same performance. in case of custom scopes owb can be way faster in combination with special add-ons for the corresponding custom scopes. the add-ons are needed to reset the cached instances, if the scope ends before the request ends. in case of codi you still have all advantages of codi-scopes as well as the performance of the request scope. that's possible due to the awesome concepts in owb as well as the UnscopeBeanEvent of codi. (please notice that weld v1.1.2 which is called "standalone" in this chart is a newer version compared to weld v1.1.2 shipped with jboss as7 out-of-the-box. the newer version already has the performance improvements mentioned before. that's the reason for the difference (and it isn't related to jboss as7))

(the lower - the better)

for this benchmark i used the simple benchmark which i used for my first post (as well as the same steps to measure the performance). in the previous benchmark i switched to jmeter because users were interested in the overall impact. this time i (again) used the simpler version because of some fluctuations with jmeter tests. besides the typical parameters which can influence the results, load tests are less reproducible e.g. because of several features of modern cpus. however, the previous posts are still valid. after publishing them i re-tested the benchmarks with different systems as well as different jdk implementations, operating systems,... . for sure the results differed a bit, but the overall result was more or less the same (esp. the ranking). however, as mentioned in the previous posts as well as in this post, these benchmarks should give you a basic impression. you might see a bit different results on your system, but the overall result is usually the same - esp. the basic messages illustrated by this benchmark:

- owb is innovative, pluggable and fast
- owb + codi == just awesome
- weld got a lot faster in the latest release
- servers which bundle old versions of weld are slower because they depend on the performance of those versions -> update the versions as soon as you can and you will increase the performance of your applications deployed to those servers for free!

[benchmark] myfaces codi scopes - weld vs owb part 3

in the previous benchmark i basically compared the scope performance of owb and weld with direct calls. this time i'm using jmeter to measure the performance under heavy load of a whole page. in the previous benchmarks the results were pretty stable. that's different this time. the results fluctuate way more and with some servers i (sometimes) got an OutOfMemoryError (depending on the settings). however, the conditions for the benchmark were the same for all servers:
- starting the server
- opening the page (which will be used for the jmeter tests)
- specifying how many el-expressions should be tested
- starting the jmeter benchmark

pages with 100, 1.000, 5.000 and 10.000 el-expressions were used for the benchmark.

all application servers were started without changes in the configuration. in tomcat mojarra 2.1.3 was used instead of myfaces-core to avoid an impact on the result e.g. due to a differing performance of renderers.

every value-binding in the page queried the value of a conversation scoped bean (codi conversations). this bean delegates the call to an injected request scoped bean. and the request scoped bean delegates to an application scoped bean which caches the list of objects which should be displayed.

as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results.

the result:
esp. tests of pages with few el-expressions didn't show a huge difference between the servers, but the results fluctuated more compared to pages with a lot of el-expressions. as you see, tomcat 7 with owb is a bit better than tomcat 7 with weld and jboss as 7. in the end the difference is not big compared to glassfish v3.1.1. the following chart should give you a basic idea about a page which uses 100 value-bindings. that might sound a lot, but a page which contains a table with 4 columns and 15 rows already leads to 60 el-calls during the rendering phase only to display the values (in case of one displayed value per cell). and if you think about the rendered attribute or expressions to switch the formatting within cells dynamically,... you will get over 100 el-calls in the rendering phase very easily.

(the higher - the better)

as mentioned before i benchmarked the page with different amounts of el-expressions. the following chart shows the average of the throughput in percent. the fastest setup (in this case tomcat 7 + owb 1.1.0) is used as measuring staff.

(the higher - the better)

it might be interesting to see the results of the benchmarks above in a different context. the following charts shows the overhead in percentage. a static html page with the same content served by jsf on tomcat 7 is the basis for the comparison and would have 0% (that means: no overhead).

(the lower - the better)

measurements beyond hello word:
there are applications with even larger pages. the following chart shows the numbers for 30.000 value bindings per page. compared to the value-bindings of the benchmark above, it uses more complex bindings like
#{bean1.bean2.bean3.property} instead of directly delegating to a property of the first bean which resolves the final property. as you see owb gets even better with more complex scenarios.

(the higher - the better)

as mentioned before i used the settings which are shipped by the vendors out-of-the-box. since they are different i run the same constellation described above with 1.000 (instead of 30.000) value bindings per page. the following chart shows the result with -Xms128m -Xmx1500m -XX:MaxPermSize=256m (these values are the highest values used at least by one of the servers).

(the higher - the better)

codi meets scala

werner wrote nice blog entries about using scala in combination with jsf. in the second part he shows the basic approach how to implement the type-safe view-config the scala way. let's hope we will see a follow-up about nice view-config features like multiple inheritance of configs (like a SecuredPages interface).

[benchmark] myfaces codi scopes - owb vs weld part 2

the last few days we heard a lot about how great jboss as 7 (jboss application server v7) should be. i already tested the pre-release version concerning the compatibility with codi. it worked pretty well. that was awesome. in this test i'm using the final version which starts in a bit more than 2 sec. (on my machine). but now it's time to measure the runtime performance. therefore i used the latest releases of all containers. (just in case of glassfish i used the nightly of glassfish v3.2 to be able to use the latest version.) in case of jboss as 7 and glassfish v3 i took the weld versions they provide out of the box and on tomcat 7 and jetty 7 i used the current openwebbeans (= owb) release.

the result - jboss as 7 starts quite fast but the runtime performance is still better with a servlet container like tomcat or jetty + owb. however, i'm glad to see that there is a step forward from weld v1.1.1 to v1.1.2 but there is still a lot of room for improvements.

the tested scopes are the scopes provided by myfaces codi (with the exception of the request scope - it's just included as an orientation). the most significant result in the first chart is that the slowest scope (which is still very fast) is faster with owb than the fastest scope with weld. (if you keep the tolerance in mind we could say it's maybe not faster but as least equivalent.)

as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: <0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average.

as you see there are more or less the same results in tomcat and jetty. the results depend on the cdi version and not the container. the differences are within the tolerance. the difference between glassfish and jboss as 7 is caused by the newer version of weld in jboss as 7. so independent of how fast jboss as 7 is (e.g. during startup), the runtime-performance depends on parts like the used cdi implementation. this benchmark shows what you get out-of-the-box. for sure with servlet containers like tomcat, jetty,... you have the choice. if performance is important for your project, go with owb (it's already used by several big real world projects, it's fast, very solid and provides a powerful spi to customize the behaviour if you need to).


so it might be interesting to compare the currently released versions directly:

note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.

codi for all - all for codi

it's really great. people notify us about successful tests on different environments.

now codi is tested on:
- Tomcat
- TomEE
- Jetty
- JEE 6 Application-Servers (JBossAS, WebSphere, Glassfish)
- JEE 5 Application-Servers (WLS, WebSphere,...)
- dmServer

an up to date list and further details are available here.

7th release of myfaces-extensions-cdi -> v1

The Apache MyFaces team is pleased to announce the 7th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.0!

codi meets jboss as 7

since jboss application server v7 (jboss as 7) is short before the beta 4 and rc1 release, i tested the latest head with the latest version of codi. as tweeted, everything worked well. all workarounds for mojarra and weld we had to use for glassfish v3 also work on as7.

goodbye ubuntu - welcome mint (ubuntu.better)

since years i'm using ubuntu. most of the time it worked pretty well. since some weeks i'm testing mint linux (it's based on ubuntu) as well as the current snapshots of other more famous dists like fedora. now i completely switched to mint. the original reason was gnome 2 but it turned out that they do a lot of things way better and i can use it as it is (i even like the design).

since i like their vision, i hope that i can keep it as long as possible.

session based view-scope with codi

codi itself offers an adapter for the view-scope of jsf2+ as well as a view-access scope which sounds similar but is something completely different (there is a 2nd blog entry about the difference). this entry is not about the view-access scope. it's about the view-scope which was introduced by jsf2. the adapter provided by codi allows you to bind cdi beans to the view-scope of jsf2+ directly. that's the reason why it's only available for jsf2+ whereas the other scopes of codi can be used with jsf1.2 as well as jsf2+. however, besides the basic concept of the view-scope, the default implementation has also some disadvantages (like losing the state in case of a browser-refresh, if there is no form with input components). if you haven't faced such issues, you might skip this blog entry. as mentioned before there is no standard way for jsf1.2 users to use the view-scope of jsf2+.

after several questions about it i decided to implement a codi-add-on which can be used with jsf1.2 as well as with jsf2+. due to the powerful spi of codi, the result is a simple implementation which offers additional features like grouped beans (you can manually destroy beans of the same group immediately even though you stay on the  same page), optional bean events,... .

it's e.g. problematic for some use-cases that the jsf2+ implementation of the view-scope stores the beans in the component tree. so several users ask for a session based view-scope. that means the beans for a page will be stored in the session instead of the component tree. if you really need such a scope instead of the view-access-scope provided by codi, you can implement such a scope with the spi of codi + two simple classes.

approach #1

the first one is a marker annotation and the second one an observer for the PreViewConfigNavigateEvent. that's it! if you only use the type-safe navigation of codi, you are done and you annotate your bean with @View and the @ConversationScoped annotation provided by codi. as soon as a navigation to a new page is detected all conversation scoped beans annotated with @View will be destroyed.

	@ApplicationScoped
	public class SimulatedViewScopeObserver
	{
	protected void observeNavigation(
	@Observes PreViewConfigNavigateEvent preViewConfigNavigateEvent,
	EditableWindowContext editableWindowContext)
	{
	if (!preViewConfigNavigateEvent.getFromView()
	.equals(preViewConfigNavigateEvent.getToView()))
	{
	for(Map.Entry<ConversationKey, EditableConversation> conversation :
	editableWindowContext.getConversations().entrySet())
	{
	if(ConversationScoped.class
	.isAssignableFrom(conversation.getKey().getScope()))
	{
	if(conversation.getKey().getConversationGroup()
	.isAnnotationPresent(View.class))
	{
	conversation.getValue().close();
	}
	}
	}
	}
	}
	}

view raw SimulatedViewScopeObserver.java hosted with ❤ by GitHub

	@Target({TYPE})
	@Retention(RUNTIME)
	@Documented
	public @interface View
	{
	}

view raw View.java hosted with ❤ by GitHub

if you don't use the type-safe navigation of codi, you can implement e.g. a custom jsf navigation handler which does the same for all navigations.

if you prefer a single annotation instead (let's call it @MyViewScoped), you can write a portable cdi extension which adds the @ConversationScoped dynamically to all beans which are annotated with @MyViewScoped.

it took longer to write this blog entry, than implementing this mechanism :)

or

approach #2

the result of this approach is the same like approach #1. the advantage is that you don't have to care about the navigation and the disadvantage is that you have to extend a default implementation.

if you are ok with extending the default implementation (with weld you have to #veto the default implementation instead of using @Specializes), you can override the default implementation of #createConversation (a method which is part of the spi of codi). if you just implement the interface, you would override everything and you would deactivate all codi scopes. ok - so let's add a new scope with the same marker annotation and a ConversationFactory instead of the observer:

	class ViewConversationExpirationEvaluator
	implements ConversationExpirationEvaluator
	{
	private static final long serialVersionUID = -1298186767354202960L;
	private String viewId;
	private boolean expired;
	ViewConversationExpirationEvaluator()
	{
	if(FacesContext.getCurrentInstance().getViewRoot() != null)
	{
	this.viewId = FacesContext.getCurrentInstance()
	.getViewRoot().getViewId();
	}
	}
	public boolean isExpired()
	{
	return this.viewId == null ||
	!this.viewId.equals(FacesContext.getCurrentInstance()
	.getViewRoot().getViewId());
	}
	public void touch()
	{
	if(this.viewId == null && !this.expired)
	{
	this.viewId = FacesContext.getCurrentInstance()
	.getViewRoot().getViewId();
	}
	}
	public void expire()
	{
	this.viewId = null;
	this.expired = true;
	}
	}

view raw ViewConversationExpirationEvaluator.java hosted with ❤ by GitHub

	@Target({TYPE})
	@Retention(RUNTIME)
	@Documented
	public @interface ViewConversationScoped
	{
	}

view raw ViewConversationScoped.java hosted with ❤ by GitHub

	@Specializes
	public class ViewScopeAwareConversationFactory extends JsfAwareConversationFactory
	{
	private static final long serialVersionUID = 8809629790207239230L;
	@Inject
	private BeanManager beanManager;
	@Override
	public EditableConversation createConversation(
	ConversationKey conversationKey, ConversationConfig configuration)
	{
	if(conversationKey.getConversationGroup()
	.isAnnotationPresent(ViewConversationScoped.class))
	{
	return new DefaultConversation(conversationKey,
	new ViewConversationExpirationEvaluator(),
	configuration,
	this.beanManager);
	}
	return super.createConversation(conversationKey, configuration);
	}
	}

view raw ViewScopeAwareConversationFactory.java hosted with ❤ by GitHub

this implementation is compatible with all jsf concepts which are supported by codi!

approach #2.1

this approach is the same like #2 but instead of implementing it on our own, we can just use the @ViewConversationScoped provided by the enhanced-conversations add-on for codi:

	import org.os890.codi.addon.conversation.api.ViewConversationScoped;
	import javax.annotation.PostConstruct;
	import javax.inject.Named;
	import java.io.Serializable;
	import java.util.Date;
	@Named
	@ViewConversationScoped
	public class ViewConversationBean implements Serializable
	{
	private static final long serialVersionUID = 609266293914288287L;
	private Date createdAt;
	@PostConstruct
	protected void init()
	{
	this.createdAt = new Date();
	}
	public Date getCreatedAt()
	{
	return createdAt;
	}
	}

view raw ViewConversationBean.java hosted with ❤ by GitHub