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.