Tuesday, December 31, 2013

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.

Monday, December 30, 2013

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.

Thursday, December 26, 2013

[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:

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.

Monday, December 16, 2013

[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:




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.:

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

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

Monday, December 2, 2013

[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:



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

Friday, October 25, 2013

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).

Monday, September 23, 2013

the face of deltaspike 0913

the progess of creating deltaspike:


Monday, September 9, 2013

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.

Sunday, September 8, 2013

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).

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

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.[...]).

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.

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).

Monday, May 6, 2013

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.



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.

Sunday, May 5, 2013

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:




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).

Wednesday, May 1, 2013

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!

Monday, April 22, 2013

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.)

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

Saturday, February 23, 2013

[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...