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.
Showing posts with label apache. Show all posts
Showing posts with label apache. Show all posts
Monday, May 5, 2014
Sunday, April 20, 2014
[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,...).
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.
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,...).
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.
Labels:
apache,
cdi,
deltaspike,
deltaspike-add-on,
jsf,
jsr 299,
jsr 330
Friday, August 9, 2013
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
Labels:
apache,
jax-rs,
jboss,
jboss as,
jboss as 7,
jbossas7,
wink,
wink-add-on
Thursday, August 8, 2013
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.
Monday, July 22, 2013
[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.[...]).
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.[...]).
Labels:
apache,
cdi,
codi,
ConversationScoped,
deltaspike,
deltaspike-add-on,
extcdi,
jsf,
jsf 2.0,
jsr 299,
jsr 330,
myfaces-extensions,
scopes,
ViewAccessScoped,
WindowScoped
Thursday, July 18, 2013
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.
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.
Sunday, July 14, 2013
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).
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).
Thursday, April 18, 2013
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
the initial project-team is listed in http://s.apache.org/QGq
Monday, January 24, 2011
apache member
last week i received an awesome invitation from matthias to become an asf member. i'm honored and accepted with pleasure! thx to all members!
Subscribe to:
Posts (Atom)