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)