[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[
https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-564:
Attachment: DELTASPIKE-564_first_draft.patch
first draft (without a special jsf-component)
usage:
#1 configure DoubleSubmitPreventionFilter in the web.xml
#2 add the following component to a form
{code}
h:inputHidden id=#{dsCurrentRequestToken.key}
value=#{dsCurrentRequestToken.value}/
{code}
or use
{code}
h:inputHidden id=myPrefix_#{dsCurrentRequestToken.key}
value=#{dsCurrentRequestToken.value}/
{code}
if there are multiple forms on the same page which use prependId=false
optional double submit prevention
-
Key: DELTASPIKE-564
URL: https://issues.apache.org/jira/browse/DELTASPIKE-564
Project: DeltaSpike
Issue Type: New Feature
Components: JSF-Module, Servlet-Module
Affects Versions: 0.6
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Fix For: 0.7
Attachments: DELTASPIKE-564_first_draft.patch
duplicated post-requests shouldn't get processed
#1 post requests need to get synchronized (per session)
#2 post requests need to consume an existing request-token
#3 re-render the page in case of a duplicated post-requests (+ skip full
processing)
#4 in case of jsf: reset the previous request-token(s) per window in case of
a get-request (because a new page isn't aware of them)
#5 reset the request-tokens in case of a duplicated post-requests per
window, since the page will get re-rendered with a new token
#6 don't create request-tokens in case of resource-requests
#7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the
jsf-js implementation has to process them sequentially)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-563) Deactivatable support for PhaseListener
[ https://issues.apache.org/jira/browse/DELTASPIKE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-563: Attachment: (was: DELTASPIKE-563.patch) Deactivatable support for PhaseListener --- Key: DELTASPIKE-563 URL: https://issues.apache.org/jira/browse/DELTASPIKE-563 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 a deactivated PhaseListener should never get added to the list of phase-listeners -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: cdictrl build/test structure
Yes, I bumped into this through DELTASPIKE-558, and that made me think how CI could be made simpler/faster. A separate profile would work well and would be an appropriate solution, IMHO, exactly for the reasons you mention -- that cdictrl is something special. More simply, it would be nice to have a switch (profile, property, @Category,...) to exclude all-things-SE (incl. cdictrl, test-control) for container integration testing. Though not the most elegant, a possible solution would be a property-absence-activated profile like incontainer added in root pom and modules/pom, which would contain the modules that are not to be tested in container integration... ( activationpropertyname!incontainer/name/property/activation). On 7.4.2014 23:08, Mark Struberg wrote: Hi Ron! The reason why cdictrl don't inherit from parent is that it is essentially a different beast. It is not an extension FOR containers, but is IS the part who boots the containers. Means it also has totally different dependencies, etc. That is also the reason why it is not part of the 'modules' but an own part. A big part of the parent pom is e.g. the switching of containers. But the cdictrl each run with exactly their own containers. We could exclude the cdictrl module if you activate other containers. Or we might introduce a profile to be able to completely skip the cdictrl tree. I guess you are interested in making CI faster? LieGrue, strub On Thursday, 3 April 2014, 17:06, Ron Smeral rsme...@redhat.com wrote: Hi, I'm pretty sure something similar was discussed already, but anyway: the cdictrl module is kind of strange with regard to the build structure. It doesn't inherit from parent-code, but it is a module of deltaspike-project (the root). This results in the fact, that cdictrl gets always tested, even in real-container profiles (e.g. wildfly-managed) which doesn't make sense. And the ContainerCtrlTckTest can't be categorised as SeCategory (which it should be), because it doesn't depend on test-utils. This unfortunate project structure is especially problematic with regard to issues like https://issues.apache.org/jira/browse/DELTASPIKE-558, where the cdictrl tests hang and thus block the testsuite, without any clean way of skipping it. Any chance of a little project restructuring? Ron -- Ron Smeral JBoss Quality Engineer Brno -- Ron Smeral JBoss Quality Engineer Brno
Extended Persistent Context
Hello everyone, I would like to know if you think about create an option that exists in seam 2, that I can open the entitymanager for many requests?
Re: Extended Persistent Context
I am also curious about best practice for this (right now) and perhaps in the future. The thing is the Deltaspike /CDI style is very nice to work with and it would be a preferred API for me. On 8 April 2014 13:33, Rafael Meireles rafaelmeire...@gmail.com wrote: Hello everyone, I would like to know if you think about create an option that exists in seam 2, that I can open the entitymanager for many requests?
Re: Extended Persistent Context
hi, please have a look at [1]. regards, gerhard [1] https://cwiki.apache.org/confluence/display/EXTCDI/JPA+Usage#JPAUsage-ExtendedPersistenceContexts 2014-04-08 13:37 GMT+02:00 Karl Kildén karl.kil...@gmail.com: I am also curious about best practice for this (right now) and perhaps in the future. The thing is the Deltaspike /CDI style is very nice to work with and it would be a preferred API for me. On 8 April 2014 13:33, Rafael Meireles rafaelmeire...@gmail.com wrote: Hello everyone, I would like to know if you think about create an option that exists in seam 2, that I can open the entitymanager for many requests?
[jira] [Commented] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963039#comment-13963039 ] Gerhard Petracek commented on DELTASPIKE-564: - i'll also prototype a version specific to jsf optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module, Servlet-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 Attachments: DELTASPIKE-564_first_draft.patch duplicated post-requests shouldn't get processed #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) -- This message was sent by Atlassian JIRA (v6.2#6252)
Site build
Is there a way to build/run Deltaspike site locally ? Should this be documented anywhere ( http://deltaspike.apache.org/community.html / http://deltaspike.apache.org/build.html ) for those (as me) who wants to contribute with documentation ? Thanks -- Rafael Benevides | Senior Software Engineer JBoss Developer M: +55-61-9269-6576 Better technology. Faster innovation. Powered by community collaboration. See how it works at www.redhat.com
[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-564: Attachment: DELTASPIKE-564_jsf_only_-_first_draft.patch optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module, Servlet-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 Attachments: DELTASPIKE-564_first_draft.patch, DELTASPIKE-564_jsf_only_-_first_draft.patch duplicated post-requests shouldn't get processed #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-564: Component/s: (was: Servlet-Module) optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 Attachments: DELTASPIKE-564_jsf_only_-_first_draft.patch duplicated post-requests shouldn't get processed #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-564: Attachment: (was: DELTASPIKE-564_first_draft.patch) optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 Attachments: DELTASPIKE-564_jsf_only_-_first_draft.patch duplicated post-requests shouldn't get processed #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-564: Attachment: (was: DELTASPIKE-564_jsf_only_-_first_draft.patch) optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 duplicated post-requests shouldn't get processed #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-564: Description: duplicated post-requests shouldn't get processed without jsf: #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) with jsf2+ (and ds): #1 ignore jsf-ajax requests since they have to be queued according to the spec. #2 ignore get-requests since they shouldn't change the state (we couldn't support them at all) #3 browser-window-handling is done implicitly (window-scoped bean) - only the handling of post-requests is needed was: duplicated post-requests shouldn't get processed #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 Attachments: DELTASPIKE-564.patch duplicated post-requests shouldn't get processed without jsf: #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) with jsf2+ (and ds): #1 ignore jsf-ajax requests since they have to be queued according to the spec. #2 ignore get-requests since they shouldn't change the state (we couldn't support them at all) #3 browser-window-handling is done implicitly (window-scoped bean) - only the handling of post-requests is needed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-564: Attachment: DELTASPIKE-564.patch optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 Attachments: DELTASPIKE-564.patch duplicated post-requests shouldn't get processed without jsf: #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) with jsf2+ (and ds): #1 ignore jsf-ajax requests since they have to be queued according to the spec. #2 ignore get-requests since they shouldn't change the state (we couldn't support them at all) #3 browser-window-handling is done implicitly (window-scoped bean) - only the handling of post-requests is needed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-564: Attachment: (was: DELTASPIKE-564.patch) optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 duplicated post-requests shouldn't get processed without jsf: #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) with jsf2+ (and ds): #1 ignore jsf-ajax requests since they have to be queued according to the spec. #2 ignore get-requests since they shouldn't change the state (we couldn't support them at all) #3 browser-window-handling is done implicitly (window-scoped bean) - only the handling of post-requests is needed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-564) optional double submit prevention
[ https://issues.apache.org/jira/browse/DELTASPIKE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-564: Attachment: DELTASPIKE-564.patch optional double submit prevention - Key: DELTASPIKE-564 URL: https://issues.apache.org/jira/browse/DELTASPIKE-564 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.7 Attachments: DELTASPIKE-564.patch duplicated post-requests shouldn't get processed without jsf: #1 post requests need to get synchronized (per session) #2 post requests need to consume an existing request-token #3 re-render the page in case of a duplicated post-requests (+ skip full processing) #4 in case of jsf: reset the previous request-token(s) per window in case of a get-request (because a new page isn't aware of them) #5 reset the request-tokens in case of a duplicated post-requests per window, since the page will get re-rendered with a new token #6 don't create request-tokens in case of resource-requests #7 ignore duplicated jsf-ajax requests (they shouldn't happen, since the jsf-js implementation has to process them sequentially) with jsf2+ (and ds): #1 ignore jsf-ajax requests since they have to be queued according to the spec. #2 ignore get-requests since they shouldn't change the state (we couldn't support them at all) #3 browser-window-handling is done implicitly (window-scoped bean) - only the handling of post-requests is needed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-544) api for a fine-grained control of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963410#comment-13963410 ] Thomas Andraschko commented on DELTASPIKE-544: -- Any idea for the new API? Currently it would be possible to inject ViewAccessBeanHolder and call #destroBeans api for a fine-grained control of @ViewAccessScoped beans - Key: DELTASPIKE-544 URL: https://issues.apache.org/jira/browse/DELTASPIKE-544 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 0.7 in codi there is an unified approach for it (Conversation#close). see e.g.: http://s.apache.org/sF since the scope-implementations are splitted, we need a new api for it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-544) api for a fine-grained control of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963410#comment-13963410 ] Thomas Andraschko edited comment on DELTASPIKE-544 at 4/8/14 8:38 PM: -- Any idea for the new API? Currently it would be possible to inject ViewAccessBeanHolder and call #destroyBeans was (Author: tandraschko): Any idea for the new API? Currently it would be possible to inject ViewAccessBeanHolder and call #destroBeans api for a fine-grained control of @ViewAccessScoped beans - Key: DELTASPIKE-544 URL: https://issues.apache.org/jira/browse/DELTASPIKE-544 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 0.7 in codi there is an unified approach for it (Conversation#close). see e.g.: http://s.apache.org/sF since the scope-implementations are splitted, we need a new api for it. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Site build
I believe that the links below may help you. :-) Build process: http://www.apache.org/dev/cmsref#faq-build-tools Build scripts: https://svn.apache.org/repos/infra/websites/cms/build/ DeltaSpike Site: https://svn.apache.org/repos/asf/deltaspike/site/trunk/ Regards, Bruno 2014-04-08 14:19 GMT-03:00 Rafael Benevides benevi...@redhat.com: Is there a way to build/run Deltaspike site locally ? Should this be documented anywhere ( http://deltaspike.apache.org/community.html / http://deltaspike.apache.org/build.html ) for those (as me) who wants to contribute with documentation ? Thanks -- *Rafael Benevides | Senior Software Engineer* JBoss Developer M: +55-61-9269-6576 [image: Red Hat] Better technology. Faster innovation. Powered by community collaboration. See how it works at www.redhat.com [image: LinkedIn] http://www.linkedin.com/company/3258288 [image: Youtube] https://www.youtube.com/redhatlatam
Re: Extended Persistent Context
I looked this link when I started my project, but this solution doesn't work. This solution just create a entity manager with the conversational scope and the entity manager stay serialized, but with this solution, the entity manager doesn't stay open during the conversation. About the best practice of the extended persistence context, here we have a project in production with seam 2, JSF 1.2, EJB 3 and JPA 1, running in a JBoss Application Server and this system is used by many people in the state of Ceará, Brazil. We have around 300 - 400 users concurrent and the Application Servers are in Cluster. Can you explain better, this: the Deltaspike /CDI style is very nice to work 2014-04-08 9:01 GMT-03:00 Gerhard Petracek gerhard.petra...@gmail.com: hi, please have a look at [1]. regards, gerhard [1] https://cwiki.apache.org/confluence/display/EXTCDI/JPA+Usage#JPAUsage-ExtendedPersistenceContexts 2014-04-08 13:37 GMT+02:00 Karl Kildén karl.kil...@gmail.com: I am also curious about best practice for this (right now) and perhaps in the future. The thing is the Deltaspike /CDI style is very nice to work with and it would be a preferred API for me. On 8 April 2014 13:33, Rafael Meireles rafaelmeire...@gmail.com wrote: Hello everyone, I would like to know if you think about create an option that exists in seam 2, that I can open the entitymanager for many requests? -- Atenciosamente, Rafael Meireles Caetano Arquiteto Java EE Sefaz - CE Fone: +55 85 8811-1806
Re: Extended Persistent Context
hi rafael, please provide a demo-application which illustrates the issue. back then it worked and since your own disposer calls #close, it should still work. regards, gerhard 2014-04-09 2:04 GMT+02:00 Rafael Meireles rafaelmeire...@gmail.com: I looked this link when I started my project, but this solution doesn't work. This solution just create a entity manager with the conversational scope and the entity manager stay serialized, but with this solution, the entity manager doesn't stay open during the conversation. About the best practice of the extended persistence context, here we have a project in production with seam 2, JSF 1.2, EJB 3 and JPA 1, running in a JBoss Application Server and this system is used by many people in the state of Ceará, Brazil. We have around 300 - 400 users concurrent and the Application Servers are in Cluster. Can you explain better, this: the Deltaspike /CDI style is very nice to work 2014-04-08 9:01 GMT-03:00 Gerhard Petracek gerhard.petra...@gmail.com: hi, please have a look at [1]. regards, gerhard [1] https://cwiki.apache.org/confluence/display/EXTCDI/JPA+Usage#JPAUsage-ExtendedPersistenceContexts 2014-04-08 13:37 GMT+02:00 Karl Kildén karl.kil...@gmail.com: I am also curious about best practice for this (right now) and perhaps in the future. The thing is the Deltaspike /CDI style is very nice to work with and it would be a preferred API for me. On 8 April 2014 13:33, Rafael Meireles rafaelmeire...@gmail.com wrote: Hello everyone, I would like to know if you think about create an option that exists in seam 2, that I can open the entitymanager for many requests? -- Atenciosamente, Rafael Meireles Caetano Arquiteto Java EE Sefaz - CE Fone: +55 85 8811-1806
