[JBoss JIRA] (WFWIP-3) Enhance Search to support OR for parallel tasks
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-3?page=com.atlassian.jira.plugin.sy... ]
Rostislav Svoboda reassigned WFWIP-3:
-------------------------------------
Assignee: Kabir Khan
> Enhance Search to support OR for parallel tasks
> -----------------------------------------------
>
> Key: WFWIP-3
> URL: https://issues.jboss.org/browse/WFWIP-3
> Project: WildFly WIP
> Issue Type: Feature Request
> Components: Overbård
> Reporter: Rostislav Svoboda
> Assignee: Kabir Khan
>
> Enhance Search to support OR for parallel tasks
> My motivation for this to find all Items which have incomplete Test Dev or incomplete Pre-Check. I don't want to check 2 queries, I'd love to have just one.
> Currently only AND notion is supported
> *Test Dev (TD)*
> (/) TODO
> (/) In Progress
> (/) Review
> (x) Done
> *Pre-Checked (PC)*
> (/) TODO
> (/) In Progress
> (x) Done
> Some items can have TD done and not PC done, some Items can have PC done manually and just TD is stuck. This is the use case for OR notion in search.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFWIP-3) Enhance Search to support OR for parallel tasks
by Rostislav Svoboda (JIRA)
Rostislav Svoboda created WFWIP-3:
-------------------------------------
Summary: Enhance Search to support OR for parallel tasks
Key: WFWIP-3
URL: https://issues.jboss.org/browse/WFWIP-3
Project: WildFly WIP
Issue Type: Feature Request
Components: Overbård
Reporter: Rostislav Svoboda
Enhance Search to support OR for parallel tasks
My motivation for this to find all Items which have incomplete Test Dev or incomplete Pre-Check. I don't want to check 2 queries, I'd love to have just one.
Currently only AND notion is supported
*Test Dev (TD)*
(/) TODO
(/) In Progress
(/) Review
(x) Done
*Pre-Checked (PC)*
(/) TODO
(/) In Progress
(x) Done
Some items can have TD done and not PC done, some Items can have PC done manually and just TD is stuck. This is the use case for OR notion in search.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10229) org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-10229?page=com.atlassian.jira.plugin... ]
Tom Jenkinson commented on WFLY-10229:
--------------------------------------
I don't understand why ContextTransactionManager is reporting it is rolled back if Narayana thinks it is only marked rollback - but perhaps that was explained on the private thread?
Regarding sending the private email thread, I think if there is still any ambiguity then it would be better to create a thread on wildfly-dev (with any sensitive information removed) such that a pipermail link (http://lists.jboss.org/pipermail/wildfly-dev/) can be provided to this issue and others can contribute.
> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10229
> URL: https://issues.jboss.org/browse/WFLY-10229
> Project: WildFly
> Issue Type: Task
> Components: Transactions
> Reporter: Scott Marlow
> Assignee: David Lloyd
> Fix For: 13.0.0.Beta1
>
>
> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() is currently using com.arjuna.ats.jta.TransactionManager, instead it should use org.wildfly.transaction.client.ContextTransactionManager.getStatus().
> I'm seeing a case in Hibernate ORM 5.3, where org.wildfly.transaction.client.ContextTransactionManager.getStatus() returns 4 but TransactionSynchronizationRegistryWrapper.getStatus() returns 1.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (ELY-1480) Coverity, Explicit null dereferenced in FileSystemSecurityRealm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1480?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1480:
---------------------------------
+1 algorithm should be required for {{<password>}}
> Coverity, Explicit null dereferenced in FileSystemSecurityRealm
> ---------------------------------------------------------------
>
> Key: ELY-1480
> URL: https://issues.jboss.org/browse/ELY-1480
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.2.0.Beta11
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> There are 2 occurences of call to PasswordFactory.getInstance(algorithm) in FileSystemSecurityRealm where algorithm can be null, because algorithm is optional in wildfly-config.xml
> {code:xml|title=elytron-1_0_1.xsd}
> <xsd:complexType name="credential-type">
> <xsd:simpleContent>
> <xsd:extension base="xsd:string">
> <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
> <xsd:attribute name="format" type="xsd:string" use="optional"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> <xsd:complexType name="otp-credential-type">
> <xsd:simpleContent>
> <xsd:extension base="xsd:string">
> <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
> <xsd:attribute name="hash" type="xsd:string" use="optional"/>
> <xsd:attribute name="seed" type="xsd:string" use="optional"/>
> <xsd:attribute name="sequence" type="xsd:string" use="optional"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> {code}
> Algorithm is dereferenced in PasswordFactory.getInstance(algorithm) down in
> {code:java|title=java.security.Provider$ServiceKey.java}
> private ServiceKey(String type, String algorithm, boolean intern) {
> this.type = type;
> this.originalAlgorithm = algorithm;
> algorithm = algorithm.toUpperCase(ENGLISH);
> this.algorithm = intern ? algorithm.intern() : algorithm;
> }
> {code}
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847...
> [2] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10197) AuthenticationPolicyContextTestCase fails under a security manager
by Martin Stefanko (JIRA)
[ https://issues.jboss.org/browse/WFLY-10197?page=com.atlassian.jira.plugin... ]
Martin Stefanko reassigned WFLY-10197:
--------------------------------------
Assignee: Martin Stefanko (was: Alessio Soldano)
> AuthenticationPolicyContextTestCase fails under a security manager
> ------------------------------------------------------------------
>
> Key: WFLY-10197
> URL: https://issues.jboss.org/browse/WFLY-10197
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web Services
> Reporter: David Lloyd
> Assignee: Martin Stefanko
>
> Stack trace:
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "getPolicy")" in code source "(vfs:/content/picketlink-sts-ws.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.picketlink-sts-ws.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:99)
> at org.jboss.as.test.integration.ws.authentication.policy.resources.EchoService.echo(EchoService.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
> ... 103 more
> {noformat}
> I think the {{EchoService}} deployment needs the {{getPolicy}} permission in order to complete its task.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (ELY-1480) Coverity, Explicit null dereferenced in FileSystemSecurityRealm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1480?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1480:
----------------------------
Component/s: Realms
(was: Authentication Client)
> Coverity, Explicit null dereferenced in FileSystemSecurityRealm
> ---------------------------------------------------------------
>
> Key: ELY-1480
> URL: https://issues.jboss.org/browse/ELY-1480
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.2.0.Beta11
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> There are 2 occurences of call to PasswordFactory.getInstance(algorithm) in FileSystemSecurityRealm where algorithm can be null, because algorithm is optional in wildfly-config.xml
> {code:xml|title=elytron-1_0_1.xsd}
> <xsd:complexType name="credential-type">
> <xsd:simpleContent>
> <xsd:extension base="xsd:string">
> <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
> <xsd:attribute name="format" type="xsd:string" use="optional"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> <xsd:complexType name="otp-credential-type">
> <xsd:simpleContent>
> <xsd:extension base="xsd:string">
> <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
> <xsd:attribute name="hash" type="xsd:string" use="optional"/>
> <xsd:attribute name="seed" type="xsd:string" use="optional"/>
> <xsd:attribute name="sequence" type="xsd:string" use="optional"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> {code}
> Algorithm is dereferenced in PasswordFactory.getInstance(algorithm) down in
> {code:java|title=java.security.Provider$ServiceKey.java}
> private ServiceKey(String type, String algorithm, boolean intern) {
> this.type = type;
> this.originalAlgorithm = algorithm;
> algorithm = algorithm.toUpperCase(ENGLISH);
> this.algorithm = intern ? algorithm.intern() : algorithm;
> }
> {code}
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847...
> [2] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10101) [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10101?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-10101:
---------------------------------------
I've started soak over weekend on the workstation with enabled traces and there was no crash of any server this time. I'll re-execute it again with traces. It's possible that enabled traces might influence this.
> [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
> --------------------------------------------------------------
>
> Key: WFLY-10101
> URL: https://issues.jboss.org/browse/WFLY-10101
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
>
> After ~13 hours there is unexpected crash of one server in SOAK test. There is no error/warning in the logs.
> Test Scenario:
> * Start 2 servers
> * Client sends messages to input queue. Messages then go through:
> * One server to another through MDB reading and sending them from remote container through resource adapter
> * Messages are forwarded from one server to another over JMS bridge and back over Core bridge
> * Messages have JMSReplyTo defined with a temporary queue, that is filled with responses for the client
> * Messages are read from the destination with stateless EJB and sent back to clients
> * Client reads the messages after the pass through all the soak modules.
> Pass Criteria: In the last step receiver consumes all messages sent by producer.
> Actual Result:
> After ~13 hours 1st server suddenly crashes. There is no error/warning in server logs.
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10238) Wsprovide tool doesn't generate/keep class files on JDK10
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-10238?page=com.atlassian.jira.plugin... ]
Marek Kopecký commented on WFLY-10238:
--------------------------------------
Btw, I this issue is valid on both RHEL and Windows OS
> Wsprovide tool doesn't generate/keep class files on JDK10
> ---------------------------------------------------------
>
> Key: WFLY-10238
> URL: https://issues.jboss.org/browse/WFLY-10238
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Marek Kopecký
> Assignee: R Searls
> Priority: Blocker
> Fix For: 13.0.0.Beta1
>
> Attachments: classes.zip
>
>
> Wsprovide tool doesn't keep class files on JDK10
> Example:
> {noformat}
> [mkopecky@localhost bin]$ jdk8
> [mkopecky@localhost bin]$ java -version
> java version "1.8.0_111"
> Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
> [mkopecky@localhost bin]$ ./wsprovide.sh -k -c ~/erase10/classes -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> java2ws -s /home/mkopecky/playground/wf/wfly.22/wfly.22/bin/out -classdir /home/mkopecky/playground/wf/wfly.22/wfly.22/bin/out -d /home/mkopecky/playground/wf/wfly.22/wfly.22/bin/out -verbose -cp /home/mkopecky/erase10/classes/: -wrapperbean -createxsdimports org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> java2ws - Apache CXF 3.2.4
> [mkopecky@localhost bin]$ find out/ | grep class
> out/org/jboss/as/testsuite/integration/scripts/test/tools/jaxws/EchoPlus1.class
> out/org/jboss/as/testsuite/integration/scripts/test/tools/jaxws/EchoPlus1Response.class
> [mkopecky@localhost bin]$ jdk10
> [mkopecky@localhost bin]$ rm -rf out
> [mkopecky@localhost bin]$ java -version
> java version "10" 2018-03-20
> Java(TM) SE Runtime Environment 18.3 (build 10+46)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)
> [mkopecky@localhost bin]$ ./wsprovide.sh -k -c ~/erase10/classes -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> java2ws -s /home/mkopecky/playground/wf/wfly.22/wfly.22/bin/out -classdir /home/mkopecky/playground/wf/wfly.22/wfly.22/bin/out -d /home/mkopecky/playground/wf/wfly.22/wfly.22/bin/out -verbose -cp /home/mkopecky/erase10/classes/: -wrapperbean -createxsdimports org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> java2ws - Apache CXF 3.2.4
> [mkopecky@localhost bin]$ find out/ | grep class
> [mkopecky@localhost bin]$
> {noformat}
> I attached input class files. I see this issue on WF with latest WS.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months