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.[...]).
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.
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).
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!
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:
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).
you can't upgrade the cdi container in your ee6 server.
reality:
once you picked an ee6 server, you have to use what you have in there.
reality:
you can't use owb in an ee6 server which ships weld per default.
reality:
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
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.)
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 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
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...
Saturday, November 17, 2012
mint 14
usually i don't blog about operating systems.
however, have you thought linux or esp. mint doesn't look awesome?
if you invest about 1 hour to adjust the default theme, a custom dock (docky) and some other fine-tunings, you get a really nice user-experience!
one picture doesn't show the whole story, but here is a basic impression:
however, have you thought linux or esp. mint doesn't look awesome?
if you invest about 1 hour to adjust the default theme, a custom dock (docky) and some other fine-tunings, you get a really nice user-experience!
one picture doesn't show the whole story, but here is a basic impression:
Thursday, November 8, 2012
Friday, May 11, 2012
Wednesday, May 2, 2012
speedup the tomee startup
apache tomee is based on apache tomcat and adds the java-ee web-profile on top of it (based on apache projects like myfaces, openwebbeans, bval,...). the runtime performance is great and also the startup time is nice. esp. during the development phase every second hurts (at least a bit). with a simple change it's easy to remove some overhead! the following part shows the difference.
tomee just adds some libs to tomcat. that means you can also use a different version of tomcat easily - so it's easy to get tweaks and bugfixes of the latest version of tomcat also for tomee and you can use the std. tomcat plugin for your ide. however, that also means you (can) get some overhead - currently the demo apps shipped with tomcat cause such an overhead during the server startup. just by removing the demo web-apps you can reduce the startup time of tomcat itself by about 50 percent (here from ~1.4 seconds to ~0.7 seconds). for tomee you can do the same, but you have to keep a webapp called "tomee" (it's needed to use remote-ejbs - so it isn't a demo). if you don't need remote-ejbs, you can remove all webapps shipped by tomee to improve the startup performance even further.
the following chart shows the differences of the mentioned constellations. the value for jboss as7 is just a reference value.
the following chart shows the overhead introduced by tomee (compared to a standalone tomcat).
please note:
1)
all those values depend on the machine, operating-system,... - in addition the values are rounded and should just give a basic impression about the differences (please don't see it e.g. as a tomee vs as7 comparison).
2)
there are 2 values printed during the tomcat/tomee startup. the first one is listed as "Initialization processed in ..." and the second one as "Server startup in ...". the values in the charts always show the sum of both ( "Server startup in ..." sounds like the sum but it is not the sum of the full startup process).
3)
as7 is also based on tomcat but the integration is way deeper and therefore it isn't given that the startup of tomcat itself takes the same time as with tomcat standalone or tomee (that's the reason why there is no separation for as7 in the second chart).
tomee just adds some libs to tomcat. that means you can also use a different version of tomcat easily - so it's easy to get tweaks and bugfixes of the latest version of tomcat also for tomee and you can use the std. tomcat plugin for your ide. however, that also means you (can) get some overhead - currently the demo apps shipped with tomcat cause such an overhead during the server startup. just by removing the demo web-apps you can reduce the startup time of tomcat itself by about 50 percent (here from ~1.4 seconds to ~0.7 seconds). for tomee you can do the same, but you have to keep a webapp called "tomee" (it's needed to use remote-ejbs - so it isn't a demo). if you don't need remote-ejbs, you can remove all webapps shipped by tomee to improve the startup performance even further.
the following chart shows the differences of the mentioned constellations. the value for jboss as7 is just a reference value.
the following chart shows the overhead introduced by tomee (compared to a standalone tomcat).
please note:
1)
all those values depend on the machine, operating-system,... - in addition the values are rounded and should just give a basic impression about the differences (please don't see it e.g. as a tomee vs as7 comparison).
2)
there are 2 values printed during the tomcat/tomee startup. the first one is listed as "Initialization processed in ..." and the second one as "Server startup in ...". the values in the charts always show the sum of both ( "Server startup in ..." sounds like the sum but it is not the sum of the full startup process).
3)
as7 is also based on tomcat but the integration is way deeper and therefore it isn't given that the startup of tomcat itself takes the same time as with tomcat standalone or tomee (that's the reason why there is no separation for as7 in the second chart).
Sunday, April 22, 2012
2nd release of apache deltaspike
the apache deltaspike team is pleased to announce the 2nd release (v0.2-incubating).
we release early and often. so take the chance and test the new features provided by this release. in the next release we will add further deltaspike-core features and we will start with further modules.
we would be happy to receive your feedback to improve apache deltaspike step by step.
release notes:
http://s.apache.org/DeltaSpike_02incubating
we release early and often. so take the chance and test the new features provided by this release. in the next release we will add further deltaspike-core features and we will start with further modules.
we would be happy to receive your feedback to improve apache deltaspike step by step.
release notes:
http://s.apache.org/DeltaSpike_02incubating
Tuesday, April 10, 2012
12th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 12th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.5!
Sunday, March 4, 2012
openwebbeans on glassfish3 for jsf-applications
several users would like to use owb on glassfish3. if a full integration isn't needed and the only problem is an exception in jersey during the bootstrapping process, it's quite easy to work around it.
you need the following owb modules:
- openwebbeans-impl
- openwebbeans-spi
- openwebbeans-web
- openwebbeans-jsf
attention: that isn't a full integration. as you see e.g. jersey can't be used with this workaround.
you need the following owb modules:
- openwebbeans-impl
- openwebbeans-spi
- openwebbeans-web
- openwebbeans-jsf
attention: that isn't a full integration. as you see e.g. jersey can't be used with this workaround.
Thursday, February 16, 2012
11th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 11th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.4!
Sunday, February 12, 2012
1st release of apache deltaspike
the apache deltaspike team is pleased to announce the first release (v0.1-incubating).
with this first step we started to merge apache myfaces codi-core and jboss solder. we will release early and often. so take the chance and test the first features provided by this release. in the next release we will add further deltaspike-core features and we will start with further modules.
we would be happy to receive your feedback to improve apache deltaspike step by step.
release notes:
http://s.apache.org/DeltaSpike_01incubating
with this first step we started to merge apache myfaces codi-core and jboss solder. we will release early and often. so take the chance and test the first features provided by this release. in the next release we will add further deltaspike-core features and we will start with further modules.
we would be happy to receive your feedback to improve apache deltaspike step by step.
release notes:
http://s.apache.org/DeltaSpike_01incubating
Monday, February 6, 2012
Wednesday, January 25, 2012
codi meets tomee
recently the open-ejb team released beta2 of tomee v1.
tomee is already optimized a lot. today we saw an issue during the deployment of a codi demo to tomee. thx to romain manni-bucau we found the issue pretty quickly. due to an optimization tomee filters myfaces-* jar files to improve the scanning performance. so you just have to rename the jar file(s) of codi until the issue gets fixed.
(or manually patch org\apache\openejb\config\NewLoaderLogic.class in webapps\openejb\lib\openejb-core-4.0.0-beta-2.jar)
furthermore, we will add an integration test to tomee to avoid that it happens again.
so have fun with myfaces codi on tomee!
tomee is already optimized a lot. today we saw an issue during the deployment of a codi demo to tomee. thx to romain manni-bucau we found the issue pretty quickly. due to an optimization tomee filters myfaces-* jar files to improve the scanning performance. so you just have to rename the jar file(s) of codi until the issue gets fixed.
(or manually patch org\apache\openejb\config\NewLoaderLogic.class in webapps\openejb\lib\openejb-core-4.0.0-beta-2.jar)
furthermore, we will add an integration test to tomee to avoid that it happens again.
so have fun with myfaces codi on tomee!
Wednesday, January 11, 2012
10th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 10th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.3!
Thursday, December 22, 2011
deltaspike repository
today we got our git repository for deltaspike: https://git-wip-us.apache.org/repos/asf/incubator-deltaspike.git
5th release of myfaces-extensions-validator
The Apache MyFaces team is pleased to announce the 5th release of Apache MyFaces Extensions Validator (aka ExtVal).
Friday, December 9, 2011
deltaspike mailing lists
today matt benson created our mailing lists and the first tests were successful: http://goo.gl/oRFtU and http://goo.gl/DZix0
thx matt!
thx matt!
Wednesday, December 7, 2011
deltaspike joins the asf incubator
the vote to join the incubator was closed. there were 8 binding +1 votes, 3 non-binding +1 votes and no -1 votes. in parallel several other folks showed up and told us that they are interested to join the effort.
Tuesday, December 6, 2011
9th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 9th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.2!
Wednesday, November 30, 2011
deltaspike - the future of myfaces codi (is bright)
today we announced the future of myfaces codi.
that means: codi goes apache tlp (top level project) together with others (esp. the seam3 team and the cdi-source team). as mentioned in the announcement: we will continue with codi. several features will be promoted to deltaspike and codi v2 will be based on deltaspike and will provide all features which won't be available in deltaspike itself. codi v1 will continue (it will be improved and maintained as it is and won't migrate to deltaspike).
that means: codi goes apache tlp (top level project) together with others (esp. the seam3 team and the cdi-source team). as mentioned in the announcement: we will continue with codi. several features will be promoted to deltaspike and codi v2 will be based on deltaspike and will provide all features which won't be available in deltaspike itself. codi v1 will continue (it will be improved and maintained as it is and won't migrate to deltaspike).
Sunday, August 28, 2011
[scopes] render-scope vs flash-scoped vs codi scopes
frameworks like seam provide a so called render-scope e.g. to use beans after a redirect for rendering the next page. that's very often not enough because beans are usually also needed on a subsequent request to the same page. the flash scope is also not the best solution because it's usually also used to overcome the redirect issue of request scoped beans. therefore, myfaces codi introduced the view-access-scope which keeps beans as long as they are accessed by a view (also supports any kind of ajax scenarios). however, if you really need the behaviour of @RenderScoped, you can use e.g. the @PostRenderView callback to terminate beans (which have one of the codi scopes) manually or you can provide a custom marker and you terminate all beans with this marker automatically in a phase-listener. the needed information is available in the wiki (or just contact the myfaces mailing list, if you need further information about it).
Saturday, August 27, 2011
[myfaces] setup of codi and extval
in the last weeks i saw a lot of users looking for information about setting up and/or configuring extval and/or codi.
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
Monday, August 22, 2011
8th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 8th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.1!
Monday, August 15, 2011
[scopes] view-scope vs view-access-scope
a lot of people were looking for this information.
you can find the information in the wiki of codi.
however, the short answer is:
the view-scope of jsf2+ is bound to a concrete jsf page. that means: as soon as you navigate to a different page, the state gets lost. that's better than nothing, but not useful for a lot of use-cases. the main use-case which needs it are ajax-requests on a page and the data used by them aren't needed on other pages, but it's pretty easy to break it e.g. with a browser-refresh on a page which stores the data in a view-scoped bean and has no form with input components. (in a previous blog post i described how to use the infrastructure provided by codi to create a session based view-scope to overcome such disadvantages cause by storing view scoped beans as part of the tree-state.)
like with the view-scope view-access-scoped beans are available on a page, but they also exist for the next page. that means: they are forwarded to the next page and get destroyed autom. if they don't get used during the first request of the next page. that's e.g. useful for wizards. if you have a wizard page which doesn't use the bean or you have to support the possibility to interrupt a wizard, you can use the grouped-conversation scope (and even the window-scope) provided by codi. however, due to the powerful api of codi you can also destroy the scope manually at any time (if needed).
you can find the information in the wiki of codi.
however, the short answer is:
the view-scope of jsf2+ is bound to a concrete jsf page. that means: as soon as you navigate to a different page, the state gets lost. that's better than nothing, but not useful for a lot of use-cases. the main use-case which needs it are ajax-requests on a page and the data used by them aren't needed on other pages, but it's pretty easy to break it e.g. with a browser-refresh on a page which stores the data in a view-scoped bean and has no form with input components. (in a previous blog post i described how to use the infrastructure provided by codi to create a session based view-scope to overcome such disadvantages cause by storing view scoped beans as part of the tree-state.)
like with the view-scope view-access-scoped beans are available on a page, but they also exist for the next page. that means: they are forwarded to the next page and get destroyed autom. if they don't get used during the first request of the next page. that's e.g. useful for wizards. if you have a wizard page which doesn't use the bean or you have to support the possibility to interrupt a wizard, you can use the grouped-conversation scope (and even the window-scope) provided by codi. however, due to the powerful api of codi you can also destroy the scope manually at any time (if needed).
Tuesday, August 2, 2011
[benchmark] boost myfaces codi scopes with owb v1.1.1
this is my last blog-entry about the performance of cdi implementations and codi scopes which is planned for the next months. why? you will see it in a minute.
within the last weeks we gave the weld team some hints how they can tweak the performance of their scopes. as you can see in the following benchmark, they improved the performance of std. scopes in weld a lot. the performance of the std. scopes is now pretty much the same as with owb. all differences are within the tolerance. however, the owb team (special thx to mark) is again one step ahead. the next release of owb (v1.1.1) will allow to use a very fast instance cache for custom scopes. based on this feature, i implemented the scope-boost add-on for codi. the result/s you can see in the chart: codi scopes are as fast as the request scope of owb. a nice detail about that: since owb v1.1.1 is faster than v1.1.0, codi scopes (+ add-on) in combination with owb v1.1.1 are faster than the (already very fast) request scope of owb v1.1.0 (you might remember the awesome results of the previous benchmarks).
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results (tolerance: <0,25ms). all application servers were started without changes in the configuration. for producing the other results i used again tomcat v7.0.19. in this benchmark the servers aren't that important, because there is no class of those servers between the method call and the final method of the bean (just the proxies used by the cdi implementation). that means jboss as7 as well as glassfish v3 are just slower because they don't ship the latest version of weld. for sure - if you upgrade your server, you will get a better performance with those servers.
the result:
as mentioned before std. scopes in weld (the currently latest release) and owb have about the same performance. in case of custom scopes owb can be way faster in combination with special add-ons for the corresponding custom scopes. the add-ons are needed to reset the cached instances, if the scope ends before the request ends. in case of codi you still have all advantages of codi-scopes as well as the performance of the request scope. that's possible due to the awesome concepts in owb as well as the UnscopeBeanEvent of codi. (please notice that weld v1.1.2 which is called "standalone" in this chart is a newer version compared to weld v1.1.2 shipped with jboss as7 out-of-the-box. the newer version already has the performance improvements mentioned before. that's the reason for the difference (and it isn't related to jboss as7))
for this benchmark i used the simple benchmark which i used for my first post (as well as the same steps to measure the performance). in the previous benchmark i switched to jmeter because users were interested in the overall impact. this time i (again) used the simpler version because of some fluctuations with jmeter tests. besides the typical parameters which can influence the results, load tests are less reproducible e.g. because of several features of modern cpus. however, the previous posts are still valid. after publishing them i re-tested the benchmarks with different systems as well as different jdk implementations, operating systems,... . for sure the results differed a bit, but the overall result was more or less the same (esp. the ranking). however, as mentioned in the previous posts as well as in this post, these benchmarks should give you a basic impression. you might see a bit different results on your system, but the overall result is usually the same - esp. the basic messages illustrated by this benchmark:
- owb is innovative, pluggable and fast
- owb + codi == just awesome
- weld got a lot faster in the latest release
- servers which bundle old versions of weld are slower because they depend on the performance of those versions -> update the versions as soon as you can and you will increase the performance of your applications deployed to those servers for free!
within the last weeks we gave the weld team some hints how they can tweak the performance of their scopes. as you can see in the following benchmark, they improved the performance of std. scopes in weld a lot. the performance of the std. scopes is now pretty much the same as with owb. all differences are within the tolerance. however, the owb team (special thx to mark) is again one step ahead. the next release of owb (v1.1.1) will allow to use a very fast instance cache for custom scopes. based on this feature, i implemented the scope-boost add-on for codi. the result/s you can see in the chart: codi scopes are as fast as the request scope of owb. a nice detail about that: since owb v1.1.1 is faster than v1.1.0, codi scopes (+ add-on) in combination with owb v1.1.1 are faster than the (already very fast) request scope of owb v1.1.0 (you might remember the awesome results of the previous benchmarks).
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results (tolerance: <0,25ms). all application servers were started without changes in the configuration. for producing the other results i used again tomcat v7.0.19. in this benchmark the servers aren't that important, because there is no class of those servers between the method call and the final method of the bean (just the proxies used by the cdi implementation). that means jboss as7 as well as glassfish v3 are just slower because they don't ship the latest version of weld. for sure - if you upgrade your server, you will get a better performance with those servers.
the result:
as mentioned before std. scopes in weld (the currently latest release) and owb have about the same performance. in case of custom scopes owb can be way faster in combination with special add-ons for the corresponding custom scopes. the add-ons are needed to reset the cached instances, if the scope ends before the request ends. in case of codi you still have all advantages of codi-scopes as well as the performance of the request scope. that's possible due to the awesome concepts in owb as well as the UnscopeBeanEvent of codi. (please notice that weld v1.1.2 which is called "standalone" in this chart is a newer version compared to weld v1.1.2 shipped with jboss as7 out-of-the-box. the newer version already has the performance improvements mentioned before. that's the reason for the difference (and it isn't related to jboss as7))
(the lower - the better)
for this benchmark i used the simple benchmark which i used for my first post (as well as the same steps to measure the performance). in the previous benchmark i switched to jmeter because users were interested in the overall impact. this time i (again) used the simpler version because of some fluctuations with jmeter tests. besides the typical parameters which can influence the results, load tests are less reproducible e.g. because of several features of modern cpus. however, the previous posts are still valid. after publishing them i re-tested the benchmarks with different systems as well as different jdk implementations, operating systems,... . for sure the results differed a bit, but the overall result was more or less the same (esp. the ranking). however, as mentioned in the previous posts as well as in this post, these benchmarks should give you a basic impression. you might see a bit different results on your system, but the overall result is usually the same - esp. the basic messages illustrated by this benchmark:
- owb is innovative, pluggable and fast
- owb + codi == just awesome
- weld got a lot faster in the latest release
- servers which bundle old versions of weld are slower because they depend on the performance of those versions -> update the versions as soon as you can and you will increase the performance of your applications deployed to those servers for free!
Sunday, July 17, 2011
[benchmark] myfaces codi scopes - weld vs owb part 3
in the previous benchmark i basically compared the scope performance of owb and weld with direct calls. this time i'm using jmeter to measure the performance under heavy load of a whole page. in the previous benchmarks the results were pretty stable. that's different this time. the results fluctuate way more and with some servers i (sometimes) got an OutOfMemoryError (depending on the settings). however, the conditions for the benchmark were the same for all servers:
- starting the server
- opening the page (which will be used for the jmeter tests)
- specifying how many el-expressions should be tested
- starting the jmeter benchmark
pages with 100, 1.000, 5.000 and 10.000 el-expressions were used for the benchmark.
all application servers were started without changes in the configuration. in tomcat mojarra 2.1.3 was used instead of myfaces-core to avoid an impact on the result e.g. due to a differing performance of renderers.
every value-binding in the page queried the value of a conversation scoped bean (codi conversations). this bean delegates the call to an injected request scoped bean. and the request scoped bean delegates to an application scoped bean which caches the list of objects which should be displayed.
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results.
the result:
esp. tests of pages with few el-expressions didn't show a huge difference between the servers, but the results fluctuated more compared to pages with a lot of el-expressions. as you see, tomcat 7 with owb is a bit better than tomcat 7 with weld and jboss as 7. in the end the difference is not big compared to glassfish v3.1.1. the following chart should give you a basic idea about a page which uses 100 value-bindings. that might sound a lot, but a page which contains a table with 4 columns and 15 rows already leads to 60 el-calls during the rendering phase only to display the values (in case of one displayed value per cell). and if you think about the rendered attribute or expressions to switch the formatting within cells dynamically,... you will get over 100 el-calls in the rendering phase very easily.
as mentioned before i benchmarked the page with different amounts of el-expressions. the following chart shows the average of the throughput in percent. the fastest setup (in this case tomcat 7 + owb 1.1.0) is used as measuring staff.
it might be interesting to see the results of the benchmarks above in a different context. the following charts shows the overhead in percentage. a static html page with the same content served by jsf on tomcat 7 is the basis for the comparison and would have 0% (that means: no overhead).
measurements beyond hello word:
there are applications with even larger pages. the following chart shows the numbers for 30.000 value bindings per page. compared to the value-bindings of the benchmark above, it uses more complex bindings like
#{bean1.bean2.bean3.property} instead of directly delegating to a property of the first bean which resolves the final property. as you see owb gets even better with more complex scenarios.
as mentioned before i used the settings which are shipped by the vendors out-of-the-box. since they are different i run the same constellation described above with 1.000 (instead of 30.000) value bindings per page. the following chart shows the result with -Xms128m -Xmx1500m -XX:MaxPermSize=256m (these values are the highest values used at least by one of the servers).
- starting the server
- opening the page (which will be used for the jmeter tests)
- specifying how many el-expressions should be tested
- starting the jmeter benchmark
pages with 100, 1.000, 5.000 and 10.000 el-expressions were used for the benchmark.
all application servers were started without changes in the configuration. in tomcat mojarra 2.1.3 was used instead of myfaces-core to avoid an impact on the result e.g. due to a differing performance of renderers.
every value-binding in the page queried the value of a conversation scoped bean (codi conversations). this bean delegates the call to an injected request scoped bean. and the request scoped bean delegates to an application scoped bean which caches the list of objects which should be displayed.
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results.
the result:
esp. tests of pages with few el-expressions didn't show a huge difference between the servers, but the results fluctuated more compared to pages with a lot of el-expressions. as you see, tomcat 7 with owb is a bit better than tomcat 7 with weld and jboss as 7. in the end the difference is not big compared to glassfish v3.1.1. the following chart should give you a basic idea about a page which uses 100 value-bindings. that might sound a lot, but a page which contains a table with 4 columns and 15 rows already leads to 60 el-calls during the rendering phase only to display the values (in case of one displayed value per cell). and if you think about the rendered attribute or expressions to switch the formatting within cells dynamically,... you will get over 100 el-calls in the rendering phase very easily.
(the higher - the better)
as mentioned before i benchmarked the page with different amounts of el-expressions. the following chart shows the average of the throughput in percent. the fastest setup (in this case tomcat 7 + owb 1.1.0) is used as measuring staff.
(the higher - the better)
(the lower - the better)
there are applications with even larger pages. the following chart shows the numbers for 30.000 value bindings per page. compared to the value-bindings of the benchmark above, it uses more complex bindings like
#{bean1.bean2.bean3.property} instead of directly delegating to a property of the first bean which resolves the final property. as you see owb gets even better with more complex scenarios.
(the higher - the better)
as mentioned before i used the settings which are shipped by the vendors out-of-the-box. since they are different i run the same constellation described above with 1.000 (instead of 30.000) value bindings per page. the following chart shows the result with -Xms128m -Xmx1500m -XX:MaxPermSize=256m (these values are the highest values used at least by one of the servers).
(the higher - the better)
Friday, July 15, 2011
codi meets scala
werner wrote nice blog entries about using scala in combination with jsf. in the second part he shows the basic approach how to implement the type-safe view-config the scala way. let's hope we will see a follow-up about nice view-config features like multiple inheritance of configs (like a SecuredPages interface).
Tuesday, July 12, 2011
[benchmark] myfaces codi scopes - owb vs weld part 2
the last few days we heard a lot about how great jboss as 7 (jboss application server v7) should be. i already tested the pre-release version concerning the compatibility with codi. it worked pretty well. that was awesome. in this test i'm using the final version which starts in a bit more than 2 sec. (on my machine). but now it's time to measure the runtime performance. therefore i used the latest releases of all containers. (just in case of glassfish i used the nightly of glassfish v3.2 to be able to use the latest version.) in case of jboss as 7 and glassfish v3 i took the weld versions they provide out of the box and on tomcat 7 and jetty 7 i used the current openwebbeans (= owb) release.
the result - jboss as 7 starts quite fast but the runtime performance is still better with a servlet container like tomcat or jetty + owb. however, i'm glad to see that there is a step forward from weld v1.1.1 to v1.1.2 but there is still a lot of room for improvements.
the tested scopes are the scopes provided by myfaces codi (with the exception of the request scope - it's just included as an orientation). the most significant result in the first chart is that the slowest scope (which is still very fast) is faster with owb than the fastest scope with weld. (if you keep the tolerance in mind we could say it's maybe not faster but as least equivalent.)
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: <0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average.
as you see there are more or less the same results in tomcat and jetty. the results depend on the cdi version and not the container. the differences are within the tolerance. the difference between glassfish and jboss as 7 is caused by the newer version of weld in jboss as 7. so independent of how fast jboss as 7 is (e.g. during startup), the runtime-performance depends on parts like the used cdi implementation. this benchmark shows what you get out-of-the-box. for sure with servlet containers like tomcat, jetty,... you have the choice. if performance is important for your project, go with owb (it's already used by several big real world projects, it's fast, very solid and provides a powerful spi to customize the behaviour if you need to).
so it might be interesting to compare the currently released versions directly:
note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.
the result - jboss as 7 starts quite fast but the runtime performance is still better with a servlet container like tomcat or jetty + owb. however, i'm glad to see that there is a step forward from weld v1.1.1 to v1.1.2 but there is still a lot of room for improvements.
the tested scopes are the scopes provided by myfaces codi (with the exception of the request scope - it's just included as an orientation). the most significant result in the first chart is that the slowest scope (which is still very fast) is faster with owb than the fastest scope with weld. (if you keep the tolerance in mind we could say it's maybe not faster but as least equivalent.)
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: <0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average.
as you see there are more or less the same results in tomcat and jetty. the results depend on the cdi version and not the container. the differences are within the tolerance. the difference between glassfish and jboss as 7 is caused by the newer version of weld in jboss as 7. so independent of how fast jboss as 7 is (e.g. during startup), the runtime-performance depends on parts like the used cdi implementation. this benchmark shows what you get out-of-the-box. for sure with servlet containers like tomcat, jetty,... you have the choice. if performance is important for your project, go with owb (it's already used by several big real world projects, it's fast, very solid and provides a powerful spi to customize the behaviour if you need to).
so it might be interesting to compare the currently released versions directly:
note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.
Friday, July 8, 2011
codi for all - all for codi
it's really great. people notify us about successful tests on different environments.
now codi is tested on:
- Tomcat
- TomEE
- Jetty
- JEE 6 Application-Servers (JBossAS, WebSphere, Glassfish)
- JEE 5 Application-Servers (WLS, WebSphere,...)
- dmServer
an up to date list and further details are available here.
now codi is tested on:
- Tomcat
- TomEE
- Jetty
- JEE 6 Application-Servers (JBossAS, WebSphere, Glassfish)
- JEE 5 Application-Servers (WLS, WebSphere,...)
- dmServer
an up to date list and further details are available here.
Thursday, July 7, 2011
7th release of myfaces-extensions-cdi -> v1
The Apache MyFaces team is pleased to announce the 7th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.0!
Tuesday, June 21, 2011
codi meets jboss as 7
since jboss application server v7 (jboss as 7) is short before the beta 4 and rc1 release, i tested the latest head with the latest version of codi. as tweeted, everything worked well. all workarounds for mojarra and weld we had to use for glassfish v3 also work on as7.
Monday, June 20, 2011
goodbye ubuntu - welcome mint (ubuntu.better)
since years i'm using ubuntu. most of the time it worked pretty well. since some weeks i'm testing mint linux (it's based on ubuntu) as well as the current snapshots of other more famous dists like fedora. now i completely switched to mint. the original reason was gnome 2 but it turned out that they do a lot of things way better and i can use it as it is (i even like the design).
since i like their vision, i hope that i can keep it as long as possible.
since i like their vision, i hope that i can keep it as long as possible.
Wednesday, June 1, 2011
session based view-scope with codi
codi itself offers an adapter for the view-scope of jsf2+ as well as a view-access scope which sounds similar but is something completely different (there is a 2nd blog entry about the difference). this entry is not about the view-access scope. it's about the view-scope which was introduced by jsf2. the adapter provided by codi allows you to bind cdi beans to the view-scope of jsf2+ directly. that's the reason why it's only available for jsf2+ whereas the other scopes of codi can be used with jsf1.2 as well as jsf2+. however, besides the basic concept of the view-scope, the default implementation has also some disadvantages (like losing the state in case of a browser-refresh, if there is no form with input components). if you haven't faced such issues, you might skip this blog entry. as mentioned before there is no standard way for jsf1.2 users to use the view-scope of jsf2+.
after several questions about it i decided to implement a codi-add-on which can be used with jsf1.2 as well as with jsf2+. due to the powerful spi of codi, the result is a simple implementation which offers additional features like grouped beans (you can manually destroy beans of the same group immediately even though you stay on the same page), optional bean events,... .
it's e.g. problematic for some use-cases that the jsf2+ implementation of the view-scope stores the beans in the component tree. so several users ask for a session based view-scope. that means the beans for a page will be stored in the session instead of the component tree. if you really need such a scope instead of the view-access-scope provided by codi, you can implement such a scope with the spi of codi + two simple classes.
approach #1
the first one is a marker annotation and the second one an observer for the PreViewConfigNavigateEvent. that's it! if you only use the type-safe navigation of codi, you are done and you annotate your bean with @View and the @ConversationScoped annotation provided by codi. as soon as a navigation to a new page is detected all conversation scoped beans annotated with @View will be destroyed.
if you don't use the type-safe navigation of codi, you can implement e.g. a custom jsf navigation handler which does the same for all navigations.
if you prefer a single annotation instead (let's call it @MyViewScoped), you can write a portable cdi extension which adds the @ConversationScoped dynamically to all beans which are annotated with @MyViewScoped.
it took longer to write this blog entry, than implementing this mechanism :)
or
approach #2
the result of this approach is the same like approach #1. the advantage is that you don't have to care about the navigation and the disadvantage is that you have to extend a default implementation.
if you are ok with extending the default implementation (with weld you have to #veto the default implementation instead of using @Specializes), you can override the default implementation of #createConversation (a method which is part of the spi of codi). if you just implement the interface, you would override everything and you would deactivate all codi scopes. ok - so let's add a new scope with the same marker annotation and a ConversationFactory instead of the observer:
this implementation is compatible with all jsf concepts which are supported by codi!
approach #2.1
this approach is the same like #2 but instead of implementing it on our own, we can just use the @ViewConversationScoped provided by the enhanced-conversations add-on for codi:
after several questions about it i decided to implement a codi-add-on which can be used with jsf1.2 as well as with jsf2+. due to the powerful spi of codi, the result is a simple implementation which offers additional features like grouped beans (you can manually destroy beans of the same group immediately even though you stay on the same page), optional bean events,... .
it's e.g. problematic for some use-cases that the jsf2+ implementation of the view-scope stores the beans in the component tree. so several users ask for a session based view-scope. that means the beans for a page will be stored in the session instead of the component tree. if you really need such a scope instead of the view-access-scope provided by codi, you can implement such a scope with the spi of codi + two simple classes.
approach #1
the first one is a marker annotation and the second one an observer for the PreViewConfigNavigateEvent. that's it! if you only use the type-safe navigation of codi, you are done and you annotate your bean with @View and the @ConversationScoped annotation provided by codi. as soon as a navigation to a new page is detected all conversation scoped beans annotated with @View will be destroyed.
if you don't use the type-safe navigation of codi, you can implement e.g. a custom jsf navigation handler which does the same for all navigations.
if you prefer a single annotation instead (let's call it @MyViewScoped), you can write a portable cdi extension which adds the @ConversationScoped dynamically to all beans which are annotated with @MyViewScoped.
it took longer to write this blog entry, than implementing this mechanism :)
or
approach #2
the result of this approach is the same like approach #1. the advantage is that you don't have to care about the navigation and the disadvantage is that you have to extend a default implementation.
if you are ok with extending the default implementation (with weld you have to #veto the default implementation instead of using @Specializes), you can override the default implementation of #createConversation (a method which is part of the spi of codi). if you just implement the interface, you would override everything and you would deactivate all codi scopes. ok - so let's add a new scope with the same marker annotation and a ConversationFactory instead of the observer:
this implementation is compatible with all jsf concepts which are supported by codi!
approach #2.1
this approach is the same like #2 but instead of implementing it on our own, we can just use the @ViewConversationScoped provided by the enhanced-conversations add-on for codi:
Thursday, May 19, 2011
Saturday, May 14, 2011
6th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 6th release of Apache MyFaces Extensions CDI (aka CODI).
Friday, April 15, 2011
Thursday, April 7, 2011
5th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 5th release of Apache MyFaces Extensions CDI (aka CODI).
Tuesday, March 29, 2011
[benchmark] request scope - owb vs weld vs spring
after some performance improvements (see OWB-557) i did a simple benchmark in order to compare the request-scope of owb, weld and spring3 (with ScopedProxyMode.TARGET_CLASS). as you know the results depend on a lot of parameters. anyway, the following chart should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: ~0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average.
the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations.
note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.
the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations.
note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.
[benchmark] myfaces codi scopes - codi vs orchestra
i did a simple benchmark in order to compare codi (+ owb 1.1) and the scopes of orchestra (without persistence interceptor). as you know the results depend on a lot of parameters. anyway, the following chart should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: ~0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average.
the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations.
note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.
the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations.
note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.
Saturday, March 26, 2011
[benchmark] myfaces codi scopes - OWB vs Weld
i did a simple benchmark in order to check if we have to optimize owb even more. therefore, i also compared it with the performance of weld. as you know the results depend on a lot of parameters. anyway, the following chart should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: ~0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average. due to the quite slow initialization in weld (the result would be ~3,8 ms in case of the request scope), so i had to execute the benchmark ~3 times before the result got stable (to keep it fair i did the same with owb even though the differences are not that high). the 3 runs are those runs after the numbers had been stabilized.
the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations of both cdi implementations.
this benchmark uses the weld version which is bundled with glassfish 3.1:
this benchmark uses the (currently) latest snapshot of weld (downloaded from the snapshot repository):
note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.
the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations of both cdi implementations.
this benchmark uses the weld version which is bundled with glassfish 3.1:
this benchmark uses the (currently) latest snapshot of weld (downloaded from the snapshot repository):
note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.
Thursday, March 17, 2011
apache myfaces pmc chair
now it's official - i'm the new pmc chair of myfaces.
i'll try to continue the great work of the previous chairs!
furthermore, i would like to thank matthias for being such a great chair!
i wish you all the best for your new job!
in my first blog-post as new pmc chair i would like to mention:
everybody is welcome to join our awesome community!
esp. those guys who congratulated me directly because they haven't subscribed one of our lists. ;)
you can also follow us (not only me) via:
i'll try to continue the great work of the previous chairs!
furthermore, i would like to thank matthias for being such a great chair!
i wish you all the best for your new job!
in my first blog-post as new pmc chair i would like to mention:
everybody is welcome to join our awesome community!
esp. those guys who congratulated me directly because they haven't subscribed one of our lists. ;)
you can also follow us (not only me) via:
Monday, March 14, 2011
[benchmark] myfaces codi scopes
after some performance improvements in owb (thx to mark!) and codi i created a benchmark for the upcoming versions (owb 1.1 and codi 0.9.4). as you know the results depend on a lot of parameters. anyway, the following chart should give you a basic impression about the performance of the myfaces scopes. on my system i can reproduce the results (tolerance: ~0,5 ms in the benchmark with security-manager). the benchmark invokes a method of a scoped bean via an el-expression 1000 times (i've used the el-ri). the benchmark was started 3 times and the chart shows the rounded average.
with a security-manager:
without a security-manager:
hint: this benchmark isn't comparable with the result(s) of the first benchmark back in 2010 because the test-system has more resources now.
furthermore, i compared the result with spring 3 and orchestra (tolerance: ~0,5 ms).
with a security-manager:
without a security-manager:
hint: this benchmark isn't comparable with the result(s) of the first benchmark back in 2010 because the test-system has more resources now.
furthermore, i compared the result with spring 3 and orchestra (tolerance: ~0,5 ms).
Sunday, March 6, 2011
4th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 4th release of Apache MyFaces Extensions CDI (aka CODI).
Saturday, February 26, 2011
codi examples with myfaces stylesheet
there are several examples for myfaces codi in the myfaces-repository. most of them are just dev examples esp. for an easier communication between members of the dev team. users might be confused because they don't know the intention of the details. therefore, i started with the first hello-world example which will be shipped with the next release. currently the example shows some simple use-cases. you will see further examples in the near future. all examples (which are available in the myfaces-repository) with the official myfaces-stylesheet might be interesting for users.
screenshot of the first example:
screenshot of the first example:
Sunday, February 20, 2011
Thursday, February 3, 2011
codi meets the cloud
thx to matthias we have a first demo based on apache technologies which is deployed to a cloud infrastructure. as you can see the demo also includes myfaces codi!
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!
Sunday, January 16, 2011
3rd release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 3rd release of Apache MyFaces Extensions CDI (aka CODI).
Friday, December 10, 2010
2nd release of myfaces-extensions-cdi
2nd release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 2nd release of Apache MyFaces Extensions CDI (aka CODI).
The Apache MyFaces team is pleased to announce the 2nd release of Apache MyFaces Extensions CDI (aka CODI).
Sunday, November 28, 2010
myfaces extval release news r3 -> r4
these slides give a short overview of the most important new features of the 4th release of myfaces extval.
Saturday, November 27, 2010
4th release of myfaces-extensions-validator
The Apache MyFaces team is pleased to announce the 4th release of Apache MyFaces Extensions Validator (aka ExtVal).
Monday, November 15, 2010
Sunday, November 14, 2010
1st release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 1st release of Apache MyFaces Extensions CDI (aka CODI).
Thursday, November 11, 2010
[infra] myfaces extensions meet dvcs
it's getting easier for the community to contribute to myfaces-extensions *!
now we have official git mirrors:
and
as well as inofficial mercurial mirrors (hg isn't supported by the asf):
and
in case of myfaces-extensions * the mercurial repositories provide an additional feature. early adaptors can request an inofficial (external) milestone at any time. it's easier to handle issues compared to nightly builds.
dvcs like mercurial and git allow easy forking of repositories and experimenting with new features. with features like squash it's very easy to donate the result of your feature-branch!
so let's get started: fork -> experiment -> donate (your patch)!
Saturday, October 23, 2010
ubuntu 10.10
usually i don't blog about operating systems.
however, have you thought linux or esp. ubuntu doesn't look awesome?
if you invest about 2 hours to adjust the default theme, ui animations (of compiz), a custom dock (avant window navigator) and some other fine-tunings, you get a really nice user-experience!
one picture doesn't show the whole story, but here is a basic impression:
however, have you thought linux or esp. ubuntu doesn't look awesome?
if you invest about 2 hours to adjust the default theme, ui animations (of compiz), a custom dock (avant window navigator) and some other fine-tunings, you get a really nice user-experience!
one picture doesn't show the whole story, but here is a basic impression:
Friday, September 24, 2010
[javaone] myfaces extval and myfaces codi meet j1 2010
that's nice! matthias and ali presented myfaces at j1 2010. one part of the presentation was myfaces extval (e.g. [1] [2]) and a second part was about myfaces codi (e.g. [1] [2]). it was the first preview of myfaces codi at a java conference.
Thursday, September 23, 2010
[preview] codi meets cwiki.apache.org
it's really nice. myfaces codi as well as the documentation for it is still in progress and i see a lot of positive response out there.
some days ago i started with the documentation (it's still in progress) and google analytics shows that people are already reading it!
some days ago i started with the documentation (it's still in progress) and google analytics shows that people are already reading it!
os890 meets bitbucket
it's planned to continue with the repository at https://bitbucket.org/os890. it's easier for users to fork it. well - mercurial might be a barrier for some of you, however, it's really easy and nice (a nice mercurial intro). you can easily fork an existing repository and it's easier to merge in your enhancements. so we hopefully get rid of all the hidden forks and the pain of manual merges.
Monday, August 2, 2010
[benchmark] myfaces extval
after some performance improvements (see EXTVAL-80) i created a benchmark for the bean-validation (jsr-303) integration module for extval r3 and r4m3. as you know the results depend on a lot of parameters. anyway, the following chart should give you a first impression about the performance improvements. on my system i can reproduce the results (tolerance: ~2 ms). the benchmark invokes the validation for a component 1000 times. the value-binding points to a property which hosts one bv-constraint. the benchmark was started 3 times and the chart shows the rounded average of 10 validations (just because it's more interesting than the validation of 1000 ui components).
furthermore, the chart shows the impact of 2 optimizations described in a first draft for advanced extval/bv topics. optimization #1 just deregisters the validation interceptor which allows to create any kind of custom annotations for jsf validation (it's the base implementation of the property-validation module). optimization #2 deregisters the implementation of EXTVAL-83 - one of the new features available in r4+.
furthermore, the chart shows the impact of 2 optimizations described in a first draft for advanced extval/bv topics. optimization #1 just deregisters the validation interceptor which allows to create any kind of custom annotations for jsf validation (it's the base implementation of the property-validation module). optimization #2 deregisters the implementation of EXTVAL-83 - one of the new features available in r4+.
Monday, July 26, 2010
[benchmark] myfaces codi scopes
after some performance improvements in owb (see #966927 and esp. OWB-425) i created a benchmark for the new (pre alpha-1) myfaces codi scopes (@ConversationScoped != std. CDI conversations, @ViewAccessScoped and @WindowScoped). as you know the results depend on a lot of parameters. anyway, the following chart should give you a first impression about the performance of the myfaces scopes. furthermore, it's a preview concerning the improved performance of the el-resolver of owb. on my system i can reproduce the results (tolerance: ~2 ms). the benchmark invokes a method of a scoped bean via an el-expression 1000 times (i've used the el-ri). the benchmark was started 3 times and the chart shows the rounded average.
(maybe you are wondering why std. cdi conversations provide a better performance than the codi conversations. the simple answer is: std. cdi conversations just don't provide that much features... they are more like a per window session with some annoying drawbacks.)
(maybe you are wondering why std. cdi conversations provide a better performance than the codi conversations. the simple answer is: std. cdi conversations just don't provide that much features... they are more like a per window session with some annoying drawbacks.)
Saturday, July 3, 2010
[preview] early preview of the 4th release
the current milestone already offers a lot of the features which will be available in the 4th release. the 4th release will introduce new features for the validation modules as well as some performance improvements and an improved jsf 2 support. until the next release, we will also improve the documentation. so it will take some time to get out the next version of extval. anyway, the current milestone is already quite stable and used in several applications out there.
once again extval (1.x and 2.x) offers features which aren't available in other validation frameworks for jsf. e.g. extval allows to use @Valid in combination with jsf. beyond the features of bean-validation (jsr 303) itself extval provides the possibility to use an annotation called @ConstraintSource. it allows e.g. to annotate dto's with this new annotation(s) in order to specify the source which hosts the constraints. so you don't have to repeat all the constraints in classes like dto's.
once again extval (1.x and 2.x) offers features which aren't available in other validation frameworks for jsf. e.g. extval allows to use @Valid in combination with jsf. beyond the features of bean-validation (jsr 303) itself extval provides the possibility to use an annotation called @ConstraintSource. it allows e.g. to annotate dto's with this new annotation(s) in order to specify the source which hosts the constraints. so you don't have to repeat all the constraints in classes like dto's.
Tuesday, June 1, 2010
multi-field form validation with jsr 303
there is a new extval add-on (new location). this first draft of the add-on allows so called multi-field (or cross-field) validation based on jsr 303.
within the page you just use normal input components - e.g.:
furthermore, you annotate e.g. your page bean with @FormValidator. the annotation also allows to specify a specific view-id, conditions as well as validation groups. to implement a more fine-grained multi-validation it's possible to provide multiple form-bean classes. to implement more complex combinations it's possible to use @FormValidator.List(...). (as alternative you can also us the provided java api to map your bean(s) to a form-validator. so if you don't like to use the annotation you can provide a separated mapping.)
usage of @FormValidator:
in the page you see the id's of the different components. we have to use these id's as field-names (or setter-methods) in the form-validator.
the following figure shows a possible form-validator for this example:
as soon as the form-validator-bean is annotated with @Form, the validator is called by the bean-validation engine. so the violation message gets processed by the bean-validation engine and the final message is added as global faces-message.
(if you would like to use the current ConstraintValidatorContext of bean-validation, you can directly implement the FormBean interface instead of extending ViolationMessageAwareFormBean.)
if you use e.g. input components within a data-table, you can use 'add'-methods instead of the setter-method. in the form-validator you can use a data-structure like a list per column. as soon as the validation process starts (at the end of the validation phase) the form-validator contains all values (in case of input components in tables the validator is aware of all table values). so it's possible to implement any multi-field validation you can imagine (in case of input components in tables also validations per row as well as across rows).
additional features:
it's possible to map the form-bean-class to specific view-id's, to provide conditions as well as validation groups.
within the page you just use normal input components - e.g.:
furthermore, you annotate e.g. your page bean with @FormValidator. the annotation also allows to specify a specific view-id, conditions as well as validation groups. to implement a more fine-grained multi-validation it's possible to provide multiple form-bean classes. to implement more complex combinations it's possible to use @FormValidator.List(...). (as alternative you can also us the provided java api to map your bean(s) to a form-validator. so if you don't like to use the annotation you can provide a separated mapping.)
usage of @FormValidator:
in the page you see the id's of the different components. we have to use these id's as field-names (or setter-methods) in the form-validator.
the following figure shows a possible form-validator for this example:
as soon as the form-validator-bean is annotated with @Form, the validator is called by the bean-validation engine. so the violation message gets processed by the bean-validation engine and the final message is added as global faces-message.
(if you would like to use the current ConstraintValidatorContext of bean-validation, you can directly implement the FormBean interface instead of extending ViolationMessageAwareFormBean.)
if you use e.g. input components within a data-table, you can use 'add'-methods instead of the setter-method. in the form-validator you can use a data-structure like a list per column. as soon as the validation process starts (at the end of the validation phase) the form-validator contains all values (in case of input components in tables the validator is aware of all table values). so it's possible to implement any multi-field validation you can imagine (in case of input components in tables also validations per row as well as across rows).
additional features:
it's possible to map the form-bean-class to specific view-id's, to provide conditions as well as validation groups.
Monday, May 31, 2010
[review] apache myfaces 1.2 web-application development
i reviewed a book about myfaces.
here you can read it.
here you can read it.
Friday, April 9, 2010
extval meets cwiki.apache.org
today i created a new cwiki-space for extval.
within the next weeks i'll move and improve the documentation of extval.
you are welcome to ask questions in order to improve the content!
within the next weeks i'll move and improve the documentation of extval.
you are welcome to ask questions in order to improve the content!
Saturday, March 27, 2010
creating feeds with jsf is easy now
about one month ago i proposed a simple annotation based approach for creating feeds easily (e.g. based on jpa entities). now a first draft is available here. it's great that it's available quite fast after the initial brainstorming!
Friday, March 26, 2010
extval meets paper
bart kummel wrote a book about the myfaces project.
i'll publish a review about the book quite soon.
it also contains an intro of myfaces extval!
it's really great that the extval chapter is the free sample chapter.
so enjoy reading it!
i'll publish a review about the book quite soon.
it also contains an intro of myfaces extval!
it's really great that the extval chapter is the free sample chapter.
so enjoy reading it!
Thursday, March 25, 2010
extval r3 in action - fullstack 2010
this fullstack demo illustrates some use-cases of using jsf 1.2, spring 3, myfaces extval r3, bean-validation,... in case of myfaces extval the demo also shows how to keep all layers outside the view-layer independent of extval classes. so you see how to re-use existing (extval independent) constraints for ui validation in a typesafe way.
furthermore, the demo shows how to integrate bean-validation (jsr 303) in jsf 1.x applications.
further details are available in the (short) readme file.
here is the list of the used technologies:
- jsf 1.2 (+ facelets)
- myfaces orchestra
- myfaces extval r3 (+ some add-ons)
- bean-validation (jsr 303)
- spring 3
- jpa 1.0
- primefaces
furthermore, the demo shows how to integrate bean-validation (jsr 303) in jsf 1.x applications.
further details are available in the (short) readme file.
here is the list of the used technologies:
- jsf 1.2 (+ facelets)
- myfaces orchestra
- myfaces extval r3 (+ some add-ons)
- bean-validation (jsr 303)
- spring 3
- jpa 1.0
- primefaces
Wednesday, March 24, 2010
myfaces extval release news r2 -> r3
these slides give a short overview of the most important features of the 3rd release of myfaces extval.
3rd release of myfaces-extensions-validator
the apache myfaces team is pleased to announce a new release of myfaces-extensions-validator!
the release contains several improvements and new features as well as a new validation module for using bean-validation (jsr 303) with jsf 1.x and 2.0.
(compared to the standard integration of bv in jsf 2.0 extval 2.0.3 offers more advanced and typesafe features.)
released versions:
extval 1.1.3 (for jsf 1.1.x)
extval 1.2.3 (for jsf 1.2.x)
extval 2.0.3 (for jsf 2.0.x)
the release contains several improvements and new features as well as a new validation module for using bean-validation (jsr 303) with jsf 1.x and 2.0.
(compared to the standard integration of bv in jsf 2.0 extval 2.0.3 offers more advanced and typesafe features.)
released versions:
extval 1.1.3 (for jsf 1.1.x)
extval 1.2.3 (for jsf 1.2.x)
extval 2.0.3 (for jsf 2.0.x)
Friday, March 5, 2010
[add-on] spring 3 managed constraint validation for extval
there is a new add-on which allows using typesafe spring 3 dependency injection for constraint validators. so it's possible to inject other beans (e.g. a validation service, a repository,...) into a constraint validator.
it's similar to the native extval di support. the main difference is that the add-on offers a typesafe alternative. you just have to extend the default-implementation (listed at @Constraint(validatedBy = {...})) and provide the custom implementation as spring bean.
it's similar to the native extval di support. the main difference is that the add-on offers a typesafe alternative. you just have to extend the default-implementation (listed at @Constraint(validatedBy = {...})) and provide the custom implementation as spring bean.
Saturday, February 20, 2010
welcome myfaces-codi
it's official - myfaces is going to host a new extensions module.
besides myfaces-extval and myfaces-extscript we now start myfaces-extcdi which is also known as myfaces-codi (context and dependency injection)
(pronounced like the name).
myfaces-codi will provide portable CDI (Contexts and Dependency Injection) extensions which are useful for JSF applications.
we have already collected some nice ideas.
however, everyone is welcome to donate further ideas, implementations,...
so let's welcome codi!
besides myfaces-extval and myfaces-extscript we now start myfaces-extcdi which is also known as myfaces-codi (context and dependency injection)
(pronounced like the name).
myfaces-codi will provide portable CDI (Contexts and Dependency Injection) extensions which are useful for JSF applications.
we have already collected some nice ideas.
however, everyone is welcome to donate further ideas, implementations,...
so let's welcome codi!
Tuesday, February 9, 2010
myfaces-extval @ jsfdays 2010
last year i presented extval at my trinidad workshop (esp. the integration and special features in combination with trinidad).
this year i'll give a jsf fullstack workshop. one part of the workshop will show how to integrate bean-validation in a jsf 1.x application via myfaces extval as well as the migration path for upgrading to jsf 2.0.
the rest of the workshop will be interesting as well (for sure)!
if you are interested - just register here!
this year i'll give a jsf fullstack workshop. one part of the workshop will show how to integrate bean-validation in a jsf 1.x application via myfaces extval as well as the migration path for upgrading to jsf 2.0.
the rest of the workshop will be interesting as well (for sure)!
if you are interested - just register here!
Thursday, December 17, 2009
myfaces extval @ jsfcentral
the next part of the article series is available at jsfcentral.
thx to the jsfcentral team!
thx to the jsfcentral team!
metadata based validation @ejug seminar (german)
the slides of the metadata based validation presentation at the ejug seminar in linz.
Subscribe to:
Comments (Atom)