[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
[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
[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
[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