[
https://jira.nuxeo.com/browse/NXP-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Guillaume updated NXP-6677:
-----------------------------------
Description:
Since we upgraded to JBoss 5, ejb3 support has become a real pain:
- deployment is very slow and eats a lot of memory
- a lot of bugs that we had to walkaround
- application is about twice slower under load when using EJB3
In parallel, we don't really need EJB3 support anymore:
- remoting is done via content-automation
- in specific cases VCS Client/Server mode could be used
- new shell relies on automation
- transaction demarcation is completly managed by Nuxeo
This means we can get ridd of the EJB3 facades:
- remove bundles from default distributions
- double performances under JBoss 5
If needed, we could maintains a compat assembly containing the facacdes?
Associated work includes:
- remove the facades
- be sure to correctly integrate the JCA pooling without using
DocumentManagerBean
- check behavior for Rollback in case of runtime errors
- check JPA integraton (i.e. try to get the JPA context from the container now
that we can not inject it via EJBContext)
was:
Since we upgraded to JBoss 5, ejb3 support has become a real pain :
- deployment is very slow and eats a lot of memory
- a lot of bugs that we had to walkaround
- application is about twice slower under load when using EJB3
In parallele, we don't really need EJB3 support anymore :
- remoting is done via content-automation
- in specific cases VCS Client/Server mode could be used
- new shell relies on automation
- transaction demarcation is completly managed by Nuxeo
This means we can get ridd of the EJB3 facades :
- remove bundles from default distributions
- double performances under JBoss 5
If needed, we could maintains a compat assembly containing the facacdes ?
Associated work includes :
- remove the facades
- be sure to correctly integrate the JCA pooling without using
DocumentManagerBean
- check behavior for Rollback in case of runtime errors
- check JPA integraton (i.e. try to get the JPA context from the container now
that we can not inject it via EJBContext)
> Remove EJB facade from default distributions
> --------------------------------------------
>
> Key: NXP-6677
> URL: https://jira.nuxeo.com/browse/NXP-6677
> Project: Nuxeo Enterprise Platform
> Issue Type: User story
> Components: Infrastructure
> Reporter: Thierry Delprat
> Fix For: 5.4.3
>
>
> Since we upgraded to JBoss 5, ejb3 support has become a real pain:
> - deployment is very slow and eats a lot of memory
> - a lot of bugs that we had to walkaround
> - application is about twice slower under load when using EJB3
> In parallel, we don't really need EJB3 support anymore:
> - remoting is done via content-automation
> - in specific cases VCS Client/Server mode could be used
> - new shell relies on automation
> - transaction demarcation is completly managed by Nuxeo
> This means we can get ridd of the EJB3 facades:
> - remove bundles from default distributions
> - double performances under JBoss 5
> If needed, we could maintains a compat assembly containing the facacdes?
> Associated work includes:
> - remove the facades
> - be sure to correctly integrate the JCA pooling without using
> DocumentManagerBean
> - check behavior for Rollback in case of runtime errors
> - check JPA integraton (i.e. try to get the JPA context from the container
> now that we can not inject it via EJBContext)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
