[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
by kostd kostd (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
kostd kostd commented on WFLY-7075:
-----------------------------------
{quote}
in order to alleviate the risk of integrating uncommitted changes into the persistence context in the event that the transaction is later rolled back.
{quote}
after tx rollback we fully drop associated XPC and begin new one on next request(Our XPC is conversation-scoped and we simply begin new conversation). Therefore no risk for us to integrate uncommited and "rolled back" changes.
> proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> 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
>
>
> 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.
> *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, 10 months
[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-5938 to WFLY-7080:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7080 (was: JBEAP-5938)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR4)
> Creating ssl context with only required attribute cause NPE
> -----------------------------------------------------------
>
> Key: WFLY-7080
> URL: https://issues.jboss.org/browse/WFLY-7080
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {noformat}
> In log of server there is exception:
> {noformat}
> 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
> at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("server-ssl-context" => "server2")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {noformat}
> Looking into org.wildfly.security.ssl.SSLContextBuilder, one question come to my mind. Is there still possibility for user to configure equivalent of SSLContext.getInstance("Default")?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1279) [GSS] compilation of spreadsheet fails with specific condition
by Hiroko Miura (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1279?page=com.atlassian.jira.plugi... ]
Hiroko Miura updated DROOLS-1279:
---------------------------------
Description:
Reproducer is attached.with problematic spredsheet named SampleNG.xml.
Compilation of this fails with the following error.
java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0
text=Unable to Analyse Expression checktest == AAA:
[Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()]
[Near : {... checktest == AAA ....}]
because the following DRL is generated.
rule "HelloWorld_12"
when
m:Message(checktest in (AAA), status == "Message.HELLO")
...
i.e. double quotation of value ("AAA") specified in the cell is removed.
If D column does not exist like Sample.xml(also included in reproducer) or rule template of D column is modified like "status == $param " (see SampleOK.xml), this does not happen.
was:
Reproducer is attached.with problematic spredsheet named SampleNG.xml.
Compilation of this fails with the following error.
java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0
text=Unable to Analyse Expression checktest == AAA:
[Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()]
[Near : {... checktest == AAA ....}]
because the following DRL is generated.
rule "HelloWorld_12"
when
m:Message(checktest in(AAA), (checktest != "dummy") == "false")
...
i.e. double quotation of value ("AAA") specified in the cell is removed.
If D column does not exist like Sample.xml(also included in reproducer) or D column is modified like SampleOK.xml, this does not happen.
Attachment: reproducer.zip
> [GSS] compilation of spreadsheet fails with specific condition
> --------------------------------------------------------------
>
> Key: DROOLS-1279
> URL: https://issues.jboss.org/browse/DROOLS-1279
> Project: Drools
> Issue Type: Bug
> Components: build, decision tables
> Affects Versions: 6.4.0.Final
> Reporter: Hiroko Miura
> Assignee: Petr Široký
> Labels: support
> Fix For: 6.5.0.Final
>
> Attachments: reproducer.zip
>
>
> Reproducer is attached.with problematic spredsheet named SampleNG.xml.
> Compilation of this fails with the following error.
> java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0
> text=Unable to Analyse Expression checktest == AAA:
> [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()]
> [Near : {... checktest == AAA ....}]
> because the following DRL is generated.
> rule "HelloWorld_12"
> when
> m:Message(checktest in (AAA), status == "Message.HELLO")
> ...
> i.e. double quotation of value ("AAA") specified in the cell is removed.
>
> If D column does not exist like Sample.xml(also included in reproducer) or rule template of D column is modified like "status == $param " (see SampleOK.xml), this does not happen.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1279) [GSS] compilation of spreadsheet fails with specific condition
by Hiroko Miura (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1279?page=com.atlassian.jira.plugi... ]
Hiroko Miura updated DROOLS-1279:
---------------------------------
Attachment: (was: repoduser.zip)
> [GSS] compilation of spreadsheet fails with specific condition
> --------------------------------------------------------------
>
> Key: DROOLS-1279
> URL: https://issues.jboss.org/browse/DROOLS-1279
> Project: Drools
> Issue Type: Bug
> Components: build, decision tables
> Affects Versions: 6.4.0.Final
> Reporter: Hiroko Miura
> Assignee: Petr Široký
> Labels: support
> Fix For: 6.5.0.Final
>
>
> Reproducer is attached.with problematic spredsheet named SampleNG.xml.
> Compilation of this fails with the following error.
> java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0
> text=Unable to Analyse Expression checktest == AAA:
> [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()]
> [Near : {... checktest == AAA ....}]
> because the following DRL is generated.
> rule "HelloWorld_12"
> when
> m:Message(checktest in(AAA), (checktest != "dummy") == "false")
> ...
> i.e. double quotation of value ("AAA") specified in the cell is removed.
>
> If D column does not exist like Sample.xml(also included in reproducer) or D column is modified like SampleOK.xml, this does not happen.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7079) Further optimize size of fine session attribute names cache entry
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7079:
----------------------------------
Summary: Further optimize size of fine session attribute names cache entry
Key: WFLY-7079
URL: https://issues.jboss.org/browse/WFLY-7079
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 11.0.0.Alpha1
1. Marshalling of AtomicInteger writes an unnecessary class descriptor, as no externalizer exists
2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7078) Further optimize size of fine session attribute names cache entry
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7078?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-7078:
-------------------------------
Description:
1. Marshalling of AtomicInteger writes an unnecessary class descriptor, as no externalizer exists
2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE
was:
1. Marshalling of AtomicInteger writes an unnecessary class descriptor
2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE
> Further optimize size of fine session attribute names cache entry
> -----------------------------------------------------------------
>
> Key: WFLY-7078
> URL: https://issues.jboss.org/browse/WFLY-7078
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Alpha1
>
>
> 1. Marshalling of AtomicInteger writes an unnecessary class descriptor, as no externalizer exists
> 2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7078) Further optimize size of fine session attribute names cache entry
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7078:
----------------------------------
Summary: Further optimize size of fine session attribute names cache entry
Key: WFLY-7078
URL: https://issues.jboss.org/browse/WFLY-7078
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 11.0.0.Alpha1
1. Marshalling of AtomicInteger writes an unnecessary class descriptor
2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ]
Shigeru Chiba edited comment on JASSIST-263 at 9/8/16 3:04 PM:
---------------------------------------------------------------
That is right behavior. First of all, BuildingClassLoader does not keep a given class file by defineClass(). So returning no URL is correct behavior. To address this, ClassPool should keep it for further accesses but your implementation creates a new instance of ClassPool, which does not remember a class file generated before, whenever {{findClass}} is invoked.
A quick fix is to make {{pool}} be a field in {{BuildClassLoader}}.
was (Author: chiba):
That is right behavior. First of all, BuildingClassLoader does not keep a given class file by defineClass(). So returning no URL is correct behavior. To address this, ClassPool should keep it for further accesses but your implementation creates a new instance of ClassPool, which does not remember a class file generated before.
A quick fix is to make {{pool}} be a field in {{BuildClassLoader}}.
> ClassPool cannot read generated classes
> ---------------------------------------
>
> Key: JASSIST-263
> URL: https://issues.jboss.org/browse/JASSIST-263
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Reporter: Paul Pogonyshev
> Assignee: Shigeru Chiba
> Attachments: JavassistBug.java
>
>
> ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example.
> As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-263:
---------------------------------------
That is right behavior. First of all, BuildingClassLoader does not keep a given class file by defineClass(). So returning no URL is correct behavior. To address this, ClassPool should keep it for further accesses but your implementation creates a new instance of ClassPool, which does not remember a class file generated before.
A quick fix is to make {{pool}} be a field in {{BuildClassLoader}}.
> ClassPool cannot read generated classes
> ---------------------------------------
>
> Key: JASSIST-263
> URL: https://issues.jboss.org/browse/JASSIST-263
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Reporter: Paul Pogonyshev
> Assignee: Shigeru Chiba
> Attachments: JavassistBug.java
>
>
> ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example.
> As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months