March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-54) Automation SWS-QE: Implement SWS REST API Client

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-54?page=com.atlassian.jira.plugin.s... ] Hayk Hovsepyan updated SWSQE-54: -------------------------------- Sprint: SWS QE Sprint 2 > Automation SWS-QE: Implement SWS REST API Client > ------------------------------------------------ > > Key: SWSQE-54 > URL: https://issues.jboss.org/browse/SWSQE-54 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-54) Automation SWS-QE: Implement SWS REST API Client

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-54: ----------------------------------- Summary: Automation SWS-QE: Implement SWS REST API Client Key: SWSQE-54 URL: https://issues.jboss.org/browse/SWSQE-54 Project: Swift Sunshine QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2352) Executable model test coverage: run the optaplanner turtleTests with the executable model turned on and see if it survives the ordeal

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2352?page=com.atlassian.jira.plugi... ] Tibor Zimányi commented on DROOLS-2352: --------------------------------------- Linking a bug on which the tests fail. > Executable model test coverage: run the optaplanner turtleTests with the executable model turned on and see if it survives the ordeal > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2352 > URL: https://issues.jboss.org/browse/DROOLS-2352 > Project: Drools > Issue Type: Task > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Tibor Zimányi > > For now, we're looking for a one time test. Later I presume the exe model will be come the default, so these tests would just run? > To run the optaplanner turtle tests, run all tests in optaplanner-examples with the VM parameter `-DrunTurtleTests=true`. They take 48 hours to run. You can also just run one, for example NurseRosteringSolveAllTurtleTest, but don't forget that VM parameter. > Mario Fusco says you can do this to turn on the executable model: > {code} > kieBuilder.buildAll( ExecutableModelProject.class ); > {code} > I presume you 'd need to hack that in `ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory()`. > Note: I have no idea if this even make sense: those turtle tests use a drl file input and don't use the kie-maven-plugin. We're looking for a switch to just turn it on and see if they are all still green. Mario thinks it's possible, if I understand it correctly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9960) Remove SLF4J dependency from Hibernate Validator module

by Guillaume Smet (JIRA)

[ https://issues.jboss.org/browse/WFLY-9960?page=com.atlassian.jira.plugin.... ] Guillaume Smet updated WFLY-9960: --------------------------------- Summary: Remove SLF4J dependency from Hibernate Validator module (was: Remove SLF4J depedency from Hibernate Validator module) > Remove SLF4J dependency from Hibernate Validator module > ------------------------------------------------------- > > Key: WFLY-9960 > URL: https://issues.jboss.org/browse/WFLY-9960 > Project: WildFly > Issue Type: Enhancement > Reporter: Guillaume Smet > Assignee: Guillaume Smet > Priority: Trivial > Fix For: 13.0.0.Beta1 > > > As discussed on HipChat the other day, Hibernate Validator is using JBoss Logging exclusively for a while so the SLF4J dependency can be removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2367) Executable model - Drools context (kcontext) doesn't work when used together with a global

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-2367: ------------------------------------- Summary: Executable model - Drools context (kcontext) doesn't work when used together with a global Key: DROOLS-2367 URL: https://issues.jboss.org/browse/DROOLS-2367 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.6.0.Final Reporter: Tibor Zimányi Assignee: Mario Fusco When using kcontext on RHS of a rule together with a global, the consequence lambda is incorrectly generated which leads to this error [1]. This heviour can be reproduced by copypasting this test [2] into CompilerTest class from modelcompiler package. [1] https://gist.github.com/baldimir/8b4f494a42a0cbed3e6b191e85774cb4 [2] https://gist.github.com/baldimir/94ef23595574d7cdcbb500d0e97059ed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9960) Remove SLF4J depedency from Hibernate Validator module

by Guillaume Smet (JIRA)

Guillaume Smet created WFLY-9960: ------------------------------------ Summary: Remove SLF4J depedency from Hibernate Validator module Key: WFLY-9960 URL: https://issues.jboss.org/browse/WFLY-9960 Project: WildFly Issue Type: Enhancement Reporter: Guillaume Smet Assignee: Guillaume Smet Priority: Trivial Fix For: 13.0.0.Beta1 As discussed on HipChat the other day, Hibernate Validator is using JBoss Logging exclusively for a while so the SLF4J dependency can be removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9943) Sometimes WF process does not exit on RHEL 6 (32/64 bit) and IBM JDK 8

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-9943?page=com.atlassian.jira.plugin.... ] Miroslav Novak commented on WFLY-9943: -------------------------------------- [~kabirkhan] This one seems to IBM SDK 8 issue on RHEL 6. Is there a way to report this to IBM? > Sometimes WF process does not exit on RHEL 6 (32/64 bit) and IBM JDK 8 > ---------------------------------------------------------------------- > > Key: WFLY-9943 > URL: https://issues.jboss.org/browse/WFLY-9943 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 12.0.0.Final > Environment: RHEL 6 32/64 bit > IBM SDK 8.0.5.10: > {code}java version "1.8.0_161 > Java(TM) SE Runtime Environment (build 8.0.5.10 - pxi3280sr5fp10-20180214_01(SR5 FP10)) > IBM J9 VM (build 2.9, JRE 1.8.0 Linux x86-32 20180208_378436 (JIT enabled, AOT enabled) > OpenJ9 - 39bb844 > OMR - c04ccb2 > IBM - 2321a81) > JCL - 20180209_01 based on Oracle jdk8u161-b12 > {code} > Reporter: Miroslav Novak > Assignee: Jason Greene > Attachments: pstack.txt > > > Sometimes happens that WF12 process does not exit when :shutdown CLI operation called and hangs indefinitely. This happens only RHEL 6 (32/64 bit) with IBM SDK8. > Calling kill -3 does not create any javacore dump and only output could be gathered from pstack (attached). It indicates that JVM shutdown thread is hanging on: > {code} > Thread 25 (Thread 0xb7792b70 (LWP 25507)): > #0 0x00bd4424 in __kernel_vsyscall () > #1 0x00b2243c in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib/libpthread.so.0 > #2 0x004f8b1f in monitor_wait_original () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9thr29.so > #3 0x004f9957 in omrthread_monitor_wait () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9thr29.so > #4 0x0033e217 in protectedDestroyJavaVM () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9vm29.so > #5 0x0042cf6e in omrsig_protect () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9prt29.so > #6 0x0033db93 in DestroyJavaVM () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9vm29.so > #7 0x00815999 in DestroyJavaVM () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libjvm.so > #8 0x00528649 in JavaMain () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/bin/../lib/i386/jli/libjli.so > #9 0x00b1ebc9 in start_thread () from /lib/libpthread.so.0 > #10 0x001fc04e in clone () from /lib/libc.so.6 > {code} > There are other 24 threads which might be blocking this thread or a dead lock. This appears to be problem in IBM SDK 8 in combination RHEL 6 GLIBC_2.3.2 library. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9081) Support ServletContainerInitializer placed on WARs

by cnsgithub cnsgithub (JIRA)

[ https://issues.jboss.org/browse/WFLY-9081?page=com.atlassian.jira.plugin.... ] cnsgithub cnsgithub edited comment on WFLY-9081 at 3/6/18 4:14 AM: ------------------------------------------------------------------- I think something related to this, broke something with WF12 when using Spring. Currently i can't provide a *.war to test but a class residing in the *.war classes path is no longer recognized. (Addition: It seems to happen only if the *.war is residing inside an *.ear) import org.springframework.web.WebApplicationInitializer; public class MyWebApplicationInitializer implements WebApplicationInitializer [0m[0m09:52:16,244 INFO [io.undertow.servlet] (ServerService Thread Pool -- 51) No Spring WebApplicationInitializer types detected on classpath org.springframework.web.SpringServletContainerInitializer @Override public void onStartup(@Nullable Set<Class<?>> webAppInitializerClasses, ServletContext servletContext) ->> WebAppInitializerClasses does not contain the MyWebApplicationInitializer anymore Ultimately this call is coming from: WarMetaDataProcessor I hope this is enough to find the cause of this. The same configuration worked fine with WF11 Final. was (Author: pcom.progweb): I think something related to this, broke something with WF12 when using Spring. Currently i can't provide a *.war to test but a class residing in the *.war classes path is no longer recognized. import org.springframework.web.WebApplicationInitializer; public class MyWebApplicationInitializer implements WebApplicationInitializer [0m[0m09:52:16,244 INFO [io.undertow.servlet] (ServerService Thread Pool -- 51) No Spring WebApplicationInitializer types detected on classpath org.springframework.web.SpringServletContainerInitializer @Override public void onStartup(@Nullable Set<Class<?>> webAppInitializerClasses, ServletContext servletContext) ->> WebAppInitializerClasses does not contain the MyWebApplicationInitializer anymore Ultimately this call is coming from: WarMetaDataProcessor I hope this is enough to find the cause of this. The same configuration worked fine with WF11 Final. > Support ServletContainerInitializer placed on WARs > -------------------------------------------------- > > Key: WFLY-9081 > URL: https://issues.jboss.org/browse/WFLY-9081 > Project: WildFly > Issue Type: Feature Request > Reporter: Guillermo González de Agüero > Assignee: Stuart Douglas > Fix For: 12.0.0.Beta1, 12.0.0.Final > > > The Servlet spec only talks about the presence of ServletContainerInitializer's within JAR files bundled on the WAR. It says nothing about what to do when found on the WAR and Undertow is ignored them right now, which is spec complaint. > However, WildFly has the only Servlet container I'm aware of that ignores that classes, having tested Payara, WebLogic,WebSphere Liberty, Jetty, Tomcat and Resin. > It would be good to support them on Undertow too. > I've also opened an issue on the Servlet spec repository, so this can be clarified for future versions of the document: https://github.com/javaee/servlet-spec/issues/179 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9959) Version in welcome page is not correct

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9959?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9959: ------------------------------ Component/s: Build System > Version in welcome page is not correct > -------------------------------------- > > Key: WFLY-9959 > URL: https://issues.jboss.org/browse/WFLY-9959 > Project: WildFly > Issue Type: Task > Components: Build System > Affects Versions: 12.0.0.Final > Reporter: Tomaz Cerar > Assignee: Jason Greene > > It still says 11. > We should probably have it expanded to version of server at build time. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9959) Version in welcome page is not correct

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-9959: --------------------------------- Summary: Version in welcome page is not correct Key: WFLY-9959 URL: https://issues.jboss.org/browse/WFLY-9959 Project: WildFly Issue Type: Task Reporter: Tomaz Cerar Assignee: Jason Greene It still says 11. We should probably have it expanded to version of server at build time. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2018