[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich edited comment on WFLY-7075 at 9/20/16 8:38 AM:
-----------------------------------------------------------------------
I have tried latest changes - all works perfectly )
I also check properties overriding:
{code:title=properties overriding}
@PersistenceContext(properties={@PersistenceProperty(name="wildfly.jpa.allowjoinedunsync", value="false")})
private EntityManager em;
{code}
it also works as expected.
was (Author: veselroger):
I have tried latest changes - all works perfectly )
I also check properties overriding - it also works as expected.
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich commented on WFLY-7075:
----------------------------------------------
I have tried latest changes - all works perfectly )
I also check properties overriding - it also works as expected.
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7150) EJB injection with indirection via web.xml is ignored
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7150?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-7150:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1377705
Bugzilla Update: Perform
> EJB injection with indirection via web.xml is ignored
> -----------------------------------------------------
>
> Key: WFLY-7150
> URL: https://issues.jboss.org/browse/WFLY-7150
> Project: WildFly
> Issue Type: Bug
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
>
> If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected.
> This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code.
> Reproducer can be found here:
> git@github.com:wfink/jboss-eap-quickstarts.git
> BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2
> SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app)
> see ejb-multi-server/README-reproducerEJB-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1793) add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1793?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet updated WFCORE-1793:
--------------------------------------
Fix Version/s: (was: 3.0.0.Alpha8)
> add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1793
> URL: https://issues.jboss.org/browse/WFCORE-1793
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced:
> {{CLI}}
> {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true)
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false)
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}])
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }{code}
> {{Server}}
> {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt
> 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt
> 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code}
> This issue does not seem to arise when the content is passed to the server by input stream index.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1793) add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1793?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reopened WFCORE-1793:
---------------------------------------
The issue was in 2 parts, looks like only the first was fixed by the PR
> add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1793
> URL: https://issues.jboss.org/browse/WFCORE-1793
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha8
>
>
> Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced:
> {{CLI}}
> {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true)
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false)
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}])
> {
> "outcome" => "failed",
> "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment",
> "rolled-back" => true
> }{code}
> {{Server}}
> {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt
> 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt
> 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code}
> This issue does not seem to arise when the content is passed to the server by input stream index.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7148) Excessive loopback connections on Windows
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7148?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-7148:
-----------------------------------
please test on 10.1.0 to verify.
also what do you mean by loopback connections? it does create as many threads, which result in file handles, but not connections, at least not on start.
> Excessive loopback connections on Windows
> -----------------------------------------
>
> Key: WFLY-7148
> URL: https://issues.jboss.org/browse/WFLY-7148
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Johan Persson
> Assignee: Jason Greene
>
> Using WildFly 8.2.0 on Windows, an excessive amount of loopback connections are established upon application server start. The amount of connections is roughly equal to io-threads*2
> <subsystem xmlns="urn:jboss:domain:io:1.1">
> <worker name="default" io-threads="1000"/>
> <buffer-pool name="default"/>
> </subsystem>
> (we are seeing ~2000 connections using io-threads=1000). The same configuration doesn't cause this issue on linux (We see 1000 I/O-threads on both windows and linux, but much fewer connections on linux).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months