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.
Saturday, May 31, 2014
Friday, May 30, 2014
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.
Thursday, May 29, 2014
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.
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.
Wednesday, May 21, 2014
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!
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!
Saturday, May 10, 2014
[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:
and
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.
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
public class DefaultEventBroadcastingTest | |
{ | |
@Inject | |
private AsynchronousEvent<MyEvent> myAsyncEvent; | |
public void fireAsyncEvent() | |
{ | |
this.myAsyncEvent.fire(new MyEvent(/*...*/)); | |
} | |
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@ApplicationScoped | |
public class AsyncObserver | |
{ | |
public void onEvent(@ObservesAsynchronous MyEvent event) | |
{ | |
//... | |
} | |
} |
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.
Labels:
async,
cdi,
deltaspike,
deltaspike-add-on,
disruptor,
events,
jsr 299
Monday, May 5, 2014
[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:
an example for a simple manual-mock for the cdi-bean:
an example for a simple mockito-mock for the cdi-bean:
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.
an example for a simple cdi-bean:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@RequestScoped | |
public class MyCdiBean | |
{ | |
private int count = 0; | |
public int getCount() | |
{ | |
return count; | |
} | |
public void increaseCount() | |
{ | |
count++; | |
} | |
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@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()); | |
} | |
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@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()); | |
} | |
} |
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.
Labels:
apache,
cdi,
deltaspike,
deltaspike-add-on,
jsr 299,
jsr 330
Subscribe to:
Posts (Atom)