[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 Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7075:
------------------------------------
FYI [https://java.net/projects/jpa-spec/lists/users/archive/2016-09/message/1] asks if [https://java.net/jira/browse/JPA_SPEC-6] should be reconsidered for the next JPA release.
> 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
> Fix For: 11.0.0.Alpha1
>
> 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-7194) Simplify creation of trust/key-manager in elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7194?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7194:
----------------------------------
*Part 1* was rejected. JVM default is not recommended because not portable between JVMs. Change of attribute to required would broke back compatibility. JVM default can be allowed as special value "Default" => https://github.com/wildfly-security/elytron-subsystem/issues/235
> Simplify creation of trust/key-manager in elytron
> -------------------------------------------------
>
> Key: WFLY-7194
> URL: https://issues.jboss.org/browse/WFLY-7194
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> If I want to setup TLS [1], I have to create key manager with CLI command
> {code}
> /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509")
> {code}
> 1. It seems to me {{algorithm}} can be optional. If not set {{TrustManagerFactory.getDefaultAlgorithm()}} can be used.
> 2. Also, please, enhance xsd/model documentation with clear statement that this {{password}} attribute is in fact "key password" . Or probably better rename attribute from {{password}} to {{key-password}} to make it absolutely clear to everyone.
> 3. {{key-store}} attribute is declared optional in xsd . In model it is properly declared as required. Please change XSD to express it is required.
> {code}
> <xs:attribute name="key-store" type="xs:string" use="optional">
> <xs:annotation>
> <xs:documentation>
> Reference to the KeyStore to use with the KeyManager.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
> 4.{{password}} attribute is optional, probably should be required
> {code}
> "password" => {
> "type" => STRING,
> "description" => "The password to use when initialising the underlying KeyManagerFactory.",
> "expressions-allowed" => true,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "deprecated" => {
> "since" => "1.0.0",
> "reason" => "Will be updated to use proper CredentialStore references."
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {code}
> [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7196) The outcome of xa_commit call on non exiting transaction is silently ignored
by Tom Ross (JIRA)
Tom Ross created WFLY-7196:
------------------------------
Summary: The outcome of xa_commit call on non exiting transaction is silently ignored
Key: WFLY-7196
URL: https://issues.jboss.org/browse/WFLY-7196
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Reporter: Tom Ross
This from mail thread on transactional mailing list:
{noformat}
There is definitely a bug in EJBR.
These two at least look wrong by inspection:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it.
You could simulate this with a test case that gets hold of the EJBR XAResource and invokes:
xar.prepare(dummyXid) and does not get back XAER_NOTA
That explains how the root transaction can prepare/commit without error as we can see here:
2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions.
What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue.
What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently.
After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7196) The outcome of xa_commit call on non exiting transaction is silently ignored
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/WFLY-7196?page=com.atlassian.jira.plugin.... ]
Tom Ross updated WFLY-7196:
---------------------------
Description:
This is from mail thread on transactional mailing list:
{noformat}
There is definitely a bug in EJBR.
These two at least look wrong by inspection:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it.
You could simulate this with a test case that gets hold of the EJBR XAResource and invokes:
xar.prepare(dummyXid) and does not get back XAER_NOTA
That explains how the root transaction can prepare/commit without error as we can see here:
2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions.
What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue.
What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently.
After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that.
{noformat}
was:
This from mail thread on transactional mailing list:
{noformat}
There is definitely a bug in EJBR.
These two at least look wrong by inspection:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it.
You could simulate this with a test case that gets hold of the EJBR XAResource and invokes:
xar.prepare(dummyXid) and does not get back XAER_NOTA
That explains how the root transaction can prepare/commit without error as we can see here:
2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions.
What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue.
What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently.
After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that.
{noformat}
> The outcome of xa_commit call on non exiting transaction is silently ignored
> ----------------------------------------------------------------------------
>
> Key: WFLY-7196
> URL: https://issues.jboss.org/browse/WFLY-7196
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Tom Ross
>
> This is from mail thread on transactional mailing list:
> {noformat}
> There is definitely a bug in EJBR.
> These two at least look wrong by inspection:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
> The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it.
> You could simulate this with a test case that gets hold of the EJBR XAResource and invokes:
> xar.prepare(dummyXid) and does not get back XAER_NOTA
> That explains how the root transaction can prepare/commit without error as we can see here:
> 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
> 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
> Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions.
> What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue.
> What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently.
> After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7195) Transaction context should not be propagated when calling remote server asynchronously
by Tom Ross (JIRA)
Tom Ross created WFLY-7195:
------------------------------
Summary: Transaction context should not be propagated when calling remote server asynchronously
Key: WFLY-7195
URL: https://issues.jboss.org/browse/WFLY-7195
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Environment: Wildfly 10.x
Reporter: Tom Ross
When an EJB call is made asynchronously between two JBoss servers the transaction context should not be propagated as per EJB spec.
{noformat}
EJB 3.2 4.5.3 Transactions
The client’s transaction context does not propagate with an asynchronous method invocation. From the
Bean Provider’s point of view, there is never a transaction context flowing in from the client. This
means, for example, that the semantics of the REQUIRED transaction attribute on an asynchronous
method are exactly the same as REQUIRES_NEW.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-987:
----------------------------------
Assignee: Mario Fusco (was: Maciej Swiderski)
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Mario Fusco
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7194) Simplify creation of trust/key-manager in elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7194?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved JBEAP-6159 to WFLY-7194:
-----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7194 (was: JBEAP-6159)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: (was: 7.1.0.DR4)
> Simplify creation of trust/key-manager in elytron
> -------------------------------------------------
>
> Key: WFLY-7194
> URL: https://issues.jboss.org/browse/WFLY-7194
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> If I want to setup TLS [1], I have to create key manager with CLI command
> {code}
> /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509")
> {code}
> 1. It seems to me {{algorithm}} can be optional. If not set {{TrustManagerFactory.getDefaultAlgorithm()}} can be used.
> 2. Also, please, enhance xsd/model documentation with clear statement that this {{password}} attribute is in fact "key password" . Or probably better rename attribute from {{password}} to {{key-password}} to make it absolutely clear to everyone.
> 3. {{key-store}} attribute is declared optional in xsd . In model it is properly declared as required. Please change XSD to express it is required.
> {code}
> <xs:attribute name="key-store" type="xs:string" use="optional">
> <xs:annotation>
> <xs:documentation>
> Reference to the KeyStore to use with the KeyManager.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
> 4.{{password}} attribute is optional, probably should be required
> {code}
> "password" => {
> "type" => STRING,
> "description" => "The password to use when initialising the underlying KeyManagerFactory.",
> "expressions-allowed" => true,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "deprecated" => {
> "since" => "1.0.0",
> "reason" => "Will be updated to use proper CredentialStore references."
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {code}
> [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-261:
--------------------------------------
[~sebersole] I think yes, part of the text from the linked [http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-June/000307...] proposal is quoted here, which I think is showing that the application developer changes their Hibernate applications to privately export these classes to Hibernate:
{quote}
Proposal
--------
Extend the language of module declarations so that a package can be
declared to be exported at run time but not at compile time. This is,
roughly, the dual of the `requires static` construct proposed for
#CompileTimeDependences, hence we propose to introduce a new modifier,
`dynamic`, for use on the `exports` directive. It has the following
meanings:
- At compile time, `exports dynamic P` does not cause the package `P`
to be exported, though it does require `P` to be a package defined
in the module.
- In phases after compile time, `exports dynamic P` behaves in exactly
the same way as `exports P`. It therefore takes part fully in
resolution and configuration, and is subject to the same consistency
constraints as normally-exported packages (e.g., no split packages).
Thus a module declaration of the form
module com.foo.app {
requires hibernate.core;
requires hibernate.entitymanager;
exports dynamic com.foo.app.model;
}
makes the types in the `com.foo.app.model` package accessible at run time
but not at compile time. In combination with the earlier change to
enable #ReflectionWithoutReadability [2] this means that frameworks that
today use core reflection to manipulate user classes at run time are more
likely to work out-of-the-box, without change, as automatic modules. If
the `com.foo.app.model` package in this example includes entity classes
to be managed by Hibernate then the framework will be able to access them
without further ado, but under normal circumstances an attempt to compile
code that refers directly to those classes will fail.
The `dynamic` modifier can be applied to both unqualified and qualified
`exports` directives, though the caveats on using qualified exports [3]
still apply.
{quote}
[https://java.net/projects/javaee-spec/lists/jsr366-experts/archive/2016-0...] is where I saw the (above mentioned) list of issues being discussed.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1730) Singleton service is not correctly being set in WILDFLY
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1730?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1730:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1367793|https://bugzilla.redhat.com/show_bug.cgi?id=1367793] from MODIFIED to ON_QA
> Singleton service is not correctly being set in WILDFLY
> -------------------------------------------------------
>
> Key: WFCORE-1730
> URL: https://issues.jboss.org/browse/WFCORE-1730
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 3.0.0.Alpha5
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
>
> WILDFLY doesn't call ServiceLoader (META-INF/services/org.jboss.msc.service.ServiceActivator) when it is deployed in EAR/lib. The SingletonService (not a singleton EJB) is activated in the ServiceLoader so the SingletonService hasn't been activated from the first. It works as expected when deployed as an EJB (not in EAR/lib).
> When the ServiceLoader is called, a message of "HATimerService will be installed!" is logged and the SingletonService will be activated.
> $ fgrep -e HATimerService -e '[org.jboss.as.clustering.singleton]' domain/servers/server-one/log/server.log
> 12:14:52,373 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator] (MSC service thread 1-7) HATimerService will be installed!
> 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service
> 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010340: This node will now operate as the singleton provider of the jboss.quickstart.ha.singleton.timer service
> 12:14:56,268 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerService] (MSC service thread 1-8) Start HASingleton timer service 'org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATim
> erService'
> 12:14:56,873 INFO [org.jboss.as.clustering.singleton] (notification-thread-0) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months